ef-implement

Files (4)

• SKILL.md
• checklist-format.md · references/
• orchestration.md · references/
• sweep.md · references/

SKILL.md (first lines)

# EF Implement — Stage 4 of 5

Stage 4 of 5 · per target repo · after `/ef:perspective-discovery` · next: `/ef:audit`

```
EXTRACT ─────────→ BUILD ─────────→ VERIFY
(checks + proofs)  (your call)      (Stage 5, fresh agent, whole feature)
```

The thinking already happened in Stages 1–3. Your job is to lose nothing from it, prove what you
build, and hand a *whole feature* to Stage 5. **How** you build is yours — no phases, no task list,
no step-by-step.

## Inputs — all three, or stop and run that stage

- the **requirement identifiers** this repo owns, from the PRD, and `grill-decisions` as the
  rationale authority over the RFC and PRD
- the **contract** written at the end of Stage 3 — `.ef/<feature>/contract/` (or the `## Contract`
  section of `checks.md` at `single` scale). If it exists only in a conversation, it does not exist:
  parallel slices cannot read a conversation
- an **anchor table** with no unresolved `FICTION`/`CHANGED` on a load-bearing claim

## Bindings

Every concrete command, identifier rule and convention comes from the repository, never from this
skill. Read the `ef-harness` block in the repo's context file; the contract carries the
feature-specific delta.

Where the block is absent, derive the gates from the task runner and the CI workflows, propose them,
and offer to write the block — or run `/ef:ready bootstrap`, which writes it with every gate run
once and keeps it checked. **Never invent a command** — a proof that cannot run is worse than no
proof. Prefer a command that already runs in CI.

## Critical rules

1. Every check names its **proof**: the specific test whose exit code settles it. The whole suite is
   not a proof — a suite going green says nothing about *this* claim. No proof, no check.
2. Tests assert what the check says, never what the code happens to do. **Never write a test by
   reading the implementation.**
3. Never weaken an assertion, delete a test, or skip one to make a suite pass. A red proof is a
   stop, not a note. If a check turns out to be wrong or impossible, stop and renegotiate.
4. The checks do not change while you build. Once written they are the bar you build under, not a
   position to argue against; lowering them is renegotiation with the user, visible in the diff.
   `Landing` is the exception, and it is additive.
5. **You never verify your own work.** Stage 5 is dispatched by whoever holds the whole feature,
   after the last wave, over the whole feature range. A build slice finishes, reports, and stops — it
   never spawns an agent at all.
6. **Blast radius:** an approved checklist authorises local edits and local commits. Pushing,
   deploying and production data changes need an explicit go-ahead.

---

## Extract

Read the contract and the requirements completely first, then walk the code they touch, so the checks
land on real paths and reuse what exists.

**Refuse rather than guess.** Three things must be true of every check:

- a **nameable proof** — if you cannot say which test would settle it, it is too vague to write down
- a **concrete value** — a status code, a field, a bound. Never "properly", "gracefully", "fast"
- the **boundary** is stated — you can say what is explicitly out

Missing one is normal and asking is cheap. Proceeding on a guess is not: a vague check becomes a
vague assertion that passes, which is the single failure this stage exists to prevent.

Then walk `references/sweep.md` — the requirements nobody writes down — and say where each one
landed. "Already covered by X" and "not in scope because X" are complete answers. Silence is not, and
neither is a generic one: *"authorization: handled"* is silence with a word in front of it.

Raising a sweep item is always free. Growing scope is the user's call.

### Format

Read `references/checklist-format.md` when you write `.ef/<feature>/` — after the contract is read,
the refuse gate is passed and the sweep is walked. Do not load it during the first pass. At `single`
scale the checklist is one file; at `standard` and `multi` it is split by reader — an index, the
contract by topic, one file per slice — so each builder loads only what it codes against.

Where the repository vendors the checker, run `node .ef/bin/ef-check.mjs` once the checklist is
written. Its `feature` gate fails a duplicated check id, a check with no proof, an owned requirement
no check cites, and a slice that reads a contract file that does not exist.

---

## Build

You decide how. Write the tests from the checks, implement, run each proof, commit in coherent
pieces following the repo's commit convention.

Slices run in **parallel**, one agent per ownership set. `references/orchestration.md` holds the
weighing, the ownership rules and the wave boundary. A builder is briefed with **files, not
paraphrase**: the index, the contract files its slice `Reads:`, and its slice file — nothing else from
`.ef/<feature>/`.

Two boundaries, about scope rather than care: capability nobody asked for and unrelated refactors are
not yours to add — surface them and move on. Everything else inside the work at hand is the work: a
guard clause, a clear error message, a test beyond the proofs when you can say what *should* happen
at an edge the checks did not name. Extra tests are welcome and there is no quota.

Doors get discovered while building, and deciding them is yours. Then record: append the row to
`Landing` in `checks.md` with its literal shape and the alternative you rejected, **before the code
that closes it is written**. The timing is the mechanism — an alternative is only knowable while you
are still choosing between them. Written at the end it becomes a justification of what you already did.

---

## Verify → Stage 5

When the last wave is green and the gates pass, **you** dispatch `/ef:audit <docs> audit` over
`<feature base>..HEAD` with every check in scope.

Not from inside a slice, and not scoped to the last wave. An auditor briefed by the agent that closed
the final wave inherits that agent's scope even though it inherits none of its tokens — it gets
pointed at the last wave, and a pass over four checks reads exactly like a pass over forty.

---

## Amend the feature docs

From micaelcf/ef-harness, MIT.

More from micaelcf/ef-harness