Ground a feature before you build it

Anchor one small feature in the current code, APIs, data contracts, and tests before implementing and verifying the user path.

Use this when

Use this when a larger feature can be divided into small engineering slices and guessing about APIs, persistence, or user-visible behavior would create avoidable risk.

How it runs

1. Read the project instructions and inspect the current implementation, dependencies, contracts, tests, and relevant architecture notes.
2. State the evidence, risks, files in scope, user-visible behavior, persistence impact, and validation plan for one small slice.
3. Stop for approval if inspection invalidates the approach or reveals a material scope, production, destructive, or silent-persistence change.
4. Implement only the supported slice while preserving unknown fields, round-trip behavior, and unrelated work.
5. Run the relevant repository checks and manually verify loading, error, stale, save, and cleanup states where applicable.
6. Stop after the slice and return the evidence, changed behavior, limitations, and next recommended slice.

Done when

✓ One feature slice works and its assumptions are proven by current evidence. The implementation matches observed APIs and data contracts, repository checks pass or have documented pre-existing failures, and the relevant user path is manually verified when one exists.

Why it works

Inspecting real contracts before coding prevents plausible but invented APIs or data behavior from shaping the implementation. Limiting each pass to one feature slice keeps review, verification, and persistence effects understandable.

Implementation note

Do not silently save user data, invent endpoints or data shapes, hide unavailable checks, or continue into another feature slice without approval. Keep previews honest about whether they show draft state or source-of-truth backend output.

Source: Forward Future ↗graded C · 55/100 — how grades work →

More testing loops