@fission-ai/openspec 1.0.0 → 1.0.2

package/dist/commands/workflow/instructions.js

@@ -289,7 +289,7 @@ export async function generateApplyInstructions(projectRoot, changeName, schemaN
         instruction = 'All tasks are complete! This change is ready to be archived.\nConsider running tests and reviewing the changes before archiving.';
     }
     else if (!tracksFile) {
-        // No tracking file (e.g., TDD schema) - ready to apply
+        // No tracking file configured in schema - ready to apply
         state = 'ready';
         instruction = schemaInstruction?.trim() ?? 'All required artifacts complete. Proceed with implementation.';
     }

package/dist/core/project-config.js

@@ -16,11 +16,11 @@ import { z } from 'zod';
  * - Consistent with other OpenSpec schemas
  */
 export const ProjectConfigSchema = z.object({
-    // Required: which schema to use (e.g., "spec-driven", "tdd", or project-local schema name)
+    // Required: which schema to use (e.g., "spec-driven", or project-local schema name)
     schema: z
         .string()
         .min(1)
-        .describe('The workflow schema to use (e.g., "spec-driven", "tdd")'),
+        .describe('The workflow schema to use (e.g., "spec-driven")'),
     // Optional: project context (injected into all artifact instructions)
     // Max size: 50KB (enforced during parsing)
     context: z

package/dist/core/templates/skill-templates.js

@@ -327,7 +327,6 @@ export function getNewChangeSkillTemplate() {
    Use the default schema (omit \`--schema\`) unless the user explicitly requests a different workflow.
 
    **Use a different schema only if the user mentions:**
-   - "tdd" or "test-driven" → use \`--schema tdd\`
    - A specific schema name → use \`--schema <name>\`
    - "show workflows" or "what workflows" → run \`openspec schemas --json\` and let them choose
 
@@ -347,7 +346,7 @@ export function getNewChangeSkillTemplate() {
    This shows which artifacts need to be created and which are ready (dependencies satisfied).
 
 5. **Get instructions for the first artifact**
-   The first artifact depends on the schema (e.g., \`proposal\` for spec-driven, \`spec\` for tdd).
+   The first artifact depends on the schema (e.g., \`proposal\` for spec-driven).
    Check the status output to find the first artifact with status "ready".
    \`\`\`bash
    openspec instructions <first-artifact-id> --change "<name>"
@@ -409,7 +408,7 @@ export function getContinueChangeSkillTemplate() {
    openspec status --change "<name>" --json
    \`\`\`
    Parse the JSON to understand current state. The response includes:
-   - \`schemaName\`: The workflow schema being used (e.g., "spec-driven", "tdd")
+   - \`schemaName\`: The workflow schema being used (e.g., "spec-driven")
    - \`artifacts\`: Array of artifacts with their status ("done", "ready", "blocked")
    - \`isComplete\`: Boolean indicating if all artifacts are complete
 
@@ -475,16 +474,10 @@ Common artifact patterns:
 **spec-driven schema** (proposal → specs → design → tasks):
 - **proposal.md**: Ask user about the change if not clear. Fill in Why, What Changes, Capabilities, Impact.
   - The Capabilities section is critical - each capability listed will need a spec file.
-- **specs/*.md**: Create one spec per capability listed in the proposal.
+- **specs/<capability>/spec.md**: Create one spec per capability listed in the proposal's Capabilities section (use the capability name, not the change name).
 - **design.md**: Document technical decisions, architecture, and implementation approach.
 - **tasks.md**: Break down implementation into checkboxed tasks.
 
-**tdd schema** (spec → tests → implementation → docs):
-- **spec.md**: Feature specification defining what to build.
-- **tests/*.test.ts**: Write tests BEFORE implementation (TDD red phase).
-- **src/*.ts**: Implement to make tests pass (TDD green phase).
-- **docs/*.md**: Document the implemented feature.
-
 For other schemas, follow the \`instruction\` field from the CLI output.
 
 **Guardrails**
@@ -530,7 +523,7 @@ export function getApplyChangeSkillTemplate() {
    openspec status --change "<name>" --json
    \`\`\`
    Parse the JSON to understand:
-   - \`schemaName\`: The workflow being used (e.g., "spec-driven", "tdd")
+   - \`schemaName\`: The workflow being used (e.g., "spec-driven")
    - Which artifact contains the tasks (typically "tasks" for spec-driven, check status for others)
 
 3. **Get apply instructions**
@@ -555,7 +548,6 @@ export function getApplyChangeSkillTemplate() {
    Read the files listed in \`contextFiles\` from the apply instructions output.
    The files depend on the schema being used:
    - **spec-driven**: proposal, specs, design, tasks
-   - **tdd**: spec, tests, implementation, docs
    - Other schemas: follow the contextFiles from CLI output
 
 5. **Show current progress**
@@ -1329,7 +1321,7 @@ The change is implemented! One more step—let's archive it.
 \`\`\`
 ## Archiving
 
-When a change is complete, we archive it. This moves it from \`openspec/changes/\` to \`openspec/archive/YYYY-MM-DD--<name>/\`.
+When a change is complete, we archive it. This moves it from \`openspec/changes/\` to \`openspec/changes/archive/YYYY-MM-DD-<name>/\`.
 
 Archived changes become your project's decision history—you can always find them later to understand why something was built a certain way.
 \`\`\`
@@ -1341,7 +1333,7 @@ openspec archive "<name>"
 
 **SHOW:**
 \`\`\`
-Archived to: \`openspec/archive/YYYY-MM-DD--<name>/\`
+Archived to: \`openspec/changes/archive/YYYY-MM-DD-<name>/\`
 
 The change is now part of your project's history. The code is in your codebase, the decision record is preserved.
 \`\`\`
@@ -1649,7 +1641,6 @@ export function getOpsxNewCommandTemplate() {
    Use the default schema (omit \`--schema\`) unless the user explicitly requests a different workflow.
 
    **Use a different schema only if the user mentions:**
-   - "tdd" or "test-driven" → use \`--schema tdd\`
    - A specific schema name → use \`--schema <name>\`
    - "show workflows" or "what workflows" → run \`openspec schemas --json\` and let them choose
 
@@ -1728,7 +1719,7 @@ export function getOpsxContinueCommandTemplate() {
    openspec status --change "<name>" --json
    \`\`\`
    Parse the JSON to understand current state. The response includes:
-   - \`schemaName\`: The workflow schema being used (e.g., "spec-driven", "tdd")
+   - \`schemaName\`: The workflow schema being used (e.g., "spec-driven")
    - \`artifacts\`: Array of artifacts with their status ("done", "ready", "blocked")
    - \`isComplete\`: Boolean indicating if all artifacts are complete
 
@@ -1794,16 +1785,10 @@ Common artifact patterns:
 **spec-driven schema** (proposal → specs → design → tasks):
 - **proposal.md**: Ask user about the change if not clear. Fill in Why, What Changes, Capabilities, Impact.
   - The Capabilities section is critical - each capability listed will need a spec file.
-- **specs/*.md**: Create one spec per capability listed in the proposal.
+- **specs/<capability>/spec.md**: Create one spec per capability listed in the proposal's Capabilities section (use the capability name, not the change name).
 - **design.md**: Document technical decisions, architecture, and implementation approach.
 - **tasks.md**: Break down implementation into checkboxed tasks.
 
-**tdd schema** (spec → tests → implementation → docs):
-- **spec.md**: Feature specification defining what to build.
-- **tests/*.test.ts**: Write tests BEFORE implementation (TDD red phase).
-- **src/*.ts**: Implement to make tests pass (TDD green phase).
-- **docs/*.md**: Document the implemented feature.
-
 For other schemas, follow the \`instruction\` field from the CLI output.
 
 **Guardrails**
@@ -1847,7 +1832,7 @@ export function getOpsxApplyCommandTemplate() {
    openspec status --change "<name>" --json
    \`\`\`
    Parse the JSON to understand:
-   - \`schemaName\`: The workflow being used (e.g., "spec-driven", "tdd")
+   - \`schemaName\`: The workflow being used (e.g., "spec-driven")
    - Which artifact contains the tasks (typically "tasks" for spec-driven, check status for others)
 
 3. **Get apply instructions**
@@ -1872,7 +1857,6 @@ export function getOpsxApplyCommandTemplate() {
    Read the files listed in \`contextFiles\` from the apply instructions output.
    The files depend on the schema being used:
    - **spec-driven**: proposal, specs, design, tasks
-   - **tdd**: spec, tests, implementation, docs
    - Other schemas: follow the contextFiles from CLI output
 
 5. **Show current progress**
@@ -2604,7 +2588,7 @@ export function getVerifyChangeSkillTemplate() {
    openspec status --change "<name>" --json
    \`\`\`
    Parse the JSON to understand:
-   - \`schemaName\`: The workflow being used (e.g., "spec-driven", "tdd")
+   - \`schemaName\`: The workflow being used (e.g., "spec-driven")
    - Which artifacts exist for this change
 
 3. **Get the change directory and load artifacts**
@@ -3195,7 +3179,7 @@ export function getOpsxVerifyCommandTemplate() {
    openspec status --change "<name>" --json
    \`\`\`
    Parse the JSON to understand:
-   - \`schemaName\`: The workflow being used (e.g., "spec-driven", "tdd")
+   - \`schemaName\`: The workflow being used (e.g., "spec-driven")
    - Which artifacts exist for this change
 
 3. **Get the change directory and load artifacts**

package/dist/utils/change-utils.d.ts

@@ -54,9 +54,9 @@ export declare function validateChangeName(name: string): ValidationResult;
  * console.log(result.schema) // 'spec-driven' or value from config
  *
  * @example
- * // Creates openspec/changes/add-auth/ with TDD schema
- * const result = await createChange('/path/to/project', 'add-auth', { schema: 'tdd' })
- * console.log(result.schema) // 'tdd'
+ * // Creates openspec/changes/add-auth/ with custom schema
+ * const result = await createChange('/path/to/project', 'add-auth', { schema: 'my-workflow' })
+ * console.log(result.schema) // 'my-workflow'
  */
 export declare function createChange(projectRoot: string, name: string, options?: CreateChangeOptions): Promise<CreateChangeResult>;
 //# sourceMappingURL=change-utils.d.ts.map

package/dist/utils/change-utils.js

@@ -74,9 +74,9 @@ export function validateChangeName(name) {
  * console.log(result.schema) // 'spec-driven' or value from config
  *
  * @example
- * // Creates openspec/changes/add-auth/ with TDD schema
- * const result = await createChange('/path/to/project', 'add-auth', { schema: 'tdd' })
- * console.log(result.schema) // 'tdd'
+ * // Creates openspec/changes/add-auth/ with custom schema
+ * const result = await createChange('/path/to/project', 'add-auth', { schema: 'my-workflow' })
+ * console.log(result.schema) // 'my-workflow'
  */
 export async function createChange(projectRoot, name, options = {}) {
     // Validate the name first

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@fission-ai/openspec",
-  "version": "1.0.0",
+  "version": "1.0.2",
   "description": "AI-native system for spec-driven development",
   "keywords": [
     "openspec",

package/schemas/spec-driven/schema.yaml

@@ -34,7 +34,9 @@ artifacts:
     instruction: |
       Create specification files that define WHAT the system should do.
 
-      Create one spec file per capability/feature area in specs/<name>/spec.md.
+      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
@@ -110,14 +112,17 @@ artifacts:
 
   - id: tasks
     generates: tasks.md
-    description: Implementation tasks derived from specs and design
+    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 is a checkbox: - [ ] X.Y Task description
+      - 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?)
 

package/schemas/tdd/schema.yaml

@@ -1,213 +0,0 @@
-name: tdd
-version: 1
-description: Test-driven development workflow - tests → implementation → docs
-artifacts:
-  - id: spec
-    generates: spec.md
-    description: Feature specification defining requirements
-    template: spec.md
-    instruction: |
-      Create the feature specification that defines WHAT to build.
-
-      Sections:
-      - **Feature**: Name and high-level description of the feature's purpose and user value
-      - **Requirements**: List of specific requirements. Use SHALL/MUST for normative language.
-      - **Acceptance Criteria**: Testable criteria in WHEN/THEN format
-
-      Format requirements:
-      - Each requirement should be specific and testable
-      - Use `#### Scenario: <name>` with WHEN/THEN format for acceptance criteria
-      - Define edge cases and error scenarios explicitly
-      - Every requirement MUST have at least one scenario
-
-      Example:
-      ```
-      ## Feature: User Authentication
-
-      Users can securely log into the application.
-
-      ## Requirements
-
-      ### Requirement: Password validation
-      The system SHALL validate passwords meet minimum security requirements.
-
-      #### Scenario: Valid password accepted
-      - **WHEN** password has 8+ chars, uppercase, lowercase, and number
-      - **THEN** password is accepted
-
-      #### Scenario: Weak password rejected
-      - **WHEN** password is less than 8 characters
-      - **THEN** system displays "Password too short" error
-      ```
-
-      This spec drives test creation - each scenario becomes a test case.
-    requires: []
-
-  - id: tests
-    generates: "tests/*.test.ts"
-    description: Test files written before implementation
-    template: test.md
-    instruction: |
-      Write tests BEFORE implementation (TDD red phase).
-
-      File naming:
-      - Create test files as `tests/<feature>.test.ts`
-      - One test file per feature/capability
-      - Use descriptive names matching the spec
-
-      Test structure:
-      - Use Given/When/Then format matching spec scenarios
-      - Group related tests with `describe()` blocks
-      - Each scenario from spec becomes at least one `it()` test
-
-      Coverage requirements:
-      - Cover each requirement from the spec
-      - Include happy path (success cases)
-      - Include edge cases (boundary conditions)
-      - Include error scenarios (invalid input, failures)
-      - Tests should fail initially (no implementation yet)
-
-      Example:
-      ```typescript
-      describe('Password validation', () => {
-        it('accepts valid password with all requirements', () => {
-          // GIVEN a password meeting all requirements
-          const password = 'SecurePass1';
-          // WHEN validating
-          const result = validatePassword(password);
-          // THEN it should be accepted
-          expect(result.valid).toBe(true);
-        });
-
-        it('rejects password shorter than 8 characters', () => {
-          // GIVEN a short password
-          const password = 'Short1';
-          // WHEN validating
-          const result = validatePassword(password);
-          // THEN it should be rejected with message
-          expect(result.valid).toBe(false);
-          expect(result.error).toBe('Password too short');
-        });
-      });
-      ```
-
-      Follow the spec requirements exactly - tests verify the spec.
-    requires:
-      - spec
-
-  - id: implementation
-    generates: "src/*.ts"
-    description: Implementation code to pass the tests
-    template: implementation.md
-    instruction: |
-      Implement the feature to make tests pass (TDD green phase).
-
-      TDD workflow:
-      1. Run tests - confirm they fail (red)
-      2. Write minimal code to pass ONE test
-      3. Run tests - confirm that test passes (green)
-      4. Refactor if needed while keeping tests green
-      5. Repeat for next failing test
-
-      Implementation guidelines:
-      - Write minimal code to pass each test - no more, no less
-      - Run tests frequently to verify progress
-      - Keep functions small and focused
-      - Use clear, descriptive names
-
-      Code organization:
-      - Create source files in `src/<feature>.ts`
-      - Export public API clearly
-      - Keep implementation details private
-      - Add JSDoc comments for public functions
-
-      Example structure:
-      ```typescript
-      /**
-       * Validates a password meets security requirements.
-       * @param password - The password to validate
-       * @returns Validation result with valid flag and optional error
-       */
-      export function validatePassword(password: string): ValidationResult {
-        if (password.length < 8) {
-          return { valid: false, error: 'Password too short' };
-        }
-        // ... additional checks
-        return { valid: true };
-      }
-      ```
-
-      Don't over-engineer - implement only what tests require.
-    requires:
-      - tests
-
-  - id: docs
-    generates: "docs/*.md"
-    description: Documentation for the implemented feature
-    template: docs.md
-    instruction: |
-      Document the implemented feature.
-
-      Sections:
-      - **Overview**: What the feature does and why it exists (1-2 paragraphs)
-      - **Getting Started**: Quick start guide to use the feature immediately
-      - **Examples**: Code examples showing common use cases
-      - **Reference**: Detailed API documentation, configuration options
-
-      Guidelines:
-      - Write for the user, not the developer
-      - Start with the most common use case
-      - Include copy-pasteable code examples
-      - Document all configuration options with defaults
-      - Note any limitations, edge cases, or gotchas
-      - Link to related features or specs
-
-      Example structure:
-      ```markdown
-      ## Overview
-
-      Password validation ensures user passwords meet security requirements
-      before account creation or password changes.
-
-      ## Getting Started
-
-      Import and use the validation function:
-
-      ```typescript
-      import { validatePassword } from './password';
-
-      const result = validatePassword('MySecurePass1');
-      if (!result.valid) {
-        console.error(result.error);
-      }
-      ```
-
-      ## Examples
-
-      ### Basic validation
-      ...
-
-      ### Custom error handling
-      ...
-
-      ## Reference
-
-      ### validatePassword(password)
-
-      | Parameter | Type | Description |
-      |-----------|------|-------------|
-      | password | string | The password to validate |
-
-      **Returns**: `{ valid: boolean, error?: string }`
-      ```
-
-      Reference the spec for requirements, implementation for details.
-    requires:
-      - implementation
-
-apply:
-  requires: [tests]
-  tracks: null
-  instruction: |
-    Run tests to see failures. Implement minimal code to pass each test.
-    Refactor while keeping tests green.

package/schemas/tdd/templates/docs.md

@@ -1,15 +0,0 @@
-## Overview
-
-<!-- Feature overview -->
-
-## Getting Started
-
-<!-- Quick start guide -->
-
-## Examples
-
-<!-- Code examples -->
-
-## Reference
-
-<!-- API reference or additional details -->

package/schemas/tdd/templates/implementation.md

@@ -1,11 +0,0 @@
-## Implementation Notes
-
-<!-- Technical implementation details -->
-
-## API
-
-<!-- Public API documentation -->
-
-## Usage
-
-<!-- Usage examples -->

package/schemas/tdd/templates/spec.md

@@ -1,11 +0,0 @@
-## Feature: <!-- feature name -->
-
-<!-- Feature description -->
-
-## Requirements
-
-<!-- List of requirements -->
-
-## Acceptance Criteria
-
-<!-- List of acceptance criteria -->

package/schemas/tdd/templates/test.md

@@ -1,11 +0,0 @@
-## Test Plan
-
-<!-- Describe the testing strategy -->
-
-## Test Cases
-
-### <!-- Test case name -->
-
-- **Given:** <!-- preconditions -->
-- **When:** <!-- action -->
-- **Then:** <!-- expected result -->