finishing-development
Skill1 starsChanged 21 days agoMITView on GitHub
Use after every plan unit is complete to verify the whole change once, run the problem and quality reviews in parallel, settle deferred findings under a two-round budget, and present integration choices. Units that each passed review can still break a requirement together.
In this repository10 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- brainstormingSkill
- development-workflowSkill
- exploringSkill
- requesting-reviewSkill
- systematic-debuggingSkill
- test-driven-developmentSkill
- writing-plansSkill
- writing-skillsSkill
The file
We split this skill into the rules it gives an agent
8 rules. About 0 are common, 4 are distinctive, and 4 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈4
Distinctive · estimate
This author's own choices. Worth a look.
4
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 13
Read PLAN.md, PROGRESS.md, and the Git history.
- Distinctive: line 17
No requirement changed without re-approval, and no blocking finding is open.
- Very specific: line 22
Run every command in the plan's verification table, plus the project's full spec and lint commands, once against the branch head.
- Very specific: line 43
If either review is CHANGES_REQUIRED:
- Distinctive: line 48
Commit the fix as one new commit.
- Distinctive: line 56
When verification and both reviews pass, report the result and offer only what the project supports:
- Distinctive: line 61
keep the branch for later.
- Very specific: line 64
Do not choose for the user.
≈ “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
Finishing Development
A whole-change gate, not a summary. Units that passed review one by one can still, together, miss the problem or break a rule.
1. Reconcile
- Read
PLAN.md,PROGRESS.md, and the Git history. Every unit iscompletewith its commit on the branch. - The branch diff from the recorded base holds nothing missing, unplanned, or uncommitted.
- No requirement changed without re-approval, and no blocking finding is open.
- Set
Phase: finishinginPROGRESS.md.
2. Verify once
Run every command in the plan's verification table, plus the project's full
spec and lint commands, once against the branch head. Read the whole
output. Save it as whole-verification.md in the workflow folder. This is the
evidence both reviewers read; they do not run anything.
A failure here goes to a fresh implementer as a fix brief, like a blocking finding.
3. Review in parallel
Dispatch two reviewers at the same time against
the branch head, per requesting-review:
- one applies the problem check to the whole plan;
- one applies the quality check to the whole diff.
Give both every unit's deferred Minor findings. Each one ends here: fixed in
the final fix, or accepted with a reason.
4. Fix, if needed
If either review is CHANGES_REQUIRED:
- Send all blocking findings, plus any cheap deferred Minor ones, to one fresh implementer. It fixes them, runs specs and lint once at the end, and records the output.
- Commit the fix as one new commit.
- Re-dispatch only the reviewer(s) that raised blocking findings, scoped to their findings and the fix diff.
Budget: two fix rounds. Then stop, report what is open, and ask the user.
5. Offer integration
When verification and both reviews pass, report the result and offer only what the project supports:
- merge into the base branch;
- open a pull request;
- keep the branch for later;
- discard the work.
Do not choose for the user. Discarding work or deleting a branch needs explicit
permission. Check the branch state again right before acting. Record the choice
in PROGRESS.md and set Phase: done. Keep the workflow folder until the user
asks to remove it.
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.

