@gordon.gan/specflow 1.0.0

package/prompts/plan/design-draft.md

@@ -0,0 +1,123 @@
+> **HARD GATE — READ THIS FIRST.** This is the **first iteration of deep design analysis**, NOT a placeholder skeleton and NOT a template to fill in later. If your output is "TBD", "to be decided in refine", empty bullets, or boilerplate section headers with no substance, you have failed this task. The refine phase will deepen and challenge this design — but it needs substantive material to challenge. Stub-quality output wastes the refine pass.
+
+# Plan Phase: First-Iteration Design Draft
+
+## Purpose
+
+Generate a substantive `design.md` representing your **first round of deep thinking** on this change. This is v1 of the design — refine will produce v2 by challenging assumptions, proposing alternative options, probing edge cases, and questioning scope. Your job here is to give refine something real to work with.
+
+## Inputs You Must Read
+
+- `specflow/changes/<change-name>/proposal.md` — the approved proposal
+- `specflow/changes/<change-name>/specs/<capability>/spec.md` — all delta specs
+- `specflow/specs/` (if it exists) — current main specs for conflict awareness
+- The codebase itself — read enough files to understand what exists today
+
+## Reference Example (IMPORTANT)
+
+**Before you start writing, read this example for structural and depth guidance:**
+
+`.claude/specflow/prompts/reference/specflow/example-design.md`
+
+That example is the archived design from the `create-specflow-plugin` change. Note specifically:
+
+- Each Decision has a **name**, multiple **Options considered** with trade-offs, a **Chosen** option, and a **Rationale** tying the choice back to the goals
+- Goals and Non-Goals are **specific to that change** (not generic software engineering platitudes)
+- Risks are **tied to the actual change** (port maintenance burden, progressive loading reliability, dependency cost) — not generic project management risks
+- Open Questions are concrete ("Should we register on marketplace for V1?") — not filler
+
+**Use the example as a quality bar, NOT as a content template to copy.** Your change is different; your decisions, risks, and goals are different. Match the **depth and format**, not the words.
+
+## What To Produce
+
+Generate `design.md` with the following sections. Each section has specific instructions — follow them literally.
+
+### 1. Context
+
+Describe what exists today and why this change is needed. Include:
+
+- Relevant subsystems and their current state
+- Technical constraints (language, platform, existing patterns)
+- Why now — what forces this change
+
+Not a place for "we want to build feature X." That belongs in the proposal. Context is the **technical landscape** the change lands in.
+
+### 2. Goals / Non-Goals
+
+**Identify the real Goals and Non-Goals of THIS change specifically.**
+
+- Goals: tied to success criteria from the proposal, but technically stated ("port 6 OpenSpec modules" — not "make the CLI better")
+- Non-Goals: explicit scope exclusions that a reasonable reader might assume are included ("not supporting non-Claude-Code AI tools in V1" — not generic "we will not boil the ocean")
+
+Generic goals like "maintainable code" or "good performance" are **not Goals** — those are engineering defaults. Only list Goals that are distinctive to this change.
+
+### 3. Design Decisions
+
+**Identify the real architectural decisions this change requires** — i.e., identify real branch points, not imagined ones. For each decision:
+
+1. Give it a clear name (e.g., "D1: Unified npm package with CLI + plugin")
+2. List **Options considered** — at least 2, usually 3. Each option with its trade-offs.
+3. State **Chosen** — which option you're recommending
+4. Give **Rationale** — the reasoning tying your chosen option to the Goals. Every decision needs its rationale spelled out.
+
+**Find the decisions that actually branch.** Don't invent decisions where there's no real choice. Don't skip decisions because "the answer is obvious" — write it down with the options considered and the rationale for why it's obvious.
+
+Signals that you've found a real decision:
+- "We could do X or Y, and both have real costs"
+- "The naive approach is X, but it breaks when Z"
+- "The proposal implies X but there's a tension with Y"
+
+If during this first iteration you are genuinely uncertain about an option, **mark the decision `(plan-phase analysis, may revise in refine)`**. Honesty about uncertainty is better than false certainty — refine exists precisely to close these gaps. Do NOT use this marker as an escape hatch for every decision; use it only where you actually lack information.
+
+### 4. Risks / Trade-offs
+
+**Identify specific risks tied to THIS change.** Each risk should:
+- Be concrete enough that a reader can imagine it materializing
+- Include a mitigation (what reduces likelihood or impact)
+
+**Avoid generic risks** like "schedule delay", "scope creep", "team availability", "technical debt", "unknown unknowns" — unless the risk is genuinely tied to this change (e.g., "scope creep because spec has 7 capabilities that could each justify a separate change"). If a risk applies to every software project, it's not a design risk — it's a project management concern.
+
+Good risks look like: "Port maintenance burden — 2800 lines diverging from upstream OpenSpec." Bad risks look like: "Delays may occur if the team is busy."
+
+### 5. Migration Plan (if applicable)
+
+If the change affects existing users, data, configs, or APIs, describe the migration path. If it's greenfield, you may write "N/A — greenfield change" and move on. Don't write a placeholder migration for a greenfield change.
+
+### 6. Open Questions
+
+List specific questions you genuinely cannot answer from proposal + specs + code alone. These will be addressed in refine. Examples:
+
+- "Exact CLI command naming — to be designed during implementation"
+- "Should we support operation X or defer to a future change?"
+
+If you have no real open questions, write "None at this stage" rather than inventing filler.
+
+## Quality Is Not Quantity-Gated
+
+There is **no minimum number** of decisions, risks, or open questions. Two well-argued decisions are better than five shallow ones. The user reviewing the design is the quality judge, not a counter.
+
+What matters:
+- Decisions trace to real architectural branches
+- Options have honest trade-offs, not strawmen
+- Rationale ties to Goals
+- Risks are specific and mitigable
+- The reader finishes the document knowing **how** you'd build this, not just **what**
+
+## Save and Proceed
+
+Save the document to:
+
+```
+specflow/changes/<change-name>/design.md
+```
+
+**Do NOT ask the user to confirm this draft at this stage.** The end-of-plan summary (handled by the orchestrating SKILL) will present all four plan-phase artifacts together for one cohesive user review. Write the best first-iteration design you can, save it, and move on to the next plan-phase artifact.
+
+## Remember
+
+- First iteration, not placeholder
+- Substance over structure — skip sections with "N/A" rather than fake-filling them
+- Reference example is a depth guide, not a copy target
+- Honest uncertainty > false certainty — use the `(plan-phase analysis, may revise in refine)` marker when genuinely uncertain
+- No quantity gates — quality is judged by user review
+- No confirmation gate here — the SKILL handles overall plan-phase review

