@dynamicworks/br-openspec 1.3.1 → 2.0.1

package/dist/utils/change-metadata.js

@@ -4,6 +4,7 @@ import * as yaml from 'yaml';
 import { ChangeMetadataSchema } from '../core/artifact-graph/types.js';
 import { listSchemas } from '../core/artifact-graph/resolver.js';
 import { readProjectConfig } from '../core/project-config.js';
+import { CHANGE_METADATA_MESSAGES } from '../messages/index.js';
 const METADATA_FILENAME = '.openspec.yaml';
 /**
  * Error thrown when change metadata validation fails.
@@ -29,7 +30,7 @@ export class ChangeMetadataError extends Error {
 export function validateSchemaName(schemaName, projectRoot) {
     const availableSchemas = listSchemas(projectRoot);
     if (!availableSchemas.includes(schemaName)) {
-        throw new Error(`Unknown schema '${schemaName}'. Available: ${availableSchemas.join(', ')}`);
+        throw new Error(CHANGE_METADATA_MESSAGES.unknownSchema(schemaName, availableSchemas.join(', ')));
     }
     return schemaName;
 }
@@ -48,7 +49,7 @@ export function writeChangeMetadata(changeDir, metadata, projectRoot) {
     // Validate with Zod
     const parseResult = ChangeMetadataSchema.safeParse(metadata);
     if (!parseResult.success) {
-        throw new ChangeMetadataError(`Invalid metadata: ${parseResult.error.message}`, metaPath);
+        throw new ChangeMetadataError(CHANGE_METADATA_MESSAGES.invalidMetadata(parseResult.error.message), metaPath);
     }
     // Write YAML file
     const content = yaml.stringify(parseResult.data);
@@ -57,7 +58,7 @@ export function writeChangeMetadata(changeDir, metadata, projectRoot) {
     }
     catch (err) {
         const ioError = err instanceof Error ? err : new Error(String(err));
-        throw new ChangeMetadataError(`Failed to write metadata: ${ioError.message}`, metaPath, ioError);
+        throw new ChangeMetadataError(CHANGE_METADATA_MESSAGES.failedToWriteMetadata(ioError.message), metaPath, ioError);
     }
 }
 /**
@@ -79,7 +80,7 @@ export function readChangeMetadata(changeDir, projectRoot) {
     }
     catch (err) {
         const ioError = err instanceof Error ? err : new Error(String(err));
-        throw new ChangeMetadataError(`Failed to read metadata: ${ioError.message}`, metaPath, ioError);
+        throw new ChangeMetadataError(CHANGE_METADATA_MESSAGES.failedToReadMetadata(ioError.message), metaPath, ioError);
     }
     let parsed;
     try {
@@ -87,17 +88,17 @@ export function readChangeMetadata(changeDir, projectRoot) {
     }
     catch (err) {
         const parseError = err instanceof Error ? err : new Error(String(err));
-        throw new ChangeMetadataError(`Invalid YAML in metadata file: ${parseError.message}`, metaPath, parseError);
+        throw new ChangeMetadataError(CHANGE_METADATA_MESSAGES.invalidYaml(parseError.message), metaPath, parseError);
     }
     // Validate with Zod
     const parseResult = ChangeMetadataSchema.safeParse(parsed);
     if (!parseResult.success) {
-        throw new ChangeMetadataError(`Invalid metadata: ${parseResult.error.message}`, metaPath);
+        throw new ChangeMetadataError(CHANGE_METADATA_MESSAGES.invalidMetadata(parseResult.error.message), metaPath);
     }
     // Validate that the schema exists
     const availableSchemas = listSchemas(projectRoot);
     if (!availableSchemas.includes(parseResult.data.schema)) {
-        throw new ChangeMetadataError(`Unknown schema '${parseResult.data.schema}'. Available: ${availableSchemas.join(', ')}`, metaPath);
+        throw new ChangeMetadataError(CHANGE_METADATA_MESSAGES.unknownSchema(parseResult.data.schema, availableSchemas.join(', ')), metaPath);
     }
     return parseResult.data;
 }

package/dist/utils/change-utils.js

@@ -2,6 +2,7 @@ import path from 'path';
 import { FileSystemUtils } from './file-system.js';
 import { writeChangeMetadata, validateSchemaName } from './change-metadata.js';
 import { readProjectConfig } from '../core/project-config.js';
+import { CHANGE_UTILS_MESSAGES } from '../messages/index.js';
 const DEFAULT_SCHEMA = 'spec-driven';
 /**
  * Validates that a change name follows kebab-case conventions.
@@ -24,35 +25,35 @@ export function validateChangeName(name) {
     // optionally followed by hyphen + lowercase letters/numbers (repeatable)
     const kebabCasePattern = /^[a-z][a-z0-9]*(-[a-z0-9]+)*$/;
     if (!name) {
-        return { valid: false, error: 'Change name cannot be empty' };
+        return { valid: false, error: CHANGE_UTILS_MESSAGES.nameEmpty };
     }
     if (!kebabCasePattern.test(name)) {
         // Provide specific error messages for common mistakes
         if (/[A-Z]/.test(name)) {
-            return { valid: false, error: 'Change name must be lowercase (use kebab-case)' };
+            return { valid: false, error: CHANGE_UTILS_MESSAGES.nameMustBeLowercase };
         }
         if (/\s/.test(name)) {
-            return { valid: false, error: 'Change name cannot contain spaces (use hyphens instead)' };
+            return { valid: false, error: CHANGE_UTILS_MESSAGES.nameNoSpaces };
         }
         if (/_/.test(name)) {
-            return { valid: false, error: 'Change name cannot contain underscores (use hyphens instead)' };
+            return { valid: false, error: CHANGE_UTILS_MESSAGES.nameNoUnderscores };
         }
         if (name.startsWith('-')) {
-            return { valid: false, error: 'Change name cannot start with a hyphen' };
+            return { valid: false, error: CHANGE_UTILS_MESSAGES.nameNoStartHyphen };
         }
         if (name.endsWith('-')) {
-            return { valid: false, error: 'Change name cannot end with a hyphen' };
+            return { valid: false, error: CHANGE_UTILS_MESSAGES.nameNoEndHyphen };
         }
         if (/--/.test(name)) {
-            return { valid: false, error: 'Change name cannot contain consecutive hyphens' };
+            return { valid: false, error: CHANGE_UTILS_MESSAGES.nameNoConsecutiveHyphens };
         }
         if (/[^a-z0-9-]/.test(name)) {
-            return { valid: false, error: 'Change name can only contain lowercase letters, numbers, and hyphens' };
+            return { valid: false, error: CHANGE_UTILS_MESSAGES.nameOnlyAllowedChars };
         }
         if (/^[0-9]/.test(name)) {
-            return { valid: false, error: 'Change name must start with a letter' };
+            return { valid: false, error: CHANGE_UTILS_MESSAGES.nameMustStartWithLetter };
         }
-        return { valid: false, error: 'Change name must follow kebab-case convention (e.g., add-auth, refactor-db)' };
+        return { valid: false, error: CHANGE_UTILS_MESSAGES.nameKebabCase };
     }
     return { valid: true };
 }
@@ -106,7 +107,7 @@ export async function createChange(projectRoot, name, options = {}) {
     const changeDir = path.join(projectRoot, 'openspec', 'changes', name);
     // Check if change already exists
     if (await FileSystemUtils.directoryExists(changeDir)) {
-        throw new Error(`Change '${name}' already exists at ${changeDir}`);
+        throw new Error(CHANGE_UTILS_MESSAGES.changeAlreadyExists(name, changeDir));
     }
     // Create the directory (including parent directories if needed)
     await FileSystemUtils.createDirectory(changeDir);

package/package.json

@@ -1,84 +1,82 @@
-{
-  "name": "@dynamicworks/br-openspec",
-  "version": "1.3.1",
-  "description": "AI-native system for spec-driven development",
-  "keywords": [
-    "openspec",
-    "specs",
-    "cli",
-    "ai",
-    "development"
-  ],
-  "homepage": "https://github.com/dynamicworks-com-br/BR-OpenSpec",
-  "repository": {
-    "type": "git",
-    "url": "https://github.com/dynamicworks-com-br/BR-OpenSpec"
-  },
-  "license": "MIT",
-  "author": "BR-OpenSpec Contributors",
-  "type": "module",
-  "publishConfig": {
-    "access": "public"
-  },
-  "exports": {
-    ".": {
-      "types": "./dist/index.d.ts",
-      "default": "./dist/index.js"
-    }
-  },
-  "bin": {
-    "openspec": "./bin/openspec.js"
-  },
-  "files": [
-    "dist",
-    "bin",
-    "schemas",
-    "scripts/postinstall.js",
-    "!dist/**/*.test.js",
-    "!dist/**/__tests__",
-    "!dist/**/*.map"
-  ],
-  "scripts": {
-    "lint": "eslint src/",
-    "build": "node build.js",
-    "dev": "tsc --watch",
-    "dev:cli": "node build.js && node bin/openspec.js",
-    "test": "vitest run",
-    "test:watch": "vitest",
-    "test:ui": "vitest --ui",
-    "test:coverage": "vitest --coverage",
-    "test:postinstall": "node scripts/postinstall.js",
-    "prepare": "node build.js",
-    "prepublishOnly": "node build.js",
-    "postinstall": "node scripts/postinstall.js",
-    "check:pack-version": "node scripts/pack-version-check.mjs",
-    "release": "pnpm run release:ci",
-    "release:ci": "pnpm run check:pack-version && pnpm exec changeset publish",
-    "changeset": "changeset"
-  },
-  "engines": {
-    "node": ">=20.19.0"
-  },
-  "devDependencies": {
-    "@changesets/changelog-github": "^0.5.2",
-    "@changesets/cli": "^2.27.7",
-    "@types/node": "^24.2.0",
-    "@vitest/coverage-v8": "^3.2.4",
-    "@vitest/ui": "^3.2.4",
-    "eslint": "^9.39.2",
-    "typescript": "^5.9.3",
-    "typescript-eslint": "^8.50.1",
-    "vitest": "^3.2.4"
-  },
-  "dependencies": {
-    "@inquirer/core": "^10.2.2",
-    "@inquirer/prompts": "^7.8.0",
-    "chalk": "^5.5.0",
-    "commander": "^14.0.0",
-    "fast-glob": "^3.3.3",
-    "ora": "^8.2.0",
-    "posthog-node": "^5.20.0",
-    "yaml": "^2.8.3",
-    "zod": "^4.0.17"
-  }
-}
+{
+  "name": "@dynamicworks/br-openspec",
+  "version": "2.0.1",
+  "description": "AI-native system for spec-driven development",
+  "keywords": [
+    "openspec",
+    "specs",
+    "cli",
+    "ai",
+    "development"
+  ],
+  "homepage": "https://github.com/dynamicworks-com-br/BR-OpenSpec",
+  "repository": {
+    "type": "git",
+    "url": "https://github.com/dynamicworks-com-br/BR-OpenSpec"
+  },
+  "license": "MIT",
+  "author": "BR-OpenSpec Contributors",
+  "type": "module",
+  "publishConfig": {
+    "access": "public"
+  },
+  "exports": {
+    ".": {
+      "types": "./dist/index.d.ts",
+      "default": "./dist/index.js"
+    }
+  },
+  "bin": {
+    "openspec": "./bin/openspec.js"
+  },
+  "files": [
+    "dist",
+    "bin",
+    "schemas",
+    "scripts/postinstall.js",
+    "!dist/**/*.test.js",
+    "!dist/**/__tests__",
+    "!dist/**/*.map"
+  ],
+  "engines": {
+    "node": ">=20.19.0"
+  },
+  "devDependencies": {
+    "@changesets/changelog-github": "^0.5.2",
+    "@changesets/cli": "^2.27.7",
+    "@types/node": "^24.2.0",
+    "@vitest/coverage-v8": "^3.2.4",
+    "@vitest/ui": "^3.2.4",
+    "eslint": "^9.39.2",
+    "typescript": "^5.9.3",
+    "typescript-eslint": "^8.50.1",
+    "vitest": "^3.2.4"
+  },
+  "dependencies": {
+    "@inquirer/core": "^10.2.2",
+    "@inquirer/prompts": "^7.8.0",
+    "chalk": "^5.5.0",
+    "commander": "^14.0.0",
+    "fast-glob": "^3.3.3",
+    "ora": "^8.2.0",
+    "posthog-node": "^5.20.0",
+    "yaml": "^2.8.3",
+    "zod": "^4.0.17"
+  },
+  "scripts": {
+    "lint": "eslint src/",
+    "build": "node build.js",
+    "dev": "tsc --watch",
+    "dev:cli": "node build.js && node bin/openspec.js",
+    "test": "vitest run",
+    "test:watch": "vitest",
+    "test:ui": "vitest --ui",
+    "test:coverage": "vitest --coverage",
+    "test:postinstall": "node scripts/postinstall.js",
+    "postinstall": "node scripts/postinstall.js",
+    "check:pack-version": "node scripts/pack-version-check.mjs",
+    "release": "pnpm run release:ci",
+    "release:ci": "pnpm run check:pack-version && pnpm exec changeset publish",
+    "changeset": "changeset"
+  }
+}

