validate-feature

Validate Feature

Green unit tests prove that the assertions someone wrote pass. They do not prove the feature works. The gap between the two — an API that returns 201 where the client reads 200, a checkbox that flips in memory but never reaches the store, a form that clears on a failed submit — is where features ship broken. This skill closes it: drive the running system, not the test suite.

Run this after inspect-change, before land-branch.

Cold-start control. IF docs/agents/verify.md exists, Launch and Doctor from that file before any checklist item (it owns how a later agent boots this app). Drive each item with its Feature section when one matches; Evidence must include the persist/reload check that file names. IF it is missing, continue from project.md Run locally (dev) as today, and name /configure-repo once so the user can generate the recipe (Decision M) — do not invoke it.

1. Derive the acceptance checklist from the spec

Read the feature's requirements.md, design.md, and tasks.md. For every requirement describing user-observable behavior, list its concrete checks — the happy path AND each edge/error criterion — keyed to the requirement ID. The spec is the source: a behavior nobody hand-fed you is still on the hook, and an untraced one is a gap to raise, not to skip.

Write the checklist to .skills/<CODE>/acceptance.md (a working ledger, git-ignored) and create one todo per item. Heavy reading? Dispatch a scan subagent to map the touched surface and digest it to the ledger; keep this context lean. Done when: every user-facing requirement ID has at least one concrete, observable check with an expected result.

Product context docs (optional)

Applicability: acceptance criteria touch personas or measurable success outcomes.
Load: skills/project/define-system-doc/consult-recipe.md.
Paths: docs/product/personas.md, metrics.md, principles.md.

When Approved: fold relevant constraints into checklist expectations (advisory; requirements remain normative). When absent: CONTINUE; suggest once /define-system-doc product/personas|metrics|principles only if the gap makes acceptance materially clearer; never auto-invoke.

2. Dispatch by surface

The checklist splits by where each behavior lives. Run whichever apply — most features need both:

• The change exposes an HTTP/RPC API a client calls → REQUIRED SUB-SKILL: use validate-api.
• The change has a frontend a user drives → REQUIRED SUB-SKILL: use validate-ui. That drive is kimi-webbridge. It does not install a browser harness.
• The behavior is neither an API nor a UI (a CLI, a library, a batch/cron job) → drive it directly against the running system yourself, record each observed result in the ledger, and promote the passing checks into committed tests that describe the domain behavior (docs-only spine — no requirement-ID tags required in test files). For human-eyeball qualities (visuals, feel) hand off to write-dogfood.

Hand each child its slice of the ledger by path; it writes results back to the same file.

3. Close the loop

Report the checklist with each item's observed result. Any item you could not exercise is an open risk — name it; do not let it pass silently. Then hand back to land-branch. The UI acceptance evidence is .skills/<CODE>/validate-ui.md from the webbridge drive. A product defect still gets its regression in the repo's existing test stack. Done when: every checklist item is observed green against the running system, each failure fixed with a regression test in that existing stack, and the UI drive record is on disk.