package/prompts/plan/proposal.md

@@ -0,0 +1,85 @@
+> **HARD GATE**: User must confirm the proposal direction before proceeding to spec generation. Do NOT generate delta specs until the user has reviewed and approved the proposal.
+
+# Proposal Generation
+
+Generate a proposal document following the SpecFlow format. The proposal establishes WHY a change is needed and WHAT it affects.
+
+## Process
+
+### Step 1: Baseline Awareness
+
+Check if `specflow/specs/` exists and contains spec files:
+
+```bash
+ls specflow/specs/ 2>/dev/null
+```
+
+**If specs exist:**
+1. List all existing spec files
+2. Identify which specs may be affected by the proposed change
+3. Note potential conflicts or dependencies
+4. Report: "Found N existing specs. The following may be affected: [list]"
+
+**If no specs exist:**
+- This is a greenfield change; note that no baseline specs need to be considered
+
+### Step 2: Gather Proposal Information
+
+Ask the user (one question at a time):
+
+1. **What is the change?** — One sentence summary
+2. **Why is this needed?** — Motivation and context
+3. **What is the expected outcome?** — Success criteria
+4. **What areas are affected?** — Components, modules, interfaces
+
+### Step 3: Generate Proposal Document
+
+**CRITICAL: Use the exact format below.** The `Capabilities` section creates the contract between proposal and specs phases — each capability listed here will need a corresponding spec file.
+
+```markdown
+## Why
+
+<!-- 1-2 sentences on the problem or opportunity. What problem does this solve? Why now? -->
+
+## What Changes
+
+<!-- Bullet list of changes. Be specific about new capabilities, modifications, or removals. Mark breaking changes with **BREAKING**. -->
+
+## Capabilities
+
+### New Capabilities
+<!-- Capabilities being introduced. Use kebab-case names (e.g., user-auth, data-export). Each creates specs/<name>/spec.md -->
+- `<name>`: <brief description>
+
+### Modified Capabilities
+<!-- Existing capabilities whose REQUIREMENTS are changing. Use existing spec names from specflow/specs/. Leave empty if no requirement changes. -->
+- `<existing-name>`: <what requirement is changing>
+
+## Impact
+
+<!-- Affected code, APIs, dependencies, systems -->
+```
+
+**Requirements:**
+- Keep concise (1-2 pages)
+- Focus on "why" not "how" — implementation details belong in design.md
+- Research existing specs before filling in the Capabilities section
+- Use the exact section headings shown above (`## Why`, `## What Changes`, `## Capabilities`, `## Impact`)
+
+### Step 4: Save and Present
+
+Save to: `specflow/changes/<change-name>/proposal.md`
+
+Present to user for review:
+
+> "Proposal saved to `specflow/changes/<change-name>/proposal.md`. Please review the direction and affected areas. Once you confirm, I'll proceed to generate delta specs for each affected capability."
+
+### Step 5: Gate — Wait for User Confirmation
+
+**Do NOT proceed to spec generation until the user confirms.**
+
+If the user requests changes, update the proposal and re-present.
+
+## Next Step
+
+Once approved, proceed to generate delta specs.

