Prompt templates, filled-in examples and common mistakes for each Spec-Kit slash command, plus the safety mechanisms behind the /implement loop.
This guide shows how to write a prompt for each Spec-Kit slash command so you get a usable result on the first try. Every section follows the same shape: purpose → prompt structure → example → mistakes to avoid.
Read the Spec-Kit overview first if you haven’t seen the 7-step workflow.
Run this first in every new project. It produces .specify/memory/constitution.md — the rule set the agent must follow at every later step. Think of it as the project’s “constitution”: code quality, testing, UX, performance, security.
/speckit.constitution Create the project principles with these requirements:1. Code quality: - [CLEAN-CODE RULE, e.g. functions ≤ N lines] - [NAMING CONVENTION, e.g. camelCase variables, PascalCase classes] - [OTHER, e.g. no magic numbers, no nested if > 3 levels]2. Testing: - [UNIT-TEST SCOPE] - [MIN COVERAGE] - [OTHER, e.g. integration test for every API endpoint]3. UX consistency: - [DESIGN SYSTEM / FIGMA REFERENCE] - [MANDATORY UI RULES, e.g. validation, loading state > N ms]4. Performance: - [API RESPONSE TIME TARGET] - [DB ACCESS RULES, e.g. no N+1 queries]5. Security: - [AUTHN/AUTHZ RULES] - [SENSITIVE DATA HANDLING]6. Governance: - [TIE-BREAKER RULES WHEN PRINCIPLES CONFLICT] - [DOCUMENTATION REQUIREMENTS FOR EXCEPTIONS]
/speckit.constitution Create the project principles with these requirements:1. Code quality: - Follow Clean Code, functions ≤ 30 lines - Team naming convention (camelCase variables, PascalCase classes) - No magic numbers — extract them into named constants2. Testing: - All business logic must have unit tests - Min 80% coverage on the service layer - Integration tests for every API endpoint3. UX consistency: - Use the company design system (Figma reference) - Every form needs visible validation - Loading state for any operation > 300ms4. Performance: - API response time < 500ms for 95% of requests - No N+1 queries in DB access5. Security: - Use @company/auth for authentication, don't roll your own - Don't log personal data (national IDs, card numbers, passwords)6. Governance: - When performance and code quality conflict, prefer code quality unless performance directly impacts UX - Any decision against the principles above must be justified in the spec
/speckit.specify Build [MODULE/FEATURE NAME] for [SYSTEM/PRODUCT].Context:- [1-3 sentences: what's the current problem? What does this solve?]- [If relevant, mention the affected business KPI]Users:- [ROLE 1]: [permissions and main actions]- [ROLE 2]: [permissions and main actions]- [ROLE 3]: [permissions and main actions]Main user journey ([JOURNEY NAME]):1. [Step 1 — user action]2. [Step 2 — system response]3. [Step 3 — branching condition if any]4. [Final step — end state]Functional requirements:- [BUSINESS RULE, e.g. object states]- [PERMISSION RULE, e.g. role X only sees data Y]- [DATA RULE, e.g. code format, uniqueness]Success criteria (measurable):- [CRITERION 1 + METRIC, e.g. create order in < 2 minutes]- [CRITERION 2 + METRIC, e.g. p95 API < 400ms]
/speckit.specify Build the "Internal Order Management" module for the ERP.Context:- Sales currently records orders in Excel, causing errors and making AR tracking hard.- This module replaces Excel so sales can create orders quickly and accounting can reconcile easily.Users:- Sales: create/edit own orders, view team orders- Sales Manager: view all team orders, approve orders > 100M VND- Accounting: view all orders, mark paid, export reports- Admin: configure product/customer catalogsMain user journey (Sales creates an order):1. Sales picks a customer from the catalog2. Adds products + quantities (price auto-fills from price list)3. System totals the order; sales applies discount (max 10%)4. Submit → if > 100M, status becomes "Pending Approval"; otherwise auto-becomes "Approved"5. Manager gets a notification if approval is neededFunctional requirements:- Order states: Draft, Pending Approval, Approved, Delivered, Paid, Cancelled- Every state change is logged (who, when, why)- Sales only sees their own and their team's orders (department-based)- Approved orders cannot be deleted — only cancelled with a reason- Order numbers auto-generate as DH-YYYYMM-XXXXSuccess criteria (measurable):- Sales can create a 10-line order in < 2 minutes- Manager sees pending-approval orders the moment they open the app- Accounting can export monthly AR reports to Excel
After /speckit.specify, always there are spots the AI interprets differently than you, or that you didn’t think about. This command opens a structured Q&A: the AI asks sequential questions about underspecified areas, you answer, it appends a “Clarifications” section to spec.md.
Option 1 — Empty call (recommended for the first pass):
/speckit.clarify
The AI scans spec.md itself, finds the underspecified parts and asks you about them.Option 2 — Target specific areas:
/speckit.clarify Focus on clarifying [AREA 1] and [AREA 2], because[REASON — I didn't write this carefully / it's high risk / PM is unsureabout the business rules]
Now we talk TECH. The AI reads the spec + constitution, then proposes/confirms architecture, picks libraries, sketches the data model, and designs API contracts. Output: several files under specs/<feature>/ — plan.md, research.md, data-model.md, contracts/.
/speckit.planTech stack:- Backend: [LANGUAGE + FRAMEWORK + VERSION]- Database: [DB + VERSION + SCHEMA NOTES]- Frontend: [FRAMEWORK + VERSION]- Build tool: [e.g. Vite, Gradle]- State management: [e.g. TanStack Query — why not Redux]Architecture:- [MONOLITH / MICROSERVICE / MODULE IN A MONOREPO]- [FE IS SPA / SSR / MICRO-FRONTEND?]- [CODE PATTERN, e.g. Hexagonal, Clean Architecture, MVC]Integrations:- [SYSTEM 1 + HOW TO CONNECT, e.g. SSO via Keycloak, lib @company/auth]- [SYSTEM 2 + LINK TO CONTRACT/DOC]- [SYSTEM 3 — ASYNC, e.g. Kafka topic X]Non-functional:- [PERF TARGET, e.g. p95 API < N ms for read endpoints]- [THROUGHPUT, e.g. N requests/min at peak]- [AUDIT/COMPLIANCE, e.g. logs kept N years]- [AVAILABILITY TARGET]Team conventions:- [ENDPOINT FORMAT, e.g. /api/v1/...]- [ERROR RESPONSE FORMAT, e.g. RFC 7807]- [REQUIRED ENTITY FIELDS, e.g. createdBy, createdAt, updatedBy, updatedAt]- [MIGRATION TOOL + NAMING, e.g. Flyway, V{YYYYMMDD}__{description}.sql]
/speckit.planTech stack:- Backend: Spring Boot 3.2, Java 21- Database: PostgreSQL 15 (dedicated "orders" schema)- Frontend: React 18 + TypeScript, built with Vite- State management: TanStack Query (no Redux)Architecture:- Backend is a module inside the existing ERP monorepo- Frontend is a micro-frontend, dynamically loaded into the shell app- Hexagonal pattern: controller → service → repositoryIntegrations:- SSO via Keycloak (in-house @company/auth lib)- Notifications via the shared Notification service (REST API, OpenAPI spec at /internal-docs/notification.yaml)- Customer sync from CRM via Kafka topic "crm.customer.sync"Non-functional:- API p95 < 400ms for read endpoints- Handles 100 orders/min at peak- Audit log mandatory for every order state change (kept 5 years)Team conventions:- REST endpoints follow /api/v1/orders/...- Error response per RFC 7807 (Problem Details)- Every entity has createdBy, createdAt, updatedBy, updatedAt- Flyway for migrations, naming V{YYYYMMDD}__{description}.sql
Don’t trust the first output. Run an audit prompt:
Now audit the implementation plan and the supporting files.Read carefully and check:- Any over-engineered tech choices? Specifically [STATE YOUR SUSPICION, e.g. do we really need Redis cache for < 10k records?]- Any rapidly-changing libraries that need version research? Prioritize checking [LIBRARY LIST]- Any missing references between plan.md and the supporting files?- Anything that conflicts with constitution.md?List every issue you find before fixing anything.
Turn the plan into a list of small, ordered, independent, testable tasks. Each task small enough to review in one pass, clear enough that the AI knows which file to touch.
/speckit.tasks [METHOD — e.g. follow TDD: tests first, code second].Prioritize finishing user story "[STORY NAME]" first, the rest after.Mark [P] for tasks that can run in parallel.[OTHER CONSTRAINT — e.g. each task must take < 1 hour; split if larger]
/speckit.tasks Follow TDD: tests first, code second.Prioritize finishing user story "Sales creates order" first,the rest after.Mark [P] for tasks that can run in parallel.Each task must take < 1 hour; split if larger.
After this step, open tasks.md and click Parse to DB in the SpecKit Panel so the system creates SubTasks in the database and you can track progress in the UI.
Generates concrete test cases used to verify code when /speckit.implement runs. Different from /speckit.checklist (which validates the spec/requirements quality), this command produces real test scenarios — precondition, input, expected output, pass criteria — linked to each SubTask via markers.Agent skill:speckit-testcaseOutput:testcase.md (or files under specs/<feature>/checklists/) containing test cases with markers like [TC-001], [TC-002]… linked to SubTasks via [T001] markers. After Parse-to-DB, each test case becomes a TestCase record attached to the matching SubTask.
Option 2 — Focus on a story with explicit constraints:
/speckit.testcase Focus on user story "[STORY NAME]".Generate test cases for:- All happy paths- All error and validation flows- Important edge cases (boundary, empty, max value)- [OTHER CATEGORIES, e.g. permissions, audit log]Each test case must have:- Test code: [TC-XXX]- Clear precondition- Concrete input data (real values, not placeholders)- Measurable expected output- Pass criteriaLink each test case to its SubTask via the matching [T001] marker.
/speckit.testcase Focus on user story "Sales creates order".Generate test cases for:- All happy paths: single-line order, multi-line order, with discount- All error flows: discount > 10%, product not found, customer locked- Edge cases: zero-VND order, order > 100M (auto goes to "Pending Approval"), order with duplicate products- Permissions: Sales A cannot see Sales B's orders from another teamEach test case must have:- Test code: [TC-XXX]- Clear precondition (e.g. "Sales user is logged in, at least one customer exists in the catalog")- Concrete input data (real values, not placeholders)- Measurable expected output (e.g. "Order code matches DH-202605-XXXX, status = Approved, total = 5_500_000")- Pass criteriaLink each test case to its SubTask via the matching [T001] marker(e.g. [TC-007] [T003] maps TestCase TC-007 to the SubTask whose titlecontains [T003]).
Test case without concrete input — “enter a number” makes the agent guess at run time; write “enter 5_500_000”.
Vague expected output — “succeeds” isn’t measurable; specify which field and what value.
Missing the linking marker — without [T001], the parser can’t bind the TestCase to a SubTask, leaving orphan TestCases in the DB.
Mixing test cases with test code — this command produces scenarios, not code; code is written when /speckit.implement runs.
After generating, open testcase.md and click Parse to DB just like with tasks.md. The system creates TestCase records and auto-links them to SubTasks via [T001] markers. When /speckit.implement runs, the agent reads these TestCases to know what to verify.
The AI reads tasks.md and works through them sequentially (or in parallel for [P] tasks): writes code, runs tests, commits. This is the slowest step but, if the previous steps were good, it runs almost on its own.
Option 2 — Phase by phase, with review breaks (recommended):
/speckit.implement Only run Phase [N] (user story "[STORY NAME]"), thenSTOP and report:- Tasks completed- Tests passed/failed- Files changed- Questions/blockers (if any)
Example:
/speckit.implement Only run Phase 1 (user story "Sales creates order"),then STOP and report:- Tasks completed- Tests passed/failed- Files changed- Questions/blockers (if any)
Option 3 — Continue after review:
/speckit.implement Continue from task [TASK ID, e.g. T015], I've reviewedthe previous part. Note: [IF NEEDED, e.g. I manually edited file X,re-read it before continuing]
Option 4 — Redo a specific task:
/speckit.implement Redo task [TASK ID] — the current implementation iswrong. Specifically: [SHORT DESCRIPTION OF THE BUG]. Before fixing, re-read[REFERENCE, e.g. spec.md "Audit log" section] to make sure you understandthe requirement.
Example:
/speckit.implement Redo task T008 — the current implementation is wrong.Specifically: the audit log only captures userId, missing department andIP. Before fixing, re-read spec.md "Audit log" section to make sure youunderstand the requirement.
The system drives the agent in incremental execution mode:
1
Initialize and scan
Backend queries SubTasks from the DB and scans .md files so the [x] (done), [/] (in progress), [ ] (pending) markers stay in sync with the DB.
2
Pick the target task
Picks the first SubTask with is_completed = false (by order_index) and the linked TestCases.
3
Build a focused prompt
Only 1–2 SubTasks are sent to the agent per round. The full task list is included for context but clearly marked: You finished [x], now do [/]: <title>. The relevant test command is included.
4
Execute and self-correct
The agent edits code, runs tests, reads the result.
Tests pass → move to the next SubTask.
Tests fail → analyze the log, fix the code, re-run. Capped at implement_max_loops attempts.
5
Report and update
When a SubTask finishes, the agent ticks [x] in the Markdown and reports back. Backend sets is_completed = true and pushes a WebSocket/SSE event so the UI refreshes automatically.
6
Finish
When no pending SubTasks remain, the system marks the Plan done and notifies you.
implement_max_loops — At most 5 self-correction attempts per SubTask (default). Beyond that the agent reports BLOCKED and stops instead of looping forever.
[?] marker — If the agent doesn’t have enough information, it leaves a [?] note in the Markdown rather than guessing, and asks for feedback.
