reach-feature

Files (1)

• SKILL.md

SKILL.md (first lines)

The feature flow for one slice. Work the steps in order; do not skip or reorder them. Reach does not do version control yet: never run git or start a repository, change files by overwriting them in place, and use `reach checkpoint` as the history.

1. **Read the slice.** README.md, contract/README.md, api/README.md, the `qualify` part of api/slice-api.json, shape/brief.md, then `reach plan show`, `reach status` and `reach qualify --list`. Read nothing else.
2. **Settle the behaviour with the student, in their terms.** Ask about the business user, the decision, the information and the expected result for a case they know. Never ask them about code. Save the plan: `reach plan save --behaviour "..." --input "..." --output "..." --steps "a|b|c" --edge-cases "a|b" --scenarios "<every required qualification name>|<your edge cases>" --evidence "reach qualify"`. Read the plan back in plain words and wait for their yes.
3. **Run the plan passes, then audit the plan in a second pass.** Load the reach-passes skill for the `plan` point first: several candidate plans through different lenses, scored and installed by rEach, so the saved plan is the one the evidence supports. Then load the reach-plan-audit skill and follow it: a fresh subagent where this app has one, otherwise a separate pass. It checks the saved plan against the released constraints (the required instructor APIs, the behaviour, the contract, the constraints and every required qualification name from `reach qualify --list`; for replay panels those are the supplied practice names, and Teach independently runs its graded names) and records a verdict for this exact plan. On a fail, settle the correction with the student, save the plan again and re-run the audit before any code. `reach qualify` needs a passing audit of the current plan.
4. **Choose the approach.** Decide how to build it, on your own; the student does not see this step. Panel slice: load the design-taste-frontend skill and infer the direction from shape/brief.md first.
5. **Run the scenario passes, then write the scenarios first.** Load the reach-passes skill for the `scenarios` point: the winning plan feeds the candidates, and rEach installs the best. Scenarios are written under qualify/features with steps under qualify/step_definitions (the QUALIFY directive): one scenario per required qualification name with exactly that name and the slice's tag, your edge cases after them. Backend scenarios fake ports with `grokit_fake`; replay-panel scenarios use the shipped practice names, labels, and values. A required API (api/README.md, Constraints) may be faked with a fixed answer only when the scenario asserts what the module does with that answer, never the answer itself; otherwise fake it with a lambda that checks the arguments the plan says the code passes and answers from them, so the scenario fails when the code skips the API or passes it the wrong inputs. Teach independently runs every protected graded case. They must fail on the starting copy.
6. **Run the code passes, then implement.** Load the reach-passes skill for the `code` point: the winning scenarios feed the candidates and rEach installs the best into the owned files. Then finish the work **in** the owned files, reading each before you overwrite it. Keep the first two lines of every file exactly as rEach wrote them. Update the editable README only with what the student actually said.
7. `reach check --format agent` until it prints nothing.
8. `reach qualify` (it needs a current pick at each of the three points when the course enforces the passes, and refuses known pattern-ledger problems, neither counting as a try), and follow what it prints (the TOZERO directive): pass on any notice to the student, and stop when it says to. If it returns `QF-UNCOVERED`, the assistant repairs the missing qualification scenarios using `steps.coverage.rows`, the exact names and tag, and the agreed plan. Keep the student's personal explanations and contributions in their own words; ask only for a missing business expectation. Follow the current ladder and stop conditions, then requalify as permitted. Continue the repair instead of ending with only a readiness summary.
9. `reach checkpoint save --note "<what works now>"`.
10. **Report to the student** in at most six plain lines: what the business can now rely on, one case in their words, and what is not yet covered. No code, no scenario names, no command output. Then `reach plan note --progress "..." --next "..."`.
11. **Offer to submit** with the reach-submit skill once `reach qualify` passed. Reach asks the student and submits only on their yes.

From SteveBenner/rEach, MIT.

More from SteveBenner/rEach