package/prompts/plan/specs.md

@@ -0,0 +1,114 @@
+# Delta Specs Generation
+
+Generate delta spec files that define WHAT the system should do for each affected capability.
+
+## Prerequisites
+
+- An approved proposal exists at `specflow/changes/<change-name>/proposal.md`
+- User has confirmed the proposal direction
+
+## Process
+
+### Step 1: Read Proposal
+
+Read the approved proposal. Extract:
+- Which capabilities are listed under `### New Capabilities` and `### Modified Capabilities`
+- Success criteria to translate into scenarios
+
+### Step 2: Read Existing Specs (if modifying)
+
+If modifying existing capabilities, read the current spec from `specflow/specs/<capability>/spec.md`:
+1. Understand the current requirements and scenarios
+2. For MODIFIED requirements, copy the ENTIRE requirement block first, then edit
+
+### Step 3: Generate Delta Spec Files
+
+Create one spec file per capability at `specflow/changes/<change-name>/specs/<capability>/spec.md`.
+
+**CRITICAL FORMAT — the specflow CLI parses this exact structure. Deviations will cause validation and archive failures.**
+
+Use `##` headers for delta operation sections. Use `###` for requirements. Use `####` for scenarios. Use `- **WHEN**` and `- **THEN**` bullet format for scenario steps.
+
+```markdown
+## ADDED Requirements
+
+### Requirement: <requirement name>
+<Description using SHALL/MUST for normative language.>
+
+#### Scenario: <scenario name>
+- **WHEN** <precondition or trigger>
+- **THEN** <expected outcome>
+
+#### Scenario: <another scenario>
+- **WHEN** <condition>
+- **THEN** <outcome>
+
+## MODIFIED Requirements
+
+### Requirement: <existing requirement name>
+<Full updated description — MUST include complete content, not just the diff.>
+
+#### Scenario: <scenario name>
+- **WHEN** <condition>
+- **THEN** <new expected outcome>
+
+## REMOVED Requirements
+
+### Requirement: <requirement name>
+**Reason**: <why this is being removed>
+**Migration**: <how users should adapt>
+
+## RENAMED Requirements
+
+FROM: <old requirement name>
+TO: <new requirement name>
+```
+
+**Format rules:**
+- Each requirement: `### Requirement: <name>` followed by description
+- Use SHALL/MUST for normative requirements (avoid should/may)
+- Each scenario: `#### Scenario: <name>` — **MUST use exactly 4 hashtags (`####`)**. Using 3 hashtags will fail validation silently.
+- Scenario steps: `- **WHEN** <condition>` and `- **THEN** <outcome>` — **MUST use bullet dash + bold format**
+- Every requirement MUST have at least one scenario
+- Only include the sections you need (e.g., only `## ADDED Requirements` for new capabilities)
+
+**MODIFIED requirements workflow:**
+1. Read the existing requirement from `specflow/specs/<capability>/spec.md`
+2. Copy the ENTIRE requirement block (from `### Requirement:` through all scenarios)
+3. Paste under `## MODIFIED Requirements` and edit to reflect new behavior
+4. The requirement name must match exactly (whitespace-insensitive)
+
+**Common pitfall:** Using MODIFIED with partial content loses detail during archive. If adding new concerns without changing existing behavior, use ADDED instead.
+
+### Step 4: Validate
+
+Run validation on each generated spec file:
+
+```bash
+specflow validate specflow/changes/<change-name>/specs/<capability>/spec.md
+```
+
+If validation fails, fix the format issues and re-validate.
+
+### Step 5: Save and Present
+
+Save each spec file. Then present a summary:
+
+> "Generated N delta specs:
+> - `<capability-1>`: ADDED (N requirements, M scenarios)
+> - `<capability-2>`: MODIFIED (N requirements)
+>
+> All validated. Files at `specflow/changes/<change-name>/specs/`."
+
+## Principles
+
+- **One delta spec per capability** — don't merge unrelated capabilities
+- **WHEN/THEN is mandatory** — every behavioral change must have at least one scenario
+- **Be specific** — "WHEN user runs `notecli export`" not "WHEN user interacts"
+- **Include negative scenarios** — error cases, edge cases, empty states
+- **Specs are testable** — each scenario is a potential test case
+- **No implementation details** — describe behavior, not how to build it
+
+## Next Step
+
+Once delta specs are approved, proceed to `/specflow:refine` for design work or `/specflow:build` for planning.

