agentleFS
ali-sheibaali-sheiba/development-workflow/skills/finishing-development/SKILL.md

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.

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
  1. Very specific:

    Read PLAN.md, PROGRESS.md, and the Git history.

    line 13
  2. Distinctive:

    No requirement changed without re-approval, and no blocking finding is open.

    line 17
  3. Very specific:

    Run every command in the plan's verification table, plus the project's full spec and lint commands, once against the branch head.

    line 22
  4. Very specific:

    If either review is CHANGES_REQUIRED:

    line 43
  5. Distinctive:

    Commit the fix as one new commit.

    line 48
  6. Distinctive:

    When verification and both reviews pass, report the result and offer only what the project supports:

    line 56
  7. Distinctive:

    keep the branch for later.

    line 61
  8. Very specific:

    Do not choose for the user.

    line 64

≈ “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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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

  1. Read PLAN.md, PROGRESS.md, and the Git history. Every unit is complete with its commit on the branch.
  2. The branch diff from the recorded base holds nothing missing, unplanned, or uncommitted.
  3. No requirement changed without re-approval, and no blocking finding is open.
  4. Set Phase: finishing in PROGRESS.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:

  1. 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.
  2. Commit the fix as one new commit.
  3. 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.

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.