Implementation Prompts

Implementation prompts assume design is decided. Point at pattern files; name acceptance and non-goals. Prefer plan mode approval, then a single implement pass. Technique depth: Implementation Prompts, Add Feature.

Feature implementation

Build a scoped product capability against a spec and existing patterns.

Inputs: <spec path>, <pattern files>, <entry points>, <out of scope>

Implement the feature described in <spec path>.

Follow patterns in: <pattern files>
Entry points to extend: <entry points>
Out of scope: <out of scope>

Rules:
- Read the spec and pattern files before editing.
- List ambiguities; if any are load-bearing, STOP and ask — do not
  invent product behavior.
- Match error handling, naming, and test style of the pattern files.
- No new top-level directories unless the spec requires them.
- No drive-by refactors.

Deliver:
1. Code changes
2. Tests mapped to each acceptance criterion in the spec
3. Short summary: files touched, decisions made, remaining risks

Run the relevant tests before finishing.

Expected output: minimal diff, tests per acceptance criterion, summary with risks.

Evaluate: Diff stays near entry points. Spec acceptance all covered. No speculative abstractions. See Shallow Implementation.

Variations:

• Add "diff budget: ≤ N files."
• Require a plan first, then "implement the approved plan only."

Backend implementation

Service/API/data-path work with explicit integrity constraints.

Inputs: <endpoint or job>, <model/schema paths>, <idempotency rule>, <transaction boundary>, <test command>

Implement backend change: <endpoint or job>

Models/schema: <model/schema paths>
Idempotency: <idempotency rule>
Transaction boundary: <transaction boundary>
Pattern to mirror: (same directory as the closest existing handler)

Requirements:
- Validate inputs at the boundary; never trust client shapes.
- State transitions only as allowed by the model; log + no-op or
  409 on illegal transitions — pick one and document in code comment.
- DB writes for one request/event happen inside <transaction boundary>.
- Errors use the existing envelope.
- Include migration only if schema must change; expand/contract safe.

Tests (<test command>):
- Happy path
- Duplicate/idempotent replay
- Illegal state transition
- Downstream dependency failure

Do not touch UI. Do not add unrelated endpoints.

Expected output: handler/job + tests covering integrity cases; migration only if required.

Evaluate: Replay is safe. Illegal transitions handled. No N+1 surprises on the write path you care about.

Variations:

• Webhook-specific: signature verify + event-id dedupe table.
• Queue consumer: at-least-once + poison-message policy.

Frontend / UI implementation

UI work constrained to existing components and states.

Inputs: <screen or flow>, <component library paths>, <API client path>, <states required>, <a11y requirements>

Implement UI for: <screen or flow>

Reuse: <component library paths>
Data via: <API client path>
Must handle states: <states required>
A11y: <a11y requirements>

Rules:
- No new CSS framework or component library.
- Prefer composition of existing primitives over one-off styled divs.
- Wire loading/empty/error/success explicitly.
- Forms: client validation matching API constraints; show server errors.
- No business logic in components that already belongs in the API client
  or a shared lib — follow existing layering.

Tests: component/integration tests for the critical path and one
failure state. Match existing test utilities.

Out of scope: redesign, new design tokens, analytics unless specified.

Expected output: UI wired to real client, all required states, focused tests.

Evaluate: States aren't missing. Components reused. No parallel styling system. Keyboard/focus basics met if required.

Variations:

• "Match visual patterns of <reference screen path> exactly."
• Storybook stories instead of/in addition to tests.

Incremental implementation

Ship the smallest vertical slice, then stop for review.

Inputs: <full goal>, <slice definition>, <done means>, <explicitly defer>

We are implementing incrementally.

Full goal (context only): <full goal>
THIS slice only: <slice definition>
Done means: <done means>
Explicitly defer: <explicitly defer>

Implement only this slice. Leave TODOs as comments referencing the
deferred items — do not partially build them.

After tests pass, stop and summarize what a follow-up slice should do.
Do not start the follow-up.

Expected output: complete slice, passing tests, deferred list — nothing beyond.

Evaluate: Deferred items truly absent (not half-built). Slice is demoable/shippable on its own.

Variations:

• Tie each slice to a PR title convention.
• Require feature flag off-by-default.

Constrained file-scope build

Hard file allowlist to stop agent sprawl.

Inputs: <task>, <allowlist files>, <readonly context files>, <forbidden paths>

Task: <task>

You may MODIFY only these files:
<allowlist files>

You may READ:
<readonly context files>