package/prompts/plan/tasks-draft.md

@@ -0,0 +1,123 @@
+> **HARD GATE — READ THIS FIRST.** Generate substantive first-iteration tasks. Not placeholders. Not "TBD". Not empty group headers. Each group gets real tasks with concrete verbs. Build Phase A will later rewrite this to writing-plans precision (exact paths, code blocks, bite-sized steps) — but you are producing the first honest pass at "what needs to happen," not a skeleton for someone else to fill.
+
+# Plan Phase: First-Iteration Tasks Draft
+
+## Purpose
+
+Generate a substantive first-iteration `tasks.md` that maps the change into coarse, concrete work items. This is **v1 of the task plan** — Build Phase A will use writing-plans to produce v2 (with exact file paths, code snippets, and bite-sized test-first steps). Your job here is to outline the real work so refine can challenge it and Build Phase A can refine it into executable form.
+
+## Inputs You Must Read
+
+- `specflow/changes/<change-name>/proposal.md` — establishes scope and capabilities
+- `specflow/changes/<change-name>/specs/<capability>/spec.md` — delta specs define behavior
+- `specflow/changes/<change-name>/design.md` — design decisions that drive the tasks
+- `templates/tasks.md` (if it exists in the SpecFlow install) — the tasks template scaffold
+
+## Top-of-File Marker (Required)
+
+The generated `tasks.md` file **must begin** with this HTML comment as its first line (this is content you inject into the output file, not part of this prompt):
+
+```
+<!-- Plan-phase first-iteration tasks. Will be rewritten to writing-plans precision in /specflow:build Phase A. -->
+```
+
+This marker tells future readers (and the Build Phase A prompt) that this document is coarse-grained by design and will be rewritten to a stricter format later.
+
+## Structure Rules
+
+1. **3 to 8 task groups** at the top level
+   - Each group uses `## N. <Group Name>` as its header (where N is a positive integer starting at 1)
+   - Group names are capability- or layer-oriented, not generic ("Core artifact management" — not "Phase 1")
+
+2. **Each group contains 2 to 6 concrete checkbox items**
+   - Format: `- [ ] N.M <动作短语>` where N is the group number and M is the item index within the group
+   - Mixed Chinese and English is acceptable (project convention); pick the language the action verb flows in
+
+3. **Items are concrete actions, not topics**
+   - "实现 searchNotes 纯函数" (good — specific function)
+   - "添加 CLI --verbose 标志并接入 logger" (good — specific change)
+   - "处理搜索逻辑" (bad — vague topic, not an action)
+   - "handle searching" (bad — same problem in English)
+   - "完善测试" (bad — improvement verb without a subject)
+
+4. **Each item should be a coherent unit of work** — roughly the size that Build Phase A will later expand into a handful of bite-sized TDD steps. If an item feels like it's really 5 unrelated actions, split it.
+
+## Grouping Guidance
+
+Let the change characteristics drive the grouping. Two common strategies — pick whichever fits better, or mix them deliberately:
+
+- **By capability**: each spec capability becomes a group. Good when the change introduces parallel capabilities with clean seams between them.
+  - Example: `## 1. notes-search capability`, `## 2. notes-export capability`
+- **By implementation layer**: data → service → API → CLI → docs. Good when the change touches many layers of one feature.
+  - Example: `## 1. Schema and migrations`, `## 2. Repository layer`, `## 3. Service layer`, `## 4. CLI wiring`, `## 5. Tests and verification`
+
+If the change has both parallel capabilities and deep layering, a two-level grouping is fine (groups by capability, items implicitly ordered layer-by-layer inside each group).
+
+## Example — Good Granularity
+
+Below is a short worked example for a hypothetical "add search to notes CLI" change. Study the **granularity and verb concreteness**, not the specific content.
+
+```markdown
+<!-- Plan-phase first-iteration tasks. Will be rewritten to writing-plans precision in /specflow:build Phase A. -->
+
+# notes-search Implementation Tasks
+
+## 1. 搜索核心逻辑
+
+- [ ] 1.1 实现 searchNotes 纯函数（输入: notes[], query; 输出: 匹配列表）
+- [ ] 1.2 实现 fuzzy-match 评分算法并暴露 scoreNote(note, query)
+- [ ] 1.3 为 searchNotes 和 scoreNote 写单元测试（覆盖空 query、空 notes、多匹配排序）
+
+## 2. 持久化层接入
+
+- [ ] 2.1 在 NoteRepository 上增加 listAllForSearch 方法（不分页）
+- [ ] 2.2 更新 InMemoryNoteRepository 的测试夹具提供搜索样本数据
+
+## 3. CLI 命令
+
+- [ ] 3.1 新增 `notes search <query>` 子命令并接入 commander 路由
+- [ ] 3.2 实现 search 命令的输出格式（按分数降序，截断正文到 80 字符）
+- [ ] 3.3 为 CLI 命令写集成测试（调用子命令，断言输出）
+
+## 4. 文档与样例
+
+- [ ] 4.1 在 README 的 Usage 段落增加 search 示例
+- [ ] 4.2 在 specflow/specs/notes-search/spec.md 对齐最终命令形态
+```
+
+Note how each item names a specific artifact or action (`searchNotes` function, `NoteRepository.listAllForSearch` method, `notes search <query>` command) rather than a fuzzy area ("handle searching", "improve CLI"). That level of concreteness is the target.
+
+## What This Draft Is NOT
+
+- It is **not** the writing-plans format. Build Phase A does that rewrite with exact file paths, code blocks, and `Write test → Run test → Implement → Run test → Commit` per step. Do not pre-write those here — you don't yet have the design detail to do it well, and duplicating effort wastes the refine pass.
+- It is **not** a skeleton to be filled in. Every item should reflect a real action you'd expect to perform.
+- It is **not** a design document. If you find yourself writing "decide whether to use X or Y" as a task, that's a design decision that belongs in `design.md`. Move it there.
+
+## Coverage Check
+
+After drafting, skim your task list against the design and specs:
+
+- Is every capability in the delta specs represented by at least one task?
+- Does every design decision that requires implementation work have tasks backing it?
+- Are tests called out as explicit items (they should be — even at this granularity)?
+- Is documentation covered if the design introduces user-facing changes?
+
+If a capability or design decision has **no tasks**, either add them or note in `design.md` that this part is out-of-scope / handled by the existing code. Silent gaps are the failure mode to avoid.
+
+## Save and Proceed
+
+Save the document to:
+
+```
+specflow/changes/<change-name>/tasks.md
+```
+
+**Do NOT ask the user to confirm this draft at this stage.** The orchestrating SKILL will present all plan-phase artifacts together at the end of the plan phase. Refine will challenge and restructure; Build Phase A will rewrite to precision. Your job is to hand off a substantive first pass.
+
+## Remember
+
+- Substantive, not placeholder
+- 3 to 8 groups, 2 to 6 items each
+- Concrete verbs on concrete subjects
+- Top-of-file marker comment is mandatory
+- Writing-plans precision comes in Build Phase A — do not pre-write it here

