/dog:spec — Spec-Driven Development

A four-phase development workflow that writes a spec first, plans second, breaks into tasks third, and implements last — with human approval gates at each phase transition.

When to Use

• Starting any feature with unclear or evolving requirements
• When you need to align with the user before writing code
• When a feature might be interpreted multiple ways

When NOT to Use

• Pure bug fixes with obvious solutions — use /dog:investigate instead
• Tasks already specified in a PRP file — use /dog:prp-implement directly

Phases

SPECIFY → spec.md (user stories + acceptance criteria)
    ↓
PLAN → plan.md  [Gate: human approves before TASKS]
    ↓
TASKS → tasks.md (ordered task list)  [Gate: human approves before IMPLEMENT]
    ↓
IMPLEMENT → execute tasks with /dog:verification-before-completion after each

---

Phase 1 — SPECIFY

Goal: Write spec.md with user stories and acceptance criteria.

Output format (spec.md):

# Spec: {feature name}

## Problem Statement
One paragraph: what problem does this solve and for whom?

## User Stories
- As a {user}, I want to {action} so that {benefit}
- ...

## Acceptance Criteria
- [ ] {measurable outcome 1}
- [ ] {measurable outcome 2}
- ...

## Out of Scope
- {what this spec explicitly does NOT include}

## Open Questions
- {anything that needs clarification before planning}

Ask the user for clarification on any open questions before proceeding.

---

Phase 2 — PLAN

Goal: Write plan.md with approach, architecture, and file-level changes.

Output format (plan.md):

# Plan: {feature name}

## Approach
One paragraph: how will this be implemented?

## Architecture
- New files: {list with purpose}
- Modified files: {list with what changes}
- Dependencies: {new packages or services}

## Risks
- {risk}: {mitigation}

## Sequence
1. {step 1}
2. {step 2}
...

Gate: Present plan.md to the user and ask:

"Plan ready. Does this approach look correct? Approve to continue to task breakdown."

Do not proceed without explicit approval.

---

Phase 3 — TASKS

Goal: Write tasks.md with an ordered, executable task list.

Output format (tasks.md):

# Tasks: {feature name}

- [ ] Task 1: {description} — `{file(s)}`
- [ ] Task 2: {description} — `{file(s)}`
...

Rules:

• Each task is independently completable
• Tasks are ordered by dependency (unblocked tasks first)
• Each task names the file(s) it touches

Gate: Present tasks.md to the user and ask:

"Task breakdown ready. Does this look correct? Approve to begin implementation."

Do not begin implementation without explicit approval.

---

Phase 4 — IMPLEMENT

Goal: Execute tasks in order. After each task, run /dog:verification-before-completion.

For each task:

1. Implement the task
2. Run the relevant verification (build, test, lint)
3. Mark the task as [x] in tasks.md
4. Only proceed to the next task if verification passes

If verification fails: fix before proceeding — do not skip ahead.

---

Verification

A complete spec-driven development cycle produces:

1. spec.md with user stories and acceptance criteria
2. plan.md with approach, architecture, and risks
3. tasks.md with all tasks marked [x]
4. All acceptance criteria in spec.md checked off

Related

• Skill: dog:brainstorming, dog:writing-plans, dog:verification-before-completion
• Command: /dog:prp-plan, /dog:prp-implement
• Agent: planner, architect