The to-spec Skill: What It Writes and When to Skip It
How Matt Pocock's /to-spec skill turns a planning conversation into a spec issue, what its template leaves out, and when a spec is not worth the step.
Practical articles for teams using spec-first delivery. The focus is on writing clearer requirements, tightening review loops, and shipping with fewer surprises.
New here? Start with the spec-first guide — API contracts, acceptance criteria, and the case studies all build on it. We publish when a piece survives our own review gate, not on a schedule.
Filter by topic. Start with the article closest to your current delivery risk — each one links onward to the related routes.
How Matt Pocock's /to-spec skill turns a planning conversation into a spec issue, what its template leaves out, and when a spec is not worth the step.
What harness engineering means for AI coding agents, how it differs from spec-driven development, and how to run both.
AGENTS.md is a README for coding agents. The hard part is the boundary: which rules are true for every change, and which belong in a spec for one change.
A Cursor rule that never fires is worse than no rule. Three frontmatter fields decide which of the four types you wrote, and most teams write the dead one.
A five-stage spec-first workflow for teams running AI coding agents: spec packets, bounded tasks, write scopes, evidence gates, and PR review that scales.
Write API spec contracts for MCP servers: input schemas, output shapes, error taxonomies, idempotency flags, and versioning that AI agent clients can rely on.
OpenSpec vs Superpowers vs Spec Kit, checked Nov 2026: what each one owns, how to combine them, and which to start with.
A copy-ready packet for giving AI coding tools a bounded task, acceptance criteria, file ownership, tests, and review evidence before code generation starts.
See how Spec Skills fits spec-first delivery through constrained prompts, spec injection, boundary enforcement, and reviewable AI output.
Same refund feature built two ways: vibe coding ships fast but misses edge cases, while spec coding defines scope, acceptance criteria, tests, and rollout proof.
20 real-world acceptance criteria examples in Given/When/Then format covering authentication, e-commerce, APIs, data processing, payments, and notifications.
How to write a technical specification document for software: the sections to include, five worked examples (config, API, migration, UI), and a copy-ready template.
Define database schemas before writing migrations, including columns, constraints, indexes, API alignment, and rollout order.
AI coding tools drift without constraints, adding fields, renaming functions, expanding scope, and inventing tests. Spec-first prompts keep changes reviewable.
Govern AI-assisted coding with spec-driven prompts: define scope, boundaries, evidence, and audit trails before generated code reaches review.
Review AI-generated pull requests against acceptance criteria: inspect the diff, run evidence checks, and catch failures a quick skim misses.
Use a pre-merge risk register for AI-generated code: flag auth, data, contract, migration, rollback, and observability risks.
Use test-evidence gates for AI-generated code: require meaningful tests before merge and catch hallucinated implementations before release.
Design API specs for LLM-powered agentic clients with discoverable fields, idempotency, dry-runs, semantic descriptions, and safe destructive actions.
Add contract testing from OpenAPI to CI with generated tests, provider checks, consumer expectations, and reliable fixtures.
Specification patterns for event-driven systems: schema versioning, command vs fact events, orchestration choices, idempotent handlers, and replay safety.
Write payment workflow specs with retryable errors, declined-card handling, timeout behavior, 3DS branches, and dunning states.
Avoid ten specification mistakes that hide decisions, blur acceptance criteria, skip failure paths, and push scope arguments into implementation.
Quality gates for AI-assisted code: pre-prompt spec checks, diff review, test evidence, and human sign-off before generated code ships.
Use this pre-coding review checklist to separate blockers from preferences, record accepted risks, and attach test evidence before implementation begins.
What is spec-first development? A complete guide to surfacing hidden decisions about scope, contracts, edge cases, and acceptance criteria before coding starts.
Static pagination · Page 1/3 · 26 articles
Use this as the orientation piece if you want the overall model, tradeoffs, and where spec-first work pays off.
Read the full guideA complete template, worked example, and free generator covering acceptance criteria, edge cases, and the sections every spec needs.
Open the template guideWhich spec tool decides what gets built, which one controls how the agent builds it, and how to run two of them together.
Read the comparisonPick the path that matches the problem in front of you. Each path starts with a practical article, then points toward a template, checklist, or tool you can use in the same session.
Start with the complete guide, then compare spec-first with agile and use the adoption plan only after the team agrees on the behavior you want to protect.
Start the foundations pathUse the technical spec guide, acceptance criteria examples, and edge-case articles when a ticket is too broad for implementation.
Follow the writing pathStart here when a change touches external consumers, database shape, idempotency, compatibility, or release safety.
Follow the contract pathStart with a spec packet, then move into prompts, risk registers, PR review gates, and test evidence before generated code reaches production.
Follow the AI pathUse these hubs when you want a structured route through the library instead of one article at a time. Each hub includes a decision table, copy-ready block, and related guides.
Start here for the method, core decisions, review gates, and evidence habits.
Open hubUse this route for schema diffs, compatibility, versioning, webhooks, and deprecation.
Open hubTurn success statements into testable criteria with failure paths and proof.
Open hubConnect prompts, risk registers, acceptance mapping, and test evidence.
Open hub