Forbidden (do not touch even if tempting):
<forbidden paths>

If the task cannot be completed within the allowlist, stop and propose
the minimal allowlist expansion — do not expand unilaterally.

Implement, test, summarize. No refactors outside the allowlist.

Expected output: changes only in allowlist; or a stop with expansion proposal.

Evaluate: git diff --name-only ⊆ allowlist. No "helper" files smuggled in.

Variations:

• Allowlist directories instead of files.
• Add max LOC changed.

Walking skeleton

End-to-end thin path first — proves integration before features thicken.

Inputs: <user-visible thin path>, <systems to connect>, <success signal>, <non-goals>

Build a walking skeleton only.

Thin path: <user-visible thin path>
Connect: <systems to connect>
Success signal: <success signal>
Non-goals: <non-goals>

Requirements:
- One path works end-to-end (UI → API → DB or equivalent).
- Hard-code or stub non-essential branches; label stubs clearly.
- No polish, no edge-case completeness, no admin UI.
- Include one smoke test (or script) that asserts <success signal>.

Stop when the smoke test passes. List the next thickening steps —
do not implement them.

Expected output: thin E2E path + smoke test + next-steps list.

Evaluate: Smoke test fails if any link in the chain is broken. No feature completeness theater.

Variations:

• Skeleton for a new microservice: health → one write → one read.
• Use as slice #1 after Large task decomposition.

Exemplar-then-replicate

Copy a known-good module's shape, then adapt.

Inputs: <exemplar path>, <new target>, <behavior deltas>, <must stay identical>

Implement <new target> by replicating the structure of <exemplar path>.

Behavior deltas (only these may differ):
<behavior deltas>

Must stay identical to exemplar:
<must stay identical>

Process:
1. Summarize the exemplar's structure (files, layers, test layout).
2. Create the new module mirroring that structure.
3. Apply only the listed deltas.
4. Port/adapt tests the same way.

Do not "improve" the exemplar's pattern. If the exemplar looks wrong,
flag it — don't silently fix it in the replica.

Expected output: structural twin of exemplar with listed deltas only; mirrored tests.

Evaluate: Diff against exemplar is mostly renames + delta lines. No architectural "upgrades."

Variations:

• Exemplar is a PR, not a path (git show).
• Forbid new dependencies even if exemplar has old ones you dislike — change exemplar first in a separate task.

Interface-first parallel prep

Prepare frozen interfaces and stubs so multiple agents can implement in parallel.

Inputs: <modules>, <contract file path>, <stub strategy>, <integration test plan>

Prepare for parallel implementation of: <modules>

Contract source of truth: <contract file path>
Stub strategy: <stub strategy>

Do:
1. Verify/complete the contract file; mark BLOCKING gaps.
2. Generate typed stubs / interfaces / route skeletons that compile.
3. Add contract tests or fixture validators from the contract examples.
4. Add a thin integration test plan (not full impl) describing how
   modules will be joined.

Do NOT implement business logic inside modules.
Output a brief for each module implementer: inputs, forbidden changes,
commands to run.

Expected output: compiling stubs, contract tests, per-module implementer briefs.

Evaluate: Stubs compile. Contract gaps are BLOCKING or gone. Briefs are disjoint on file ownership. See Multi-agent patterns.

Variations:

• Generate OpenAPI + server stubs only.
• Add a merge checklist for the integrator agent.

Behavior-preserving extract

Extract a module without changing observable behavior (setup for later change).

Inputs: <source region>, <new module path>, <public API to expose>, <characterization tests command>

Extract <source region> into <new module path> with public API:
<public API to expose>

Constraints:
- Observable behavior MUST NOT change.
- First: add/adjust characterization tests via <characterization tests command>
  that pin current behavior; they must pass on HEAD before extract.
- Then extract; tests must still pass with no assertion changes
  except import paths.
- No feature additions, no renames for taste, no performance "wins."

Summarize the extract and any suspicious behavior you pinned.

Expected output: extract PR-sized diff; characterization tests green before and after.

Evaluate: Test assertions unchanged (imports ok). Behavior diffs empty. Suspicious pins listed. Pair with Refactor.

Variations:

• Extract interface only; keep implementation in place behind it.
• Limit to pure functions first.

Related

• Implementation Prompts — weak/strong rationale
• Add Feature — end-to-end feature playbook
• MVP Build — walking skeleton in a greenfield context
• Prompt Anatomy — structure these prompts assume
• Shallow Implementation — what bad impl looks like
• Multi-agent patterns — parallel implementation after interface freeze