forge-simplify
Skill13 starsChanged 44 days agoMITView on GitHub
Simplify a bounded candidate without changing accepted behavior, then run affected proof and independent Review when it changes. Use for "Forge simplify", an explicit bounded simplification request through Forge, or the authorized post-Review delivery phase. Direct Simplify stops at its result and never starts QA or Ship.
In this repository9 other files it gives its agents.
- AGENTS.mdAGENTS.md
- forge-buildSkill
- forge-code-reviewSkill
- forge-planSkill
- forge-reviewSkill
- forge-shipSkill
- forgeSkill
- forge-specSkill
- forge-verifySkill
The file
We split this skill into the rules it gives an agent
3 rules. About 0 are common, 2 are distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈2
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 10
Run only when explicitly invoked through Forge, selected by the caller, or reached by an authorized delivery after Build and independent …
- Distinctive: line 33
Follow the owning procedure.
- Distinctive: line 48
Use the simplification record guidance in the existing log.
≈ “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
Forge Simplify
<skill name="forge-simplify">
<activation>
Run only when explicitly invoked through Forge, selected by the caller, or reached
by an authorized delivery after Build and independent Review pass. Direct Build
or Review alone does not authorize this phase. Reuse accepted Launch and scope;
an installed skill name does not prove native slash-command support.
</activation>
<setup>
Read [authority](../forge-shared/references/authority.md) and
[target harness resolution](../forge-shared/references/target-harness.md),
[Launch and gates](../forge-shared/references/workflows.md), and the target
repository's applicable harness. Adopt [Engineer](../../agents/engineer/instructions.md)
for behavior-preserving simplification. In delivery, this is a separate Engineer
assignment after the initial Build/Review loop, before QA.
</setup>
<workflow>
<step n="1" name="Bind scope and the actual baseline">
Identify accepted authority, requested scope and writes, exact candidate/base,
preservation scope, current proof, and any actual prior Review. Delivery requires
passing Build/Review before Simplify. A direct bounded Simplify request needs no
pre-edit Review PASS; inspect its actual baseline and follow the
[owning procedure](references/simplify.md). Never invent prior evidence or start a
broader delivery lifecycle.
</step>
<step n="2" name="Simplify and refresh affected evidence">
Follow the owning procedure. Return changes with affected proof or an evidenced
no-op. Before completing a changed operation, obtain independent
[Review](../forge-review/SKILL.md) bound to the resulting complete candidate. Use
delta Review and reuse unaffected evidence by reason when prior passing evidence
exists; without it, review the requested outcome and affected commitments without
claiming an earlier verdict. A no-op retains the same candidate and any actual
prior evidence, explicitly reporting missing prior Review.
</step>
<step n="3" name="Inspect and stop or hand off">
The accountable owner reads the actual return and relevant new log entries under
[shared returns](../forge-shared/references/returns.md). Delivery proceeds to QA
only with current passing Review; direct Simplify stops at its bounded result.
</step>
</workflow>
<output>
Use [the simplification record guidance](assets/simplify.md) in the existing log.
Report the actual baseline and prior Review presence/absence, inspected paths, changes or no-op basis, resulting
candidate, affected and reused proof, independent verdict, gaps, and boundary.
</output>
<checklist>
- Accepted scope, exact baseline, and actual prior Review presence/absence resolved.
- Separate delivery assignment follows passing Build/Review and precedes QA.
- Required behavior and harness preserved; no unrelated cleanup or new scope.
- Changed operation completes only with affected proof and independent Review bound to the whole result.
- No-op preserves the candidate and any actual prior evidence; missing prior Review remains explicit.
- Direct operation adds no pre-edit Review PASS gate and stops without QA or Ship.
</checklist>
</skill>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.