package/prompts/reference/openspec/apply-instruction.md

@@ -0,0 +1,2 @@
+Read context files, work through pending tasks, mark complete as you go.
+Pause if you hit blockers or need clarification.

package/prompts/reference/openspec/design-instruction.md

@@ -0,0 +1,20 @@
+Create the design document that explains HOW to implement the change.
+
+When to include design.md (create only if any apply):
+- Cross-cutting change (multiple services/modules) or new architectural pattern
+- New external dependency or significant data model changes
+- Security, performance, or migration complexity
+- Ambiguity that benefits from technical decisions before coding
+
+Sections:
+- **Context**: Background, current state, constraints, stakeholders
+- **Goals / Non-Goals**: What this design achieves and explicitly excludes
+- **Decisions**: Key technical choices with rationale (why X over Y?). Include alternatives considered for each decision.
+- **Risks / Trade-offs**: Known limitations, things that could go wrong. Format: [Risk] → Mitigation
+- **Migration Plan**: Steps to deploy, rollback strategy (if applicable)
+- **Open Questions**: Outstanding decisions or unknowns to resolve
+
+Focus on architecture and approach, not line-by-line implementation.
+Reference the proposal for motivation and specs for requirements.
+
+Good design docs explain the "why" behind technical decisions.

package/prompts/reference/openspec/proposal-instruction.md

