sspec-plan

name	sspec-plan
description	Break design into concrete tasks. Fill tasks.md with file-level execution plan. Use after design alignment.
metadata	{"author":"frostime","version":"3.0.0"}

SSPEC Plan

---

Output Contract

When this phase ends, tasks.md MUST contain:

• Phases with file-level tasks (single/sub) OR milestones (root)
• Verification criteria for each phase
• User Check steps for phases that implement user-visible BC-* behavior
• Progress section initialized

Task Quality Standards

Each task SHOULD be:

• Specific: names exact file path + action
• Small: <2 hours
• Independently testable: has an obvious check

Reference Spec, Don't Repeat

tasks.md references spec.md / design.md — never re-describe design.

spec.md / design.md	tasks.md
Defines behavior contracts, interfaces, data model, logic	Lists file-level actions + verification
Explains how it should work	Tells agent what to do next and how to verify
BC-1: cache hit behavior	User Check: BC-1: sign in twice -> second request uses cache
feat(cache): Add user cache module	Create cache.py — implement interface per spec

• ✅ "Implement feat(cache): Add user cache module per spec"
• ✅ "Create handler following the data flow in design.md"
• ✅ "User Check: BC-1: run command X -> observe output Y"
• ❌ Re-listing all function signatures
• ❌ Re-describing the algorithm
• ❌ Defining new behavior that is not in spec.md Behavior Contract

Single/Sub vs Root

change-type	tasks.md form
single / sub	Phase-based, file-level tasks (<2h each)
root	Milestone-based, one entry per sub-change (no file-level detail)

Root rules: no file-level tasks; each phase has Deliverable + Sub-change link; root stays active until all sub-changes complete.

Verification

Each phase MUST have explicit verification criteria.

Use this split:

• Verification: agent-run checks such as test commands, build/lint, sandbox CLI runs, and expected output.
• User Check: black-box review steps for user-visible BC-* behavior. State user action + expected observable result.

Rules:

• Behavior boundary/default/error/compatibility changes SHOULD include User Check unless impractical.
• Pure internal/refactor-only changes MAY omit User Check when spec.md states no user-visible behavior change.
• Do not write "it works"; name the specific passing condition.

Exit: @align Report

Present the task breakdown (phases, total tasks, key Verification/User Check criteria). This is a report, not a hard gate — continue to sspec-implement unless the user interrupts.

📚 Examples: examples.md