agentleFS
alphazedealphazede/bearing-lite/skills/implementer/SKILL.md

implementer

Skill3 starsChanged 3 months agoApache-2.0View on GitHub

Implement one approved bounded packet in an exact write set. Continue the same-wave session when identity, authority, route, and generation are unchanged. Use for Implementer, Product Implementer, Test Implementer, implementation, repair, or integration packets. Do not use for orchestration, planning, independent assurance, publication, destructive action, owner decisions, or unset scope.

10 other projects use a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

4 rules. 0 are common, 2 are distinctive, and 2 are very specific to this project.

  • 0

    Common

    Most of the 10 edited versions we read keep these.

  • 2

    Distinctive

    This author's own choices. Worth a look.

  • 2

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    If it cannot continue, return WAITING_ON.

    line 30
  2. Distinctive:

    Test Implementer: author real-dependency tests, self-check their validity, and prove the expected baseline failure.

    line 40
  3. Very specific:

    Follow the red/repair/green ordering in references/tdd.md.

    line 43
  4. Distinctive:

    Never expand scope, self-certify as assurance, publish, or hide a failure.

    line 60

“Common” is measured: kept by at least 6 in 10 of the 10 edited versions of this file we could read. “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

Implementer

One profile-enabled assignment and invocation. Extra runs or route changes need authority.

Inputs and match

  • Inputs: approved baseline, objective, dependencies, exact write set, authority, acceptance/SEIT rows, commands, stop rule, compact return schema, visible wave receipt, and profile identity from the recorded Lifecycle snapshot.
  • Match: one packet is READY and every input is fixed.
  • Non-match: multi-packet coordination, design gaps, missing authority, assurance, or owner-only action.
  • Split: tdd orders Test Implementer before Product Implementer from the frozen snapshot. Test Implementer may change only tests and approved fixtures. Product Implementer write set excludes tests and must not weaken independently authored tests. Same-feature parallel is prohibited. single_implementer writes product plus tests. Neither self-certifies.
  • Repair: consume the frozen review receipt and exact write set under advance authority, or legacy parent-accepted REPAIR_REQUIRED: candidate ref/revision/digest, finding IDs, same worktree/branch/generation. Same-session reviewer repair needs no controller round-trip when preauthorized; never expand scope or reset allowance. Planning-artifact writes use repair_transition in .bearing-round.lock (../reviewer/references/repair-transition.md).

Algorithm

  1. Continue this assignment while identity, authority, route, and generation hold. If it cannot continue, return WAITING_ON; a new invocation needs explicit authority. Do not infer missing owner choices. Read dispatch identities only from the recorded Lifecycle snapshot, never from the current global defaults file. Revalidate the visible checkout lease against the approved Lifecycle, repository, checkout/worktree, branch, candidate revision, generation, and active state at wave start, after detected drift, and before commit. Released, stale-generation, forged, or branch/HEAD-drifted leases fail closed. Authorized same-Lifecycle candidate progress whose parent is the current leased revision refreshes candidate_revision on the same generation. On mismatch, return WAITING_ON without writing.
  2. Test Implementer: author real-dependency tests, self-check their validity, and prove the expected baseline failure. Repair test defects in this assignment. For a verified contract defect, establish the smallest failing regression first. Follow the red/repair/green ordering in references/tdd.md.
  3. Make the smallest change that satisfies the packet inside the write set. For a published standard, verify its cited document and clause before changing code; neighbouring behavior is not the authority. When the packet carries a design lens, follow its rows per ../planning-and-design/references/oopdsa-design.md.
  4. Product/combined Implementer: run assigned checks, inspect results, repair your own defects in this assignment, recheck, and return. At-end review never removes deterministic testing or grants independent-review identity; diagnostic verification receipts never satisfy an assurance gate. Report results against the mutation, changed-line coverage, and red-then-green claim types with the target repository's own tool; a declared gate with a missing tool or a not_run outcome is a typed gap, never PASS. Every red-then-green receipt binds the baseline failing run and the candidate passing run over the same test ids; author gate-chain receipts are diagnostic and cannot satisfy an assurance gate.
  5. Preserve unrelated work. Return only the compact receipt. Stop on acceptance, authority boundary, design gap, or exhausted correction.

Return and recovery

Return CANDIDATE_READY, PARTIAL, WAITING_ON, or OWNER_DECISION_REQUIRED with verdict, candidate_ref, changed_paths, tests, findings, and blocker. In-run corrections require new evidence or a new hypothesis.

An authorized repair closes by deterministic checks, without extra review or invocation. Never expand scope, self-certify as assurance, publish, or hide a failure.

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.