name: fast-drive version: 1 description: Fast OpenSpec workflow - design -> tasks -> apply artifacts: - id: design generates: design.md description: Self-contained solution brief and execution plan template: design.md instruction: | Create design.md as the self-contained source of truth for what will change, why it is changing, and how the work will be executed. This workflow does not use proposal or specs artifacts. design.md MUST preserve the important outcomes from prior exploration and user discussion so a later apply phase can proceed correctly even after context compression or in a new session. Write for someone who cannot see the earlier conversation. Keep simple changes concise, but include enough detail to make execution unambiguous. Add more detail when any apply: - Cross-cutting change across multiple systems, teams, workstreams, or artifacts - New dependency, integration, vendor, tool, policy, or external input - Significant information model, process model, data model, or ownership changes - Security, privacy, compliance, performance, operational, or migration complexity - Ambiguity that benefits from decisions before execution - Prior discussion settled non-obvious requirements, constraints, or rejected alternatives Required sections: - **Context**: Problem, current state, relevant references, and the user request that triggered this change - **Discussion Notes**: Key points from exploration or prior discussion that must not be lost. Include agreed conclusions, user preferences, constraints, and important rejected ideas. - **Requirements**: Expected outcomes, behavior/process/interface/content changes, continuity expectations, and acceptance criteria. - **Goals / Non-Goals**: What this change will achieve and what is explicitly out of scope. - **Execution Guardrails**: Must-follow constraints, forbidden approaches, preserved behavior/processes, dependency limits, and project- or workflow-specific boundaries. - **Affected Areas**: Concrete artifacts, references, stakeholders, systems, workstreams, documents, configurations, assets, or handoffs that are relevant to the change. - **Decisions**: Key choices with rationale (why X over Y?). For each important decision, include alternatives considered and why they were not chosen. - **Execution Plan**: Main workstreams or artifacts to change, integration or handoff points, sequencing, and any rollout notes. - **Verification Plan**: Validation checks, reviews, approvals, acceptance checks, documentation checks, communication checks, and manual checks needed to prove the change is complete. - **Risks / Trade-offs**: Known limitations and things that could go wrong. Format: [Risk] -> Mitigation - **Open Questions**: Outstanding decisions, assumptions, or unknowns to resolve before execution. Separate blocking questions that must pause apply from non-blocking follow-ups. Use "None" if there are no open questions. Optional sections when relevant: - **Migration / Rollout Plan**: Rollout steps, communication, ownership, rollback, or continuity strategy. Focus on preserving requirements, rationale, constraints, and approach. Avoid line-by-line or step-by-step details unless a detail is a deliberate decision from the discussion. Prefer durable summaries over chat transcripts. Use concrete artifact names, data/information shapes, examples, stakeholders, ownership, and edge cases when they affect execution. Do not use task checkboxes in design.md; checkboxes belong only in tasks.md. Final design.md must not contain unresolved template comments, empty table rows, or placeholder text. If information is missing, state assumptions and open questions instead of inventing hidden requirements. Do not rely on unstated chat context. requires: [] - id: tasks generates: tasks.md description: Trackable execution checklist derived from design.md template: tasks.md instruction: | Create tasks.md by breaking design.md into executable work. **IMPORTANT: Follow the template below exactly.** The apply phase parses checkbox format to track progress. Tasks not using `- [ ]` will not be tracked. Guidelines: - Derive tasks from design.md. Do not depend on proposal.md or specs artifacts; any relevant prior discussion must already be captured in design.md. - Group related tasks under `##` numbered headings - Each task MUST be a single-line checkbox: `- [ ] X.Y Task description` - Tasks should be small enough to complete in one session - Order tasks by dependency (what must be done first?) - Start with context review tasks when execution depends on guardrails, affected areas, or open questions - Include validation tasks for checks, reviews, approvals, acceptance, documentation, communication, and manual checks when required - Do not include repository, version-control, or release operation tasks unless they are explicitly part of the change scope - Final tasks.md must not contain unresolved template comments, empty table rows, or placeholder task text Example: ``` ## 1. Context Review - [ ] 1.1 Read design.md and identify scope, requirements, decisions, guardrails, and open questions - [ ] 1.2 Review relevant artifacts and references listed in Affected Areas ## 2. Execution - [ ] 2.1 Execute first concrete work item from design.md - [ ] 2.2 Execute next concrete work item from design.md ## 3. Validation - [ ] 3.1 Run required validation from Verification Plan - [ ] 3.2 Perform quality checks required by the project or workflow - [ ] 3.3 Perform required manual review or acceptance checks from Verification Plan ## 4. Documentation / Communication - [ ] 4.1 Update relevant documentation, runbooks, communication materials, or project references if behavior, process, interface, configuration, or usage changed ``` Reference design.md for scope, requirements, decisions, execution direction, and verification expectations. Each task should be verifiable: it must be clear when the task is done. requires: - design apply: requires: - design - tasks tracks: tasks.md instruction: | Read design.md first, then tasks.md. Also follow workflow context/configuration, such as openspec/config.yaml when available, and any relevant project or workflow documentation referenced by design.md. Treat design.md as the source of truth for scope, requirements, decisions, guardrails, execution direction, and verification expectations. Work through pending tasks in dependency order and mark complete as you go. Mark a task complete only after its execution and required verification are done. Pause if tasks conflict with design.md, if design.md has blocking open questions, or if clarification is needed.