Spec Skills Prompt Patterns for Spec Workflows

A catalog of Spec Skills prompt patterns for common spec workflows: feature spec drafting, AC generation, review assistance, and risk-register surfacing. With the exact prompt shapes I use.

Published on 2026-03-10 · Updated 2026-05-06 · 8 min read · Author: Spec Coding Editorial Team · Review policy: Editorial Policy

The Shape Every Spec Skills Prompt Shares

I have been running Spec Skills against spec work for about a year, and every prompt I keep in rotation has the same five parts. System role, spec context, the single task, boundaries, and an output shape. If any one of those is missing the output drifts, and the drift is always the same: confident prose, plausible sections, no decision I can act on.

The meta-pattern is short enough to memorize. I write the role first so the model stops pretending to be a neutral assistant. I paste the spec or the fragment of it that matters, not a summary. I give it one task, never a list. I tell it what it may not do. And I demand a format, usually templated markdown or a JSON blob, because prose is where spec work goes to die.

Acceptance Criteria for the Meta-Pattern

I treat the meta-pattern itself as a spec. If the prompt does not pass these, I rewrite the prompt before I blame the model.

- Given a prompt aimed at Spec Skills for spec work
  When I read it back before sending
  Then it contains a role, context, one task, boundaries, and an output shape

- Given a prompt missing any of those five parts
  When I send it anyway
  Then I expect shallow output and I do not complain about the model

- Given the output shape is prose
  When the task is a spec artifact
  Then I rewrite the shape as markdown template or JSON before reuse

Pattern 1: Feature Spec Draft

This is the one I use most. The prompt asks for the five core sections I believe a feature spec must have, and nothing else. Problem, scope, non-goals, acceptance, risks. No architecture. No timeline. No rollout. Those live in separate patterns.

The trick is that I feed in the raw material, usually a ticket and a short conversation transcript, and I say explicitly: do not invent anything that is not in the source. If you do not have enough for a section, write UNKNOWN and list what you need. UNKNOWN is the most valuable token in my workflow, because it surfaces the places the human still has to think.

Pattern 2: Edge-Case Hunt

Once I have a spec draft, I feed it back in with a different role and one task: what breaks. The prompt says you are a skeptical staff engineer reviewing this for production. List the top ten ways the described behavior fails in the real world. Prioritize by how embarrassing the failure would be on a Friday afternoon.

The output shape is a numbered list, each item with a one-line failure description and a one-line mitigation. Ten is deliberate. Five is too few to force the model past the obvious. Twenty gets padded. Ten is the sweet spot where the last two items are the ones worth stealing.

Pattern 3: Review Assistant

This pattern pairs the spec with a PR diff. The task is single and boring on purpose: list every place the diff diverges from the spec. Not bugs. Not style. Divergences only. For each one, quote the spec line and the diff line and say whether the spec is wrong, the code is wrong, or both need to change.

I do not ask for a verdict. The human still does the verdict. What the prompt gives me is an index, and the index is the thing I would never build by hand in a fifteen-minute review window.

Pattern 4: Risk-Register Surfacer

This is the one that pays for itself every week. Here is the exact prompt shape my team uses, with the field labels we actually ship:

ROLE: You are a risk analyst reviewing a feature spec before implementation.

CONTEXT:
<paste the full spec here>

TASK: Surface risks in seven categories. One line per risk, no prose.

CATEGORIES:
1. Data integrity (what could corrupt, leak, or be lost)
2. Access and authorization (who sees what they should not)
3. Availability (what takes the system down)
4. Compatibility (what breaks for existing users or integrations)
5. Compliance (what regulators or contracts care about)
6. Cost (what causes the bill to surprise us)
7. Operational (what on-call has to page someone for)

BOUNDARY: Do not propose mitigations. Do not rank. Do not combine.
If a category has no risk, write "none identified" and stop.

OUTPUT: Markdown with one heading per category and a bullet list beneath.

The categories are not negotiable and the boundary is the key line. The first time I wrote this I let the model propose mitigations and it filled eighty percent of the tokens with reassurance. Cutting that out is what made the pattern useful.

Pattern 5: Spec-to-Tests

Feed in the acceptance criteria list, ask for Given/When/Then cases, one per AC plus one failure variant per AC. The output shape is a single pre block of cases, no commentary. I paste it straight into the test plan document and a human trims from there.

What I have learned: if the AC list is written in product-speak, this pattern returns product-speak tests. Garbage in, confidently-formatted garbage out. The pattern is a mirror. If the output looks thin it means the AC list is thin, and that is the actual bug worth fixing.

Pattern 6: Non-Goals Extractor

This is the hardest prompt to get right and the most valuable when it works. I feed in a PRD or a long Slack thread and ask: what is this project explicitly not trying to do, based only on what the source material implies through exclusion or hedging. Do not speculate. Quote the sentence that implies each non-goal.

Most runs return two or three decent non-goals and one terrible one. That is fine. Two real non-goals captured on day one saves a scope argument on day thirty, and I will take that trade every time.

The Failure Mode Nobody Warns You About

The single biggest mistake I see teams make is asking for everything in one prompt. Generate the spec, the tests, the risks, the rollout plan. The output is always shallow, because the model is splitting attention across six tasks and the context window is burning tokens on transitions between them.

Prompts are pipelines. Draft the spec. Pass the draft to the edge-case hunt. Pass the edge cases back into a spec revision. Pass the revised spec to the risk-register surfacer. Pass the AC list to spec-to-tests. Each stage is narrow and each stage is cheap to rerun when the upstream changes. Cramming the whole workflow into one mega-prompt is the prompt-engineering equivalent of a thousand-line function.

Storing the Library

I keep every pattern in a flat directory of markdown files, one per pattern, with the prompt body, an example input, an example output, and a changelog of when I tweaked the wording and why. This ties back to the prompt library discipline: if a pattern is not versioned and dated, it will silently rot as models change underneath it.

Output format matters more than anyone admits. Structured JSON or templated markdown beats prose every time, because structured output is diffable, parseable, and forces the model to commit. Prose lets it hedge. The patterns in this catalog all specify format, and that is not decoration.

What I Would Tell a New Teammate

Pick two patterns to master before trying the rest. Feature spec draft and risk-register surfacer. Those two alone cover sixty percent of the spec work that matters, and they teach you the meta-pattern by repetition. Everything else is a variation on the same five parts: role, context, task, boundary, shape. Once that shape is muscle memory, writing a new pattern for a new workflow takes about ten minutes and one real example to calibrate against.

Workflow Artifact to Copy

Use this when the article becomes part of a Spec Skills run. It keeps the model output tied to a bounded source packet and gives reviewers something concrete to mark up.

Spec Skills workflow packet: Spec Skills Prompt Patterns for Spec Workflows

Decision to make:
- Use Spec Skills prompt patterns for feature specs, acceptance criteria, spec reviews, risk registers, and controlled AI coding workflows.

Owner check:
- Product owner:
- Engineering owner:
- QA or operations reviewer:

Scope boundary:
- In scope:
- Out of scope:
- Assumption that still needs approval:

Acceptance evidence:
- Test or fixture:
- Log, metric, or screenshot:
- Manual review step:

Tool boundary: the model may draft structure and open questions, but owner approval is still required for scope, contract behavior, and release risk.

Reviewer prompt:
- What would still be ambiguous to someone who missed the planning meeting?
- What evidence would make this safe enough to ship?

Editorial Review Note

Reviewed Apr 28, 2026. This update added a reusable artifact, checked the article against the related topic hub, and tightened the next-step links so the page works as a practical reference rather than a standalone essay.