@@ -0,0 +1,18 @@
+Create the proposal document that establishes WHY this change is needed.
+
+Sections:
+- **Why**: 1-2 sentences on the problem or opportunity. What problem does this solve? Why now?
+- **What Changes**: Bullet list of changes. Be specific about new capabilities, modifications, or removals. Mark breaking changes with **BREAKING**.
+- **Capabilities**: Identify which specs will be created or modified:
+  - **New Capabilities**: List capabilities being introduced. Each becomes a new `specs/<name>/spec.md`. Use kebab-case names (e.g., `user-auth`, `data-export`).
+  - **Modified Capabilities**: List existing capabilities whose REQUIREMENTS are changing. Only include if spec-level behavior changes (not just implementation details). Each needs a delta spec file. Check `specflow/specs/` for existing spec names. Leave empty if no requirement changes.
+- **Impact**: Affected code, APIs, dependencies, or systems.
+
+IMPORTANT: The Capabilities section is critical. It creates the contract between
+proposal and specs phases. Research existing specs before filling this in.
+Each capability listed here will need a corresponding spec file.
+
+Keep it concise (1-2 pages). Focus on the "why" not the "how" -
+implementation details belong in design.md.
+
+This is the foundation - specs, design, and tasks all build on this.

package/prompts/reference/openspec/specs-instruction.md

