engineering-plan
Skill6 starsChanged 18 days agoMITView on GitHub
Define an engineering change or experiment before implementation, with observable acceptance criteria and proportionate validation. Use for substantial changes, migrations, benchmarks or ambiguous requirements; keep routine fixes lightweight.
In this repository10 other files it gives its agents.
- AGENTS.mdAGENTS.md
- claim-ledgerSkill
- critic-reviewSkill
- distributed-orchestrationSkill
- engineering-governanceSkill
- execution-integritySkill
- literature-provenanceSkill
- multi-agent-collaborationSkill
- technical-writingSkill
- worker-taskSkill
The file
We split this skill into the rules it gives an agent
1 rule. About 0 are common, 1 is distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈1
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 6
Read relevant code, tests and project constraints.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Read relevant code, tests and project constraints. State the problem, desired behavior, affected interfaces and out-of-scope work. Resolve facts from artifacts; batch unresolved questions that materially affect the outcome, with recommended choices. Continue independent work while awaiting an answer.
Define observable pass/fail criteria and how to exercise them. Match validation to risk: a bug may need a reproducer and regression check; a migration may need compatibility checks and rollback. Settle critical assumptions before high-cost or irreversible work. Do not impose design approval when the user's instruction already authorizes the change.
For experiments or performance claims, record the hypothesis, primary metric, baseline, workload, seeds or sampling, resource budget, failure accounting and success threshold before inspecting results. Compare arms with equivalent effort. Separate exploratory observations from confirmatory results; label post-result changes and never apply a new rule retroactively.
For a registered production run, commit the executable decision evaluator, fixed acceptance contract, complete declared adapters/dependencies and meaningful boundary/negative tests before generating the registered result. Run and review those tests, anchor the receipt through the trusted pre-run approval, and bind the workload IDs and binary schema. The toolkit's optional preregister.py implements file/commit checks and a consumed-registration ledger; review its deployment trust boundary rather than treating local timestamps as proof. A failed criterion must stay NOT SHOWN; any approved new attempt names its parent and reason prospectively.
For long jobs, exercise the launch and a small representative unit first. Record resource limits, output paths and actual resume behavior. Use only dry-run interfaces the command really supports. Launch through the host's authorized background facility; do not keep a model session waiting for hours.
When the project adopts Milestone Mode, batch C/V checks at Pilot Readout, Pre-Main Launch and CLAIMS Entry. Freeze one evidence packet per gate and route it through an authorized scheduler receipt; routine progress is not a reason for a model wake. Record node capability/entitlement preflight and a migration plan before assigning expensive work. If scope, governing assumptions or budget need a top-level choice, block with owner H. Preserve H's trusted decision reference and label any amendment or waiver; do not retroactively relabel observed failure as a passed registered test.
Assess outputs using the original criteria. Preserve failed cases, skipped work and negative results. Have important conclusions reviewed or independently verified when warranted. Record decisions and limits in the project's evidence ledger, then report what was established.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

