---
name: conversation-to-spec
description: "Turns a discussion into a spec with goals, non-goals, decisions, open questions and acceptance criteria that can be tested. Use when a conversation or meeting notes need to become a written spec with testable acceptance criteria. Do not use for breaking a finished spec into tickets or interviewing someone to uncover requirements. Related topics: product, writing."
---

# Conversation to Spec

Turns a discussion into a spec with goals, non-goals, decisions, open questions and acceptance criteria that can be tested.

## When to use

Use this skill when a conversation or meeting notes need to become a written spec with testable acceptance criteria. Do not use it for breaking a finished spec into tickets or interviewing someone to uncover requirements.

## Workflow

1. Ask the user for each input listed below in a single message, skipping any they have already given. Where options are listed, offer them, but accept other answers too.
2. Separate what was decided from what was suggested or left open in the discussion.
3. Write the problem, goal and non-goals in plain words before any behavior.
4. Describe the behavior concretely with example inputs and outputs and record each decision with its reason.
5. Turn requirements into acceptance criteria that are observable checks, one result each.
6. Mark assumptions, list open questions with owners, and flag the least certain statements.

## Inputs

- **Discussion notes** (longer free text)
- **Feature name** (free text, e.g. "Short working name")
- **Audience for the spec** (choose one: Engineers, Product and design, Mixed team)
- **Known constraints** (longer free text)
- **Detail level** (choose one: One page, Standard, Detailed)

## Output

A spec with problem, goal, non-goals, decisions, behavior with examples, constraints, open questions and acceptance criteria, ending with a shaky-statements list.

## Prompt template

Fill the inputs into this template and follow it as the full instruction.

### Conversation to Spec

Turn this discussion into a spec.

- Discussion notes: {{Discussion notes}}
- Feature name: {{Feature name}}
- Audience for the spec: {{Audience for the spec}}
- Known constraints: {{Known constraints}}
- Detail level: {{Detail level}}

Read the whole discussion and separate what was decided from what was merely suggested. Write the spec in this order: problem and goal in plain words; non-goals, which prevent scope creep; decisions made, each with its reason; the behavior in concrete terms, with examples of inputs and outputs; constraints; open questions with a proposed owner; and acceptance criteria written as checks anyone can run, one observable result each. Mark anything that was only implied as an assumption instead of stating it as fact. Do not add features nobody mentioned. Keep terms consistent and define any term used in a special sense. End with a list of the sentences you are least sure were agreed.

## Pitfalls

- Presenting a floated idea as a decision, which the team then builds.
- Acceptance criteria such as 'works well', which nobody can check.
- Inventing requirements to fill gaps instead of listing them as open questions.