@@ -0,0 +1,47 @@
+Create specification files that define WHAT the system should do.
+
+Create one spec file per capability listed in the proposal's Capabilities section.
+- New capabilities: use the exact kebab-case name from the proposal (specs/<capability>/spec.md).
+- Modified capabilities: use the existing spec folder name from specflow/specs/<capability>/ when creating the delta spec at specs/<capability>/spec.md.
+
+Delta operations (use ## headers):
+- **ADDED Requirements**: New capabilities
+- **MODIFIED Requirements**: Changed behavior - MUST include full updated content
+- **REMOVED Requirements**: Deprecated features - MUST include **Reason** and **Migration**
+- **RENAMED Requirements**: Name changes only - use FROM:/TO: format
+
+Format requirements:
+- Each requirement: `### Requirement: <name>` followed by description
+- Use SHALL/MUST for normative requirements (avoid should/may)
+- Each scenario: `#### Scenario: <name>` with WHEN/THEN format
+- **CRITICAL**: Scenarios MUST use exactly 4 hashtags (`####`). Using 3 hashtags or bullets will fail silently.
+- Every requirement MUST have at least one scenario.
+
+MODIFIED requirements workflow:
+1. Locate the existing requirement in specflow/specs/<capability>/spec.md
+2. Copy the ENTIRE requirement block (from `### Requirement:` through all scenarios)
+3. Paste under `## MODIFIED Requirements` and edit to reflect new behavior
+4. Ensure header text matches exactly (whitespace-insensitive)
+
+Common pitfall: Using MODIFIED with partial content loses detail at archive time.
+If adding new concerns without changing existing behavior, use ADDED instead.
+
+Example:
+```
+## ADDED Requirements
+
+### Requirement: User can export data
+The system SHALL allow users to export their data in CSV format.
+
+#### Scenario: Successful export
+- **WHEN** user clicks "Export" button
+- **THEN** system downloads a CSV file with all user data
+
+## REMOVED Requirements
+
+### Requirement: Legacy export
+**Reason**: Replaced by new export system
+**Migration**: Use new export endpoint at /api/v2/export
+```
+
+Specs should be testable - each scenario is a potential test case.

package/prompts/reference/openspec/tasks-instruction.md

@@ -0,0 +1,26 @@
+Create the task list that breaks down the implementation work.
+
+**IMPORTANT: Follow the template below exactly.** The apply phase parses
+checkbox format to track progress. Tasks not using `- [ ]` won't be tracked.
+
+Guidelines:
+- Group related tasks under ## numbered headings
+- Each task MUST be a checkbox: `- [ ] X.Y Task description`
+- Tasks should be small enough to complete in one session
+- Order tasks by dependency (what must be done first?)
+
+Example:
+```
+## 1. Setup
+
+- [ ] 1.1 Create new module structure
+- [ ] 1.2 Add dependencies to package.json
+
+## 2. Core Implementation
+
+- [ ] 2.1 Implement data export function
+- [ ] 2.2 Add CSV formatting utilities
+```
+
+Reference specs for what needs to be built, design for how to build it.
+Each task should be verifiable - you know when it's done.