claude-code lastVerified: 2026-05-08

Claude Code Feature Prompt — Constraint-First Implementation Template

A Claude Code feature implementation prompt that enforces existing-architecture preservation. Free-text feature spec + constraint toggles for Vite projects.

On this page
  1. What this prompt does
  2. The prompt
  3. Why each section earns its place
  4. Variants by feature type
  5. When to use this prompt versus the generator
  6. Common pitfalls when Claude Code adds features

What this prompt does

Asking Claude Code “build me a settings page” is how a Vite project ends up with a second routing library, a third state-management dependency, and a fourth styling system by Friday. This prompt frames feature work as a constraint problem: here is the feature spec, here are the architectural rails the implementation must stay between, here is the acceptance test. Claude Code is excellent at implementing inside narrow rails — it just needs the rails. The parameterised version lives at /tools/ai-feature-prompt-generator and lets you toggle the five constraint switches one at a time.

The prompt

feature-prompt.md
# Feature spec
Implement <one-paragraph spec of the feature, including the user-facing
behaviour and the page or component name>.

# Architectural constraints (do not violate)

- Routing stays on the existing router (no new routing library, no new outer layout)
- Reuse components from src/components/; do not introduce a parallel UI kit
- Styling: Tailwind v4 utilities + daisyUI classes only; no CSS Modules, no styled-components
- Add visible loading + error states for any async data the feature touches
- No new runtime dependencies; if a missing capability is needed, flag it and stop

# Acceptance criteria

- The feature renders at the agreed URL and exercises the happy path end-to-end
- Existing tests still pass: `pnpm test --run`
- The new code path has at least one Vitest test covering the happy path
- `pnpm build` succeeds and the bundle size diff is < 20 KB gzipped
- A link to the new feature exists from the page the user would naturally arrive from

# Output format

1. Short paragraph: which existing files you will edit and which new files you will add.
2. The diffs (one section per file, full file contents only for new files).
3. The exact commands you ran and their truncated output.
4. One sentence per acceptance criterion confirming it is satisfied.

Why each section earns its place

The Feature spec is intentionally free-text — Claude Code is good at translating a paragraph into a component skeleton and a test. The Architectural constraints block names the five defences a Vite project actually needs: routing stability, component reuse, styling consistency, loading-and-error states, and dependency restraint. Each constraint maps to a specific failure mode the agent has demonstrated repeatedly across community reports — mounting a second router under /admin, generating a fresh <Button> instead of importing the existing one, dropping in react-spinners for a loader, swallowing fetch errors. The Acceptance criteria block is what turns “build a feature” from open-ended generation into a checklist Claude Code can self-grade against. The bundle-size budget catches the tree-shake regression you only notice when CI fails three days later.

Variants by feature type

Each row scopes the constraints differently — a dashboard page has different acceptance criteria than a dark-mode toggle.

Feature typeAcceptance criteria additions
Auth formValidates inputs client-side; surfaces server errors inline; CSRF-safe
Dashboard pageLoading skeleton; empty state; error retry button; data fetched once
Dark-mode togglePersists across reloads via localStorage; honours prefers-color-scheme
Pricing pageStatic content; no JS interactivity; SEO-ready meta tags emitted
Settings panelOptimistic UI; rollback on save failure; keyboard navigation works
Modal / dialogFocus-trapped; closes on Escape; aria-modal + aria-labelledby set

The auth-form row tightens validation rules; the dashboard row demands the three states; the toggle row demands persistence. Pick the row, paste the additions into the Acceptance criteria block, and Claude Code now has a checklist tied to the feature class instead of generic guidance.

When to use this prompt versus the generator

The hand-authored page is for one-off pastes and SEO arrival traffic. The /tools/ai-feature-prompt-generator is for daily use because it lets you flip the five architectural-constraint switches per feature — sometimes you genuinely need a new dependency (you are integrating Stripe; @stripe/stripe-js is non-negotiable), and the toggle expresses that without you editing the prompt prose.

Common pitfalls when Claude Code adds features

Feature creep is the headline failure: ask for a settings panel, get a settings panel plus a notifications drawer plus a refactored navbar. Counter it by listing the precise files you expect to be touched. Dependency bloat is second: Claude Code reaches for react-hook-form on every form. Counter it by adding “no new runtime dependencies” to your locked decisions in CLAUDE.md. Layout drift is third: a new page silently mounts under a fresh outer container, breaking the visual rhythm. Counter it by demanding that every new page imports the same Layout used by sibling pages. For the inverse problem — fixing a bug rather than adding a feature — see the Claude Code bug fix prompt. For locking behaviour under a refactor, see the Claude Code refactor prompt.