package/schemas/spec-driven/schema.yaml

@@ -1,153 +1,153 @@
-name: spec-driven
-version: 1
-description: Fluxo de trabalho BR-OpenSpec padrão - proposta → specs → design → tarefas
-artifacts:
-  - id: proposal
-    generates: proposal.md
-    description: Initial proposal document outlining the change
-    template: proposal.md
-    instruction: |
-      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 `openspec/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.
-    requires: []
-
-  - id: specs
-    generates: "specs/**/*.md"
-    description: Detailed specifications for the change
-    template: spec.md
-    instruction: |
-      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 openspec/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 openspec/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.
-    requires:
-      - proposal
-
-  - id: design
-    generates: design.md
-    description: Technical design document with implementation details
-    template: design.md
-    instruction: |
-      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.
-    requires:
-      - proposal
-
-  - id: tasks
-    generates: tasks.md
-    description: Implementation checklist with trackable tasks
-    template: tasks.md
-    instruction: |
-      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.
-    requires:
-      - specs
-      - design
-
-apply:
-  requires: [tasks]
-  tracks: tasks.md
-  instruction: |
-    Read context files, work through pending tasks, mark complete as you go.
-    Pause if you hit blockers or need clarification.
+name: spec-driven
+version: 1
+description: Fluxo de trabalho BR-OpenSpec padrão - proposta → specs → design → tarefas
+artifacts:
+  - id: proposal
+    generates: proposal.md
+    description: Initial proposal document outlining the change
+    template: proposal.md
+    instruction: |
+      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 `openspec/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.
+    requires: []
+
+  - id: specs
+    generates: "specs/**/*.md"
+    description: Detailed specifications for the change
+    template: spec.md
+    instruction: |
+      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 openspec/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 openspec/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.
+    requires:
+      - proposal
+
+  - id: design
+    generates: design.md
+    description: Technical design document with implementation details
+    template: design.md
+    instruction: |
+      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.
+    requires:
+      - proposal
+
+  - id: tasks
+    generates: tasks.md
+    description: Implementation checklist with trackable tasks
+    template: tasks.md
+    instruction: |
+      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.
+    requires:
+      - specs
+      - design
+
+apply:
+  requires: [tasks]
+  tracks: tasks.md
+  instruction: |
+    Read context files, work through pending tasks, mark complete as you go.
+    Pause if you hit blockers or need clarification.

package/schemas/spec-driven/templates/design.md

@@ -1,19 +1,19 @@
-## Context
-
-<!-- Background and current state -->
-
-## Goals / Non-Goals
-
-**Goals:**
-<!-- What this design aims to achieve -->
-
-**Non-Goals:**
-<!-- What is explicitly out of scope -->
-
-## Decisions
-
-<!-- Key design decisions and rationale -->
-
-## Risks / Trade-offs
-
-<!-- Known risks and trade-offs -->
+## Context
+
+<!-- Background and current state -->
+
+## Goals / Non-Goals
+
+**Goals:**
+<!-- What this design aims to achieve -->
+
+**Non-Goals:**
+<!-- What is explicitly out of scope -->
+
+## Decisions
+
+<!-- Key design decisions and rationale -->
+
+## Risks / Trade-offs
+
+<!-- Known risks and trade-offs -->