feat: add comprehensive retrospective-based improvements

Based on OPENSPEC_COMPREHENSIVE_RETROSPECTIVE.md analysis:

Added critical missing documentation:
- Scenario formatting requirements (#### Scenario: headers) - #1 pain point
- Complete spec file structure examples with ADDED/MODIFIED sections
- Delta file location and extraction explanation
- Debugging commands (show --json --deltas-only)
- Troubleshooting section with common errors and solutions

Expanded implementation:
- Added 2 new task sections (Spec File Documentation, Troubleshooting)
- Increased from 41 to 52 total implementation tasks
- Added critical items to CLAUDE.md template tasks

This directly addresses the retrospective's top issues:
1. Scenario format documentation (marked "COMPLETELY MISSING")
2. Complete spec file examples
3. Delta detection debugging
4. Silent parsing failure explanations

CHANGE_VS_SPEC.md

@@ -1,76 +0,0 @@
-## openspec change vs spec: behavior differences and recommendations
-
-This document compares how `openspec change` and `openspec spec` behave today (focused on `show` and `list`) and recommends a raw-first, minimal standard to keep behavior simple and predictable before adding smarter formatting later.
-
-## Summary of key differences and recommendations
-
-| Area | Current: change | Current: spec | Recommendation |
-|---|---|---|---|
-| Invocation (show) | `openspec change show [change-name]` auto-picks when only one active change | `openspec spec show <spec-id>` requires id | Require explicit IDs for both. If `change-name` is omitted, print available IDs and a short hint (e.g., use `openspec change list`) and exit non-zero. No auto-pick. No interactive picker. |
-| Default text output (show) | Raw `proposal.md` content | Formatted summary | Default both to RAW: print the underlying Markdown file as-is. Provide a future `--pretty` flag (non-default) for formatted output. |
-| Filtering flags (show) | `--requirements-only` affects text and JSON | `--requirements`, `--no-scenarios`, `-r/--requirement` | Raw-first: in TEXT mode, no filtering. All filtering applies only to JSON output. Deprecate text-mode filters. Keep minimal JSON filters only. |
-| JSON shape (show) | Full change object; `--requirements-only` can return an array | Filtered object | Always return an OBJECT. Minimal, stable shape. Change: `{ id, title, deltaCount, deltas, taskStatus? }`. Spec: `{ id, title, overview, requirementCount, requirements, metadata }`. No top-level arrays. |
-| Text output (list) | "Active Changes" with progress | "Available Specifications" with teaser | Default both to RAW/minimal: print IDs only by default. Add `--long` to show `id + title` and minimal details (counts). No teasers. |
-| JSON shape (list) | `[{ name, title, deltas, taskStatus }]` | `[{ id, title, overview, requirementCount }]` | Unify minimal keys: `id`, `title`, counts only. Change: `deltaCount`, `taskStatus`. Spec: `requirementCount`. Drop `overview` from list JSON. Sort by `id`. |
-| Error/exit policy | Spinner + `process.exit(1)` in some paths | `exitCode` in others | Raw-first: no spinners in errors. Use `console.error` + `process.exitCode = 1` consistently. |
-| Empty states (list) | Graceful | Errors if specs missing | Raw-first: graceful empty state everywhere. Print "No items found" and exit 0. |
-| Multi-selection (change show) | Auto-pick single; error when multiple | N/A | Keep auto-pick single. If multiple, print IDs inline and exit non-zero. No interactive prompts. |
-| Colors/TTY | Mixed | Chalk only | Raw-first: minimal color; honor `NO_COLOR` and add `--no-color`. |
-
-## Detailed guidance
-
-### 1) Unify flags and semantics (raw-first)
-- Text mode: no filters; just raw file content.
-- JSON mode: allow minimal filters only.
-  - Specs: `--json` returns the structured spec. Optional: `-r/--requirement <n>` and `--requirements-only` apply to JSON only.
-  - Changes: `--json` returns the structured change. Optional: `--deltas-only` applies to JSON only.
-- Deprecate text-mode filtering flags across both commands.
-- Optional future: `--pretty` (text formatting) as a non-default enhancement.
-
-### 2) Normalize JSON contracts (minimal and stable)
-- Show (change): `{ id, title, deltaCount, deltas: [...], taskStatus?: { total, completed } }`
-- Show (spec): `{ id, title, overview, requirementCount, requirements: [...], metadata: { format, version } }`
-- List (change): `[{ id, title, deltaCount, taskStatus }]`
-- List (spec): `[{ id, title, requirementCount }]`
-- Notes:
-  - No top-level arrays for filtered show responses; always objects.
-  - Avoid derived/pretty fields (e.g., teasers, percentages). Counts only.
-
-### 3) Standardize text UI (minimal)
-- Show: print raw Markdown file contents.
-- List (default): print IDs only, one per line.
-- List (`--long`): print `id: title` plus minimal counts where relevant.
-- Keep colors minimal; support `--no-color` and respect `NO_COLOR`.
-
-### 4) Consistent error handling and empty states
-- Use `console.error` + `process.exitCode = 1`. Avoid `process.exit(1)`.
-- No spinners (`ora`) in raw-first mode.
-- Empty states print a simple message and exit 0.
-
-### 5) Discoverability and UX
-- No `change-name` provided: print IDs inline and a short hint; exit non-zero. No auto-pick. No interactive prompts.
-- Add `--no-color` for deterministic logs and pipelines.
-
-### 6) Backwards compatibility and deprecation
-- Keep legacy flags as aliases for one minor release.
-- Print a clear deprecation warning when a legacy flag is used.
-- Update CLI docs/README/specs to reflect raw-first behavior.
-
-### 7) Test coverage updates
-- Add tests asserting raw text outputs (file passthrough) for `show`.
-- Add tests for minimal list outputs (IDs by default, `--long` for details).
-- Add JSON contract tests asserting minimal, stable shapes and JSON-only filtering.
-
-### 8) Library alignment with existing commands
-- No new dependencies.
-- Do not use `@inquirer/prompts` in `change`/`spec` show/list (keep non-interactive). Interaction remains limited to `init`, `diff`, and `archive` where already in use.
-- Do not use `ora` in `change`/`spec` (including validate). Use `console.error` and `process.exitCode`.
-- Use `chalk` minimally; support `--no-color` and respect `NO_COLOR`.
-- Keep using the shared `Validator` where applicable.
-- Do not introduce `jest-diff` into `change`/`spec` (remains specific to `diff`).
-
-## Why this approach
-- Keeps the system raw and predictable; easy to compose in scripts.
-- Minimizes UI/formatting logic until real needs emerge.
-- Stabilizes JSON for tooling and avoids top-level arrays.
-- Simple to extend later with `--pretty` and richer filtering if needed.

OPENSPEC_COMPREHENSIVE_RETROSPECTIVE.md

@@ -0,0 +1,343 @@
+# Comprehensive Retrospective: Creating an OpenSpec Change Proposal
+
+## Executive Summary
+
+This document consolidates learnings from creating the `bulk-validation-interactive-selection` change proposal for OpenSpec. The process revealed critical gaps in documentation, unhelpful error messages, and areas where the system could be more user-friendly. While OpenSpec's core functionality works correctly, the user experience for creating changes needs significant improvement.
+
+## Table of Contents
+1. [Errors Encountered](#errors-encountered)
+2. [System Issues vs User Errors](#system-issues-vs-user-errors)
+3. [Documentation Gaps Analysis](#documentation-gaps-analysis)
+4. [Key Learnings](#key-learnings)
+5. [Recommendations](#recommendations)
+6. [Conclusion](#conclusion)
+
+---
+
+## Errors Encountered
+
+### Error 1: Misunderstanding Delta Structure
+**Error Message:** `✗ [ERROR] deltas: Change must have at least one delta`
+
+**What Happened:**
+Initially attempted to define deltas directly in the `proposal.md` file using markdown sections like:
+```markdown
+### Delta: Add validate-all command
+**Type**: Feature addition
+**Effort**: Small (< 100 lines)
+```
+
+**Root Cause:**
+Fundamental misunderstanding of how OpenSpec processes deltas. Deltas are derived from spec files in the change's `specs/` directory, not from the proposal itself.
+
+**Discovery Process:**
+- Examined `ChangeParser` class in `/src/core/parsers/change-parser.ts`
+- Found that `parseDeltaSpecs()` method looks for spec files in `specs/` subdirectory
+- Learned that deltas are extracted by comparing spec files against existing specs
+
+### Error 2: Missing Operation Prefix in Section Headers
+**Error Message:** `✗ [ERROR] deltas: Change must have at least one delta`
+
+**What Happened:**
+Created new spec files with standard `## Requirements` headers instead of operation-prefixed headers.
+
+**Root Cause:**
+Failed to understand that ALL spec files in a change need operation prefixes (`ADDED`, `MODIFIED`, etc.) in their section headers, regardless of whether they're new specs or modifications.
+
+**Discovery Process:**
+- Created new specs with `## Requirements` → No deltas detected
+- Changed to `## ADDED Requirements` → Deltas detected successfully!
+- Realized creating new specs works perfectly fine once properly formatted
+
+**Important Clarification:**
+OpenSpec fully supports creating new specs. They appear as ADDED operations in the deltas. My initial analysis incorrectly suggested this was a limitation, but it was actually just a formatting issue.
+
+### Error 3: Improper Scenario Formatting
+**Error Message:** 
+```
+✗ [ERROR] deltas.0.requirements.0.scenarios: Requirement must have at least one scenario
+✗ [ERROR] deltas.1.requirements.0.scenarios: Requirement must have at least one scenario
+```
+
+**What Happened:**
+Formatted scenarios as bullet lists under a bold "Scenarios:" label:
+```markdown
+**Scenarios:**
+- **WHEN** executing command
+- **THEN** expected behavior
+```
+
+**Root Cause:**
+OpenSpec's parser expects scenarios to be defined as level 4 headers (`####`) with specific formatting:
+```markdown
+#### Scenario: Descriptive scenario name
+
+- **WHEN** executing command
+- **THEN** expected behavior
+```
+
+**Discovery Process:**
+- Checked parsed JSON output: `npx openspec change show bulk-validation-interactive-selection --json`
+- Saw `"scenarios": []` empty array despite having scenario content
+- Examined working spec files and found the `#### Scenario:` header pattern
+
+### Error 4: File Path Confusion
+**Initial Confusion:**
+Wasn't clear whether to create specs that would become part of the main `openspec/specs/` or just define them in the change.
+
+**Resolution:**
+Learned that changes can:
+1. Create new specs (they start in `changes/{change-name}/specs/` and move to `openspec/specs/` when archived)
+2. Modify existing specs (by creating a spec file with the same name as one in `openspec/specs/`)
+3. The validation system detects both patterns and creates appropriate deltas
+
+---
+
+## System Issues vs User Errors
+
+### System Issues / Bugs
+
+#### 1. Unhelpful Error Messages ⚠️
+**Issue:** `✗ [ERROR] deltas: Change must have at least one delta`
+
+**Why This Is a System Problem:**
+- Error message provides no guidance on HOW to create deltas
+- Doesn't mention that deltas come from `specs/` subdirectory
+- Doesn't explain the required section headers
+- A better error would be: "No deltas found. Ensure your change has a specs/ directory with .md files containing sections like '## ADDED Requirements'"
+
+#### 2. Silent Scenario Parsing Failures ⚠️
+**Issue:** When scenarios were formatted incorrectly, they were silently ignored
+
+**Why This Is a System Problem:**
+- Parser silently returns empty scenarios array instead of warning
+- No validation error explaining the format issue
+- User gets "Requirement must have at least one scenario" without knowing their scenarios exist but aren't parsed
+
+**Evidence:**
+```json
+{
+  "text": "The CLI SHALL provide a top-level `show` command with interactive selection.",
+  "scenarios": []  // Silent failure - scenarios existed but weren't parsed
+}
+```
+
+#### 3. No Validation for Proposal Structure During Creation
+**Issue:** System allows creating invalid proposals without early feedback
+
+**Why This Is a System Problem:**
+- No scaffolding or template commands
+- No incremental validation as you build
+- Must fully create the change before discovering structural issues
+
+### User Errors (My Mistakes)
+
+#### 1. Trying to Define Deltas in Proposal.md
+- Incorrectly assumed deltas could be inline in the proposal
+- System correctly expects deltas in separate spec files
+
+#### 2. Using Wrong Section Headers
+- Used `## Requirements` instead of `## ADDED Requirements`
+- Convention is documented in existing changes, but I didn't examine carefully
+
+#### 3. Wrong Scenario Format
+- Used bullet lists instead of `#### Scenario:` headers
+- Made assumptions instead of checking existing patterns
+
+### Gray Areas
+
+1. **Documentation gaps** - While examples exist, there's no comprehensive "How to Create a Change" guide
+2. **Lack of tooling** - No scaffolding commands to create properly structured changes
+
+---
+
+## Documentation Gaps Analysis
+
+### Critical Gaps in openspec/README.md
+
+#### 1. Scenario Format - COMPLETELY MISSING ⚠️
+**What README Shows:** No scenario examples at all
+
+**What's Actually Required:**
+```markdown
+#### Scenario: Descriptive name
+- **WHEN** condition
+- **THEN** expected outcome
+- **AND** additional outcomes
+```
+
+**Impact:** This was the biggest struggle. The README mentions requirements but never shows how to write scenarios. Without this, requirements fail validation.
+
+#### 2. Complete Spec File Example - MISSING
+**What README Shows:** Only fragments
+
+**What's Actually Needed:** A complete working example showing:
+- Full spec file structure
+- Proper requirement format
+- Scenario formatting
+- All required elements
+
+#### 3. Validation Commands - NOT MENTIONED
+**Missing from README:**
+- `npx openspec change validate <change-name>`
+- `npx openspec change show <change-name> --json`
+- The `--strict` flag for catching warnings
+
+#### 4. Delta Detection Explanation - INCOMPLETE
+**What's Missing:**
+- WHERE the system looks for specs (specs/ subdirectory)
+- THAT deltas are automatically extracted
+- HOW to debug when deltas aren't detected
+- WHAT error messages mean
+
+### Misleading Documentation
+
+#### "Store only the changes" - MISLEADING
+**Line 145:** `# - Store only the changes (not complete future state)`
+
+**Problem:** This suggests storing diffs or partial content. In reality, you need:
+- Complete requirements in their final form
+- Full scenario definitions
+- The entire requirement text
+
+### Documentation That Was Helpful
+1. Delta section headers (`## ADDED Requirements`) - clearly documented
+2. Directory structure - excellent visualization
+3. When to create proposals - well defined
+
+---
+
+## Key Learnings
+
+### 1. OpenSpec's Delta Detection Algorithm
+The system follows this process:
+1. Scans `openspec/changes/{change-name}/specs/` directory
+2. For each spec file found, parses for delta sections (`ADDED`, `MODIFIED`, `REMOVED`, `RENAMED`)
+3. Creates delta objects with operation type, affected spec, and requirements
+4. Validates that at least one delta exists for the change to be valid
+
+**Important:** Creating entirely new specs is fully supported! New specs use `## ADDED Requirements` and appear as ADDED operations in the deltas.
+
+### 2. Spec File Structure Requirements
+Valid spec files must follow this structure:
+```markdown
+# Spec Title
+
+## [ADDED|MODIFIED|REMOVED|RENAMED] Requirements
+
+### Requirement: Clear requirement statement
+
+The requirement description using SHALL/SHOULD/MAY.
+
+#### Scenario: Scenario name
+
+- **WHEN** condition
+- **THEN** expected outcome
+- **AND** additional outcomes
+```
+
+### 3. Change Proposal Structure
+A valid change must have:
+- `## Why` section - explaining the motivation
+- `## What Changes` section - summarizing the changes
+- `specs/` directory with properly formatted spec files containing deltas
+- Each delta must have at least one requirement with at least one scenario
+
+### 4. Validation Commands Are Essential
+```bash
+# Basic validation
+npx openspec change validate {change-name}
+
+# Strict validation (recommended)
+npx openspec change validate {change-name} --strict
+
+# Debug delta detection
+npx openspec change show {change-name} --json | jq '.deltas'
+```
+
+---
+
+## Recommendations
+
+### High Priority (System Bugs to Fix)
+
+1. **Improve Error Messages**
+   - Add actionable guidance to error messages
+   - Example: "No deltas found. Check: 1) specs/ directory exists, 2) Files use ## ADDED Requirements headers, 3) Each requirement has #### Scenario: sections"
+
+2. **Add Warnings for Malformed Content**
+   - Warn when scenarios exist but aren't properly formatted
+   - Show which line/file has the issue
+
+3. **Add Delta Detection Debugging**
+   - Command like `openspec change debug-deltas {change-name}`
+   - Show which files were scanned, what was found, what was rejected
+
+### Medium Priority (Documentation Improvements)
+
+1. **Add Complete Working Example to README**
+   - Full change proposal with all files
+   - Properly formatted specs with scenarios
+   - Show the validation output
+
+2. **Add Troubleshooting Section**
+   - Common errors and their solutions
+   - How to debug delta detection
+   - Scenario formatting requirements
+
+3. **Add Validation Best Practices**
+   - When to use `--strict`
+   - How to use JSON output for debugging
+   - Common validation patterns
+
+### Low Priority (Developer Experience)
+
+1. **Add Scaffolding Command**
+   ```bash
+   openspec change scaffold {change-name}
+   ```
+   - Creates proper directory structure
+   - Includes template files with correct formatting
+   - Adds example scenarios
+
+2. **Add Interactive Creation Wizard**
+   - Guide users through change creation
+   - Validate as they go
+   - Suggest fixes for common issues
+
+3. **Add Auto-fix Capability**
+   - `--fix` flag to correct common formatting issues
+   - Convert bullet list scenarios to proper headers
+   - Add missing operation prefixes
+
+---
+
+## Conclusion
+
+The OpenSpec system works correctly for its intended design, but the user experience for creating changes needs significant improvement. The core issues stem from:
+
+### System Issues
+- **Unhelpful error messages** that don't guide users to solutions
+- **Silent parsing failures** that provide no feedback about malformed content
+- **Lack of debugging tools** to understand what went wrong
+
+### Documentation Issues
+- **Critical formatting requirements missing** (especially scenario format)
+- **No complete working examples** showing all required elements
+- **Validation commands not documented** despite being essential
+
+### User Issues
+- **Incorrect assumptions** about how the system works
+- **Not examining existing patterns** carefully enough
+- **Trying to shortcut** instead of following established conventions
+
+### The Path Forward
+
+With better error messages, complete documentation, and basic tooling support, most of the errors encountered could be prevented. The system's delta-centric approach is powerful and ensures changes are atomic and trackable, but it needs to be more discoverable and user-friendly.
+
+The most impactful improvements would be:
+1. Adding scenario format documentation to the README
+2. Improving error messages with actionable guidance
+3. Creating a scaffolding command for new changes
+
+These changes would transform OpenSpec from a system that works correctly but is hard to use, into one that actively helps developers succeed.

build.js

@@ -11,10 +11,11 @@ if (existsSync('dist')) {
   rmSync('dist', { recursive: true, force: true });
 }
 
-// Run TypeScript compiler
+// Run TypeScript compiler (use local version explicitly)
 console.log('Compiling TypeScript...');
 try {
-  execSync('tsc', { stdio: 'inherit' });
+  execSync('./node_modules/.bin/tsc -v', { stdio: 'inherit' });
+  execSync('./node_modules/.bin/tsc', { stdio: 'inherit' });
   console.log('\n✅ Build completed successfully!');
 } catch (error) {
   console.error('\n❌ Build failed!');

openspec/README.md

@@ -49,6 +49,64 @@ openspec/
 │   └── archive/            # Completed changes (dated)
 ```
 
+## CLI Usage: show command
+
+Use the `show` command to display change proposals or specs with automatic detection and interactive selection.
+
+- Interactive (no args, in a TTY):
+
+```bash
+openspec show
+# → prompts to pick change/spec, then item
+```
+
+- Direct item (auto-detect type):
+
+```bash
+openspec show demo            # shows change 'demo'
+openspec show auth            # shows spec 'auth'
+```
+
+- Disambiguation when names collide:
+
+```bash
+openspec show foo             # if both change/spec exist → error suggests --type
+openspec show foo --type spec # forces spec
+openspec show foo --type change
+```
+
+- Common flags:
+
+```bash
+# JSON output (both types)
+openspec show <item> --json
+
+# Change-only flags
+openspec show <change-id> --json --deltas-only
+openspec show <change-id> --json --requirements-only  # deprecated alias of --deltas-only
+
+# Spec-only flags
+openspec show <spec-id> --json --requirements
+openspec show <spec-id> --json --no-scenarios
+openspec show <spec-id> --json -r 1                  # show requirement 1 only (1-based)
+```
+
+- Interactivity controls:
+
+```bash
+openspec show --no-interactive  # never prompt
+
+# or via env
+OPEN_SPEC_INTERACTIVE=0 openspec show
+```
+
+- Backwards compatibility (subcommands also support interactive selection when no arg):
+
+```bash
+openspec change show [change-id] [--json] [--deltas-only]
+openspec spec show [spec-id] [--json] [--requirements] [--no-scenarios] [-r N]
+```
+
 ### Capability Organization
 
 **Use capabilities, not features** - Each directory under `specs/` represents a single, focused responsibility:

openspec/changes/adopt-verb-noun-cli-structure/specs/cli-list/spec.md

@@ -0,0 +1,57 @@
+# Delta: CLI List Command
+
+## MODIFIED Requirements
+
+### Requirement: Command Execution
+The command SHALL scan and analyze either active changes or specs based on the selected mode.
+
+#### Scenario: Scanning for changes (default)
+- **WHEN** `openspec list` is executed without flags
+- **THEN** scan the `openspec/changes/` directory for change directories
+- **AND** exclude the `archive/` subdirectory from results
+- **AND** parse each change's `tasks.md` file to count task completion
+
+#### Scenario: Scanning for specs
+- **WHEN** `openspec list --specs` is executed
+- **THEN** scan the `openspec/specs/` directory for capabilities
+- **AND** read each capability's `spec.md`
+- **AND** parse requirements to compute requirement counts
+
+### Requirement: Output Format
+The command SHALL display items in a clear, readable table format with mode-appropriate progress or counts.
+
+#### Scenario: Displaying change list (default)
+- **WHEN** displaying the list of changes
+- **THEN** show a table with columns:
+  - Change name (directory name)
+  - Task progress (e.g., "3/5 tasks" or "✓ Complete")
+
+#### Scenario: Displaying spec list
+- **WHEN** displaying the list of specs
+- **THEN** show a table with columns:
+  - Spec id (directory name)
+  - Requirement count (e.g., "requirements 12")
+
+### Requirement: Empty State
+The command SHALL provide clear feedback when no items are present for the selected mode.
+
+#### Scenario: Handling empty state (changes)
+- **WHEN** no active changes exist (only archive/ or empty changes/)
+- **THEN** display: "No active changes found."
+
+#### Scenario: Handling empty state (specs)
+- **WHEN** no specs directory exists or contains no capabilities
+- **THEN** display: "No specs found."
+
+### Requirement: Flags
+The command SHALL accept flags to select the noun being listed.
+
+#### Scenario: Selecting specs
+- **WHEN** `--specs` is provided
+- **THEN** list specs instead of changes
+
+#### Scenario: Selecting changes
+- **WHEN** `--changes` is provided
+- **THEN** list changes explicitly (same as default behavior)
+
+

openspec/changes/archive/2025-08-19-add-change-commands/specs/cli-list/spec.md

@@ -1,6 +1,6 @@
 ## MODIFIED Requirements
 
-### Requirement: List Command Behavior
+### Requirement: Command Execution
 
 The current `list` command behavior SHALL be preserved but marked as deprecated.
 

openspec/changes/archive/2025-08-19-add-interactive-show-command/proposal.md

@@ -0,0 +1,20 @@
+## Why
+
+Users frequently need to view changes and specs but must know in advance whether they're looking at a change or spec. The current subcommand structure (`change show`, `spec show`) creates friction when:
+- Users want to quickly view an item without remembering its type
+- Exploring the codebase requires switching between different show commands
+- Show commands without arguments return errors instead of helpful guidance
+
+## What Changes
+
+- Add new top-level `show` command for displaying changes or specs with intelligent selection
+- Support direct item display: `openspec show <item>` with automatic type detection
+- Interactive selection when no arguments provided
+- Enhance existing `change show` and `spec show` to support interactive selection (backwards compatibility)
+- Maintain all existing format options (--json, --deltas-only, --requirements, etc.)
+
+## Impact
+
+- New specs to create: cli-show
+- Specs to enhance: cli-change, cli-spec (for backwards compatibility)
+- Affected code: src/cli/index.ts, src/commands/show.ts (new), src/commands/spec.ts, src/commands/change.ts

openspec/changes/archive/2025-08-19-add-interactive-show-command/specs/cli-change/spec.md

@@ -0,0 +1,23 @@
+# CLI Change Command Spec
+
+## ADDED Requirements
+
+### Requirement: Interactive show selection
+
+The change show command SHALL support interactive selection when no change name is provided.
+
+#### Scenario: Interactive change selection for show
+
+- **WHEN** executing `openspec change show` without arguments
+- **THEN** display an interactive list of available changes
+- **AND** allow the user to select a change to show
+- **AND** display the selected change content
+- **AND** maintain all existing show options (--json, --deltas-only)
+
+#### Scenario: Non-interactive fallback keeps current behavior
+
+- **GIVEN** stdin is not a TTY or `--no-interactive` is provided or environment variable `OPEN_SPEC_INTERACTIVE=0`
+- **WHEN** executing `openspec change show` without a change name
+- **THEN** do not prompt interactively
+- **AND** print the existing hint including available change IDs
+- **AND** set `process.exitCode = 1`

openspec/changes/archive/2025-08-19-add-interactive-show-command/specs/cli-show/spec.md

@@ -0,0 +1,83 @@
+# CLI Show Command Spec
+
+## ADDED Requirements
+
+### Requirement: Top-level show command
+
+The CLI SHALL provide a top-level `show` command for displaying changes and specs with intelligent selection.
+
+#### Scenario: Interactive show selection
+
+- **WHEN** executing `openspec show` without arguments
+- **THEN** prompt user to select type (change or spec)
+- **AND** display list of available items for selected type
+- **AND** show the selected item's content
+
+#### Scenario: Non-interactive environments do not prompt
+
+- **GIVEN** stdin is not a TTY or `--no-interactive` is provided or environment variable `OPEN_SPEC_INTERACTIVE=0`
+- **WHEN** executing `openspec show` without arguments
+- **THEN** do not prompt
+- **AND** print a helpful hint with examples for `openspec show <item>` or `openspec change/spec show`
+- **AND** exit with code 1
+
+#### Scenario: Direct item display
+
+- **WHEN** executing `openspec show <item-name>`
+- **THEN** automatically detect if item is a change or spec
+- **AND** display the item's content
+- **AND** use appropriate formatting based on item type
+
+#### Scenario: Type detection and ambiguity handling
+
+- **WHEN** executing `openspec show <item-name>`
+- **THEN** if `<item-name>` uniquely matches a change or a spec, show that item
+- **AND** if it matches both, print an ambiguity error and suggest `--type change|spec` or using `openspec change show`/`openspec spec show`
+- **AND** if it matches neither, print not-found with nearest-match suggestions
+
+#### Scenario: Explicit type override
+
+- **WHEN** executing `openspec show --type change <item>`
+- **THEN** treat `<item>` as a change ID and show it (skipping auto-detection)
+
+- **WHEN** executing `openspec show --type spec <item>`
+- **THEN** treat `<item>` as a spec ID and show it (skipping auto-detection)
+
+### Requirement: Output format options
+
+The show command SHALL support various output formats consistent with existing commands.
+
+#### Scenario: JSON output
+
+- **WHEN** executing `openspec show <item> --json`
+- **THEN** output the item in JSON format
+- **AND** include parsed metadata and structure
+- **AND** maintain format consistency with existing change/spec show commands
+
+#### Scenario: Flag scoping and delegation
+
+- **WHEN** showing a change or a spec via the top-level command
+- **THEN** accept common flags such as `--json`
+- **AND** pass through type-specific flags to the corresponding implementation
+  - Change-only flags: `--deltas-only` (alias `--requirements-only` deprecated)
+  - Spec-only flags: `--requirements`, `--no-scenarios`, `-r/--requirement`
+- **AND** ignore irrelevant flags for the detected type with a warning
+
+### Requirement: Interactivity controls
+
+- The CLI SHALL respect `--no-interactive` to disable prompts.
+- The CLI SHALL respect `OPEN_SPEC_INTERACTIVE=0` to disable prompts globally.
+- Interactive prompts SHALL only be shown when stdin is a TTY and interactivity is not disabled.
+
+#### Scenario: Change-specific options
+
+- **WHEN** showing a change with `openspec show <change-name> --deltas-only`
+- **THEN** display only the deltas in JSON format
+- **AND** maintain compatibility with existing change show options
+
+#### Scenario: Spec-specific options  
+
+- **WHEN** showing a spec with `openspec show <spec-id> --requirements`
+- **THEN** display only requirements in JSON format
+- **AND** support other spec options (--no-scenarios, -r)
+- **AND** maintain compatibility with existing spec show options

openspec/changes/archive/2025-08-19-add-interactive-show-command/specs/cli-spec/spec.md

@@ -0,0 +1,23 @@
+# CLI Spec Command Spec
+
+## ADDED Requirements
+
+### Requirement: Interactive spec show
+
+The spec show command SHALL support interactive selection when no spec-id is provided.
+
+#### Scenario: Interactive spec selection for show
+
+- **WHEN** executing `openspec spec show` without arguments
+- **THEN** display an interactive list of available specs
+- **AND** allow the user to select a spec to show
+- **AND** display the selected spec content
+- **AND** maintain all existing show options (--json, --requirements, --no-scenarios, -r)
+
+#### Scenario: Non-interactive fallback keeps current behavior
+
+- **GIVEN** stdin is not a TTY or `--no-interactive` is provided or environment variable `OPEN_SPEC_INTERACTIVE=0`
+- **WHEN** executing `openspec spec show` without a spec-id
+- **THEN** do not prompt interactively
+- **AND** print the existing error message for missing spec-id
+- **AND** set non-zero exit code

openspec/changes/archive/2025-08-19-add-interactive-show-command/tasks.md

@@ -0,0 +1,142 @@
+# Implementation Tasks — Add Interactive Show Command
+
+## Goals
+- Add a top-level `show` command with intelligent selection and type detection.
+- Add interactive selection to `change show` and `spec show` when no ID is provided.
+- Preserve raw-first output behavior and existing JSON formats/filters.
+- Respect `--no-interactive` and `OPEN_SPEC_INTERACTIVE=0` consistently.
+
+---
+
+## 1) CLI wiring
+- [x] In `src/cli/index.ts` add a top-level command: `program.command('show [item-name]')`
+  - Options:
+    - `--json`
+    - `--type <type>` where `<type>` is `change|spec`
+    - `--no-interactive`
+    - Allow passing-through type-specific flags using `.allowUnknownOption(true)` so the top-level can forward flags to the underlying type handler.
+  - Action: instantiate `new ShowCommand().execute(itemName, options)`.
+- [x] Update `change show` subcommand to accept `--no-interactive` and pass it to `ChangeCommand.show(...)`.
+- [x] Change `spec show` subcommand to accept optional ID (`show [spec-id]`), add `--no-interactive`, and pass to spec show implementation.
+
+Acceptance:
+- `openspec show` exists and prints a helpful hint in non-interactive contexts when no args.
+- Unknown flags for other types do not crash parsing; they are warned/ignored appropriately.
+
+---
+
+## 2) New module: `src/commands/show.ts`
+- [x] Create `ShowCommand` with:
+  - `execute(itemName?: string, options?: { json?: boolean; type?: string; noInteractive?: boolean; [k: string]: any })`
+  - Interactive path when `!itemName` and interactive is enabled:
+    - Prompt: "What would you like to show?" → `change` or `spec`.
+    - Load available IDs for the chosen type and prompt selection.
+    - Delegate to type-specific show implementation.
+  - Non-interactive path when `!itemName`:
+    - Print hint with examples:
+      - `openspec show <item>`
+      - `openspec change show`
+      - `openspec spec show`
+    - Exit with code 1.
+  - Direct item path when `itemName` is provided:
+    - Type override via `--type` takes precedence.
+    - Otherwise detect using `getActiveChangeIds()` and `getSpecIds()`.
+    - If ambiguous and no override: print error + suggestion to pass `--type` or use subcommands; exit code 1.
+    - If unknown: print not-found with nearest-match suggestions; exit code 1.
+    - On success: delegate to type-specific show.
+- [x] Flag scoping and pass-through:
+  - Common: `--json` → forwarded to both types.
+  - Change-only: `--deltas-only`, `--requirements-only` (deprecated alias).
+  - Spec-only: `--requirements`, `--no-scenarios`, `-r/--requirement`.
+  - Warn and ignore irrelevant flags for the resolved type.
+
+Acceptance:
+- `openspec show <change-id> --json --deltas-only` matches `openspec change show <id> --json --deltas-only` output.
+- `openspec show <spec-id> --json --requirements` matches `openspec spec show <id> --json --requirements` output.
+- Ambiguity and not-found behaviors match the `cli-show` spec.
+
+---
+
+## 3) Refactor spec show into reusable API
+- [x] In `src/commands/spec.ts`, extract show logic into an exported `SpecCommand` with `show(specId?: string, options?: { json?: boolean; requirements?: boolean; scenarios?: boolean; requirement?: string; noInteractive?: boolean })`.
+  - Reuse current helpers (`parseSpecFromFile`, `filterSpec`, raw-first printing).
+  - Keep `registerSpecCommand` but delegate to `new SpecCommand().show(...)`.
+- [x] Update CLI spec show subcommand to optional arg and interactive behavior (see section 4).
+
+Acceptance:
+- Existing `spec show` tests continue to pass.
+- New `SpecCommand.show` can be called from `ShowCommand`.
+
+---
+
+## 4) Backwards-compatible interactive in subcommands
+- [x] `src/commands/change.ts` → extend `show(changeName?: string, options?: { json?: boolean; requirementsOnly?: boolean; deltasOnly?: boolean; noInteractive?: boolean })`:
+  - When `!changeName` and interactive enabled: prompt from `getActiveChangeIds()` and show the selected change.
+  - Non-interactive fallback: keep current behavior (print available IDs + `openspec change list` hint, set `process.exitCode = 1`).
+- [x] `src/commands/spec.ts` → `SpecCommand.show` as above:
+  - When `!specId` and interactive enabled: prompt from `getSpecIds()` and show the selected spec.
+  - Non-interactive fallback: print the same error as existing behavior for missing `<spec-id>` and set non-zero exit code.
+
+Acceptance:
+- `openspec change show` in non-interactive prints list hint and exits non-zero.
+- `openspec spec show` in non-interactive prints missing-arg error and exits non-zero.
+
+---
+
+## 5) Shared utilities
+- [x] Extract `nearestMatches` and `levenshtein` from `src/commands/validate.ts` into `src/utils/match.ts` (exported helpers).
+- [x] Update `ValidateCommand` and new `ShowCommand` to import from `utils/match`.
+
+Acceptance:
+- Build succeeds with shared helpers and no duplication.
+
+---
+
+## 6) Hints, warnings, and messages
+- [x] Top-level `show` hint (non-interactive no-arg):
+  - Lines include: `openspec show <item>`, `openspec change show`, `openspec spec show`, and "Or run in an interactive terminal.".
+- [x] Ambiguity message suggests `--type change|spec` and the subcommands.
+- [x] Not-found suggests nearest matches (up to 5).
+- [x] Irrelevant flag warnings for the resolved type (printed to stderr, no crash).
+
+Acceptance:
+- Messages match the `cli-show` spec wording intent and style used elsewhere.
+
+---
+
+## 7) Tests
+Add tests mirroring existing patterns (non-TTY simulation via `OPEN_SPEC_INTERACTIVE=0`).
+
+- [x] `test/commands/show.test.ts`
+  - Non-interactive, no arg → prints hint and exits non-zero.
+  - Direct item detection for change and for spec.
+  - Ambiguity case when both exist → error and suggestion for `--type`.
+  - Not-found case → nearest-match suggestions.
+  - Pass-through flags: change `--json --deltas-only`, spec `--json --requirements`.
+- [x] `test/commands/change.interactive-show.test.ts` (non-interactive fallback)
+  - Ensure `openspec change show` without args prints available IDs + list hint and non-zero exit.
+- [x] `test/commands/spec.interactive-show.test.ts` (non-interactive fallback)
+  - Ensure `openspec spec show` without args prints missing-arg error and non-zero exit.
+
+Acceptance:
+- All new tests pass after build; no regressions in existing tests.
+
+---
+
+## 8) Documentation (optional but recommended)
+- [x] Update `openspec/README.md` usage examples to include the new `show` command with type detection and flags.
+
+---
+
+## 9) Non-functional checks
+- [x] Run `pnpm build` and all tests (`pnpm test`).
+- [x] Ensure no linter/type errors and messages are consistent with existing style.
+
+---
+
+## Notes on consistency
+- Follow raw-first behavior for text output: passthrough file content with no formatting, mirroring current `change show` and `spec show`.
+- Reuse `isInteractive` and `item-discovery` helpers for consistent prompting behavior.
+- Keep JSON output shapes identical to current `ChangeCommand.show` and `spec show` outputs.
+
+

openspec/changes/archive/2025-08-19-add-skip-specs-archive-option/specs/cli-archive/spec.md

@@ -164,4 +164,28 @@ The command SHALL handle various error conditions gracefully.
 **Confirmation for spec updates**: Provides visibility into what will change, prevents accidental overwrites, and ensures users understand the impact before specs are modified
 **Non-blocking confirmation**: Declining spec updates doesn't cancel archiving - users can review specs and choose to update them separately if needed
 **--yes flag for automation**: Allows CI/CD pipelines to archive without interactive prompts while maintaining safety by default for manual use
-**--skip-specs flag**: Enables archiving of changes that don't modify specs (like infrastructure, tooling, or documentation changes) without unnecessary spec update prompts or operations
+**--skip-specs flag**: Enables archiving of changes that don't modify specs (like infrastructure, tooling, or documentation changes) without unnecessary spec update prompts or operations
+
+## ADDED Requirements
+
+### Requirement: Skip Specs Option
+
+The archive command SHALL support a `--skip-specs` flag that skips all spec update operations and proceeds directly to archiving.
+
+#### Scenario: Skipping spec updates with flag
+
+- **WHEN** executing `openspec archive <change> --skip-specs`
+- **THEN** skip spec discovery and update confirmation
+- **AND** proceed directly to moving the change to archive
+- **AND** display a message indicating specs were skipped
+
+### Requirement: Non-blocking confirmation
+
+The archive operation SHALL proceed when the user declines spec updates instead of cancelling the entire operation.
+
+#### Scenario: User declines spec update confirmation
+
+- **WHEN** the user declines spec update confirmation
+- **THEN** skip spec updates
+- **AND** continue with the archive operation
+- **AND** display a success message indicating specs were not updated

openspec/changes/archive/2025-08-19-add-spec-commands/proposal.md

@@ -16,4 +16,4 @@ Currently, OpenSpec specs can only be viewed as markdown files. This makes progr
 - **Affected specs**: None (new capability)
 - **Affected code**: 
   - src/cli/index.ts (register new command)
-  - package.json (add zod dependency)
+  - package.json (add zod dependency)

openspec/changes/archive/2025-08-19-add-zod-validation/specs/cli-diff/spec.md

@@ -1,4 +1,4 @@
-## MODIFIED Requirements
+## ADDED Requirements
 
 ### Requirement: Diff Command Enhancement
 

openspec/changes/archive/2025-08-19-adopt-delta-based-changes/specs/cli-archive/spec.md

@@ -24,6 +24,8 @@ Before moving the change to archive, the command SHALL apply delta changes to ma
 - **THEN** abort with error message showing the conflict
 - **AND** suggest manual resolution
 
+## ADDED Requirements
+
 ### Requirement: Display Output
 
 The command SHALL provide clear feedback about delta operations.

openspec/changes/archive/2025-08-19-adopt-delta-based-changes/specs/cli-diff/spec.md

@@ -4,8 +4,16 @@
 
 ### Requirement: Display Format
 
+The diff command SHALL display unified diff output in text format.
+
 **Reason for removal**: The standard unified diff format is replaced by requirement-level side-by-side comparison that better shows semantic changes rather than line-by-line text differences.
 
+#### Scenario: Unified diff output (deprecated)
+
+- **WHEN** running `openspec diff <change>`
+- **THEN** show a unified text diff of files
+- **AND** include `+`/`-` prefixed lines representing additions and removals
+
 ## MODIFIED Requirements
 
 ### Requirement: Diff Output
@@ -23,6 +31,8 @@ The command SHALL show a requirement-level comparison displaying only changed re
   - Indicates removed requirements (not in future)
   - Aligns modified requirements for easy comparison
 
+## ADDED Requirements
+
 ### Requirement: Validation
 
 The command SHALL validate that changes can be applied successfully.

openspec/changes/archive/2025-08-19-adopt-delta-based-changes/specs/openspec-conventions/spec.md

@@ -1,6 +1,6 @@
 # OpenSpec Conventions - Changes
 
-## ADDED Requirements
+## MODIFIED Requirements
 
 ### Requirement: Header-Based Requirement Identification
 
@@ -31,8 +31,6 @@ Requirement headers SHALL serve as unique identifiers for programmatic matching
 - **THEN** ensure no duplicate headers exist within a spec
 - **AND** validation tools SHALL flag duplicate headers as errors
 
-## MODIFIED Requirements
-
 ### Requirement: Change Storage Convention
 
 Change proposals SHALL store only the additions, modifications, and removals to specifications, not complete future states.
@@ -100,10 +98,4 @@ The archive process SHALL programmatically apply delta changes to current specif
 - **AND** require manual resolution before proceeding
 - **AND** provide clear guidance on resolving conflicts
 
-## REMOVED Requirements
-
-### Requirement: Future State Storage
-
-**Reason for removal**: Replaced by delta-based change storage which provides better review experience and clearer change tracking.
-
-**Migration path**: All new changes must use delta format.
+ 

openspec/changes/archive/2025-08-19-adopt-verb-noun-cli-structure/design.md

@@ -0,0 +1,19 @@
+# Design: Verb–Noun CLI Structure Adoption
+
+## Overview
+We will make verb commands (`list`, `show`, `validate`, `diff`, `archive`) the primary interface and keep noun commands (`spec`, `change`) as deprecated aliases for one release.
+
+## Decisions
+
+1. Keep routing centralized in `src/cli/index.ts`.
+2. Add `--specs`/`--changes` to `openspec list`, with `--changes` as default.
+3. Show deprecation warnings for `openspec change list` and, more generally, for any `openspec change ...` and `openspec spec ...` subcommands.
+4. Do not change `show`/`validate` behavior beyond help text; they already support `--type` for disambiguation.
+
+## Backward Compatibility
+All noun-based commands continue to work with clear deprecation warnings directing users to verb-first equivalents.
+
+## Out of Scope
+JSON output parity for `openspec list` across modes and `show --specs/--changes` discovery are follow-ups.
+
+

openspec/changes/archive/2025-08-19-adopt-verb-noun-cli-structure/proposal.md

@@ -0,0 +1,67 @@
+# Change: Adopt Verb–Noun CLI Structure (Deprecate Noun-Based Commands)
+
+## Why
+
+Most widely used CLIs (git, docker, kubectl) start with an action (verb) followed by the object (noun). This matches how users think: “do X to Y”. Using verbs as top-level commands improves clarity, discoverability, and extensibility.
+
+## What Changes
+
+- Promote top-level verb commands as primary entry points: `list`, `show`, `validate`, `diff`, `archive`.
+- Deprecate noun-based top-level commands: `openspec spec ...` and `openspec change ...`.
+- Introduce consistent noun scoping via flags where applicable (e.g., `--changes`, `--specs`) and keep smart defaults.
+- Clarify disambiguation for `show` and `validate` when names collide.
+
+### Mappings (From → To)
+
+- **List**
+  - From: `openspec change list`
+  - To: `openspec list --changes` (default), or `openspec list --specs`
+
+- **Show**
+  - From: `openspec spec show <spec-id>` / `openspec change show <change-id>`
+  - To: `openspec show <item-id>` with auto-detect, use `--type spec|change` if ambiguous
+
+- **Validate**
+  - From: `openspec spec validate <spec-id>` / `openspec change validate <change-id>`
+  - To: `openspec validate <item-id> --type spec|change`, or bulk: `openspec validate --specs` / `--changes` / `--all`
+
+### Backward Compatibility
+
+- Keep `openspec spec` and `openspec change` available with deprecation warnings for one release cycle.
+- Update help text to point users to the verb–noun alternatives.
+
+## Impact
+
+- **Affected specs**:
+  - `cli-list`: Add support for `--specs` and explicit `--changes` (default remains changes)
+  - `openspec-conventions`: Add explicit requirement establishing verb–noun CLI design and deprecation guidance
+- **Affected code**:
+  - `src/cli/index.ts`: Un-deprecate top-level `list`; mark `change list` as deprecated; ensure help text and warnings align
+  - `src/core/list.ts`: Support listing specs via `--specs` and default to changes; shared output shape
+  - Optional follow-ups: tighten `show`/`validate` help and ambiguity handling
+
+## Explicit Changes
+
+**CLI Design**
+- From: Mixed model with nouns (`spec`, `change`) and some top-level verbs; `openspec list` currently deprecated
+- To: Verbs as primary: `openspec list|show|validate|diff|archive`; nouns scoped via flags or item ids; noun commands deprecated
+- Reason: Align with common CLIs; improve UX; simpler mental model
+- Impact: Non-breaking with deprecation period; users migrate incrementally
+
+**Listing Behavior**
+- From: `openspec change list` (primary), `openspec list` (deprecated)
+- To: `openspec list` as primary, defaulting to `--changes`; add `--specs` to list specs
+- Reason: Consistent verb–noun style; better discoverability
+- Impact: New option; preserves existing behavior via default
+
+## Rollout and Deprecation Policy
+
+- Show deprecation warnings on noun-based commands for one release.
+- Document new usage in `openspec/README.md` and CLI help.
+- After one release, consider removing noun-based commands, or keep as thin aliases without warnings.
+
+## Open Questions
+
+- Should `show` also accept `--changes`/`--specs` for discovery without an id? (Out of scope here; current auto-detect and `--type` remain.)
+
+

openspec/changes/archive/2025-08-19-adopt-verb-noun-cli-structure/specs/cli-list/spec.md

@@ -0,0 +1,57 @@
+# Delta: CLI List Command
+
+## MODIFIED Requirements
+
+### Requirement: Command Execution
+The command SHALL scan and analyze either active changes or specs based on the selected mode.
+
+#### Scenario: Scanning for changes (default)
+- **WHEN** `openspec list` is executed without flags
+- **THEN** scan the `openspec/changes/` directory for change directories
+- **AND** exclude the `archive/` subdirectory from results
+- **AND** parse each change's `tasks.md` file to count task completion
+
+#### Scenario: Scanning for specs
+- **WHEN** `openspec list --specs` is executed
+- **THEN** scan the `openspec/specs/` directory for capabilities
+- **AND** read each capability's `spec.md`
+- **AND** parse requirements to compute requirement counts
+
+### Requirement: Output Format
+The command SHALL display items in a clear, readable table format with mode-appropriate progress or counts.
+
+#### Scenario: Displaying change list (default)
+- **WHEN** displaying the list of changes
+- **THEN** show a table with columns:
+  - Change name (directory name)
+  - Task progress (e.g., "3/5 tasks" or "✓ Complete")
+
+#### Scenario: Displaying spec list
+- **WHEN** displaying the list of specs
+- **THEN** show a table with columns:
+  - Spec id (directory name)
+  - Requirement count (e.g., "requirements 12")
+
+### Requirement: Empty State
+The command SHALL provide clear feedback when no items are present for the selected mode.
+
+#### Scenario: Handling empty state (changes)
+- **WHEN** no active changes exist (only archive/ or empty changes/)
+- **THEN** display: "No active changes found."
+
+#### Scenario: Handling empty state (specs)
+- **WHEN** no specs directory exists or contains no capabilities
+- **THEN** display: "No specs found."
+
+### Requirement: Flags
+The command SHALL accept flags to select the noun being listed.
+
+#### Scenario: Selecting specs
+- **WHEN** `--specs` is provided
+- **THEN** list specs instead of changes
+
+#### Scenario: Selecting changes
+- **WHEN** `--changes` is provided
+- **THEN** list changes explicitly (same as default behavior)
+
+

openspec/changes/archive/2025-08-19-adopt-verb-noun-cli-structure/specs/openspec-conventions/spec.md

@@ -0,0 +1,23 @@
+# Delta: OpenSpec Conventions — Verb–Noun CLI Design
+
+## ADDED Requirements
+
+### Requirement: Verb–Noun CLI Command Structure
+OpenSpec CLI design SHALL use verbs as top-level commands with nouns provided as arguments or flags for scoping.
+
+#### Scenario: Verb-first command discovery
+- **WHEN** a user runs a command like `openspec list`
+- **THEN** the verb communicates the action clearly
+- **AND** nouns refine scope via flags or arguments (e.g., `--changes`, `--specs`)
+
+#### Scenario: Backward compatibility for noun commands
+- **WHEN** users run noun-prefixed commands such as `openspec spec ...` or `openspec change ...`
+- **THEN** the CLI SHALL continue to support them for at least one release
+- **AND** display a deprecation warning that points to verb-first alternatives
+
+#### Scenario: Disambiguation guidance
+- **WHEN** item names are ambiguous between changes and specs
+- **THEN** `openspec show` and `openspec validate` SHALL accept `--type spec|change`
+- **AND** the help text SHALL document this clearly
+
+

openspec/changes/archive/2025-08-19-adopt-verb-noun-cli-structure/tasks.md

@@ -0,0 +1,27 @@
+# Implementation Tasks
+
+## 1. CLI Behavior and Help
+- [x] 1.1 Un-deprecate top-level `openspec list`; mark `change list` as deprecated with warning that points to `openspec list`
+- [x] 1.2 Add support to list specs via `openspec list --specs` and keep `--changes` as default
+- [x] 1.3 Update command descriptions and `--help` output to emphasize verb–noun pattern
+- [x] 1.4 Keep `openspec spec ...` and `openspec change ...` commands working but print deprecation notices
+
+## 2. Core List Logic
+- [x] 2.1 Extend `src/core/list.ts` to accept a mode: `changes` (default) or `specs`
+- [x] 2.2 Implement `specs` listing: scan `openspec/specs/*/spec.md`, compute requirement count via parser, format output consistently
+- [x] 2.3 Share output structure for both modes; preserve current text table; ensure JSON parity in future change
+
+## 3. Specs and Conventions
+- [x] 3.1 Update `openspec/specs/cli-list/spec.md` to document `--specs` (and default to changes)
+- [x] 3.2 Update `openspec/specs/openspec-conventions/spec.md` with a requirement for verb–noun CLI design and deprecation guidance
+
+## 4. Tests and Docs
+- [x] 4.1 Update tests: ensure `openspec list` works for changes and specs; keep `change list` tests but assert warning
+- [ ] 4.2 Update README and any usage docs to show new primary commands
+- [ ] 4.3 Add migration notes in repo CHANGELOG or README
+
+## 5. Follow-ups (Optional, not in this change)
+- [ ] 5.1 Consider `openspec show --specs/--changes` for discovery without ids
+- [ ] 5.2 Consider JSON output for `openspec list` with `--json` for both modes
+
+

openspec/changes/archive/2025-08-19-bulk-validation-interactive-selection/proposal.md

@@ -0,0 +1,20 @@
+## Why
+
+Currently, users must validate changes and specs individually by specifying each ID. This creates friction when:
+- Teams want to validate all changes/specs before a release
+- Developers need to ensure consistency across multiple related changes  
+- Users run validation commands without arguments and receive errors instead of helpful guidance
+- The subcommand structure requires users to know in advance whether they're validating a change or spec
+
+## What Changes
+
+- Add new top-level `validate` command with intuitive flags (--all, --changes, --specs)
+- Enhance existing `change validate` and `spec validate` to support interactive selection (backwards compatibility)
+- Interactive selection by default when no arguments provided
+- Support direct item validation: `openspec validate <item>` with automatic type detection
+
+## Impact
+
+- New specs to create: cli-validate
+- Specs to enhance: cli-change, cli-spec (for backwards compatibility)
+- Affected code: src/cli/index.ts, src/commands/validate.ts (new), src/commands/spec.ts, src/commands/change.ts

openspec/changes/archive/2025-08-19-bulk-validation-interactive-selection/specs/cli-change/spec.md

@@ -0,0 +1,22 @@
+# CLI Change Command Spec
+
+## ADDED Requirements
+
+### Requirement: Interactive validation selection
+
+The change validate command SHALL support interactive selection when no change name is provided.
+
+#### Scenario: Interactive change selection for validation
+
+- **WHEN** executing `openspec change validate` without arguments
+- **THEN** display an interactive list of available changes
+- **AND** allow the user to select a change to validate
+- **AND** validate the selected change
+
+#### Scenario: Non-interactive fallback keeps current behavior
+
+- **GIVEN** stdin is not a TTY or `--no-interactive` is provided or environment variable `OPEN_SPEC_INTERACTIVE=0`
+- **WHEN** executing `openspec change validate` without a change name
+- **THEN** do not prompt interactively
+- **AND** print the existing hint including available change IDs
+- **AND** set `process.exitCode = 1`

openspec/changes/archive/2025-08-19-bulk-validation-interactive-selection/specs/cli-spec/spec.md

@@ -0,0 +1,23 @@
+# CLI Spec Command Spec
+
+## ADDED Requirements
+
+### Requirement: Interactive spec validation
+
+The spec validate command SHALL support interactive selection when no spec-id is provided.
+
+#### Scenario: Interactive spec selection for validation
+
+- **WHEN** executing `openspec spec validate` without arguments
+- **THEN** display an interactive list of available specs
+- **AND** allow the user to select a spec to validate
+- **AND** validate the selected spec
+- **AND** maintain all existing validation options (--strict, --json)
+
+#### Scenario: Non-interactive fallback keeps current behavior
+
+- **GIVEN** stdin is not a TTY or `--no-interactive` is provided or environment variable `OPEN_SPEC_INTERACTIVE=0`
+- **WHEN** executing `openspec spec validate` without a spec-id
+- **THEN** do not prompt interactively
+- **AND** print the existing error message for missing spec-id
+- **AND** set non-zero exit code

openspec/changes/archive/2025-08-19-bulk-validation-interactive-selection/specs/cli-validate/spec.md

@@ -0,0 +1,149 @@
+# CLI Validate Command Spec
+
+## ADDED Requirements
+
+### Requirement: Top-level validate command
+
+The CLI SHALL provide a top-level `validate` command for validating changes and specs with flexible selection options.
+
+#### Scenario: Interactive validation selection
+
+- **WHEN** executing `openspec validate` without arguments
+- **THEN** prompt user to select what to validate (all, changes, specs, or specific item)
+- **AND** perform validation based on selection
+- **AND** display results with appropriate formatting
+
+#### Scenario: Non-interactive environments do not prompt
+
+- **GIVEN** stdin is not a TTY or `--no-interactive` is provided or environment variable `OPEN_SPEC_INTERACTIVE=0`
+- **WHEN** executing `openspec validate` without arguments
+- **THEN** do not prompt interactively
+- **AND** print a helpful hint listing available commands/flags and exit with code 1
+
+#### Scenario: Direct item validation
+
+- **WHEN** executing `openspec validate <item-name>`
+- **THEN** automatically detect if item is a change or spec
+- **AND** validate the specified item
+- **AND** display validation results
+
+### Requirement: Bulk and filtered validation
+
+The validate command SHALL support flags for bulk validation (--all) and filtered validation by type (--changes, --specs).
+
+#### Scenario: Validate everything
+
+- **WHEN** executing `openspec validate --all`
+- **THEN** validate all changes in openspec/changes/ (excluding archive)
+- **AND** validate all specs in openspec/specs/
+- **AND** display a summary showing passed/failed items
+- **AND** exit with code 1 if any validation fails
+
+#### Scenario: Scope of bulk validation
+
+- **WHEN** validating with `--all` or `--changes`
+- **THEN** include all change proposals under `openspec/changes/`
+- **AND** exclude the `openspec/changes/archive/` directory
+
+- **WHEN** validating with `--specs`
+- **THEN** include all specs that have a `spec.md` under `openspec/specs/<id>/spec.md`
+
+#### Scenario: Validate all changes
+
+- **WHEN** executing `openspec validate --changes`
+- **THEN** validate all changes in openspec/changes/ (excluding archive)
+- **AND** display results for each change
+- **AND** show summary statistics
+
+#### Scenario: Validate all specs
+
+- **WHEN** executing `openspec validate --specs`
+- **THEN** validate all specs in openspec/specs/
+- **AND** display results for each spec
+- **AND** show summary statistics
+
+### Requirement: Validation options and progress indication
+
+The validate command SHALL support standard validation options (--strict, --json) and display progress during bulk operations.
+
+#### Scenario: Strict validation
+
+- **WHEN** executing `openspec validate --all --strict`
+- **THEN** apply strict validation to all items
+- **AND** treat warnings as errors
+- **AND** fail if any item has warnings or errors
+
+#### Scenario: JSON output
+
+- **WHEN** executing `openspec validate --all --json`
+- **THEN** output validation results as JSON
+- **AND** include detailed issues for each item
+- **AND** include summary statistics
+
+#### Scenario: JSON output schema for bulk validation
+
+- **WHEN** executing `openspec validate --all --json` (or `--changes` / `--specs`)
+- **THEN** output a JSON object with the following shape:
+  - `items`: Array of objects with fields `{ id: string, type: "change"|"spec", valid: boolean, issues: Issue[], durationMs: number }`
+  - `summary`: Object `{ totals: { items: number, passed: number, failed: number }, byType: { change?: { items: number, passed: number, failed: number }, spec?: { items: number, passed: number, failed: number } } }`
+  - `version`: String identifier for the schema (e.g., `"1.0"`)
+- **AND** exit with code 1 if any `items[].valid === false`
+
+Where `Issue` follows the existing per-item validation report shape `{ level: "ERROR"|"WARNING"|"INFO", path: string, message: string }`.
+
+#### Scenario: Show validation progress
+
+- **WHEN** validating multiple items (--all, --changes, or --specs)
+- **THEN** show progress indicator or status updates
+- **AND** indicate which item is currently being validated
+- **AND** display running count of passed/failed items
+
+#### Scenario: Concurrency limits for performance
+
+- **WHEN** validating multiple items
+- **THEN** run validations with a bounded concurrency (e.g., 4–8 in parallel)
+- **AND** ensure progress indicators remain responsive
+
+### Requirement: Item type detection and ambiguity handling
+
+The validate command SHALL handle ambiguous names and explicit type overrides to ensure clear, deterministic behavior.
+
+#### Scenario: Direct item validation with automatic type detection
+
+- **WHEN** executing `openspec validate <item-name>`
+- **THEN** if `<item-name>` uniquely matches a change or a spec, validate that item
+
+#### Scenario: Ambiguity between change and spec names
+
+- **GIVEN** `<item-name>` exists both as a change and as a spec
+- **WHEN** executing `openspec validate <item-name>`
+- **THEN** print an ambiguity error explaining both matches
+- **AND** suggest passing `--type change` or `--type spec`, or using `openspec change validate` / `openspec spec validate`
+- **AND** exit with code 1 without performing validation
+
+#### Scenario: Unknown item name
+
+- **WHEN** the `<item-name>` matches neither a change nor a spec
+- **THEN** print a not-found error
+- **AND** show nearest-match suggestions when available
+- **AND** exit with code 1
+
+#### Scenario: Explicit type override
+
+- **WHEN** executing `openspec validate --type change <item>`
+- **THEN** treat `<item>` as a change ID and validate it (skipping auto-detection)
+
+- **WHEN** executing `openspec validate --type spec <item>`
+- **THEN** treat `<item>` as a spec ID and validate it (skipping auto-detection)
+
+### Requirement: Interactivity controls
+
+- The CLI SHALL respect `--no-interactive` to disable prompts.
+- The CLI SHALL respect `OPEN_SPEC_INTERACTIVE=0` to disable prompts globally.
+- Interactive prompts SHALL only be shown when stdin is a TTY and interactivity is not disabled.
+
+#### Scenario: Disabling prompts via flags or environment
+
+- **WHEN** `openspec validate` is executed with `--no-interactive` or with environment `OPEN_SPEC_INTERACTIVE=0`
+- **THEN** the CLI SHALL not display interactive prompts
+- **AND** SHALL print non-interactive hints or chosen outputs as appropriate

openspec/changes/archive/2025-08-19-bulk-validation-interactive-selection/tasks.md

@@ -0,0 +1,81 @@
+# Implementation Tasks
+
+## 1. Change Command: Interactive Validation Selection
+- [x] 1.1 Add `--no-interactive` flag to `change validate` in `src/cli/index.ts`
+- [x] 1.2 Implement interactivity gate respecting TTY and `OPEN_SPEC_INTERACTIVE=0` in `src/commands/change.ts`
+- [x] 1.3 When no `[change-name]` is provided and interactivity is allowed, prompt with a list of active changes (exclude `archive/`) and validate the selected one
+- [x] 1.4 Preserve current non-interactive fallback: print available change IDs and hint, set `process.exitCode = 1`
+- [x] 1.5 Tests: add coverage for interactive and non-interactive flows
+  - Added `test/commands/change.interactive-validate.test.ts`
+
+## 2. Spec Command: Interactive Validation Selection
+- [x] 2.1 Make `spec validate` accept optional `[spec-id]` in `src/commands/spec.ts` registration
+- [x] 2.2 Add `--no-interactive` flag to `spec validate`
+- [x] 2.3 Implement interactivity gate respecting TTY and `OPEN_SPEC_INTERACTIVE=0`
+- [x] 2.4 When no `[spec-id]` provided and interactivity allowed, prompt to select from `openspec/specs/*/spec.md` and validate the selected spec
+- [x] 2.5 Preserve current non-interactive fallback when no spec-id and no interactivity: print existing error and exit code non-zero
+- [x] 2.6 Tests: add coverage for interactive and non-interactive flows
+  - Added `test/commands/spec.interactive-validate.test.ts`
+
+## 3. New Top-level `validate` Command
+- [x] 3.1 Add `validate` command in `src/cli/index.ts`
+  - Options: `--all`, `--changes`, `--specs`, `--type <change|spec>`, `--strict`, `--json`, `--no-interactive`
+  - Usage: `openspec validate [item-name]`
+- [x] 3.2 Create `src/commands/validate.ts` implementing:
+  - [x] 3.2.1 Interactive selector when no args (choices: All, Changes, Specs, Specific item)
+  - [x] 3.2.2 Non-interactive fallback with helpful hint and exit code 1
+  - [x] 3.2.3 Direct item validation with automatic type detection
+  - [x] 3.2.4 Ambiguity error when name exists as both change and spec; suggest `--type` or subcommands
+  - [x] 3.2.5 Unknown item handling with nearest-match suggestions
+  - [x] 3.2.6 Bulk validation for `--all`, `--changes`, `--specs` (exclude `openspec/changes/archive/`)
+  - [x] 3.2.7 Respect `--strict` and `--json` options; JSON shape per spec
+  - [x] 3.2.8 Exit with code 1 if any validation fails
+  - [x] 3.2.9 Bounded concurrency (default 4–8) for bulk validation
+  - [x] 3.2.10 Progress indication during bulk runs (current item, running counts)
+
+## 4. Utilities and Shared Helpers
+- [x] 4.1 Add `src/utils/interactive.ts` with `isInteractive(stdin: NodeJS.ReadStream, noInteractiveFlag?: boolean): boolean`
+  - Considers: `process.stdin.isTTY`, `--no-interactive`, `OPEN_SPEC_INTERACTIVE=0`
+- [x] 4.2 Add `src/utils/item-discovery.ts` with:
+  - `getActiveChangeIds(root = process.cwd()): Promise<string[]>` (exclude `archive/`)
+  - `getSpecIds(root = process.cwd()): Promise<string[]>` (folders with `spec.md`)
+- [ ] 4.3 Optional: `src/utils/concurrency.ts` helper for bounded parallelism
+- [x] 4.4 Reuse `src/core/validation/validator.ts` for item validation
+
+## 5. JSON Output (Bulk Validation)
+- [x] 5.1 Implement JSON schema:
+  - `items: Array<{ id: string, type: "change"|"spec", valid: boolean, issues: Issue[], durationMs: number }>`
+  - `summary: { totals: { items: number, passed: number, failed: number }, byType: { change?: { items: number, passed: number, failed: number }, spec?: { items: number, passed: number, failed: number } } }`
+  - `version: "1.0"`
+- [x] 5.2 Ensure process exit code is 1 if any `items[].valid === false`
+- [x] 5.3 Tests for JSON shape (keys, types, counts) and exit code behavior
+  - Added `test/commands/validate.test.ts`
+
+## 6. Progress and UX
+- [x] 6.1 Use `ora` or minimal console progress to show current item and running counts
+- [x] 6.2 Keep output stable in `--json` mode (no extra logs to stdout; use stderr for progress if needed)
+- [x] 6.3 Ensure responsiveness with concurrency limits
+
+## 7. Tests
+- [x] 7.1 Add top-level validate tests: `test/commands/validate.test.ts`
+  - Includes non-interactive hint, --all JSON, --specs with concurrency, ambiguity error
+- [ ] 7.2 Add unit tests for `isInteractive` and item discovery helpers
+- [x] 7.3 Extend existing change/spec command tests to cover interactive `validate`
+  - Added `test/commands/change.interactive-validate.test.ts`, `test/commands/spec.interactive-validate.test.ts`
+
+## 8. CLI Help and Docs
+- [x] 8.1 Update command descriptions/options in `src/cli/index.ts`
+- [x] 8.2 Verify help output includes `validate` command and flags
+- [x] 8.3 Ensure existing specs under `openspec/changes/bulk-validation-interactive-selection/specs/*` remain satisfied
+
+## 9. Non-functional
+- [x] 9.1 Code style and types: explicit types for exported APIs; avoid `any`
+- [x] 9.2 No linter errors; stable formatting; avoid unrelated refactors
+- [x] 9.3 Maintain existing behavior for unaffected commands
+
+## 10. Acceptance Criteria Mapping
+- [x] AC-1: `openspec change validate` interactive selection when no arg (TTY only; respects `--no-interactive`/env) — matches cli-change spec
+- [x] AC-2: `openspec spec validate` interactive selection when no arg (TTY only; respects `--no-interactive`/env) — matches cli-spec spec
+- [x] AC-3: New `openspec validate` supports interactive selection, bulk/filtered validation, JSON schema, progress, concurrency, exit codes — matches cli-validate spec
+
+

openspec/changes/archive/2025-08-19-fix-update-tool-selection/proposal.md

@@ -25,4 +25,16 @@ Modify the update command to:
 - Update command only modifies existing AI tool configuration files
 - No new AI tool files created during update
 - Team members can use different AI tools without conflicts
-- Existing projects continue to work (backward compatibility)
+- Existing projects continue to work (backward compatibility)
+
+## Why
+
+Users need predictable, tool-agnostic behavior from `openspec update`. Creating or forcing updates for AI tool files that a project does not use causes confusion and merge conflicts. Restricting updates to existing files and always updating core OpenSpec files keeps the workflow consistent for mixed-tool teams.
+
+## What Changes
+
+- **cli-update:** Modify update behavior to update only existing AI tool configuration files and never create new ones; always update core OpenSpec files and display an ASCII-safe success message.
+
+## ADDED Requirements
+
+Removed from proposal to follow conventions. See `specs/cli-update/spec.md` for the delta requirements content.

openspec/changes/archive/2025-08-19-fix-update-tool-selection/specs/cli-update/spec.md

@@ -0,0 +1,23 @@
+## ADDED Requirements
+
+### Requirement: Tool-Agnostic Updates
+
+The update command SHALL update only existing AI tool configuration files and SHALL NOT create new ones.
+
+#### Scenario: Updating existing tool files
+
+- **WHEN** a user runs `openspec update`
+- **THEN** update each AI tool configuration file that exists (e.g., CLAUDE.md, COPILOT.md)
+- **AND** do not create missing tool configuration files
+- **AND** preserve user content outside OpenSpec markers
+
+### Requirement: Core Files Always Updated
+
+The update command SHALL always update the core OpenSpec files and display an ASCII-safe success message.
+
+#### Scenario: Successful update
+
+- **WHEN** the update completes successfully
+- **THEN** replace `openspec/README.md` with the latest template
+- **AND** update existing AI tool configuration files within markers
+- **AND** display the message: "Updated OpenSpec instructions"

openspec/changes/archive/2025-08-19-improve-validate-error-messages/proposal.md

@@ -0,0 +1,25 @@
+# improve-validate-error-messages
+
+## Why
+
+Developers struggle to resolve validation failures because current errors lack actionable guidance. Common issues include: missing deltas, missing required sections, and misformatted scenarios that are silently ignored. Without clear remediation steps, users cannot quickly correct structure or formatting, leading to frustration and rework. Improving error messages with concrete fixes, file/section hints, and suggested commands will significantly reduce time-to-green and make OpenSpec more approachable.
+
+## What Changes
+
+- Validation errors SHALL include specific remediation steps (what to change and where).
+- "No deltas found" error SHALL guide users to create `specs/` with proper delta headers and suggest debug commands.
+- Missing required sections (Spec: Purpose/Requirements; Change: Why/What Changes) SHALL include expected header names and a minimal skeleton example.
+- Likely misformatted scenarios (bulleted WHEN/THEN/AND) SHALL emit a targeted warning explaining the `#### Scenario:` format and show a conversion template.
+- All reported issues SHALL include the source file path and structured location (e.g., `deltas[0].requirements[0]`).
+- Non-JSON output SHOULD end with a short "Next steps" footer when invalid.
+
+## Impact
+
+- Affected CLI: validate
+- Affected code:
+  - `src/commands/validate.ts`
+  - `src/core/validation/validator.ts`
+  - `src/core/validation/constants.ts`
+  - `src/core/parsers/*` (wrapping thrown errors with richer context)
+
+

openspec/changes/archive/2025-08-19-improve-validate-error-messages/specs/cli-validate/spec.md

@@ -0,0 +1,55 @@
+# Validate Command
+
+## ADDED Requirements
+
+### Requirement: Validation SHALL provide actionable remediation steps
+Validation output SHALL include specific guidance to fix each error, including expected structure, example headers, and suggested commands to verify fixes.
+
+#### Scenario: No deltas found in change
+- **WHEN** validating a change with zero parsed deltas
+- **THEN** show error "No deltas found" with guidance:
+  - Ensure `openspec/changes/{id}/specs/` exists with `.md` files
+  - Use delta headers: `## ADDED Requirements`, `## MODIFIED Requirements`, `## REMOVED Requirements`, `## RENAMED Requirements`
+  - Each requirement must include at least one `#### Scenario:` block
+  - Try: `openspec change show {id} --json --deltas-only` to inspect what was parsed
+
+#### Scenario: Missing required sections
+- **WHEN** a required section is missing
+- **THEN** the validator SHALL include expected header names and a minimal skeleton:
+  - For Spec: `## Purpose`, `## Requirements`
+  - For Change: `## Why`, `## What Changes`
+  - Show an example snippet of the missing section
+
+### Requirement: Validator SHALL detect likely misformatted scenarios and warn with a fix
+The validator SHALL recognize bulleted lines that look like scenarios (e.g., lines beginning with WHEN/THEN/AND) and emit a targeted warning with a conversion example to `#### Scenario:`.
+
+#### Scenario: Bulleted WHEN/THEN under a Requirement
+- **WHEN** bullets that start with WHEN/THEN/AND are found under a requirement without any `#### Scenario:` headers
+- **THEN** emit warning: "Scenarios must use '#### Scenario:' headers", and show a conversion template:
+```
+#### Scenario: Short name
+- **WHEN** ...
+- **THEN** ...
+- **AND** ...
+```
+
+### Requirement: All issues SHALL include file paths and structured locations
+Error, warning, and info messages SHALL include:
+- Source file path (`openspec/changes/{id}/proposal.md`, `.../specs/{cap}/spec.md`)
+- Structured path (e.g., `deltas[0].requirements[0].scenarios`)
+
+#### Scenario: Zod validation error
+- **WHEN** a schema validation fails
+- **THEN** the message SHALL include `file`, `path`, and a remediation hint if applicable
+
+### Requirement: Invalid results SHALL include a Next steps footer in human-readable output
+The CLI SHALL append a Next steps footer when the item is invalid and not using `--json`, including:
+- Summary line with counts
+- Top-3 guidance bullets (contextual to the most frequent or blocking errors)
+- A suggestion to re-run with `--json` and/or the debug command
+
+#### Scenario: Change invalid summary
+- **WHEN** a change validation fails
+- **THEN** print "Next steps" with 2-3 targeted bullets and suggest `openspec change show <id> --json --deltas-only`
+
+

openspec/changes/archive/2025-08-19-improve-validate-error-messages/tasks.md

@@ -0,0 +1,21 @@
+## 1. Enhance validation messages
+- [x] 1.1 Add remediation guidance for "No deltas found"
+- [x] 1.2 Include file path and structured path in all issues
+- [x] 1.3 Improve messages for missing required sections (Spec, Change)
+- [x] 1.4 Detect likely misformatted scenarios and warn with conversion example
+- [x] 1.5 Add "Next steps" footer for non-JSON invalid output
+
+## 2. Update constants and helpers
+- [x] 2.1 Centralize guidance snippets in `VALIDATION_MESSAGES`
+- [x] 2.2 Provide minimal skeleton examples for missing sections
+
+## 3. Parser integration
+- [x] 3.1 Capture parser-thrown errors and wrap with richer context
+- [x] 3.2 Add file/section references to surfaced parser errors
+
+## 4. Tests
+- [x] 4.1 Unit tests for validator message composition
+- [x] 4.2 CLI integration tests for human-readable output (with footer)
+- [x] 4.3 JSON mode tests (structure unchanged, content enriched)
+
+

openspec/changes/archive/2025-08-19-structured-spec-format/proposal.md

@@ -33,4 +33,4 @@ OpenSpec specifications lack a consistent structure that makes sections visually
 - Affected specs: openspec-conventions (enhancement to existing capability)
 - Affected code: None initially - this is a documentation standard enhancement
 - Migration: Gradual - existing specs migrate as they're modified
-- Tooling: Enables future parsing tools but doesn't require them
+- Tooling: Enables future parsing tools but doesn't require them

openspec/changes/archive/2025-08-19-structured-spec-format/specs/openspec-conventions/spec.md

@@ -1,5 +1,17 @@
 # OpenSpec Conventions Specification
 
+## ADDED Requirements
+
+### Requirement: Structured Format Adoption
+
+Behavioral specifications SHALL adopt the structured format with `### Requirement:` and `#### Scenario:` headers as the default.
+
+#### Scenario: Use structured headings for behavior
+
+- **WHEN** documenting behavioral requirements
+- **THEN** use `### Requirement:` for requirements
+- **AND** use `#### Scenario:` for scenarios with bold WHEN/THEN/AND keywords
+
 ## Purpose
 
 OpenSpec conventions SHALL define how system capabilities are documented, how changes are proposed and tracked, and how specifications evolve over time. This meta-specification serves as the source of truth for OpenSpec's own conventions.

openspec/changes/fix-update-tool-selection/specs/cli-update/spec.md

@@ -1,113 +0,0 @@
-# Update Command Specification
-
-## Purpose
-
-As a developer using OpenSpec, I want to update the OpenSpec instructions in my project when new versions are released, so that I can benefit from improvements to AI agent instructions.
-
-## Core Requirements
-
-### Requirement: Update Behavior
-
-The update command SHALL update OpenSpec instruction files to the latest templates.
-
-#### Scenario: Running update command
-
-- **WHEN** a user runs `openspec update`
-- **THEN** the command SHALL:
-  - Check if the `openspec` directory exists
-  - Replace `openspec/README.md` with the latest template (complete replacement)
-  - For each supported AI tool configuration file:
-    - Check if the file exists (e.g., CLAUDE.md, COPILOT.md)
-    - If it exists, update it using appropriate markers
-    - If it doesn't exist, skip it (do NOT create)
-    - Preserve user content outside markers
-  - Display ASCII-safe success message: "Updated OpenSpec instructions"
-
-### Requirement: Prerequisites
-
-The command SHALL require an existing OpenSpec structure before allowing updates.
-
-#### Scenario: Checking prerequisites
-
-- **GIVEN** the command requires an existing `openspec` directory (created by `openspec init`)
-- **WHEN** the `openspec` directory does not exist
-- **THEN** display error: "No OpenSpec directory found. Run 'openspec init' first."
-- **AND** exit with code 1
-
-### Requirement: File Handling
-
-The update command SHALL handle file updates in a predictable and safe manner.
-
-#### Scenario: Updating files
-
-- **WHEN** updating files
-- **THEN** completely replace `openspec/README.md` with the latest template
-- **AND** update only the AI tool configuration files that already exist
-- **AND** use the default directory name `openspec`
-- **AND** be idempotent (repeated runs have no additional effect)
-
-### Requirement: Tool-Agnostic Updates
-
-The update command SHALL work for any team member regardless of their AI tool choice.
-
-#### Scenario: Team member using Claude
-
-- **GIVEN** a team member has CLAUDE.md in their project
-- **WHEN** running `openspec update`
-- **THEN** update the CLAUDE.md file with the latest template
-- **AND** preserve user content outside OpenSpec markers
-- **AND** NOT create files for other tools
-
-#### Scenario: Team member using different tool
-
-- **GIVEN** a team member has COPILOT.md but no CLAUDE.md
-- **WHEN** running `openspec update`
-- **THEN** update the COPILOT.md file if implementation exists
-- **AND** NOT create CLAUDE.md
-- **AND** preserve user content outside OpenSpec markers
-
-#### Scenario: Mixed team environment
-
-- **GIVEN** a repository with both CLAUDE.md and COPILOT.md (different team members)
-- **WHEN** any team member runs `openspec update`
-- **THEN** update all existing AI tool configuration files
-- **AND** NOT create new AI tool configuration files
-- **AND** each team member's preferred tool remains configured
-
-## Edge Cases
-
-### Requirement: Error Handling
-
-The command SHALL handle edge cases gracefully.
-
-#### Scenario: File permission errors
-
-- **WHEN** file write fails
-- **THEN** let the error bubble up naturally with file path
-
-#### Scenario: No AI tool files exist
-
-- **GIVEN** no AI tool configuration files exist
-- **WHEN** running update
-- **THEN** only update openspec/README.md
-- **AND** display success message
-
-#### Scenario: Custom directory names
-
-- **WHEN** considering custom directory names
-- **THEN** not supported in this change
-- **AND** the default directory name `openspec` SHALL be used
-
-## Success Criteria
-
-Users SHALL be able to:
-- Update OpenSpec instructions with a single command
-- Get the latest AI agent instructions for their existing tools
-- Work in teams where members use different AI tools
-- NOT have unwanted AI tool configuration files created
-
-The update process SHALL be:
-- Simple and fast (no version checking)
-- Predictable (same result every time)
-- Self-contained (no network required)
-- Team-friendly (respects individual tool choices)

openspec/changes/update-agent-instructions/design.md

@@ -0,0 +1,130 @@
+# Design: Agent Instructions Update
+
+## Approach
+
+### Information Architecture
+- **Front-load critical information** - Three-stage workflow comes first
+- **Clear hierarchy** - Core Workflow → Quick Start → Commands → Details → Edge Cases
+- **50% length reduction** - Target ~285 lines from current ~575 lines
+- **Imperative mood** - "Create proposal" vs "You should create a proposal"
+- **Bullet points over paragraphs** - Scannable, concise information
+
+### Three-Stage Workflow Documentation
+The workflow is now prominently featured as a core concept:
+1. **Creating** - Proposal generation phase
+2. **Implementing** - Code development phase with explicit steps:
+   - Read proposal.md for understanding
+   - Read design.md for technical context
+   - Read tasks.md for checklist
+   - Implement tasks sequentially
+   - Mark complete immediately after each task
+3. **Archiving** - Post-deployment finalization phase
+
+This structure helps agents understand the lifecycle and their role at each stage. The implementation phase is particularly detailed to prevent common mistakes like skipping documentation or batching task completion.
+
+### CLI Documentation Updates
+- **Comprehensive command coverage** - All 9 primary commands documented
+- **`openspec list` prominence** - Essential for discovering changes and specs
+- **Interactive mode documentation** - How agents can use prompts effectively
+- **Complete flag documentation** - All options like --json, --type, --skip-specs
+- **Deprecation cleanup** - Remove noun-first patterns (openspec change show)
+
+### Agent-Specific Enhancements
+Based on industry best practices for coding agents (Claude Code, Cursor, etc.):
+
+**Implementation Workflow**
+- Explicit steps prevent skipping critical context
+- Reading proposal/design first ensures understanding before coding
+- Sequential task completion maintains focus
+- Immediate marking prevents losing track of progress
+- Addresses common failure mode: jumping straight to code
+
+**Spec Discovery Workflow**
+- Always check existing specs before creating new ones
+- Use `openspec list --specs` to discover current capabilities
+- Prefer modifying existing specs over creating duplicates
+- Prevents fragmentation and maintains coherent architecture
+
+**Decision Clarity**
+- Clear decision trees eliminating ambiguous conditions
+- Concrete examples for each decision branch
+- Simplified bug vs feature determination
+
+**Tool Usage Guidance**
+- Tool selection matrix (when to use Grep vs Glob vs Read)
+- Error recovery patterns for common failures
+- Verification workflows to confirm correctness
+
+**Context Management**
+- "Before Any Task" checklist for gathering context
+- What to read before starting any work
+- How to maintain state across interactions
+
+**Spec File Structure Documentation**
+- Complete examples with ADDED/MODIFIED/REMOVED sections
+- Critical scenario formatting (#### Scenario: headers)
+- Delta file location clarity (changes/{name}/specs/)
+- Addresses most common creation errors from retrospective
+
+**Troubleshooting and Debugging**
+- Common error messages with solutions
+- Delta detection debugging steps
+- Validation best practices
+- JSON output for inspection
+- Prevents hours of frustration from silent failures
+
+**Best Practices**
+- Be concise (one-line answers when appropriate)
+- Be specific (file.ts:42 line references)
+- Start simple (<100 lines, single-file defaults)
+- Justify complexity (require metrics/data)
+
+## Design Rationale
+
+### Why These Changes Matter
+
+**Cognitive Load Reduction**
+- Agents process instructions better with clear structure
+- Front-loading critical info reduces scanning time
+- Decision trees eliminate analysis paralysis
+
+**Industry Alignment**
+- Follows patterns proven effective in Claude Code, Cursor, GitHub Copilot
+- Addresses common failure modes (ambiguous decisions, missing context)
+- Optimizes for LLM strengths (pattern matching) vs weaknesses (calculations)
+
+**Addressing Critical Pain Points (from Retrospective)**
+- **Scenario formatting** - Biggest struggle, now explicitly documented with examples
+- **Complete spec structure** - Full examples prevent structural errors
+- **Delta detection issues** - Debugging commands help diagnose problems
+- **Silent parsing failures** - Troubleshooting section explains common issues
+
+**Practical Impact**
+- Faster agent comprehension of tasks
+- Fewer misinterpretations of requirements
+- More consistent implementation quality
+- Better error recovery when things go wrong
+- Prevents the most common errors identified in user experience
+
+## Trade-offs
+
+### What We're Removing
+- Lengthy explanations of concepts that can be inferred
+- Redundant examples that don't add clarity
+- Verbose edge case documentation (moved to reference section)
+- Deprecated command documentation
+
+### What We're Keeping
+- All critical workflow steps
+- Complete CLI command reference
+- Complexity management principles
+- Directory structure visualization
+- Quick reference summary
+
+## Implementation Notes
+
+The CLAUDE.md template is intentionally more concise than README.md since:
+- It appears in every project root
+- Agents can reference the full README.md for details
+- It needs to load quickly in AI context windows
+- Focus is on immediate actionable guidance

openspec/changes/update-agent-instructions/proposal.md

@@ -0,0 +1,117 @@
+# Update OpenSpec Agent Instructions
+
+## Why
+
+The current OpenSpec agent instructions need updates to follow best practices for AI assistant instructions (brevity, clarity, removing ambiguity), ensure CLI commands are current with the actual implementation, and properly document the three-stage workflow pattern that agents should follow.
+
+## What Changes
+
+### Core Structure Improvements
+- **Front-load the 3-stage workflow** as the primary mental model:
+  1. Creating a change proposal (proposal.md, spec deltas, design.md, tasks.md)
+  2. Implementing a change proposal:
+     - First read proposal.md to understand the change
+     - Read design.md if it exists for technical context
+     - Read tasks.md for the implementation checklist
+     - Complete tasks one by one
+     - Mark each task complete immediately after finishing
+  3. Archiving the change proposal (using archive command after deployment)
+- **Reduce instruction length by 50%** while maintaining all critical information
+- **Restructure with clear hierarchy**: Core Workflow → Quick Start → Commands → Details → Edge Cases
+
+### Decision Clarity Enhancements
+- **Add clear decision trees** for common scenarios (bug vs feature, proposal needed vs not)
+- **Remove ambiguous conditions** that confuse agent decision-making
+- **Add "Before Any Task" checklist** for context gathering
+- **Add "Before Creating Specs" rule** - Always check existing specs first to avoid duplicates
+
+### CLI Documentation Updates
+- **Complete command documentation** with all current functionality:
+  - `openspec init [path]` - Initialize OpenSpec in a project
+  - `openspec list` - List all active changes (default)
+  - `openspec list --specs` - List all specifications
+  - `openspec show [item]` - Display change or spec with auto-detection
+  - `openspec show` - Interactive mode for selection
+  - `openspec diff [change]` - Show spec differences for a change
+  - `openspec validate [item]` - Validate changes or specs
+  - `openspec archive [change]` - Archive completed change after deployment
+  - `openspec update [path]` - Update OpenSpec instruction files
+- **Document all flags and options**:
+  - `--json` output format for programmatic use
+  - `--type change|spec` for disambiguation
+  - `--skip-specs` for tooling-only archives
+  - `--strict` for strict validation mode
+  - `--no-interactive` to disable prompts
+- **Remove deprecated command references** (noun-first patterns like `openspec change show`)
+- **Add concrete examples** for each command variation
+- **Document debugging commands**:
+  - `openspec show [change] --json --deltas-only` for inspecting deltas
+  - `openspec validate [change] --strict` for comprehensive validation
+
+### Spec File Structure Documentation
+- **Complete spec file examples** showing proper structure:
+  ```markdown
+  ## ADDED Requirements
+  ### Requirement: Clear requirement statement
+  The system SHALL provide the functionality...
+  
+  #### Scenario: Descriptive scenario name
+  - **WHEN** condition occurs
+  - **THEN** expected outcome
+  - **AND** additional outcomes
+  ```
+- **Scenario formatting requirements** (critical - most common error):
+  - MUST use `#### Scenario:` headers (4 hashtags)
+  - NOT bullet lists or bold text
+  - Each requirement MUST have at least one scenario
+- **Delta file location** - Clear explanation:
+  - Spec files go in `changes/{name}/specs/` directory
+  - Deltas are automatically extracted from these files
+  - Use operation prefixes: ADDED, MODIFIED, REMOVED, RENAMED
+
+### Troubleshooting Section
+- **Common errors and solutions**:
+  - "Change must have at least one delta" → Check specs/ directory exists with .md files
+  - "Requirement must have at least one scenario" → Check scenario uses `#### Scenario:` format
+  - Silent scenario parsing failures → Verify exact header format
+- **Delta detection debugging**:
+  - Use `openspec show [change] --json --deltas-only` to inspect parsed deltas
+  - Check that spec files have operation prefixes (## ADDED Requirements)
+  - Verify specs/ subdirectory structure
+- **Validation best practices**:
+  - Always use `--strict` flag for comprehensive checks
+  - Use JSON output for debugging: `--json | jq '.deltas'`
+
+### Agent-Specific Improvements
+- **Implementation workflow** - Clear step-by-step process:
+  1. Read proposal.md to understand what's being built
+  2. Read design.md (if exists) for technical decisions
+  3. Read tasks.md for the implementation checklist
+  4. Implement tasks one by one in order
+  5. Mark each task complete immediately: `- [x] Task completed`
+  6. Never skip ahead or batch task completion
+- **Spec discovery workflow** - Always check existing specs before creating new ones:
+  - Use `openspec list --specs` to see all current specs
+  - Check if capability already exists before creating
+  - Prefer modifying existing specs over creating duplicates
+- **Tool selection matrix** - When to use Grep vs Glob vs Read
+- **Error recovery patterns** - How to handle common failures
+- **Context management guide** - What to read before starting tasks
+- **Verification workflows** - How to confirm changes are correct
+
+### Best Practices Section
+- **Be concise** - One-line answers when appropriate
+- **Be specific** - Use exact file paths and line numbers (file.ts:42)
+- **Start simple** - Default to <100 lines, single-file implementations
+- **Justify complexity** - Require data/metrics for any optimization
+
+## Impact
+
+- Affected specs: None (this is a tooling/documentation change)
+- Affected code: 
+  - `src/core/templates/claude-template.ts` - Update CLAUDE.md template
+- Affected documentation:
+  - `openspec/README.md` - Main OpenSpec instructions
+  - CLAUDE.md files generated by `openspec init` command
+
+Note: This is a tooling/infrastructure change that doesn't require spec updates. When archiving, use `openspec archive update-agent-instructions --skip-specs`.

openspec/changes/update-agent-instructions/tasks.md

@@ -0,0 +1,69 @@
+# Implementation Tasks
+
+## 1. Restructure OpenSpec README.md
+- [ ] 1.1 Front-load the three-stage workflow as primary content
+- [ ] 1.2 Restructure with hierarchy: Core Workflow → Quick Start → Commands → Details → Edge Cases
+- [ ] 1.3 Reduce total length by 50% (target: ~285 lines from current ~575)
+- [ ] 1.4 Add "Before Any Task" context-gathering checklist
+- [ ] 1.5 Add "Before Creating Specs" rule to check existing specs first
+
+## 2. Add Decision Clarity  
+- [ ] 2.1 Create clear decision trees for "Create Proposal?" scenarios
+- [ ] 2.2 Remove ambiguous conditions that confuse agents
+- [ ] 2.3 Add concrete examples for each decision branch
+- [ ] 2.4 Simplify bug vs feature determination logic
+- [ ] 2.5 Add explicit Stage 2 implementation steps (read → implement → mark complete)
+
+## 3. Update CLI Documentation
+- [ ] 3.1 Document `openspec list` and `openspec list --specs` commands
+- [ ] 3.2 Document `openspec show` with all flags and interactive mode
+- [ ] 3.3 Document `openspec diff [change]` for viewing spec differences
+- [ ] 3.4 Document `openspec archive` with --skip-specs option
+- [ ] 3.5 Document `openspec validate` with --strict and batch modes
+- [ ] 3.6 Document `openspec init` and `openspec update` commands
+- [ ] 3.7 Remove all deprecated noun-first command references
+- [ ] 3.8 Add concrete usage examples for each command variation
+- [ ] 3.9 Document all flags: --json, --type, --no-interactive, etc.
+- [ ] 3.10 Document debugging commands: `show --json --deltas-only`
+
+## 4. Add Spec File Documentation
+- [ ] 4.1 Add complete spec file structure example with ADDED/MODIFIED sections
+- [ ] 4.2 Document scenario formatting requirements (#### Scenario: headers)
+- [ ] 4.3 Explain delta file location (changes/{name}/specs/ directory)
+- [ ] 4.4 Show how deltas are automatically extracted
+- [ ] 4.5 Include warning about most common error (scenario formatting)
+
+## 5. Add Troubleshooting Section
+- [ ] 5.1 Document common errors and their solutions
+- [ ] 5.2 Add delta detection debugging steps
+- [ ] 5.3 Include validation best practices (--strict flag)
+- [ ] 5.4 Show how to use JSON output for debugging
+- [ ] 5.5 Add examples of silent parsing failures
+
+## 6. Add Agent-Specific Sections
+- [ ] 6.1 Add implementation workflow (read docs → implement tasks → mark complete)
+- [ ] 6.2 Add spec discovery workflow (check existing before creating)
+- [ ] 6.3 Create tool selection matrix (Grep vs Glob vs Read)
+- [ ] 6.4 Add error recovery patterns section
+- [ ] 6.5 Add context management guide
+- [ ] 6.6 Add verification workflows section
+- [ ] 6.7 Add best practices section (concise, specific, simple)
+
+## 7. Update CLAUDE.md Template
+- [ ] 7.1 Update `src/core/templates/claude-template.ts` with streamlined content
+- [ ] 7.2 Include three-stage workflow prominently
+- [ ] 7.3 Add comprehensive CLI quick reference (list, show, diff, archive, etc.)
+- [ ] 7.4 Add "Before Any Task" checklist
+- [ ] 7.5 Add "Before Creating Specs" rule
+- [ ] 7.6 Keep complexity management principles
+- [ ] 7.7 Add critical scenario formatting note (#### Scenario: headers)
+- [ ] 7.8 Include debugging command reference
+
+## 8. Testing and Validation
+- [ ] 8.1 Test all documented CLI commands for accuracy
+- [ ] 8.2 Run `openspec init` to verify CLAUDE.md generation
+- [ ] 8.3 Validate instruction clarity with example scenarios
+- [ ] 8.4 Ensure no critical information was lost in streamlining
+- [ ] 8.5 Verify decision trees eliminate ambiguity
+- [ ] 8.6 Test scenario formatting examples work correctly
+- [ ] 8.7 Verify troubleshooting steps resolve common errors

openspec/specs/cli-archive/spec.md

@@ -10,9 +10,7 @@ openspec archive [change-name] [--yes|-y]
 
 Options:
 - `--yes`, `-y`: Skip confirmation prompts (for automation)
-
 ## Requirements
-
 ### Requirement: Change Selection
 
 The command SHALL support both interactive and direct change selection methods.
@@ -72,26 +70,25 @@ The archive operation SHALL follow a structured process to safely move changes t
 
 ### Requirement: Spec Update Process
 
-Before moving the change to archive, the command SHALL update main specs to reflect the deployed reality.
+Before moving the change to archive, the command SHALL apply delta changes to main specs to reflect the deployed reality.
 
-#### Scenario: Updating specs from change
+#### Scenario: Applying delta changes
 
-- **WHEN** the change contains specs in `changes/[name]/specs/`
-- **THEN** execute these steps:
-  1. Analyze which specs will be affected by comparing with existing specs
-  2. Display a summary of spec updates to the user (see Confirmation Behavior below)
-  3. Prompt for confirmation unless `--yes` flag is provided
-  4. If confirmed, for each capability spec in the change directory:
-     - Copy the spec from `changes/[name]/specs/[capability]/spec.md` to `openspec/specs/[capability]/spec.md`
-     - Create the target directory structure if it doesn't exist
-     - Overwrite existing spec files (specs represent current reality, change specs are the new reality)
-     - Track which specs were updated for the success message
+- **WHEN** archiving a change with delta-based specs
+- **THEN** parse and apply delta changes as defined in openspec-conventions
+- **AND** validate all operations before applying
 
-#### Scenario: No specs in change
+#### Scenario: Validating delta changes
 
-- **WHEN** no specs exist in the change
-- **THEN** skip the spec update step
-- **AND** proceed with archiving
+- **WHEN** processing delta changes
+- **THEN** perform validations as specified in openspec-conventions
+- **AND** if validation fails, show specific errors and abort
+
+#### Scenario: Conflict detection
+
+- **WHEN** applying deltas would create duplicate requirement headers
+- **THEN** abort with error message showing the conflict
+- **AND** suggest manual resolution
 
 ### Requirement: Confirmation Behavior
 
@@ -129,8 +126,6 @@ The spec update confirmation SHALL provide clear visibility into changes before
 - **AND** display message: "Archive cancelled. No changes were made."
 - **AND** exit with non-zero status code
 
-## Error Handling
-
 ### Requirement: Error Conditions
 
 The command SHALL handle various error conditions gracefully.
@@ -144,6 +139,66 @@ The command SHALL handle various error conditions gracefully.
   - Archive target already exists
   - File system permissions issues
 
+### Requirement: Skip Specs Option
+
+The archive command SHALL support a `--skip-specs` flag that skips all spec update operations and proceeds directly to archiving.
+
+#### Scenario: Skipping spec updates with flag
+
+- **WHEN** executing `openspec archive <change> --skip-specs`
+- **THEN** skip spec discovery and update confirmation
+- **AND** proceed directly to moving the change to archive
+- **AND** display a message indicating specs were skipped
+
+### Requirement: Non-blocking confirmation
+
+The archive operation SHALL proceed when the user declines spec updates instead of cancelling the entire operation.
+
+#### Scenario: User declines spec update confirmation
+
+- **WHEN** the user declines spec update confirmation
+- **THEN** skip spec updates
+- **AND** continue with the archive operation
+- **AND** display a success message indicating specs were not updated
+
+### Requirement: Display Output
+
+The command SHALL provide clear feedback about delta operations.
+
+#### Scenario: Showing delta application
+
+- **WHEN** applying delta changes
+- **THEN** display for each spec:
+  - Number of requirements added
+  - Number of requirements modified
+  - Number of requirements removed
+  - Number of requirements renamed
+- **AND** use standard output symbols (+ ~ - →) as defined in openspec-conventions:
+  ```
+  Applying changes to specs/user-auth/spec.md:
+    + 2 added
+    ~ 3 modified
+    - 1 removed
+    → 1 renamed
+  ```
+
+### Requirement: Archive Validation
+
+The archive command SHALL validate changes before applying them to ensure data integrity.
+
+#### Scenario: Pre-archive validation
+
+- **WHEN** executing `openspec archive change-name`
+- **THEN** validate the change structure first
+- **AND** only proceed if validation passes
+- **AND** show validation errors if it fails
+
+#### Scenario: Force archive without validation
+
+- **WHEN** executing `openspec archive change-name --no-validate`
+- **THEN** skip validation (unsafe mode)
+- **AND** show warning about skipping validation
+
 ## Why These Decisions
 
 **Interactive selection**: Reduces typing and helps users see available changes

openspec/specs/cli-change/spec.md

@@ -0,0 +1,91 @@
+# cli-change Specification
+
+## Purpose
+TBD - created by archiving change add-change-commands. Update Purpose after archive.
+## Requirements
+### Requirement: Change Command
+
+The system SHALL provide a `change` command with subcommands for displaying, listing, and validating change proposals.
+
+#### Scenario: Show change as JSON
+
+- **WHEN** executing `openspec change show update-error --json`
+- **THEN** parse the markdown change file
+- **AND** extract change structure and deltas
+- **AND** output valid JSON to stdout
+
+#### Scenario: List all changes
+
+- **WHEN** executing `openspec change list`
+- **THEN** scan the openspec/changes directory
+- **AND** return list of all pending changes
+- **AND** support JSON output with `--json` flag
+
+#### Scenario: Show only requirement changes
+
+- **WHEN** executing `openspec change show update-error --requirements-only`
+- **THEN** display only the requirement changes (ADDED/MODIFIED/REMOVED/RENAMED)
+- **AND** exclude why and what changes sections
+
+#### Scenario: Validate change structure
+
+- **WHEN** executing `openspec change validate update-error`
+- **THEN** parse the change file
+- **AND** validate against Zod schema
+- **AND** ensure deltas are well-formed
+
+### Requirement: Legacy Compatibility
+
+The system SHALL maintain backward compatibility with the existing `list` command while showing deprecation notices.
+
+#### Scenario: Legacy list command
+
+- **WHEN** executing `openspec list`
+- **THEN** display current list of changes (existing behavior)
+- **AND** show deprecation notice: "Note: 'openspec list' is deprecated. Use 'openspec change list' instead."
+
+#### Scenario: Legacy list with --all flag
+
+- **WHEN** executing `openspec list --all`
+- **THEN** display all changes (existing behavior)
+- **AND** show same deprecation notice
+
+### Requirement: Interactive show selection
+
+The change show command SHALL support interactive selection when no change name is provided.
+
+#### Scenario: Interactive change selection for show
+
+- **WHEN** executing `openspec change show` without arguments
+- **THEN** display an interactive list of available changes
+- **AND** allow the user to select a change to show
+- **AND** display the selected change content
+- **AND** maintain all existing show options (--json, --deltas-only)
+
+#### Scenario: Non-interactive fallback keeps current behavior
+
+- **GIVEN** stdin is not a TTY or `--no-interactive` is provided or environment variable `OPEN_SPEC_INTERACTIVE=0`
+- **WHEN** executing `openspec change show` without a change name
+- **THEN** do not prompt interactively
+- **AND** print the existing hint including available change IDs
+- **AND** set `process.exitCode = 1`
+
+### Requirement: Interactive validation selection
+
+The change validate command SHALL support interactive selection when no change name is provided.
+
+#### Scenario: Interactive change selection for validation
+
+- **WHEN** executing `openspec change validate` without arguments
+- **THEN** display an interactive list of available changes
+- **AND** allow the user to select a change to validate
+- **AND** validate the selected change
+
+#### Scenario: Non-interactive fallback keeps current behavior
+
+- **GIVEN** stdin is not a TTY or `--no-interactive` is provided or environment variable `OPEN_SPEC_INTERACTIVE=0`
+- **WHEN** executing `openspec change validate` without a change name
+- **THEN** do not prompt interactively
+- **AND** print the existing hint including available change IDs
+- **AND** set `process.exitCode = 1`
+

openspec/specs/cli-diff/spec.md

@@ -9,9 +9,7 @@ The `openspec diff` command provides developers with a visual comparison between
 ```bash
 openspec diff [change-name]
 ```
-
 ## Requirements
-
 ### Requirement: Without Arguments
 
 The command SHALL provide an interactive selection when no change is specified.
@@ -33,35 +31,18 @@ The command SHALL compare specs when a specific change is provided.
 
 ### Requirement: Diff Output
 
-The command SHALL generate appropriate diff output for all spec changes.
+The command SHALL show a requirement-level comparison displaying only changed requirements.
 
-#### Scenario: Comparing existing files
+#### Scenario: Side-by-side comparison of changes
 
-- **WHEN** file exists in both locations
-- **THEN** show unified diff
-
-#### Scenario: New files
-
-- **WHEN** file only exists in change
-- **THEN** show as new file (all lines with +)
-
-#### Scenario: Deleted files
-
-- **WHEN** file only exists in current specs
-- **THEN** show as deleted (all lines with -)
-
-### Requirement: Display Format
-
-The command SHALL use standard unified diff format for consistency with existing tools.
-
-#### Scenario: Formatting diff output
-
-- **WHEN** displaying diff output
-- **THEN** use standard unified diff format:
-  - Lines prefixed with `-` for removed content
-  - Lines prefixed with `+` for added content
-  - Lines without prefix for unchanged context
-  - File headers showing the paths being compared
+- **WHEN** running `openspec diff <change>`
+- **THEN** display only requirements that have changed
+- **AND** show them in a side-by-side format that:
+  - Clearly shows the current version on the left
+  - Shows the future version on the right
+  - Indicates new requirements (not in current)
+  - Indicates removed requirements (not in future)
+  - Aligns modified requirements for easy comparison
 
 ### Requirement: Color Support
 
@@ -95,6 +76,28 @@ The command SHALL provide clear error messages for various failure conditions.
 - **WHEN** changes directory doesn't exist
 - **THEN** display "No OpenSpec changes directory found"
 
+### Requirement: Validation
+
+The command SHALL validate that changes can be applied successfully.
+
+#### Scenario: Invalid delta references
+
+- **WHEN** delta references non-existent requirement
+- **THEN** show error message with specific requirement
+- **AND** continue showing other valid changes
+- **AND** clearly mark failed changes in the output
+
+### Requirement: Diff Command Enhancement
+
+The diff command SHALL validate change structure before displaying differences.
+
+#### Scenario: Validate before diff
+
+- **WHEN** executing `openspec diff change-name`
+- **THEN** validate change structure
+- **AND** show validation warnings if present
+- **AND** continue with diff display
+
 ## Examples
 
 ```bash

openspec/specs/cli-list/spec.md

@@ -3,20 +3,22 @@
 ## Purpose
 
 The `openspec list` command SHALL provide developers with a quick overview of all active changes in the project, showing their names and task completion status.
-
 ## Requirements
-
 ### Requirement: Command Execution
+The command SHALL scan and analyze either active changes or specs based on the selected mode.
 
-The command SHALL scan and analyze all active changes to provide a comprehensive overview.
-
-#### Scenario: Scanning for changes
-
-- **WHEN** `openspec list` is executed
+#### Scenario: Scanning for changes (default)
+- **WHEN** `openspec list` is executed without flags
 - **THEN** scan the `openspec/changes/` directory for change directories
 - **AND** exclude the `archive/` subdirectory from results
 - **AND** parse each change's `tasks.md` file to count task completion
 
+#### Scenario: Scanning for specs
+- **WHEN** `openspec list --specs` is executed
+- **THEN** scan the `openspec/specs/` directory for capabilities
+- **AND** read each capability's `spec.md`
+- **AND** parse requirements to compute requirement counts
+
 ### Requirement: Task Counting
 
 The command SHALL accurately count task completion status using standard markdown checkbox patterns.
@@ -30,37 +32,42 @@ The command SHALL accurately count task completion status using standard markdow
 - **AND** calculate total tasks as the sum of completed and incomplete
 
 ### Requirement: Output Format
+The command SHALL display items in a clear, readable table format with mode-appropriate progress or counts.
 
-The command SHALL display changes in a clear, readable table format with progress indicators.
-
-#### Scenario: Displaying change list
-
-- **WHEN** displaying the list
+#### Scenario: Displaying change list (default)
+- **WHEN** displaying the list of changes
 - **THEN** show a table with columns:
   - Change name (directory name)
   - Task progress (e.g., "3/5 tasks" or "✓ Complete")
-- **AND** use status indicators:
-  - `✓` for fully completed changes (all tasks done)
-  - Progress fraction for partial completion
 
-Example output:
-```
-Changes:
-  add-auth-feature     3/5 tasks
-  update-api-docs      ✓ Complete
-  fix-validation       0/2 tasks
-  add-list-command     1/4 tasks
-```
+#### Scenario: Displaying spec list
+- **WHEN** displaying the list of specs
+- **THEN** show a table with columns:
+  - Spec id (directory name)
+  - Requirement count (e.g., "requirements 12")
+
+### Requirement: Flags
+The command SHALL accept flags to select the noun being listed.
+
+#### Scenario: Selecting specs
+- **WHEN** `--specs` is provided
+- **THEN** list specs instead of changes
+
+#### Scenario: Selecting changes
+- **WHEN** `--changes` is provided
+- **THEN** list changes explicitly (same as default behavior)
 
 ### Requirement: Empty State
+The command SHALL provide clear feedback when no items are present for the selected mode.
 
-The command SHALL provide clear feedback when no active changes are present.
-
-#### Scenario: Handling empty state
-
+#### Scenario: Handling empty state (changes)
 - **WHEN** no active changes exist (only archive/ or empty changes/)
 - **THEN** display: "No active changes found."
 
+#### Scenario: Handling empty state (specs)
+- **WHEN** no specs directory exists or contains no capabilities
+- **THEN** display: "No specs found."
+
 ### Requirement: Error Handling
 
 The command SHALL gracefully handle missing files and directories with appropriate messages.

openspec/specs/cli-show/spec.md

@@ -0,0 +1,85 @@
+# cli-show Specification
+
+## Purpose
+TBD - created by archiving change add-interactive-show-command. Update Purpose after archive.
+## Requirements
+### Requirement: Top-level show command
+
+The CLI SHALL provide a top-level `show` command for displaying changes and specs with intelligent selection.
+
+#### Scenario: Interactive show selection
+
+- **WHEN** executing `openspec show` without arguments
+- **THEN** prompt user to select type (change or spec)
+- **AND** display list of available items for selected type
+- **AND** show the selected item's content
+
+#### Scenario: Non-interactive environments do not prompt
+
+- **GIVEN** stdin is not a TTY or `--no-interactive` is provided or environment variable `OPEN_SPEC_INTERACTIVE=0`
+- **WHEN** executing `openspec show` without arguments
+- **THEN** do not prompt
+- **AND** print a helpful hint with examples for `openspec show <item>` or `openspec change/spec show`
+- **AND** exit with code 1
+
+#### Scenario: Direct item display
+
+- **WHEN** executing `openspec show <item-name>`
+- **THEN** automatically detect if item is a change or spec
+- **AND** display the item's content
+- **AND** use appropriate formatting based on item type
+
+#### Scenario: Type detection and ambiguity handling
+
+- **WHEN** executing `openspec show <item-name>`
+- **THEN** if `<item-name>` uniquely matches a change or a spec, show that item
+- **AND** if it matches both, print an ambiguity error and suggest `--type change|spec` or using `openspec change show`/`openspec spec show`
+- **AND** if it matches neither, print not-found with nearest-match suggestions
+
+#### Scenario: Explicit type override
+
+- **WHEN** executing `openspec show --type change <item>`
+- **THEN** treat `<item>` as a change ID and show it (skipping auto-detection)
+
+- **WHEN** executing `openspec show --type spec <item>`
+- **THEN** treat `<item>` as a spec ID and show it (skipping auto-detection)
+
+### Requirement: Output format options
+
+The show command SHALL support various output formats consistent with existing commands.
+
+#### Scenario: JSON output
+
+- **WHEN** executing `openspec show <item> --json`
+- **THEN** output the item in JSON format
+- **AND** include parsed metadata and structure
+- **AND** maintain format consistency with existing change/spec show commands
+
+#### Scenario: Flag scoping and delegation
+
+- **WHEN** showing a change or a spec via the top-level command
+- **THEN** accept common flags such as `--json`
+- **AND** pass through type-specific flags to the corresponding implementation
+  - Change-only flags: `--deltas-only` (alias `--requirements-only` deprecated)
+  - Spec-only flags: `--requirements`, `--no-scenarios`, `-r/--requirement`
+- **AND** ignore irrelevant flags for the detected type with a warning
+
+### Requirement: Interactivity controls
+
+- The CLI SHALL respect `--no-interactive` to disable prompts.
+- The CLI SHALL respect `OPEN_SPEC_INTERACTIVE=0` to disable prompts globally.
+- Interactive prompts SHALL only be shown when stdin is a TTY and interactivity is not disabled.
+
+#### Scenario: Change-specific options
+
+- **WHEN** showing a change with `openspec show <change-name> --deltas-only`
+- **THEN** display only the deltas in JSON format
+- **AND** maintain compatibility with existing change show options
+
+#### Scenario: Spec-specific options  
+
+- **WHEN** showing a spec with `openspec show <spec-id> --requirements`
+- **THEN** display only requirements in JSON format
+- **AND** support other spec options (--no-scenarios, -r)
+- **AND** maintain compatibility with existing spec show options
+

openspec/specs/cli-spec/spec.md

@@ -0,0 +1,87 @@
+# cli-spec Specification
+
+## Purpose
+TBD - created by archiving change add-interactive-show-command. Update Purpose after archive.
+## Requirements
+### Requirement: Interactive spec show
+
+The spec show command SHALL support interactive selection when no spec-id is provided.
+
+#### Scenario: Interactive spec selection for show
+
+- **WHEN** executing `openspec spec show` without arguments
+- **THEN** display an interactive list of available specs
+- **AND** allow the user to select a spec to show
+- **AND** display the selected spec content
+- **AND** maintain all existing show options (--json, --requirements, --no-scenarios, -r)
+
+#### Scenario: Non-interactive fallback keeps current behavior
+
+- **GIVEN** stdin is not a TTY or `--no-interactive` is provided or environment variable `OPEN_SPEC_INTERACTIVE=0`
+- **WHEN** executing `openspec spec show` without a spec-id
+- **THEN** do not prompt interactively
+- **AND** print the existing error message for missing spec-id
+- **AND** set non-zero exit code
+
+### Requirement: Spec Command
+
+The system SHALL provide a `spec` command with subcommands for displaying, listing, and validating specifications.
+
+#### Scenario: Show spec as JSON
+
+- **WHEN** executing `openspec spec show init --json`
+- **THEN** parse the markdown spec file
+- **AND** extract headings and content hierarchically
+- **AND** output valid JSON to stdout
+
+#### Scenario: List all specs
+
+- **WHEN** executing `openspec spec list`
+- **THEN** scan the openspec/specs directory
+- **AND** return list of all available capabilities
+- **AND** support JSON output with `--json` flag
+
+#### Scenario: Filter spec content
+
+- **WHEN** executing `openspec spec show init --requirements`
+- **THEN** display only requirement names and SHALL statements
+- **AND** exclude scenario content
+
+#### Scenario: Validate spec structure
+
+- **WHEN** executing `openspec spec validate init`
+- **THEN** parse the spec file
+- **AND** validate against Zod schema
+- **AND** report any structural issues
+
+### Requirement: JSON Schema Definition
+
+The system SHALL define Zod schemas that accurately represent the spec structure for runtime validation.
+
+#### Scenario: Schema validation
+
+- **WHEN** parsing a spec into JSON
+- **THEN** validate the structure using Zod schemas
+- **AND** ensure all required fields are present
+- **AND** provide clear error messages for validation failures
+
+### Requirement: Interactive spec validation
+
+The spec validate command SHALL support interactive selection when no spec-id is provided.
+
+#### Scenario: Interactive spec selection for validation
+
+- **WHEN** executing `openspec spec validate` without arguments
+- **THEN** display an interactive list of available specs
+- **AND** allow the user to select a spec to validate
+- **AND** validate the selected spec
+- **AND** maintain all existing validation options (--strict, --json)
+
+#### Scenario: Non-interactive fallback keeps current behavior
+
+- **GIVEN** stdin is not a TTY or `--no-interactive` is provided or environment variable `OPEN_SPEC_INTERACTIVE=0`
+- **WHEN** executing `openspec spec validate` without a spec-id
+- **THEN** do not prompt interactively
+- **AND** print the existing error message for missing spec-id
+- **AND** set non-zero exit code
+

openspec/specs/cli-update/spec.md

@@ -3,9 +3,7 @@
 ## Purpose
 
 As a developer using OpenSpec, I want to update the OpenSpec instructions in my project when new versions are released, so that I can benefit from improvements to AI agent instructions.
-
-## Core Requirements
-
+## Requirements
 ### Requirement: Update Behavior
 
 The update command SHALL update OpenSpec instruction files to the latest templates in a team-friendly manner.
@@ -48,6 +46,28 @@ The update command SHALL handle file updates in a predictable and safe manner.
 - **AND** be idempotent (repeated runs have no additional effect)
 - **AND** respect team members' AI tool choices by not creating unwanted files
 
+### Requirement: Tool-Agnostic Updates
+
+The update command SHALL update only existing AI tool configuration files and SHALL NOT create new ones.
+
+#### Scenario: Updating existing tool files
+
+- **WHEN** a user runs `openspec update`
+- **THEN** update each AI tool configuration file that exists (e.g., CLAUDE.md, COPILOT.md)
+- **AND** do not create missing tool configuration files
+- **AND** preserve user content outside OpenSpec markers
+
+### Requirement: Core Files Always Updated
+
+The update command SHALL always update the core OpenSpec files and display an ASCII-safe success message.
+
+#### Scenario: Successful update
+
+- **WHEN** the update completes successfully
+- **THEN** replace `openspec/README.md` with the latest template
+- **AND** update existing AI tool configuration files within markers
+- **AND** display the message: "Updated OpenSpec instructions"
+
 ## Edge Cases
 
 ### Requirement: Error Handling

openspec/specs/cli-validate/spec.md

@@ -0,0 +1,201 @@
+# cli-validate Specification
+
+## Purpose
+TBD - created by archiving change improve-validate-error-messages. Update Purpose after archive.
+## Requirements
+### Requirement: Validation SHALL provide actionable remediation steps
+Validation output SHALL include specific guidance to fix each error, including expected structure, example headers, and suggested commands to verify fixes.
+
+#### Scenario: No deltas found in change
+- **WHEN** validating a change with zero parsed deltas
+- **THEN** show error "No deltas found" with guidance:
+  - Ensure `openspec/changes/{id}/specs/` exists with `.md` files
+  - Use delta headers: `## ADDED Requirements`, `## MODIFIED Requirements`, `## REMOVED Requirements`, `## RENAMED Requirements`
+  - Each requirement must include at least one `#### Scenario:` block
+  - Try: `openspec change show {id} --json --deltas-only` to inspect what was parsed
+
+#### Scenario: Missing required sections
+- **WHEN** a required section is missing
+- **THEN** the validator SHALL include expected header names and a minimal skeleton:
+  - For Spec: `## Purpose`, `## Requirements`
+  - For Change: `## Why`, `## What Changes`
+  - Show an example snippet of the missing section
+
+### Requirement: Validator SHALL detect likely misformatted scenarios and warn with a fix
+The validator SHALL recognize bulleted lines that look like scenarios (e.g., lines beginning with WHEN/THEN/AND) and emit a targeted warning with a conversion example to `#### Scenario:`.
+
+#### Scenario: Bulleted WHEN/THEN under a Requirement
+- **WHEN** bullets that start with WHEN/THEN/AND are found under a requirement without any `#### Scenario:` headers
+- **THEN** emit warning: "Scenarios must use '#### Scenario:' headers", and show a conversion template:
+```
+#### Scenario: Short name
+- **WHEN** ...
+- **THEN** ...
+- **AND** ...
+```
+
+### Requirement: All issues SHALL include file paths and structured locations
+Error, warning, and info messages SHALL include:
+- Source file path (`openspec/changes/{id}/proposal.md`, `.../specs/{cap}/spec.md`)
+- Structured path (e.g., `deltas[0].requirements[0].scenarios`)
+
+#### Scenario: Zod validation error
+- **WHEN** a schema validation fails
+- **THEN** the message SHALL include `file`, `path`, and a remediation hint if applicable
+
+### Requirement: Invalid results SHALL include a Next steps footer in human-readable output
+The CLI SHALL append a Next steps footer when the item is invalid and not using `--json`, including:
+- Summary line with counts
+- Top-3 guidance bullets (contextual to the most frequent or blocking errors)
+- A suggestion to re-run with `--json` and/or the debug command
+
+#### Scenario: Change invalid summary
+- **WHEN** a change validation fails
+- **THEN** print "Next steps" with 2-3 targeted bullets and suggest `openspec change show <id> --json --deltas-only`
+
+### Requirement: Top-level validate command
+
+The CLI SHALL provide a top-level `validate` command for validating changes and specs with flexible selection options.
+
+#### Scenario: Interactive validation selection
+
+- **WHEN** executing `openspec validate` without arguments
+- **THEN** prompt user to select what to validate (all, changes, specs, or specific item)
+- **AND** perform validation based on selection
+- **AND** display results with appropriate formatting
+
+#### Scenario: Non-interactive environments do not prompt
+
+- **GIVEN** stdin is not a TTY or `--no-interactive` is provided or environment variable `OPEN_SPEC_INTERACTIVE=0`
+- **WHEN** executing `openspec validate` without arguments
+- **THEN** do not prompt interactively
+- **AND** print a helpful hint listing available commands/flags and exit with code 1
+
+#### Scenario: Direct item validation
+
+- **WHEN** executing `openspec validate <item-name>`
+- **THEN** automatically detect if item is a change or spec
+- **AND** validate the specified item
+- **AND** display validation results
+
+### Requirement: Bulk and filtered validation
+
+The validate command SHALL support flags for bulk validation (--all) and filtered validation by type (--changes, --specs).
+
+#### Scenario: Validate everything
+
+- **WHEN** executing `openspec validate --all`
+- **THEN** validate all changes in openspec/changes/ (excluding archive)
+- **AND** validate all specs in openspec/specs/
+- **AND** display a summary showing passed/failed items
+- **AND** exit with code 1 if any validation fails
+
+#### Scenario: Scope of bulk validation
+
+- **WHEN** validating with `--all` or `--changes`
+- **THEN** include all change proposals under `openspec/changes/`
+- **AND** exclude the `openspec/changes/archive/` directory
+
+- **WHEN** validating with `--specs`
+- **THEN** include all specs that have a `spec.md` under `openspec/specs/<id>/spec.md`
+
+#### Scenario: Validate all changes
+
+- **WHEN** executing `openspec validate --changes`
+- **THEN** validate all changes in openspec/changes/ (excluding archive)
+- **AND** display results for each change
+- **AND** show summary statistics
+
+#### Scenario: Validate all specs
+
+- **WHEN** executing `openspec validate --specs`
+- **THEN** validate all specs in openspec/specs/
+- **AND** display results for each spec
+- **AND** show summary statistics
+
+### Requirement: Validation options and progress indication
+
+The validate command SHALL support standard validation options (--strict, --json) and display progress during bulk operations.
+
+#### Scenario: Strict validation
+
+- **WHEN** executing `openspec validate --all --strict`
+- **THEN** apply strict validation to all items
+- **AND** treat warnings as errors
+- **AND** fail if any item has warnings or errors
+
+#### Scenario: JSON output
+
+- **WHEN** executing `openspec validate --all --json`
+- **THEN** output validation results as JSON
+- **AND** include detailed issues for each item
+- **AND** include summary statistics
+
+#### Scenario: JSON output schema for bulk validation
+
+- **WHEN** executing `openspec validate --all --json` (or `--changes` / `--specs`)
+- **THEN** output a JSON object with the following shape:
+  - `items`: Array of objects with fields `{ id: string, type: "change"|"spec", valid: boolean, issues: Issue[], durationMs: number }`
+  - `summary`: Object `{ totals: { items: number, passed: number, failed: number }, byType: { change?: { items: number, passed: number, failed: number }, spec?: { items: number, passed: number, failed: number } } }`
+  - `version`: String identifier for the schema (e.g., `"1.0"`)
+- **AND** exit with code 1 if any `items[].valid === false`
+
+Where `Issue` follows the existing per-item validation report shape `{ level: "ERROR"|"WARNING"|"INFO", path: string, message: string }`.
+
+#### Scenario: Show validation progress
+
+- **WHEN** validating multiple items (--all, --changes, or --specs)
+- **THEN** show progress indicator or status updates
+- **AND** indicate which item is currently being validated
+- **AND** display running count of passed/failed items
+
+#### Scenario: Concurrency limits for performance
+
+- **WHEN** validating multiple items
+- **THEN** run validations with a bounded concurrency (e.g., 4–8 in parallel)
+- **AND** ensure progress indicators remain responsive
+
+### Requirement: Item type detection and ambiguity handling
+
+The validate command SHALL handle ambiguous names and explicit type overrides to ensure clear, deterministic behavior.
+
+#### Scenario: Direct item validation with automatic type detection
+
+- **WHEN** executing `openspec validate <item-name>`
+- **THEN** if `<item-name>` uniquely matches a change or a spec, validate that item
+
+#### Scenario: Ambiguity between change and spec names
+
+- **GIVEN** `<item-name>` exists both as a change and as a spec
+- **WHEN** executing `openspec validate <item-name>`
+- **THEN** print an ambiguity error explaining both matches
+- **AND** suggest passing `--type change` or `--type spec`, or using `openspec change validate` / `openspec spec validate`
+- **AND** exit with code 1 without performing validation
+
+#### Scenario: Unknown item name
+
+- **WHEN** the `<item-name>` matches neither a change nor a spec
+- **THEN** print a not-found error
+- **AND** show nearest-match suggestions when available
+- **AND** exit with code 1
+
+#### Scenario: Explicit type override
+
+- **WHEN** executing `openspec validate --type change <item>`
+- **THEN** treat `<item>` as a change ID and validate it (skipping auto-detection)
+
+- **WHEN** executing `openspec validate --type spec <item>`
+- **THEN** treat `<item>` as a spec ID and validate it (skipping auto-detection)
+
+### Requirement: Interactivity controls
+
+- The CLI SHALL respect `--no-interactive` to disable prompts.
+- The CLI SHALL respect `OPEN_SPEC_INTERACTIVE=0` to disable prompts globally.
+- Interactive prompts SHALL only be shown when stdin is a TTY and interactivity is not disabled.
+
+#### Scenario: Disabling prompts via flags or environment
+
+- **WHEN** `openspec validate` is executed with `--no-interactive` or with environment `OPEN_SPEC_INTERACTIVE=0`
+- **THEN** the CLI SHALL not display interactive prompts
+- **AND** SHALL print non-interactive hints or chosen outputs as appropriate
+

openspec/specs/openspec-conventions/spec.md

@@ -3,6 +3,226 @@
 ## Purpose
 
 OpenSpec conventions SHALL define how system capabilities are documented, how changes are proposed and tracked, and how specifications evolve over time. This meta-specification serves as the source of truth for OpenSpec's own conventions.
+## Requirements
+### Requirement: Structured conventions for specs and changes
+
+OpenSpec conventions SHALL mandate a structured spec format with clear requirement and scenario sections so tooling can parse consistently.
+
+#### Scenario: Following the structured spec format
+
+- **WHEN** writing or updating OpenSpec specifications
+- **THEN** authors SHALL use `### Requirement: ...` followed by at least one `#### Scenario: ...` section
+
+### Requirement: Project Structure
+
+An OpenSpec project SHALL maintain a consistent directory structure for specifications and changes.
+
+#### Scenario: Initializing project structure
+
+- **WHEN** an OpenSpec project is initialized
+- **THEN** it SHALL have this structure:
+```
+openspec/
+├── project.md              # Project-specific context
+├── README.md               # AI assistant instructions
+├── specs/                  # Current deployed capabilities
+│   └── [capability]/       # Single, focused capability
+│       ├── spec.md         # WHAT and WHY
+│       └── design.md       # HOW (optional, for established patterns)
+└── changes/                # Proposed changes
+    ├── [change-name]/      # Descriptive change identifier
+    │   ├── proposal.md     # Why, what, and impact
+    │   ├── tasks.md        # Implementation checklist
+    │   ├── design.md       # Technical decisions (optional)
+    │   └── specs/          # Complete future state
+    │       └── [capability]/
+    │           └── spec.md # Clean markdown (no diff syntax)
+    └── archive/            # Completed changes
+        └── YYYY-MM-DD-[name]/
+```
+
+### Requirement: Structured Format for Behavioral Specs
+
+Behavioral specifications SHALL use a structured format with consistent section headers and keywords to ensure visual consistency and parseability.
+
+#### Scenario: Writing requirement sections
+
+- **WHEN** documenting a requirement in a behavioral specification
+- **THEN** use a level-3 heading with format `### Requirement: [Name]`
+- **AND** immediately follow with a SHALL statement describing core behavior
+- **AND** keep requirement names descriptive and under 50 characters
+
+#### Scenario: Documenting scenarios
+
+- **WHEN** documenting specific behaviors or use cases
+- **THEN** use level-4 headings with format `#### Scenario: [Description]`
+- **AND** use bullet points with bold keywords for steps:
+  - **GIVEN** for initial state (optional)
+  - **WHEN** for conditions or triggers
+  - **THEN** for expected outcomes
+  - **AND** for additional outcomes or conditions
+
+#### Scenario: Adding implementation details
+
+- **WHEN** a step requires additional detail
+- **THEN** use sub-bullets under the main step
+- **AND** maintain consistent indentation
+  - Sub-bullets provide examples or specifics
+  - Keep sub-bullets concise
+
+### Requirement: Header-Based Requirement Identification
+
+Requirement headers SHALL serve as unique identifiers for programmatic matching between current specs and proposed changes.
+
+#### Scenario: Matching requirements programmatically
+
+- **WHEN** processing delta changes
+- **THEN** use the `### Requirement: [Name]` header as the unique identifier
+- **AND** match using normalized headers: `normalize(header) = trim(header)`
+- **AND** compare headers with case-sensitive equality after normalization
+
+#### Scenario: Handling requirement renames
+
+- **WHEN** renaming a requirement
+- **THEN** use a special `## RENAMED Requirements` section
+- **AND** specify both old and new names explicitly:
+  ```markdown
+  ## RENAMED Requirements
+  - FROM: `### Requirement: Old Name`
+  - TO: `### Requirement: New Name`
+  ```
+- **AND** if content also changes, include under MODIFIED using the NEW header
+
+#### Scenario: Validating header uniqueness
+
+- **WHEN** creating or modifying requirements
+- **THEN** ensure no duplicate headers exist within a spec
+- **AND** validation tools SHALL flag duplicate headers as errors
+
+### Requirement: Change Storage Convention
+
+Change proposals SHALL store only the additions, modifications, and removals to specifications, not complete future states.
+
+#### Scenario: Creating change proposals with additions
+
+- **WHEN** creating a change proposal that adds new requirements
+- **THEN** include only the new requirements under `## ADDED Requirements`
+- **AND** each requirement SHALL include its complete content
+- **AND** use the standard structured format for requirements and scenarios
+
+#### Scenario: Creating change proposals with modifications  
+
+- **WHEN** creating a change proposal that modifies existing requirements
+- **THEN** include the modified requirements under `## MODIFIED Requirements`
+- **AND** use the same header text as in the current spec (normalized)
+- **AND** include the complete modified requirement (not a diff)
+- **AND** optionally annotate what changed with inline comments like `← (was X)`
+
+#### Scenario: Creating change proposals with removals
+
+- **WHEN** creating a change proposal that removes requirements
+- **THEN** list them under `## REMOVED Requirements`
+- **AND** use the normalized header text for identification
+- **AND** include reason for removal
+- **AND** document any migration path if applicable
+
+The `changes/[name]/specs/` directory SHALL contain:
+- Delta files showing only what changes
+- Sections for ADDED, MODIFIED, REMOVED, and RENAMED requirements
+- Normalized header matching for requirement identification
+- Complete requirements using the structured format
+- Clear indication of change type for each requirement
+
+#### Scenario: Using standard output symbols
+
+- **WHEN** displaying delta operations in CLI output
+- **THEN** use these standard symbols:
+  - `+` for ADDED (green)
+  - `~` for MODIFIED (yellow)
+  - `-` for REMOVED (red)
+  - `→` for RENAMED (cyan)
+
+### Requirement: Archive Process Enhancement
+
+The archive process SHALL programmatically apply delta changes to current specifications using header-based matching.
+
+#### Scenario: Archiving changes with deltas
+
+- **WHEN** archiving a completed change
+- **THEN** the archive command SHALL:
+  1. Parse RENAMED sections first and apply renames
+  2. Parse REMOVED sections and remove by normalized header match
+  3. Parse MODIFIED sections and replace by normalized header match (using new names if renamed)
+  4. Parse ADDED sections and append new requirements
+- **AND** validate that all MODIFIED/REMOVED headers exist in current spec
+- **AND** validate that ADDED headers don't already exist
+- **AND** generate the updated spec in the main specs/ directory
+
+#### Scenario: Handling conflicts during archive
+
+- **WHEN** delta changes conflict with current spec state
+- **THEN** the archive command SHALL report specific conflicts
+- **AND** require manual resolution before proceeding
+- **AND** provide clear guidance on resolving conflicts
+
+### Requirement: Proposal Format
+
+Proposals SHALL explicitly document all changes with clear from/to comparisons.
+
+#### Scenario: Documenting changes
+
+- **WHEN** documenting what changes
+- **THEN** the proposal SHALL explicitly describe each change:
+
+```markdown
+**[Section or Behavior Name]**
+- From: [current state/requirement]
+- To: [future state/requirement]
+- Reason: [why this change is needed]
+- Impact: [breaking/non-breaking, who's affected]
+```
+
+This explicit format compensates for not having inline diffs and ensures reviewers understand exactly what will change.
+
+### Requirement: Change Review
+
+The system SHALL support multiple methods for reviewing proposed changes.
+
+#### Scenario: Reviewing changes
+
+- **WHEN** reviewing proposed changes
+- **THEN** reviewers can compare using:
+- GitHub PR diff view when changes are committed
+- Command line: `diff -u specs/[capability]/spec.md changes/[name]/specs/[capability]/spec.md`
+- Any visual diff tool comparing current vs future state
+
+### Requirement: Structured Format Adoption
+
+Behavioral specifications SHALL adopt the structured format with `### Requirement:` and `#### Scenario:` headers as the default.
+
+#### Scenario: Use structured headings for behavior
+
+- **WHEN** documenting behavioral requirements
+- **THEN** use `### Requirement:` for requirements
+- **AND** use `#### Scenario:` for scenarios with bold WHEN/THEN/AND keywords
+
+### Requirement: Verb–Noun CLI Command Structure
+OpenSpec CLI design SHALL use verbs as top-level commands with nouns provided as arguments or flags for scoping.
+
+#### Scenario: Verb-first command discovery
+- **WHEN** a user runs a command like `openspec list`
+- **THEN** the verb communicates the action clearly
+- **AND** nouns refine scope via flags or arguments (e.g., `--changes`, `--specs`)
+
+#### Scenario: Backward compatibility for noun commands
+- **WHEN** users run noun-prefixed commands such as `openspec spec ...` or `openspec change ...`
+- **THEN** the CLI SHALL continue to support them for at least one release
+- **AND** display a deprecation warning that points to verb-first alternatives
+
+#### Scenario: Disambiguation guidance
+- **WHEN** item names are ambiguous between changes and specs
+- **THEN** `openspec show` and `openspec validate` SHALL accept `--type spec|change`
+- **AND** the help text SHALL document this clearly
 
 ## Core Principles
 
@@ -73,7 +293,6 @@ Behavioral specifications SHALL use a structured format with consistent section
   - Sub-bullets provide examples or specifics
   - Keep sub-bullets concise
 
-
 ## Change Storage Convention
 
 ### Requirement: Header-Based Requirement Identification
@@ -132,7 +351,6 @@ Change proposals SHALL store only the additions, modifications, and removals to
 - **AND** include reason for removal
 - **AND** document any migration path if applicable
 
-
 The `changes/[name]/specs/` directory SHALL contain:
 - Delta files showing only what changes
 - Sections for ADDED, MODIFIED, REMOVED, and RENAMED requirements

package.json

@@ -37,7 +37,8 @@
     "build": "node build.js",
     "dev": "tsc --watch",
     "dev:cli": "pnpm build && node bin/openspec.js",
-    "test": "vitest",
+    "test": "vitest run",
+    "test:watch": "vitest",
     "test:ui": "vitest --ui",
     "test:coverage": "vitest --coverage",
     "prepare": "npm run build"

src/cli/index.ts

@@ -9,6 +9,8 @@ import { ListCommand } from '../core/list.js';
 import { ArchiveCommand } from '../core/archive.js';
 import { registerSpecCommand } from '../commands/spec.js';
 import { ChangeCommand } from '../commands/change.js';
+import { ValidateCommand } from '../commands/validate.js';
+import { ShowCommand } from '../commands/show.js';
 
 const program = new Command();
 
@@ -92,12 +94,14 @@ program
 
 program
   .command('list')
-  .description('List all active changes with their task status (DEPRECATED: use "openspec change list" instead)')
-  .action(async () => {
+  .description('List items (changes by default). Use --specs to list specs.')
+  .option('--specs', 'List specs instead of changes')
+  .option('--changes', 'List changes explicitly (default)')
+  .action(async (options?: { specs?: boolean; changes?: boolean }) => {
     try {
-      console.log('\x1b[33m%s\x1b[0m', 'Warning: The "openspec list" command is deprecated. Please use "openspec change list" instead.\n');
       const listCommand = new ListCommand();
-      await listCommand.execute();
+      const mode: 'changes' | 'specs' = options?.specs ? 'specs' : 'changes';
+      await listCommand.execute('.', mode);
     } catch (error) {
       console.log(); // Empty line for spacing
       ora().fail(`Error: ${(error as Error).message}`);
@@ -110,13 +114,19 @@ const changeCmd = program
   .command('change')
   .description('Manage OpenSpec change proposals');
 
+// Deprecation notice for noun-based commands
+changeCmd.hook('preAction', () => {
+  console.error('Warning: The "openspec change ..." commands are deprecated. Prefer verb-first commands (e.g., "openspec list", "openspec validate --changes").');
+});
+
 changeCmd
   .command('show [change-name]')
   .description('Show a change proposal in JSON or markdown format')
   .option('--json', 'Output as JSON')
   .option('--deltas-only', 'Show only deltas (JSON only)')
   .option('--requirements-only', 'Alias for --deltas-only (deprecated)')
-  .action(async (changeName?: string, options?: { json?: boolean; requirementsOnly?: boolean; deltasOnly?: boolean }) => {
+  .option('--no-interactive', 'Disable interactive prompts')
+  .action(async (changeName?: string, options?: { json?: boolean; requirementsOnly?: boolean; deltasOnly?: boolean; noInteractive?: boolean }) => {
     try {
       const changeCommand = new ChangeCommand();
       await changeCommand.show(changeName, options);
@@ -128,11 +138,12 @@ changeCmd
 
 changeCmd
   .command('list')
-  .description('List all active changes')
+  .description('List all active changes (DEPRECATED: use "openspec list" instead)')
   .option('--json', 'Output as JSON')
   .option('--long', 'Show id and title with counts')
   .action(async (options?: { json?: boolean; long?: boolean }) => {
     try {
+      console.error('Warning: "openspec change list" is deprecated. Use "openspec list".');
       const changeCommand = new ChangeCommand();
       await changeCommand.list(options);
     } catch (error) {
@@ -146,10 +157,14 @@ changeCmd
   .description('Validate a change proposal')
   .option('--strict', 'Enable strict validation mode')
   .option('--json', 'Output validation report as JSON')
-  .action(async (changeName?: string, options?: { strict?: boolean; json?: boolean }) => {
+  .option('--no-interactive', 'Disable interactive prompts')
+  .action(async (changeName?: string, options?: { strict?: boolean; json?: boolean; noInteractive?: boolean }) => {
     try {
       const changeCommand = new ChangeCommand();
       await changeCommand.validate(changeName, options);
+      if (typeof process.exitCode === 'number' && process.exitCode !== 0) {
+        process.exit(process.exitCode);
+      }
     } catch (error) {
       console.error(`Error: ${(error as Error).message}`);
       process.exitCode = 1;
@@ -175,4 +190,54 @@ program
 
 registerSpecCommand(program);
 
+// Top-level validate command
+program
+  .command('validate [item-name]')
+  .description('Validate changes and specs')
+  .option('--all', 'Validate all changes and specs')
+  .option('--changes', 'Validate all changes')
+  .option('--specs', 'Validate all specs')
+  .option('--type <type>', 'Specify item type when ambiguous: change|spec')
+  .option('--strict', 'Enable strict validation mode')
+  .option('--json', 'Output validation results as JSON')
+  .option('--concurrency <n>', 'Max concurrent validations (defaults to env OPENSPEC_CONCURRENCY or 6)')
+  .option('--no-interactive', 'Disable interactive prompts')
+  .action(async (itemName?: string, options?: { all?: boolean; changes?: boolean; specs?: boolean; type?: string; strict?: boolean; json?: boolean; noInteractive?: boolean; concurrency?: string }) => {
+    try {
+      const validateCommand = new ValidateCommand();
+      await validateCommand.execute(itemName, options);
+    } catch (error) {
+      console.log();
+      ora().fail(`Error: ${(error as Error).message}`);
+      process.exit(1);
+    }
+  });
+
+// Top-level show command
+program
+  .command('show [item-name]')
+  .description('Show a change or spec')
+  .option('--json', 'Output as JSON')
+  .option('--type <type>', 'Specify item type when ambiguous: change|spec')
+  .option('--no-interactive', 'Disable interactive prompts')
+  // change-only flags
+  .option('--deltas-only', 'Show only deltas (JSON only, change)')
+  .option('--requirements-only', 'Alias for --deltas-only (deprecated, change)')
+  // spec-only flags
+  .option('--requirements', 'JSON only: Show only requirements (exclude scenarios)')
+  .option('--no-scenarios', 'JSON only: Exclude scenario content')
+  .option('-r, --requirement <id>', 'JSON only: Show specific requirement by ID (1-based)')
+  // allow unknown options to pass-through to underlying command implementation
+  .allowUnknownOption(true)
+  .action(async (itemName?: string, options?: { json?: boolean; type?: string; noInteractive?: boolean; [k: string]: any }) => {
+    try {
+      const showCommand = new ShowCommand();
+      await showCommand.execute(itemName, options ?? {});
+    } catch (error) {
+      console.log();
+      ora().fail(`Error: ${(error as Error).message}`);
+      process.exit(1);
+    }
+  });
+
 program.parse();

src/commands/change.ts

@@ -1,9 +1,12 @@
 import { promises as fs } from 'fs';
 import path from 'path';
+import { select } from '@inquirer/prompts';
 import { JsonConverter } from '../core/converters/json-converter.js';
 import { Validator } from '../core/validation/validator.js';
 import { ChangeParser } from '../core/parsers/change-parser.js';
 import { Change } from '../core/schemas/index.js';
+import { isInteractive } from '../utils/interactive.js';
+import { getActiveChangeIds } from '../utils/item-discovery.js';
 
 // Constants for better maintainability
 const ARCHIVE_DIR = 'archive';
@@ -23,19 +26,28 @@ export class ChangeCommand {
    * - JSON mode: minimal object with deltas; --deltas-only returns same object with filtered deltas
    *   Note: --requirements-only is deprecated alias for --deltas-only
    */
-  async show(changeName?: string, options?: { json?: boolean; requirementsOnly?: boolean; deltasOnly?: boolean }): Promise<void> {
+  async show(changeName?: string, options?: { json?: boolean; requirementsOnly?: boolean; deltasOnly?: boolean; noInteractive?: boolean }): Promise<void> {
     const changesPath = path.join(process.cwd(), 'openspec', 'changes');
     
     if (!changeName) {
+      const canPrompt = isInteractive(options?.noInteractive);
       const changes = await this.getActiveChanges(changesPath);
-      if (changes.length === 0) {
-        console.error('No change specified. No active changes found.');
+      if (canPrompt && changes.length > 0) {
+        const selected = await select({
+          message: 'Select a change to show',
+          choices: changes.map(id => ({ name: id, value: id })),
+        });
+        changeName = selected;
       } else {
-        console.error(`No change specified. Available IDs: ${changes.join(', ')}`);
+        if (changes.length === 0) {
+          console.error('No change specified. No active changes found.');
+        } else {
+          console.error(`No change specified. Available IDs: ${changes.join(', ')}`);
+        }
+        console.error('Hint: use "openspec change list" to view available changes.');
+        process.exitCode = 1;
+        return;
       }
-      console.error('Hint: use "openspec change list" to view available changes.');
-      process.exitCode = 1;
-      return;
     }
     
     const proposalPath = path.join(changesPath, changeName, 'proposal.md');
@@ -170,31 +182,40 @@ export class ChangeCommand {
     }
   }
 
-  async validate(changeName?: string, options?: { strict?: boolean; json?: boolean }): Promise<void> {
+  async validate(changeName?: string, options?: { strict?: boolean; json?: boolean; noInteractive?: boolean }): Promise<void> {
     const changesPath = path.join(process.cwd(), 'openspec', 'changes');
     
     if (!changeName) {
-      const changes = await this.getActiveChanges(changesPath);
-      if (changes.length === 0) {
-        console.error('No change specified. No active changes found.');
+      const canPrompt = isInteractive(options?.noInteractive);
+      const changes = await getActiveChangeIds();
+      if (canPrompt && changes.length > 0) {
+        const selected = await select({
+          message: 'Select a change to validate',
+          choices: changes.map(id => ({ name: id, value: id })),
+        });
+        changeName = selected;
       } else {
-        console.error(`No change specified. Available IDs: ${changes.join(', ')}`);
+        if (changes.length === 0) {
+          console.error('No change specified. No active changes found.');
+        } else {
+          console.error(`No change specified. Available IDs: ${changes.join(', ')}`);
+        }
+        console.error('Hint: use "openspec change list" to view available changes.');
+        process.exitCode = 1;
+        return;
       }
-      console.error('Hint: use "openspec change list" to view available changes.');
-      process.exitCode = 1;
-      return;
     }
     
-    const proposalPath = path.join(changesPath, changeName, 'proposal.md');
+    const changeDir = path.join(changesPath, changeName);
     
     try {
-      await fs.access(proposalPath);
+      await fs.access(changeDir);
     } catch {
-      throw new Error(`Change "${changeName}" not found at ${proposalPath}`);
+      throw new Error(`Change "${changeName}" not found at ${changeDir}`);
     }
     
     const validator = new Validator(options?.strict || false);
-    const report = await validator.validateChange(proposalPath);
+    const report = await validator.validateChangeDeltaSpecs(changeDir);
     
     if (options?.json) {
       console.log(JSON.stringify(report, null, 2));
@@ -202,12 +223,17 @@ export class ChangeCommand {
       if (report.valid) {
         console.log(`Change "${changeName}" is valid`);
       } else {
-        console.error(`Change "${changeName}" has validation issues`);
+        console.error(`Change "${changeName}" has issues`);
         report.issues.forEach(issue => {
           const label = issue.level === 'ERROR' ? 'ERROR' : 'WARNING';
           const prefix = issue.level === 'ERROR' ? '✗' : '⚠';
           console.error(`${prefix} [${label}] ${issue.path}: ${issue.message}`);
         });
+        // Next steps footer to guide fixing issues
+        this.printNextSteps();
+        if (!options?.json) {
+          process.exitCode = 1;
+        }
       }
     }
   }
@@ -245,4 +271,13 @@ export class ChangeCommand {
     
     return { total, completed };
   }
+
+  private printNextSteps(): void {
+    const bullets: string[] = [];
+    bullets.push('- Ensure change has deltas in specs/: use headers ## ADDED/MODIFIED/REMOVED/RENAMED Requirements');
+    bullets.push('- Each requirement MUST include at least one #### Scenario: block');
+    bullets.push('- Debug parsed deltas: openspec change show <id> --json --deltas-only');
+    console.error('Next steps:');
+    bullets.forEach(b => console.error(`  ${b}`));
+  }
 }

src/commands/show.ts

@@ -0,0 +1,139 @@
+import { select } from '@inquirer/prompts';
+import path from 'path';
+import { isInteractive } from '../utils/interactive.js';
+import { getActiveChangeIds, getSpecIds } from '../utils/item-discovery.js';
+import { ChangeCommand } from './change.js';
+import { SpecCommand } from './spec.js';
+import { nearestMatches } from '../utils/match.js';
+
+type ItemType = 'change' | 'spec';
+
+const CHANGE_FLAG_KEYS = new Set(['deltasOnly', 'requirementsOnly']);
+const SPEC_FLAG_KEYS = new Set(['requirements', 'scenarios', 'requirement']);
+
+export class ShowCommand {
+  async execute(itemName?: string, options: { json?: boolean; type?: string; noInteractive?: boolean; [k: string]: any } = {}): Promise<void> {
+    const interactive = isInteractive(options.noInteractive);
+    const typeOverride = this.normalizeType(options.type);
+
+    if (!itemName) {
+      if (interactive) {
+        const type = await select<ItemType>({
+          message: 'What would you like to show?',
+          choices: [
+            { name: 'Change', value: 'change' as const },
+            { name: 'Spec', value: 'spec' as const },
+          ],
+        });
+        await this.runInteractiveByType(type, options);
+        return;
+      }
+      this.printNonInteractiveHint();
+      process.exitCode = 1;
+      return;
+    }
+
+    await this.showDirect(itemName, { typeOverride, options });
+  }
+
+  private normalizeType(value?: string): ItemType | undefined {
+    if (!value) return undefined;
+    const v = value.toLowerCase();
+    if (v === 'change' || v === 'spec') return v;
+    return undefined;
+  }
+
+  private async runInteractiveByType(type: ItemType, options: { json?: boolean; noInteractive?: boolean; [k: string]: any }): Promise<void> {
+    if (type === 'change') {
+      const changes = await getActiveChangeIds();
+      if (changes.length === 0) {
+        console.error('No changes found.');
+        process.exitCode = 1;
+        return;
+      }
+      const picked = await select<string>({ message: 'Pick a change', choices: changes.map(id => ({ name: id, value: id })) });
+      const cmd = new ChangeCommand();
+      await cmd.show(picked, options as any);
+      return;
+    }
+
+    const specs = await getSpecIds();
+    if (specs.length === 0) {
+      console.error('No specs found.');
+      process.exitCode = 1;
+      return;
+    }
+    const picked = await select<string>({ message: 'Pick a spec', choices: specs.map(id => ({ name: id, value: id })) });
+    const cmd = new SpecCommand();
+    await cmd.show(picked, options as any);
+  }
+
+  private async showDirect(itemName: string, params: { typeOverride?: ItemType; options: { json?: boolean; [k: string]: any } }): Promise<void> {
+    // Optimize lookups when type is pre-specified
+    let isChange = false;
+    let isSpec = false;
+    let changes: string[] = [];
+    let specs: string[] = [];
+    if (params.typeOverride === 'change') {
+      changes = await getActiveChangeIds();
+      isChange = changes.includes(itemName);
+    } else if (params.typeOverride === 'spec') {
+      specs = await getSpecIds();
+      isSpec = specs.includes(itemName);
+    } else {
+      [changes, specs] = await Promise.all([getActiveChangeIds(), getSpecIds()]);
+      isChange = changes.includes(itemName);
+      isSpec = specs.includes(itemName);
+    }
+
+    const resolvedType = params.typeOverride ?? (isChange ? 'change' : isSpec ? 'spec' : undefined);
+
+    if (!resolvedType) {
+      console.error(`Unknown item '${itemName}'`);
+      const suggestions = nearestMatches(itemName, [...changes, ...specs]);
+      if (suggestions.length) console.error(`Did you mean: ${suggestions.join(', ')}?`);
+      process.exitCode = 1;
+      return;
+    }
+
+    if (!params.typeOverride && isChange && isSpec) {
+      console.error(`Ambiguous item '${itemName}' matches both a change and a spec.`);
+      console.error('Pass --type change|spec, or use: openspec change show / openspec spec show');
+      process.exitCode = 1;
+      return;
+    }
+
+    this.warnIrrelevantFlags(resolvedType, params.options);
+    if (resolvedType === 'change') {
+      const cmd = new ChangeCommand();
+      await cmd.show(itemName, params.options as any);
+      return;
+    }
+    const cmd = new SpecCommand();
+    await cmd.show(itemName, params.options as any);
+  }
+
+  private printNonInteractiveHint(): void {
+    console.error('Nothing to show. Try one of:');
+    console.error('  openspec show <item>');
+    console.error('  openspec change show');
+    console.error('  openspec spec show');
+    console.error('Or run in an interactive terminal.');
+  }
+
+  private warnIrrelevantFlags(type: ItemType, options: { [k: string]: any }): boolean {
+    const irrelevant: string[] = [];
+    if (type === 'change') {
+      for (const k of SPEC_FLAG_KEYS) if (k in options) irrelevant.push(k);
+    } else {
+      for (const k of CHANGE_FLAG_KEYS) if (k in options) irrelevant.push(k);
+    }
+    if (irrelevant.length > 0) {
+      console.error(`Warning: Ignoring flags not applicable to ${type}: ${irrelevant.join(', ')}`);
+      return true;
+    }
+    return false;
+  }
+}
+
+

src/commands/spec.ts

@@ -4,102 +4,132 @@ import { join } from 'path';
 import { MarkdownParser } from '../core/parsers/markdown-parser.js';
 import { Validator } from '../core/validation/validator.js';
 import type { Spec } from '../core/schemas/index.js';
+import { select } from '@inquirer/prompts';
+import { isInteractive } from '../utils/interactive.js';
+import { getSpecIds } from '../utils/item-discovery.js';
 
 const SPECS_DIR = 'openspec/specs';
 
+interface ShowOptions {
+  json?: boolean;
+  // JSON-only filters (raw-first text has no filters)
+  requirements?: boolean;
+  scenarios?: boolean; // --no-scenarios sets this to false (JSON only)
+  requirement?: string; // JSON only
+  noInteractive?: boolean;
+}
+
+function parseSpecFromFile(specPath: string, specId: string): Spec {
+  const content = readFileSync(specPath, 'utf-8');
+  const parser = new MarkdownParser(content);
+  return parser.parseSpec(specId);
+}
+
+function validateRequirementIndex(spec: Spec, requirementOpt?: string): number | undefined {
+  if (!requirementOpt) return undefined;
+  const index = Number.parseInt(requirementOpt, 10);
+  if (!Number.isInteger(index) || index < 1 || index > spec.requirements.length) {
+    throw new Error(`Requirement ${requirementOpt} not found`);
+  }
+  return index - 1; // convert to 0-based
+}
+
+function filterSpec(spec: Spec, options: ShowOptions): Spec {
+  const requirementIndex = validateRequirementIndex(spec, options.requirement);
+  const includeScenarios = options.scenarios !== false && !options.requirements;
+
+  const filteredRequirements = (requirementIndex !== undefined
+    ? [spec.requirements[requirementIndex]]
+    : spec.requirements
+  ).map(req => ({
+    text: req.text,
+    scenarios: includeScenarios ? req.scenarios : [],
+  }));
+
+  const metadata = spec.metadata ?? { version: '1.0.0', format: 'openspec' as const };
+
+  return {
+    name: spec.name,
+    overview: spec.overview,
+    requirements: filteredRequirements,
+    metadata,
+  };
+}
+
+/**
+ * Print the raw markdown content for a spec file without any formatting.
+ * Raw-first behavior ensures text mode is a passthrough for deterministic output.
+ */
+function printSpecTextRaw(specPath: string): void {
+  const content = readFileSync(specPath, 'utf-8');
+  console.log(content);
+}
+
+export class SpecCommand {
+  private SPECS_DIR = 'openspec/specs';
+
+  async show(specId?: string, options: ShowOptions = {}): Promise<void> {
+    if (!specId) {
+      const canPrompt = isInteractive(options?.noInteractive);
+      const specIds = await getSpecIds();
+      if (canPrompt && specIds.length > 0) {
+        specId = await select({
+          message: 'Select a spec to show',
+          choices: specIds.map(id => ({ name: id, value: id })),
+        });
+      } else {
+        throw new Error('Missing required argument <spec-id>');
+      }
+    }
+
+    const specPath = join(this.SPECS_DIR, specId, 'spec.md');
+    if (!existsSync(specPath)) {
+      throw new Error(`Spec '${specId}' not found at openspec/specs/${specId}/spec.md`);
+    }
+
+    if (options.json) {
+      if (options.requirements && options.requirement) {
+        throw new Error('Options --requirements and --requirement cannot be used together');
+      }
+      const parsed = parseSpecFromFile(specPath, specId);
+      const filtered = filterSpec(parsed, options);
+      const output = {
+        id: specId,
+        title: parsed.name,
+        overview: parsed.overview,
+        requirementCount: filtered.requirements.length,
+        requirements: filtered.requirements,
+        metadata: parsed.metadata ?? { version: '1.0.0', format: 'openspec' as const },
+      };
+      console.log(JSON.stringify(output, null, 2));
+      return;
+    }
+    printSpecTextRaw(specPath);
+  }
+}
+
 export function registerSpecCommand(rootProgram: typeof program) {
   const specCommand = rootProgram
     .command('spec')
     .description('Manage and view OpenSpec specifications');
 
-  interface ShowOptions {
-    json?: boolean;
-    // JSON-only filters (raw-first text has no filters)
-    requirements?: boolean;
-    scenarios?: boolean; // --no-scenarios sets this to false (JSON only)
-    requirement?: string; // JSON only
-  }
-
-  function parseSpecFromFile(specPath: string, specId: string): Spec {
-    const content = readFileSync(specPath, 'utf-8');
-    const parser = new MarkdownParser(content);
-    return parser.parseSpec(specId);
-  }
-
-  function validateRequirementIndex(spec: Spec, requirementOpt?: string): number | undefined {
-    if (!requirementOpt) return undefined;
-    const index = Number.parseInt(requirementOpt, 10);
-    if (!Number.isInteger(index) || index < 1 || index > spec.requirements.length) {
-      throw new Error(`Requirement ${requirementOpt} not found`);
-    }
-    return index - 1; // convert to 0-based
-  }
-
-  function filterSpec(spec: Spec, options: ShowOptions): Spec {
-    const requirementIndex = validateRequirementIndex(spec, options.requirement);
-    const includeScenarios = options.scenarios !== false && !options.requirements;
-
-    const filteredRequirements = (requirementIndex !== undefined
-      ? [spec.requirements[requirementIndex]]
-      : spec.requirements
-    ).map(req => ({
-      text: req.text,
-      scenarios: includeScenarios ? req.scenarios : [],
-    }));
-
-    const metadata = spec.metadata ?? { version: '1.0.0', format: 'openspec' as const };
-
-    return {
-      name: spec.name,
-      overview: spec.overview,
-      requirements: filteredRequirements,
-      metadata,
-    };
-  }
-
-  /**
-   * Print the raw markdown content for a spec file without any formatting.
-   * Raw-first behavior ensures text mode is a passthrough for deterministic output.
-   */
-  function printSpecTextRaw(specPath: string): void {
-    const content = readFileSync(specPath, 'utf-8');
-    console.log(content);
-  }
+  // Deprecation notice for noun-based commands
+  specCommand.hook('preAction', () => {
+    console.error('Warning: The "openspec spec ..." commands are deprecated. Prefer verb-first commands (e.g., "openspec show", "openspec validate --specs").');
+  });
 
   specCommand
-    .command('show <spec-id>')
+    .command('show [spec-id]')
     .description('Display a specific specification')
     .option('--json', 'Output as JSON')
     .option('--requirements', 'JSON only: Show only requirements (exclude scenarios)')
     .option('--no-scenarios', 'JSON only: Exclude scenario content')
     .option('-r, --requirement <id>', 'JSON only: Show specific requirement by ID (1-based)')
-    .action((specId: string, options: ShowOptions) => {
+    .option('--no-interactive', 'Disable interactive prompts')
+    .action(async (specId: string | undefined, options: ShowOptions & { noInteractive?: boolean }) => {
       try {
-        const specPath = join(SPECS_DIR, specId, 'spec.md');
-        
-        if (!existsSync(specPath)) {
-          throw new Error(`Spec '${specId}' not found at openspec/specs/${specId}/spec.md`);
-        }
-
-        if (options.json) {
-          if (options.requirements && options.requirement) {
-            throw new Error('Options --requirements and --requirement cannot be used together');
-          }
-          const parsed = parseSpecFromFile(specPath, specId);
-          const filtered = filterSpec(parsed, options);
-          const output = {
-            id: specId,
-            title: parsed.name,
-            overview: parsed.overview,
-            requirementCount: filtered.requirements.length,
-            requirements: filtered.requirements,
-            metadata: parsed.metadata ?? { version: '1.0.0', format: 'openspec' as const },
-          };
-          console.log(JSON.stringify(output, null, 2));
-        } else {
-          // raw-first text: print raw file
-          printSpecTextRaw(specPath);
-        }
+        const cmd = new SpecCommand();
+        await cmd.show(specId, options as any);
       } catch (error) {
         console.error(`Error: ${error instanceof Error ? error.message : 'Unknown error'}`);
         process.exitCode = 1;
@@ -166,12 +196,26 @@ export function registerSpecCommand(rootProgram: typeof program) {
     });
 
   specCommand
-    .command('validate <spec-id>')
+    .command('validate [spec-id]')
     .description('Validate a specification structure')
     .option('--strict', 'Enable strict validation mode')
     .option('--json', 'Output validation report as JSON')
-    .action(async (specId: string, options: { strict?: boolean; json?: boolean }) => {
+    .option('--no-interactive', 'Disable interactive prompts')
+    .action(async (specId: string | undefined, options: { strict?: boolean; json?: boolean; noInteractive?: boolean }) => {
       try {
+        if (!specId) {
+          const canPrompt = isInteractive(options?.noInteractive);
+          const specIds = await getSpecIds();
+          if (canPrompt && specIds.length > 0) {
+            specId = await select({
+              message: 'Select a spec to validate',
+              choices: specIds.map(id => ({ name: id, value: id })),
+            });
+          } else {
+            throw new Error('Missing required argument <spec-id>');
+          }
+        }
+
         const specPath = join(SPECS_DIR, specId, 'spec.md');
         
         if (!existsSync(specPath)) {

src/commands/validate.ts

@@ -0,0 +1,305 @@
+import { select } from '@inquirer/prompts';
+import ora from 'ora';
+import path from 'path';
+import { Validator } from '../core/validation/validator.js';
+import { isInteractive } from '../utils/interactive.js';
+import { getActiveChangeIds, getSpecIds } from '../utils/item-discovery.js';
+import { nearestMatches } from '../utils/match.js';
+
+type ItemType = 'change' | 'spec';
+
+interface ExecuteOptions {
+  all?: boolean;
+  changes?: boolean;
+  specs?: boolean;
+  type?: string;
+  strict?: boolean;
+  json?: boolean;
+  noInteractive?: boolean;
+  concurrency?: string;
+}
+
+interface BulkItemResult {
+  id: string;
+  type: ItemType;
+  valid: boolean;
+  issues: { level: 'ERROR' | 'WARNING' | 'INFO'; path: string; message: string }[];
+  durationMs: number;
+}
+
+export class ValidateCommand {
+  async execute(itemName: string | undefined, options: ExecuteOptions = {}): Promise<void> {
+    const interactive = isInteractive(options.noInteractive);
+
+    // Handle bulk flags first
+    if (options.all || options.changes || options.specs) {
+      await this.runBulkValidation({
+        changes: !!options.all || !!options.changes,
+        specs: !!options.all || !!options.specs,
+      }, { strict: !!options.strict, json: !!options.json, concurrency: options.concurrency });
+      return;
+    }
+
+    // No item and no flags
+    if (!itemName) {
+      if (interactive) {
+        await this.runInteractiveSelector({ strict: !!options.strict, json: !!options.json, concurrency: options.concurrency });
+        return;
+      }
+      this.printNonInteractiveHint();
+      process.exitCode = 1;
+      return;
+    }
+
+    // Direct item validation with type detection or override
+    const typeOverride = this.normalizeType(options.type);
+    await this.validateDirectItem(itemName, { typeOverride, strict: !!options.strict, json: !!options.json });
+  }
+
+  private normalizeType(value?: string): ItemType | undefined {
+    if (!value) return undefined;
+    const v = value.toLowerCase();
+    if (v === 'change' || v === 'spec') return v;
+    return undefined;
+  }
+
+  private async runInteractiveSelector(opts: { strict: boolean; json: boolean; concurrency?: string }): Promise<void> {
+    const choice = await select({
+      message: 'What would you like to validate?',
+      choices: [
+        { name: 'All (changes + specs)', value: 'all' },
+        { name: 'All changes', value: 'changes' },
+        { name: 'All specs', value: 'specs' },
+        { name: 'Pick a specific change or spec', value: 'one' },
+      ],
+    });
+
+    if (choice === 'all') return this.runBulkValidation({ changes: true, specs: true }, opts);
+    if (choice === 'changes') return this.runBulkValidation({ changes: true, specs: false }, opts);
+    if (choice === 'specs') return this.runBulkValidation({ changes: false, specs: true }, opts);
+
+    // one
+    const [changes, specs] = await Promise.all([getActiveChangeIds(), getSpecIds()]);
+    const items: { name: string; value: { type: ItemType; id: string } }[] = [];
+    items.push(...changes.map(id => ({ name: `change/${id}`, value: { type: 'change' as const, id } })));
+    items.push(...specs.map(id => ({ name: `spec/${id}`, value: { type: 'spec' as const, id } })));
+    if (items.length === 0) {
+      console.error('No items found to validate.');
+      process.exitCode = 1;
+      return;
+    }
+    const picked = await select<{ type: ItemType; id: string }>({ message: 'Pick an item', choices: items });
+    await this.validateByType(picked.type, picked.id, opts);
+  }
+
+  private printNonInteractiveHint(): void {
+    console.error('Nothing to validate. Try one of:');
+    console.error('  openspec validate --all');
+    console.error('  openspec validate --changes');
+    console.error('  openspec validate --specs');
+    console.error('  openspec validate <item-name>');
+    console.error('Or run in an interactive terminal.');
+  }
+
+  private async validateDirectItem(itemName: string, opts: { typeOverride?: ItemType; strict: boolean; json: boolean }): Promise<void> {
+    const [changes, specs] = await Promise.all([getActiveChangeIds(), getSpecIds()]);
+    const isChange = changes.includes(itemName);
+    const isSpec = specs.includes(itemName);
+
+    const type = opts.typeOverride ?? (isChange ? 'change' : isSpec ? 'spec' : undefined);
+
+    if (!type) {
+      console.error(`Unknown item '${itemName}'`);
+      const suggestions = nearestMatches(itemName, [...changes, ...specs]);
+      if (suggestions.length) console.error(`Did you mean: ${suggestions.join(', ')}?`);
+      process.exitCode = 1;
+      return;
+    }
+
+    if (!opts.typeOverride && isChange && isSpec) {
+      console.error(`Ambiguous item '${itemName}' matches both a change and a spec.`);
+      console.error('Pass --type change|spec, or use: openspec change validate / openspec spec validate');
+      process.exitCode = 1;
+      return;
+    }
+
+    await this.validateByType(type, itemName, opts);
+  }
+
+  private async validateByType(type: ItemType, id: string, opts: { strict: boolean; json: boolean }): Promise<void> {
+    const validator = new Validator(opts.strict);
+    if (type === 'change') {
+      const changeDir = path.join(process.cwd(), 'openspec', 'changes', id);
+      const start = Date.now();
+      const report = await validator.validateChangeDeltaSpecs(changeDir);
+      const durationMs = Date.now() - start;
+      this.printReport('change', id, report, durationMs, opts.json);
+      // Non-zero exit if invalid (keeps enriched output test semantics)
+      process.exitCode = report.valid ? 0 : 1;
+      return;
+    }
+    const file = path.join(process.cwd(), 'openspec', 'specs', id, 'spec.md');
+    const start = Date.now();
+    const report = await validator.validateSpec(file);
+    const durationMs = Date.now() - start;
+    this.printReport('spec', id, report, durationMs, opts.json);
+    process.exitCode = report.valid ? 0 : 1;
+  }
+
+  private printReport(type: ItemType, id: string, report: { valid: boolean; issues: any[] }, durationMs: number, json: boolean): void {
+    if (json) {
+      const out = { items: [{ id, type, valid: report.valid, issues: report.issues, durationMs }], summary: { totals: { items: 1, passed: report.valid ? 1 : 0, failed: report.valid ? 0 : 1 }, byType: { [type]: { items: 1, passed: report.valid ? 1 : 0, failed: report.valid ? 0 : 1 } } }, version: '1.0' };
+      console.log(JSON.stringify(out, null, 2));
+      return;
+    }
+    if (report.valid) {
+      console.log(`${type === 'change' ? 'Change' : 'Specification'} '${id}' is valid`);
+    } else {
+      console.error(`${type === 'change' ? 'Change' : 'Specification'} '${id}' has issues`);
+      for (const issue of report.issues) {
+        const label = issue.level === 'ERROR' ? 'ERROR' : issue.level;
+        const prefix = issue.level === 'ERROR' ? '✗' : issue.level === 'WARNING' ? '⚠' : 'ℹ';
+        console.error(`${prefix} [${label}] ${issue.path}: ${issue.message}`);
+      }
+      this.printNextSteps(type);
+    }
+  }
+
+  private printNextSteps(type: ItemType): void {
+    const bullets: string[] = [];
+    if (type === 'change') {
+      bullets.push('- Ensure change has deltas in specs/: use headers ## ADDED/MODIFIED/REMOVED/RENAMED Requirements');
+      bullets.push('- Each requirement MUST include at least one #### Scenario: block');
+      bullets.push('- Debug parsed deltas: openspec change show <id> --json --deltas-only');
+    } else {
+      bullets.push('- Ensure spec includes ## Purpose and ## Requirements sections');
+      bullets.push('- Each requirement MUST include at least one #### Scenario: block');
+      bullets.push('- Re-run with --json to see structured report');
+    }
+    console.error('Next steps:');
+    bullets.forEach(b => console.error(`  ${b}`));
+  }
+
+  private async runBulkValidation(scope: { changes: boolean; specs: boolean }, opts: { strict: boolean; json: boolean; concurrency?: string }): Promise<void> {
+    const spinner = !opts.json ? ora('Validating...').start() : undefined;
+    const [changeIds, specIds] = await Promise.all([
+      scope.changes ? getActiveChangeIds() : Promise.resolve<string[]>([]),
+      scope.specs ? getSpecIds() : Promise.resolve<string[]>([]),
+    ]);
+
+    const DEFAULT_CONCURRENCY = 6;
+    const maxSuggestions = 5; // used by nearestMatches
+    const concurrency = normalizeConcurrency(opts.concurrency) ?? normalizeConcurrency(process.env.OPENSPEC_CONCURRENCY) ?? DEFAULT_CONCURRENCY;
+    const validator = new Validator(opts.strict);
+    const queue: Array<() => Promise<BulkItemResult>> = [];
+
+    for (const id of changeIds) {
+      queue.push(async () => {
+        const start = Date.now();
+        const changeDir = path.join(process.cwd(), 'openspec', 'changes', id);
+        const report = await validator.validateChangeDeltaSpecs(changeDir);
+        const durationMs = Date.now() - start;
+        return { id, type: 'change' as const, valid: report.valid, issues: report.issues, durationMs };
+      });
+    }
+    for (const id of specIds) {
+      queue.push(async () => {
+        const start = Date.now();
+        const file = path.join(process.cwd(), 'openspec', 'specs', id, 'spec.md');
+        const report = await validator.validateSpec(file);
+        const durationMs = Date.now() - start;
+        return { id, type: 'spec' as const, valid: report.valid, issues: report.issues, durationMs };
+      });
+    }
+
+    const results: BulkItemResult[] = [];
+    let index = 0;
+    let running = 0;
+    let passed = 0;
+    let failed = 0;
+
+    await new Promise<void>((resolve) => {
+      const next = () => {
+        while (running < concurrency && index < queue.length) {
+          const currentIndex = index++;
+          const task = queue[currentIndex];
+          running++;
+          if (spinner) spinner.text = `Validating (${currentIndex + 1}/${queue.length})...`;
+          task()
+            .then(res => {
+              results.push(res);
+              if (res.valid) passed++; else failed++;
+            })
+            .catch((error: any) => {
+              const message = error?.message || 'Unknown error';
+              const res: BulkItemResult = { id: getPlannedId(currentIndex, changeIds, specIds) ?? 'unknown', type: getPlannedType(currentIndex, changeIds, specIds) ?? 'change', valid: false, issues: [{ level: 'ERROR', path: 'file', message }], durationMs: 0 };
+              results.push(res);
+              failed++;
+            })
+            .finally(() => {
+              running--;
+              if (index >= queue.length && running === 0) resolve();
+              else next();
+            });
+        }
+      };
+      next();
+    });
+
+    spinner?.stop();
+
+    results.sort((a, b) => a.id.localeCompare(b.id));
+    const summary = {
+      totals: { items: results.length, passed, failed },
+      byType: {
+        ...(scope.changes ? { change: summarizeType(results, 'change') } : {}),
+        ...(scope.specs ? { spec: summarizeType(results, 'spec') } : {}),
+      },
+    } as const;
+
+    if (opts.json) {
+      const out = { items: results, summary, version: '1.0' };
+      console.log(JSON.stringify(out, null, 2));
+    } else {
+      for (const res of results) {
+        if (res.valid) console.log(`✓ ${res.type}/${res.id}`);
+        else console.error(`✗ ${res.type}/${res.id}`);
+      }
+      console.log(`Totals: ${summary.totals.passed} passed, ${summary.totals.failed} failed (${summary.totals.items} items)`);
+    }
+
+    process.exitCode = failed > 0 ? 1 : 0;
+  }
+}
+
+function summarizeType(results: BulkItemResult[], type: ItemType) {
+  const filtered = results.filter(r => r.type === type);
+  const items = filtered.length;
+  const passed = filtered.filter(r => r.valid).length;
+  const failed = items - passed;
+  return { items, passed, failed };
+}
+
+function normalizeConcurrency(value?: string): number | undefined {
+  if (!value) return undefined;
+  const n = parseInt(value, 10);
+  if (Number.isNaN(n) || n <= 0) return undefined;
+  return n;
+}
+
+function getPlannedId(index: number, changeIds: string[], specIds: string[]): string | undefined {
+  const totalChanges = changeIds.length;
+  if (index < totalChanges) return changeIds[index];
+  const specIndex = index - totalChanges;
+  return specIds[specIndex];
+}
+
+function getPlannedType(index: number, changeIds: string[], specIds: string[]): ItemType | undefined {
+  const totalChanges = changeIds.length;
+  if (index < totalChanges) return 'change';
+  const specIndex = index - totalChanges;
+  if (specIndex >= 0 && specIndex < specIds.length) return 'spec';
+  return undefined;
+}
+
+

src/core/archive.ts

@@ -2,6 +2,7 @@ import { promises as fs } from 'fs';
 import path from 'path';
 import { select, confirm } from '@inquirer/prompts';
 import { FileSystemUtils } from '../utils/file-system.js';
+import { getTaskProgressForChange, formatTaskStatus } from '../utils/task-progress.js';
 import { Validator } from './validation/validator.js';
 import chalk from 'chalk';
 import {
@@ -58,16 +59,48 @@ export class ArchiveCommand {
       const validator = new Validator();
       let hasValidationErrors = false;
 
-      // Validate change.md file
-      const changeFile = path.join(changeDir, 'change.md');
+      // Validate proposal.md (non-blocking unless strict mode desired in future)
+      const changeFile = path.join(changeDir, 'proposal.md');
       try {
         await fs.access(changeFile);
         const changeReport = await validator.validateChange(changeFile);
-        
+        // Proposal validation is informative only (do not block archive)
         if (!changeReport.valid) {
-          hasValidationErrors = true;
-          console.log(chalk.red(`\nValidation errors in change.md:`));
+          console.log(chalk.yellow(`\nProposal warnings in proposal.md (non-blocking):`));
           for (const issue of changeReport.issues) {
+            const symbol = issue.level === 'ERROR' ? '⚠' : (issue.level === 'WARNING' ? '⚠' : 'ℹ');
+            console.log(chalk.yellow(`  ${symbol} ${issue.message}`));
+          }
+        }
+      } catch {
+        // Change file doesn't exist, skip validation
+      }
+
+      // Validate delta-formatted spec files under the change directory if present
+      const changeSpecsDir = path.join(changeDir, 'specs');
+      let hasDeltaSpecs = false;
+      try {
+        const candidates = await fs.readdir(changeSpecsDir, { withFileTypes: true });
+        for (const c of candidates) {
+          if (c.isDirectory()) {
+            try {
+              const candidatePath = path.join(changeSpecsDir, c.name, 'spec.md');
+              await fs.access(candidatePath);
+              const content = await fs.readFile(candidatePath, 'utf-8');
+              if (/^##\s+(ADDED|MODIFIED|REMOVED|RENAMED)\s+Requirements/m.test(content)) {
+                hasDeltaSpecs = true;
+                break;
+              }
+            } catch {}
+          }
+        }
+      } catch {}
+      if (hasDeltaSpecs) {
+        const deltaReport = await validator.validateChangeDeltaSpecs(changeDir);
+        if (!deltaReport.valid) {
+          hasValidationErrors = true;
+          console.log(chalk.red(`\nValidation errors in change delta specs:`));
+          for (const issue of deltaReport.issues) {
             if (issue.level === 'ERROR') {
               console.log(chalk.red(`  ✗ ${issue.message}`));
             } else if (issue.level === 'WARNING') {
@@ -75,41 +108,6 @@ export class ArchiveCommand {
             }
           }
         }
-      } catch {
-        // Change file doesn't exist, skip validation
-      }
-
-      // Validate spec files
-      const changeSpecsDir = path.join(changeDir, 'specs');
-      try {
-        const entries = await fs.readdir(changeSpecsDir, { withFileTypes: true });
-        
-        for (const entry of entries) {
-          if (entry.isDirectory()) {
-            const specFile = path.join(changeSpecsDir, entry.name, 'spec.md');
-            
-            try {
-              await fs.access(specFile);
-              const report = await validator.validateSpec(specFile);
-              
-              if (!report.valid) {
-                hasValidationErrors = true;
-                console.log(chalk.red(`\nValidation errors in ${entry.name}/spec.md:`));
-                for (const issue of report.issues) {
-                  if (issue.level === 'ERROR') {
-                    console.log(chalk.red(`  ✗ ${issue.message}`));
-                  } else if (issue.level === 'WARNING') {
-                    console.log(chalk.yellow(`  ⚠ ${issue.message}`));
-                  }
-                }
-              }
-            } catch {
-              // Spec file doesn't exist, skip validation
-            }
-          }
-        }
-      } catch {
-        // No specs directory, skip validation
       }
 
       if (hasValidationErrors) {
@@ -138,10 +136,12 @@ export class ArchiveCommand {
       console.log(chalk.yellow(`Affected files: ${changeDir}`));
     }
 
-    // Check for incomplete tasks
-    const tasksPath = path.join(changeDir, 'tasks.md');
-    const incompleteTasks = await this.checkIncompleteTasks(tasksPath);
-    
+    // Show progress and check for incomplete tasks
+    const progress = await getTaskProgressForChange(changesDir, changeName);
+    const status = formatTaskStatus(progress);
+    console.log(`Task status: ${status}`);
+
+    const incompleteTasks = Math.max(progress.total - progress.completed, 0);
     if (incompleteTasks > 0) {
       if (!options.yes) {
         const proceed = await confirm({
@@ -197,9 +197,22 @@ export class ArchiveCommand {
             return;
           }
 
-          // All validations passed; write files and display counts
+          // All validations passed; pre-validate rebuilt full spec and then write files and display counts
           let totals = { added: 0, modified: 0, removed: 0, renamed: 0 };
           for (const p of prepared) {
+            const specName = path.basename(path.dirname(p.update.target));
+            if (!options.noValidate) {
+              const report = await new Validator().validateSpecContent(specName, p.rebuilt);
+              if (!report.valid) {
+                console.log(chalk.red(`\nValidation errors in rebuilt spec for ${specName} (will not write changes):`));
+                for (const issue of report.issues) {
+                  if (issue.level === 'ERROR') console.log(chalk.red(`  ✗ ${issue.message}`));
+                  else if (issue.level === 'WARNING') console.log(chalk.yellow(`  ⚠ ${issue.message}`));
+                }
+                console.log('Aborted. No files were changed.');
+                return;
+              }
+            }
             await this.writeUpdatedSpec(p.update, p.rebuilt, p.counts);
             totals.added += p.counts.added;
             totals.modified += p.counts.modified;
@@ -250,11 +263,24 @@ export class ArchiveCommand {
       return null;
     }
 
-    console.log('Available changes:');
-    const choices = changeDirs.map(name => ({
-      name: name,
-      value: name
-    }));
+    // Build choices with progress inline to avoid duplicate lists
+    let choices: Array<{ name: string; value: string }> = changeDirs.map(name => ({ name, value: name }));
+    try {
+      const progressList: Array<{ id: string; status: string }> = [];
+      for (const id of changeDirs) {
+        const progress = await getTaskProgressForChange(changesDir, id);
+        const status = formatTaskStatus(progress);
+        progressList.push({ id, status });
+      }
+      const nameWidth = Math.max(...progressList.map(p => p.id.length));
+      choices = progressList.map(p => ({
+        name: `${p.id.padEnd(nameWidth)}     ${p.status}`,
+        value: p.id
+      }));
+    } catch {
+      // If anything fails, fall back to simple names
+      choices = changeDirs.map(name => ({ name, value: name }));
+    }
 
     try {
       const answer = await select({
@@ -268,23 +294,9 @@ export class ArchiveCommand {
     }
   }
 
-  private async checkIncompleteTasks(tasksPath: string): Promise<number> {
-    try {
-      const content = await fs.readFile(tasksPath, 'utf-8');
-      const lines = content.split('\n');
-      let incompleteTasks = 0;
-      
-      for (const line of lines) {
-        if (line.includes('- [ ]')) {
-          incompleteTasks++;
-        }
-      }
-      
-      return incompleteTasks;
-    } catch {
-      // No tasks.md file or error reading it
-      return 0;
-    }
+  // Deprecated: replaced by shared task-progress utilities
+  private async checkIncompleteTasks(_tasksPath: string): Promise<number> {
+    return 0;
   }
 
   private async findSpecUpdates(changeDir: string, mainSpecsDir: string): Promise<SpecUpdate[]> {

src/core/list.ts

@@ -1,5 +1,9 @@
 import { promises as fs } from 'fs';
 import path from 'path';
+import { getTaskProgressForChange, formatTaskStatus } from '../utils/task-progress.js';
+import { readFileSync } from 'fs';
+import { join } from 'path';
+import { MarkdownParser } from './parsers/markdown-parser.js';
 
 interface ChangeInfo {
   name: string;
@@ -8,83 +12,93 @@ interface ChangeInfo {
 }
 
 export class ListCommand {
-  async execute(targetPath: string = '.'): Promise<void> {
-    const changesDir = path.join(targetPath, 'openspec', 'changes');
-    
-    // Check if changes directory exists
-    try {
-      await fs.access(changesDir);
-    } catch {
-      throw new Error("No OpenSpec changes directory found. Run 'openspec init' first.");
-    }
+  async execute(targetPath: string = '.', mode: 'changes' | 'specs' = 'changes'): Promise<void> {
+    if (mode === 'changes') {
+      const changesDir = path.join(targetPath, 'openspec', 'changes');
+      
+      // Check if changes directory exists
+      try {
+        await fs.access(changesDir);
+      } catch {
+        throw new Error("No OpenSpec changes directory found. Run 'openspec init' first.");
+      }
 
-    // Get all directories in changes (excluding archive)
-    const entries = await fs.readdir(changesDir, { withFileTypes: true });
-    const changeDirs = entries
-      .filter(entry => entry.isDirectory() && entry.name !== 'archive')
-      .map(entry => entry.name);
+      // Get all directories in changes (excluding archive)
+      const entries = await fs.readdir(changesDir, { withFileTypes: true });
+      const changeDirs = entries
+        .filter(entry => entry.isDirectory() && entry.name !== 'archive')
+        .map(entry => entry.name);
 
-    if (changeDirs.length === 0) {
-      console.log('No active changes found.');
+      if (changeDirs.length === 0) {
+        console.log('No active changes found.');
+        return;
+      }
+
+      // Collect information about each change
+      const changes: ChangeInfo[] = [];
+      
+      for (const changeDir of changeDirs) {
+        const progress = await getTaskProgressForChange(changesDir, changeDir);
+        changes.push({
+          name: changeDir,
+          completedTasks: progress.completed,
+          totalTasks: progress.total
+        });
+      }
+
+      // Sort alphabetically by name
+      changes.sort((a, b) => a.name.localeCompare(b.name));
+
+      // Display results
+      console.log('Changes:');
+      const padding = '  ';
+      const nameWidth = Math.max(...changes.map(c => c.name.length));
+      for (const change of changes) {
+        const paddedName = change.name.padEnd(nameWidth);
+        const status = formatTaskStatus({ total: change.totalTasks, completed: change.completedTasks });
+        console.log(`${padding}${paddedName}     ${status}`);
+      }
       return;
     }
 
-    // Collect information about each change
-    const changes: ChangeInfo[] = [];
-    
-    for (const changeDir of changeDirs) {
-      const tasksPath = path.join(changesDir, changeDir, 'tasks.md');
-      let completedTasks = 0;
-      let incompleteTasks = 0;
-      
-      try {
-        const content = await fs.readFile(tasksPath, 'utf-8');
-        const lines = content.split('\n');
-        
-        for (const line of lines) {
-          if (line.includes('- [x]')) {
-            completedTasks++;
-          } else if (line.includes('- [ ]')) {
-            incompleteTasks++;
-          }
-        }
-      } catch {
-        // No tasks.md file
-        changes.push({
-          name: changeDir,
-          completedTasks: 0,
-          totalTasks: 0
-        });
-        continue;
-      }
-      
-      changes.push({
-        name: changeDir,
-        completedTasks,
-        totalTasks: completedTasks + incompleteTasks
-      });
+    // specs mode
+    const specsDir = path.join(targetPath, 'openspec', 'specs');
+    try {
+      await fs.access(specsDir);
+    } catch {
+      console.log('No specs found.');
+      return;
     }
 
-    // Sort alphabetically by name
-    changes.sort((a, b) => a.name.localeCompare(b.name));
+    const entries = await fs.readdir(specsDir, { withFileTypes: true });
+    const specDirs = entries.filter(e => e.isDirectory()).map(e => e.name);
+    if (specDirs.length === 0) {
+      console.log('No specs found.');
+      return;
+    }
 
-    // Display results
-    console.log('Changes:');
-    for (const change of changes) {
-      const padding = '  ';
-      const nameWidth = Math.max(...changes.map(c => c.name.length));
-      const paddedName = change.name.padEnd(nameWidth);
-      
-      let status: string;
-      if (change.totalTasks === 0) {
-        status = 'No tasks';
-      } else if (change.completedTasks === change.totalTasks) {
-        status = '✓ Complete';
-      } else {
-        status = `${change.completedTasks}/${change.totalTasks} tasks`;
+    type SpecInfo = { id: string; requirementCount: number };
+    const specs: SpecInfo[] = [];
+    for (const id of specDirs) {
+      const specPath = join(specsDir, id, 'spec.md');
+      try {
+        const content = readFileSync(specPath, 'utf-8');
+        const parser = new MarkdownParser(content);
+        const spec = parser.parseSpec(id);
+        specs.push({ id, requirementCount: spec.requirements.length });
+      } catch {
+        // If spec cannot be read or parsed, include with 0 count
+        specs.push({ id, requirementCount: 0 });
       }
-      
-      console.log(`${padding}${paddedName}     ${status}`);
+    }
+
+    specs.sort((a, b) => a.id.localeCompare(b.id));
+    console.log('Specs:');
+    const padding = '  ';
+    const nameWidth = Math.max(...specs.map(s => s.id.length));
+    for (const spec of specs) {
+      const padded = spec.id.padEnd(nameWidth);
+      console.log(`${padding}${padded}     requirements ${spec.requirementCount}`);
     }
   }
 }

src/core/parsers/change-parser.ts

@@ -94,7 +94,9 @@ export class ChangeParser extends MarkdownParser {
           spec: specName,
           operation: 'ADDED' as DeltaOperation,
           description: `Add requirement: ${req.text}`,
+          // Provide both single and plural forms for compatibility
           requirement: req,
+          requirements: [req],
         });
       });
     }
@@ -109,6 +111,7 @@ export class ChangeParser extends MarkdownParser {
           operation: 'MODIFIED' as DeltaOperation,
           description: `Modify requirement: ${req.text}`,
           requirement: req,
+          requirements: [req],
         });
       });
     }
@@ -123,6 +126,7 @@ export class ChangeParser extends MarkdownParser {
           operation: 'REMOVED' as DeltaOperation,
           description: `Remove requirement: ${req.text}`,
           requirement: req,
+          requirements: [req],
         });
       });
     }

src/core/validation/constants.ts

@@ -35,4 +35,14 @@ export const VALIDATION_MESSAGES = {
   REQUIREMENT_TOO_LONG: `Requirement text is very long (>${MAX_REQUIREMENT_TEXT_LENGTH} characters). Consider breaking it down.`,
   DELTA_DESCRIPTION_TOO_BRIEF: 'Delta description is too brief',
   DELTA_MISSING_REQUIREMENTS: 'Delta should include requirements',
+  
+  // Guidance snippets (appended to primary messages for remediation)
+  GUIDE_NO_DELTAS:
+    'No deltas found. Ensure your change has a specs/ directory with .md files using delta headers (## ADDED/MODIFIED/REMOVED/RENAMED Requirements) and that each requirement includes at least one "#### Scenario:" block. Tip: run "openspec change show <change-id> --json --deltas-only" to inspect parsed deltas.',
+  GUIDE_MISSING_SPEC_SECTIONS:
+    'Missing required sections. Expected headers: "## Purpose" and "## Requirements". Example:\n## Purpose\n[brief purpose]\n\n## Requirements\n### Requirement: Clear requirement statement\nUsers SHALL ...\n\n#### Scenario: Descriptive name\n- **WHEN** ...\n- **THEN** ...',
+  GUIDE_MISSING_CHANGE_SECTIONS:
+    'Missing required sections. Expected headers: "## Why" and "## What Changes". Ensure deltas are documented in specs/ using delta headers.',
+  GUIDE_SCENARIO_FORMAT:
+    'Scenarios must use level-4 headers. Convert bullet lists into:\n#### Scenario: Short name\n- **WHEN** ...\n- **THEN** ...\n- **AND** ...',
 } as const;

src/core/validation/validator.ts

@@ -1,5 +1,5 @@
 import { z, ZodError } from 'zod';
-import { readFileSync } from 'fs';
+import { readFileSync, promises as fs } from 'fs';
 import path from 'path';
 import { SpecSchema, ChangeSchema, Spec, Change } from '../schemas/index.js';
 import { MarkdownParser } from '../parsers/markdown-parser.js';
@@ -10,6 +10,7 @@ import {
   MAX_REQUIREMENT_TEXT_LENGTH,
   VALIDATION_MESSAGES 
 } from './constants.js';
+import { parseDeltaSpec, normalizeRequirementName } from '../parsers/requirement-blocks.js';
 
 export class Validator {
   private strictMode: boolean;
@@ -20,11 +21,10 @@ export class Validator {
 
   async validateSpec(filePath: string): Promise<ValidationReport> {
     const issues: ValidationIssue[] = [];
-    
+    const specName = this.extractNameFromPath(filePath);
     try {
       const content = readFileSync(filePath, 'utf-8');
       const parser = new MarkdownParser(content);
-      const specName = this.extractNameFromPath(filePath);
       
       const spec = parser.parseSpec(specName);
       
@@ -37,22 +37,44 @@ export class Validator {
       issues.push(...this.applySpecRules(spec, content));
       
     } catch (error) {
+      const baseMessage = error instanceof Error ? error.message : 'Unknown error';
+      const enriched = this.enrichTopLevelError(specName, baseMessage);
       issues.push({
         level: 'ERROR',
         path: 'file',
-        message: error instanceof Error ? error.message : 'Unknown error',
+        message: enriched,
       });
     }
     
     return this.createReport(issues);
   }
 
+  /**
+   * Validate spec content from a string (used for pre-write validation of rebuilt specs)
+   */
+  async validateSpecContent(specName: string, content: string): Promise<ValidationReport> {
+    const issues: ValidationIssue[] = [];
+    try {
+      const parser = new MarkdownParser(content);
+      const spec = parser.parseSpec(specName);
+      const result = SpecSchema.safeParse(spec);
+      if (!result.success) {
+        issues.push(...this.convertZodErrors(result.error));
+      }
+      issues.push(...this.applySpecRules(spec, content));
+    } catch (error) {
+      const baseMessage = error instanceof Error ? error.message : 'Unknown error';
+      const enriched = this.enrichTopLevelError(specName, baseMessage);
+      issues.push({ level: 'ERROR', path: 'file', message: enriched });
+    }
+    return this.createReport(issues);
+  }
+
   async validateChange(filePath: string): Promise<ValidationReport> {
     const issues: ValidationIssue[] = [];
-    
+    const changeName = this.extractNameFromPath(filePath);
     try {
       const content = readFileSync(filePath, 'utf-8');
-      const changeName = this.extractNameFromPath(filePath);
       const changeDir = path.dirname(filePath);
       const parser = new ChangeParser(content, changeDir);
       
@@ -67,22 +89,172 @@ export class Validator {
       issues.push(...this.applyChangeRules(change, content));
       
     } catch (error) {
+      const baseMessage = error instanceof Error ? error.message : 'Unknown error';
+      const enriched = this.enrichTopLevelError(changeName, baseMessage);
       issues.push({
         level: 'ERROR',
         path: 'file',
-        message: error instanceof Error ? error.message : 'Unknown error',
+        message: enriched,
       });
     }
     
     return this.createReport(issues);
   }
 
+  /**
+   * Validate delta-formatted spec files under a change directory.
+   * Enforces:
+   * - At least one delta across all files
+   * - ADDED/MODIFIED: each requirement has SHALL/MUST and at least one scenario
+   * - REMOVED: names only; no scenario/description required
+   * - RENAMED: pairs well-formed
+   * - No duplicates within sections; no cross-section conflicts per spec
+   */
+  async validateChangeDeltaSpecs(changeDir: string): Promise<ValidationReport> {
+    const issues: ValidationIssue[] = [];
+    const specsDir = path.join(changeDir, 'specs');
+    let totalDeltas = 0;
+
+    try {
+      const entries = await fs.readdir(specsDir, { withFileTypes: true });
+      for (const entry of entries) {
+        if (!entry.isDirectory()) continue;
+        const specName = entry.name;
+        const specFile = path.join(specsDir, specName, 'spec.md');
+        let content: string | undefined;
+        try {
+          content = await fs.readFile(specFile, 'utf-8');
+        } catch {
+          continue;
+        }
+
+        const plan = parseDeltaSpec(content);
+        const entryPath = `${specName}/spec.md`;
+
+        const addedNames = new Set<string>();
+        const modifiedNames = new Set<string>();
+        const removedNames = new Set<string>();
+        const renamedFrom = new Set<string>();
+        const renamedTo = new Set<string>();
+
+        // Validate ADDED
+        for (const block of plan.added) {
+          const key = normalizeRequirementName(block.name);
+          totalDeltas++;
+          if (addedNames.has(key)) {
+            issues.push({ level: 'ERROR', path: entryPath, message: `Duplicate requirement in ADDED: "${block.name}"` });
+          } else {
+            addedNames.add(key);
+          }
+          const requirementText = this.extractRequirementText(block.raw);
+          if (!requirementText) {
+            issues.push({ level: 'ERROR', path: entryPath, message: `ADDED "${block.name}" is missing requirement text` });
+          } else if (!this.containsShallOrMust(requirementText)) {
+            issues.push({ level: 'ERROR', path: entryPath, message: `ADDED "${block.name}" must contain SHALL or MUST` });
+          }
+          const scenarioCount = this.countScenarios(block.raw);
+          if (scenarioCount < 1) {
+            issues.push({ level: 'ERROR', path: entryPath, message: `ADDED "${block.name}" must include at least one scenario` });
+          }
+        }
+
+        // Validate MODIFIED
+        for (const block of plan.modified) {
+          const key = normalizeRequirementName(block.name);
+          totalDeltas++;
+          if (modifiedNames.has(key)) {
+            issues.push({ level: 'ERROR', path: entryPath, message: `Duplicate requirement in MODIFIED: "${block.name}"` });
+          } else {
+            modifiedNames.add(key);
+          }
+          const requirementText = this.extractRequirementText(block.raw);
+          if (!requirementText) {
+            issues.push({ level: 'ERROR', path: entryPath, message: `MODIFIED "${block.name}" is missing requirement text` });
+          } else if (!this.containsShallOrMust(requirementText)) {
+            issues.push({ level: 'ERROR', path: entryPath, message: `MODIFIED "${block.name}" must contain SHALL or MUST` });
+          }
+          const scenarioCount = this.countScenarios(block.raw);
+          if (scenarioCount < 1) {
+            issues.push({ level: 'ERROR', path: entryPath, message: `MODIFIED "${block.name}" must include at least one scenario` });
+          }
+        }
+
+        // Validate REMOVED (names only)
+        for (const name of plan.removed) {
+          const key = normalizeRequirementName(name);
+          totalDeltas++;
+          if (removedNames.has(key)) {
+            issues.push({ level: 'ERROR', path: entryPath, message: `Duplicate requirement in REMOVED: "${name}"` });
+          } else {
+            removedNames.add(key);
+          }
+        }
+
+        // Validate RENAMED pairs
+        for (const { from, to } of plan.renamed) {
+          const fromKey = normalizeRequirementName(from);
+          const toKey = normalizeRequirementName(to);
+          totalDeltas++;
+          if (renamedFrom.has(fromKey)) {
+            issues.push({ level: 'ERROR', path: entryPath, message: `Duplicate FROM in RENAMED: "${from}"` });
+          } else {
+            renamedFrom.add(fromKey);
+          }
+          if (renamedTo.has(toKey)) {
+            issues.push({ level: 'ERROR', path: entryPath, message: `Duplicate TO in RENAMED: "${to}"` });
+          } else {
+            renamedTo.add(toKey);
+          }
+        }
+
+        // Cross-section conflicts (within the same spec file)
+        for (const n of modifiedNames) {
+          if (removedNames.has(n)) {
+            issues.push({ level: 'ERROR', path: entryPath, message: `Requirement present in both MODIFIED and REMOVED: "${n}"` });
+          }
+          if (addedNames.has(n)) {
+            issues.push({ level: 'ERROR', path: entryPath, message: `Requirement present in both MODIFIED and ADDED: "${n}"` });
+          }
+        }
+        for (const n of addedNames) {
+          if (removedNames.has(n)) {
+            issues.push({ level: 'ERROR', path: entryPath, message: `Requirement present in both ADDED and REMOVED: "${n}"` });
+          }
+        }
+        for (const { from, to } of plan.renamed) {
+          const fromKey = normalizeRequirementName(from);
+          const toKey = normalizeRequirementName(to);
+          if (modifiedNames.has(fromKey)) {
+            issues.push({ level: 'ERROR', path: entryPath, message: `MODIFIED references old name from RENAMED. Use new header for "${to}"` });
+          }
+          if (addedNames.has(toKey)) {
+            issues.push({ level: 'ERROR', path: entryPath, message: `RENAMED TO collides with ADDED for "${to}"` });
+          }
+        }
+      }
+    } catch {
+      // If no specs dir, treat as no deltas
+    }
+
+    if (totalDeltas === 0) {
+      issues.push({ level: 'ERROR', path: 'file', message: this.enrichTopLevelError('change', VALIDATION_MESSAGES.CHANGE_NO_DELTAS) });
+    }
+
+    return this.createReport(issues);
+  }
+
   private convertZodErrors(error: ZodError): ValidationIssue[] {
-    return error.issues.map(err => ({
-      level: 'ERROR' as ValidationLevel,
-      path: err.path.join('.'),
-      message: err.message,
-    }));
+    return error.issues.map(err => {
+      let message = err.message;
+      if (message === VALIDATION_MESSAGES.CHANGE_NO_DELTAS) {
+        message = `${message}. ${VALIDATION_MESSAGES.GUIDE_NO_DELTAS}`;
+      }
+      return {
+        level: 'ERROR' as ValidationLevel,
+        path: err.path.join('.'),
+        message,
+      };
+    });
   }
 
   private applySpecRules(spec: Spec, content: string): ValidationIssue[] {
@@ -109,7 +281,7 @@ export class Validator {
         issues.push({
           level: 'WARNING',
           path: `requirements[${index}].scenarios`,
-          message: 'Requirement has no scenarios',
+          message: `${VALIDATION_MESSAGES.REQUIREMENT_NO_SCENARIOS}. ${VALIDATION_MESSAGES.GUIDE_SCENARIO_FORMAT}`,
         });
       }
     });
@@ -144,6 +316,20 @@ export class Validator {
     return issues;
   }
 
+  private enrichTopLevelError(itemId: string, baseMessage: string): string {
+    const msg = baseMessage.trim();
+    if (msg === VALIDATION_MESSAGES.CHANGE_NO_DELTAS) {
+      return `${msg}. ${VALIDATION_MESSAGES.GUIDE_NO_DELTAS}`;
+    }
+    if (msg.includes('Spec must have a Purpose section') || msg.includes('Spec must have a Requirements section')) {
+      return `${msg}. ${VALIDATION_MESSAGES.GUIDE_MISSING_SPEC_SECTIONS}`;
+    }
+    if (msg.includes('Change must have a Why section') || msg.includes('Change must have a What Changes section')) {
+      return `${msg}. ${VALIDATION_MESSAGES.GUIDE_MISSING_CHANGE_SECTIONS}`;
+    }
+    return msg;
+  }
+
   private extractNameFromPath(filePath: string): string {
     const parts = filePath.split('/');
     
@@ -184,4 +370,27 @@ export class Validator {
   isValid(report: ValidationReport): boolean {
     return report.valid;
   }
+
+  private extractRequirementText(blockRaw: string): string | undefined {
+    const lines = blockRaw.split('\n');
+    // Skip header
+    let i = 1;
+    const bodyLines: string[] = [];
+    for (; i < lines.length; i++) {
+      const line = lines[i];
+      if (/^####\s+/.test(line)) break; // scenarios start
+      bodyLines.push(line);
+    }
+    const text = bodyLines.join('\n').split('\n').map(l => l.trim()).find(l => l.length > 0);
+    return text;
+  }
+
+  private containsShallOrMust(text: string): boolean {
+    return /\b(SHALL|MUST)\b/.test(text);
+  }
+
+  private countScenarios(blockRaw: string): number {
+    const matches = blockRaw.match(/^####\s+/gm);
+    return matches ? matches.length : 0;
+  }
 }

src/utils/interactive.ts

@@ -0,0 +1,7 @@
+export function isInteractive(noInteractiveFlag?: boolean): boolean {
+  if (noInteractiveFlag) return false;
+  if (process.env.OPEN_SPEC_INTERACTIVE === '0') return false;
+  return !!process.stdin.isTTY;
+}
+
+

src/utils/item-discovery.ts

@@ -0,0 +1,38 @@
+import { promises as fs } from 'fs';
+import path from 'path';
+
+export async function getActiveChangeIds(root: string = process.cwd()): Promise<string[]> {
+  const changesPath = path.join(root, 'openspec', 'changes');
+  try {
+    const entries = await fs.readdir(changesPath, { withFileTypes: true });
+    return entries
+      .filter(entry => entry.isDirectory() && !entry.name.startsWith('.') && entry.name !== 'archive')
+      .map(entry => entry.name)
+      .sort();
+  } catch {
+    return [];
+  }
+}
+
+export async function getSpecIds(root: string = process.cwd()): Promise<string[]> {
+  const specsPath = path.join(root, 'openspec', 'specs');
+  const result: string[] = [];
+  try {
+    const entries = await fs.readdir(specsPath, { withFileTypes: true });
+    for (const entry of entries) {
+      if (!entry.isDirectory() || entry.name.startsWith('.')) continue;
+      const specFile = path.join(specsPath, entry.name, 'spec.md');
+      try {
+        await fs.access(specFile);
+        result.push(entry.name);
+      } catch {
+        // ignore
+      }
+    }
+  } catch {
+    // ignore
+  }
+  return result.sort();
+}
+
+

src/utils/match.ts

@@ -0,0 +1,26 @@
+export function nearestMatches(input: string, candidates: string[], max: number = 5): string[] {
+  const scored = candidates.map(candidate => ({ candidate, distance: levenshtein(input, candidate) }));
+  scored.sort((a, b) => a.distance - b.distance);
+  return scored.slice(0, max).map(s => s.candidate);
+}
+
+export function levenshtein(a: string, b: string): number {
+  const m = a.length;
+  const n = b.length;
+  const dp: number[][] = Array.from({ length: m + 1 }, () => Array(n + 1).fill(0));
+  for (let i = 0; i <= m; i++) dp[i][0] = i;
+  for (let j = 0; j <= n; j++) dp[0][j] = j;
+  for (let i = 1; i <= m; i++) {
+    for (let j = 1; j <= n; j++) {
+      const cost = a[i - 1] === b[j - 1] ? 0 : 1;
+      dp[i][j] = Math.min(
+        dp[i - 1][j] + 1,
+        dp[i][j - 1] + 1,
+        dp[i - 1][j - 1] + cost
+      );
+    }
+  }
+  return dp[m][n];
+}
+
+

src/utils/task-progress.ts

@@ -0,0 +1,43 @@
+import { promises as fs } from 'fs';
+import path from 'path';
+
+const TASK_PATTERN = /^[-*]\s+\[[\sx]\]/i;
+const COMPLETED_TASK_PATTERN = /^[-*]\s+\[x\]/i;
+
+export interface TaskProgress {
+  total: number;
+  completed: number;
+}
+
+export function countTasksFromContent(content: string): TaskProgress {
+  const lines = content.split('\n');
+  let total = 0;
+  let completed = 0;
+  for (const line of lines) {
+    if (line.match(TASK_PATTERN)) {
+      total++;
+      if (line.match(COMPLETED_TASK_PATTERN)) {
+        completed++;
+      }
+    }
+  }
+  return { total, completed };
+}
+
+export async function getTaskProgressForChange(changesDir: string, changeName: string): Promise<TaskProgress> {
+  const tasksPath = path.join(changesDir, changeName, 'tasks.md');
+  try {
+    const content = await fs.readFile(tasksPath, 'utf-8');
+    return countTasksFromContent(content);
+  } catch {
+    return { total: 0, completed: 0 };
+  }
+}
+
+export function formatTaskStatus(progress: TaskProgress): string {
+  if (progress.total === 0) return 'No tasks';
+  if (progress.completed === progress.total) return '✓ Complete';
+  return `${progress.completed}/${progress.total} tasks`;
+}
+
+

test/commands/change.interactive-show.test.ts

@@ -0,0 +1,48 @@
+import { describe, it, expect, beforeAll, beforeEach, afterEach } from 'vitest';
+import { promises as fs } from 'fs';
+import path from 'path';
+import { execSync } from 'child_process';
+
+describe('change show (interactive behavior)', () => {
+  const projectRoot = process.cwd();
+  const testDir = path.join(projectRoot, 'test-change-show-tmp');
+  const changesDir = path.join(testDir, 'openspec', 'changes');
+  const bin = path.join(projectRoot, 'bin', 'openspec.js');
+
+  beforeAll(() => {
+    execSync('pnpm -s build', { stdio: 'pipe' });
+  });
+
+  beforeEach(async () => {
+    await fs.mkdir(changesDir, { recursive: true });
+    const content = `# Change: Demo\n\n## Why\n\n## What Changes\n- x`;
+    await fs.mkdir(path.join(changesDir, 'demo'), { recursive: true });
+    await fs.writeFile(path.join(changesDir, 'demo', 'proposal.md'), content, 'utf-8');
+  });
+
+  afterEach(async () => {
+    await fs.rm(testDir, { recursive: true, force: true });
+  });
+
+  it('prints list hint and exits non-zero when no arg and non-interactive', () => {
+    const originalCwd = process.cwd();
+    const originalEnv = { ...process.env };
+    try {
+      process.chdir(testDir);
+      process.env.OPEN_SPEC_INTERACTIVE = '0';
+      let err: any;
+      try {
+        execSync(`node ${bin} change show`, { encoding: 'utf-8' });
+      } catch (e) { err = e; }
+      expect(err).toBeDefined();
+      expect(err.status).not.toBe(0);
+      expect(err.stderr.toString()).toContain('Available IDs:');
+      expect(err.stderr.toString()).toContain('openspec change list');
+    } finally {
+      process.chdir(originalCwd);
+      process.env = originalEnv;
+    }
+  });
+});
+
+

test/commands/change.interactive-validate.test.ts

@@ -0,0 +1,51 @@
+import { describe, it, expect, beforeAll, beforeEach, afterEach } from 'vitest';
+import { promises as fs } from 'fs';
+import path from 'path';
+import { execSync } from 'child_process';
+
+// Note: We cannot truly simulate TTY prompts in this test runner easily.
+// Instead, we verify non-interactive fallback behavior and basic invocation.
+
+describe('change validate (interactive behavior)', () => {
+  const projectRoot = process.cwd();
+  const testDir = path.join(projectRoot, 'test-change-validate-tmp');
+  const changesDir = path.join(testDir, 'openspec', 'changes');
+  const bin = path.join(projectRoot, 'bin', 'openspec.js');
+
+  beforeAll(() => {
+    execSync('pnpm -s build', { stdio: 'pipe' });
+  });
+
+  beforeEach(async () => {
+    await fs.mkdir(changesDir, { recursive: true });
+    const content = `# Change: Demo\n\n## Why\nBecause reasons that are sufficiently long.\n\n## What Changes\n- **spec-x:** Add something`;
+    await fs.mkdir(path.join(changesDir, 'demo'), { recursive: true });
+    await fs.writeFile(path.join(changesDir, 'demo', 'proposal.md'), content, 'utf-8');
+  });
+
+  afterEach(async () => {
+    await fs.rm(testDir, { recursive: true, force: true });
+  });
+
+  it('prints list hint and exits non-zero when no arg and non-interactive', () => {
+    const originalCwd = process.cwd();
+    const originalEnv = { ...process.env };
+    try {
+      process.chdir(testDir);
+      process.env.OPEN_SPEC_INTERACTIVE = '0';
+      let err: any;
+      try {
+        execSync(`node ${bin} change validate`, { encoding: 'utf-8' });
+      } catch (e) { err = e; }
+      expect(err).toBeDefined();
+      expect(err.status).not.toBe(0);
+      expect(err.stderr.toString()).toContain('Available IDs:');
+      expect(err.stderr.toString()).toContain('openspec change list');
+    } finally {
+      process.chdir(originalCwd);
+      process.env = originalEnv;
+    }
+  });
+});
+
+

test/commands/show.test.ts

@@ -0,0 +1,126 @@
+import { describe, it, expect, beforeEach, afterEach, beforeAll } from 'vitest';
+import { promises as fs } from 'fs';
+import path from 'path';
+import { execSync } from 'child_process';
+
+describe('top-level show command', () => {
+  const projectRoot = process.cwd();
+  const testDir = path.join(projectRoot, 'test-show-command-tmp');
+  const changesDir = path.join(testDir, 'openspec', 'changes');
+  const specsDir = path.join(testDir, 'openspec', 'specs');
+  const openspecBin = path.join(projectRoot, 'bin', 'openspec.js');
+
+  beforeAll(() => {
+    execSync('pnpm -s build', { stdio: 'pipe' });
+  });
+
+  beforeEach(async () => {
+    await fs.mkdir(changesDir, { recursive: true });
+    await fs.mkdir(specsDir, { recursive: true });
+
+    const changeContent = `# Change: Demo\n\n## Why\nBecause reasons.\n\n## What Changes\n- **auth:** Add requirement\n`;
+    await fs.mkdir(path.join(changesDir, 'demo'), { recursive: true });
+    await fs.writeFile(path.join(changesDir, 'demo', 'proposal.md'), changeContent, 'utf-8');
+
+    const specContent = `## Purpose\nAuth spec.\n\n## Requirements\n\n### Requirement: User Authentication\nText\n`;
+    await fs.mkdir(path.join(specsDir, 'auth'), { recursive: true });
+    await fs.writeFile(path.join(specsDir, 'auth', 'spec.md'), specContent, 'utf-8');
+  });
+
+  afterEach(async () => {
+    await fs.rm(testDir, { recursive: true, force: true });
+  });
+
+  it('prints hint and non-zero exit when no args and non-interactive', () => {
+    const originalCwd = process.cwd();
+    const originalEnv = { ...process.env };
+    try {
+      process.chdir(testDir);
+      process.env.OPEN_SPEC_INTERACTIVE = '0';
+      let err: any;
+      try {
+        execSync(`node ${openspecBin} show`, { encoding: 'utf-8' });
+      } catch (e) { err = e; }
+      expect(err).toBeDefined();
+      expect(err.status).not.toBe(0);
+      const stderr = err.stderr.toString();
+      expect(stderr).toContain('Nothing to show.');
+      expect(stderr).toContain('openspec show <item>');
+      expect(stderr).toContain('openspec change show');
+      expect(stderr).toContain('openspec spec show');
+    } finally {
+      process.chdir(originalCwd);
+      process.env = originalEnv;
+    }
+  });
+
+  it('auto-detects change id and supports --json', () => {
+    const originalCwd = process.cwd();
+    try {
+      process.chdir(testDir);
+      const output = execSync(`node ${openspecBin} show demo --json`, { encoding: 'utf-8' });
+      const json = JSON.parse(output);
+      expect(json.id).toBe('demo');
+      expect(Array.isArray(json.deltas)).toBe(true);
+    } finally {
+      process.chdir(originalCwd);
+    }
+  });
+
+  it('auto-detects spec id and supports spec-only flags', () => {
+    const originalCwd = process.cwd();
+    try {
+      process.chdir(testDir);
+      const output = execSync(`node ${openspecBin} show auth --json --requirements`, { encoding: 'utf-8' });
+      const json = JSON.parse(output);
+      expect(json.id).toBe('auth');
+      expect(Array.isArray(json.requirements)).toBe(true);
+    } finally {
+      process.chdir(originalCwd);
+    }
+  });
+
+  it('handles ambiguity and suggests --type', async () => {
+    // create matching spec and change named 'foo'
+    await fs.mkdir(path.join(changesDir, 'foo'), { recursive: true });
+    await fs.writeFile(path.join(changesDir, 'foo', 'proposal.md'), '# Change: Foo\n\n## Why\n\n## What Changes\n', 'utf-8');
+    await fs.mkdir(path.join(specsDir, 'foo'), { recursive: true });
+    await fs.writeFile(path.join(specsDir, 'foo', 'spec.md'), '## Purpose\n\n## Requirements\n\n### Requirement: R\nX', 'utf-8');
+
+    const originalCwd = process.cwd();
+    try {
+      process.chdir(testDir);
+      let err: any;
+      try {
+        execSync(`node ${openspecBin} show foo`, { encoding: 'utf-8' });
+      } catch (e) { err = e; }
+      expect(err).toBeDefined();
+      expect(err.status).not.toBe(0);
+      const stderr = err.stderr.toString();
+      expect(stderr).toContain('Ambiguous item');
+      expect(stderr).toContain('--type change|spec');
+    } finally {
+      process.chdir(originalCwd);
+    }
+  });
+
+  it('prints nearest matches when not found', () => {
+    const originalCwd = process.cwd();
+    try {
+      process.chdir(testDir);
+      let err: any;
+      try {
+        execSync(`node ${openspecBin} show unknown-item`, { encoding: 'utf-8' });
+      } catch (e) { err = e; }
+      expect(err).toBeDefined();
+      expect(err.status).not.toBe(0);
+      const stderr = err.stderr.toString();
+      expect(stderr).toContain("Unknown item 'unknown-item'");
+      expect(stderr).toContain('Did you mean:');
+    } finally {
+      process.chdir(originalCwd);
+    }
+  });
+});
+
+

test/commands/spec.interactive-show.test.ts

@@ -0,0 +1,47 @@
+import { describe, it, expect, beforeAll, beforeEach, afterEach } from 'vitest';
+import { promises as fs } from 'fs';
+import path from 'path';
+import { execSync } from 'child_process';
+
+describe('spec show (interactive behavior)', () => {
+  const projectRoot = process.cwd();
+  const testDir = path.join(projectRoot, 'test-spec-show-tmp');
+  const specsDir = path.join(testDir, 'openspec', 'specs');
+  const bin = path.join(projectRoot, 'bin', 'openspec.js');
+
+  beforeAll(() => {
+    execSync('pnpm -s build', { stdio: 'pipe' });
+  });
+
+  beforeEach(async () => {
+    await fs.mkdir(specsDir, { recursive: true });
+    const content = `## Purpose\nX\n\n## Requirements\n\n### Requirement: R\nText`;
+    await fs.mkdir(path.join(specsDir, 's1'), { recursive: true });
+    await fs.writeFile(path.join(specsDir, 's1', 'spec.md'), content, 'utf-8');
+  });
+
+  afterEach(async () => {
+    await fs.rm(testDir, { recursive: true, force: true });
+  });
+
+  it('errors when no arg and non-interactive', () => {
+    const originalCwd = process.cwd();
+    const originalEnv = { ...process.env };
+    try {
+      process.chdir(testDir);
+      process.env.OPEN_SPEC_INTERACTIVE = '0';
+      let err: any;
+      try {
+        execSync(`node ${bin} spec show`, { encoding: 'utf-8' });
+      } catch (e) { err = e; }
+      expect(err).toBeDefined();
+      expect(err.status).not.toBe(0);
+      expect(err.stderr.toString()).toContain('Missing required argument <spec-id>');
+    } finally {
+      process.chdir(originalCwd);
+      process.env = originalEnv;
+    }
+  });
+});
+
+

test/commands/spec.interactive-validate.test.ts

@@ -0,0 +1,47 @@
+import { describe, it, expect, beforeAll, beforeEach, afterEach } from 'vitest';
+import { promises as fs } from 'fs';
+import path from 'path';
+import { execSync } from 'child_process';
+
+describe('spec validate (interactive behavior)', () => {
+  const projectRoot = process.cwd();
+  const testDir = path.join(projectRoot, 'test-spec-validate-tmp');
+  const specsDir = path.join(testDir, 'openspec', 'specs');
+  const bin = path.join(projectRoot, 'bin', 'openspec.js');
+
+  beforeAll(() => {
+    execSync('pnpm -s build', { stdio: 'pipe' });
+  });
+
+  beforeEach(async () => {
+    await fs.mkdir(specsDir, { recursive: true });
+    const content = `## Purpose\nValid spec for interactive test.\n\n## Requirements\n\n### Requirement: X\nText`;
+    await fs.mkdir(path.join(specsDir, 's1'), { recursive: true });
+    await fs.writeFile(path.join(specsDir, 's1', 'spec.md'), content, 'utf-8');
+  });
+
+  afterEach(async () => {
+    await fs.rm(testDir, { recursive: true, force: true });
+  });
+
+  it('errors when no arg and non-interactive', () => {
+    const originalCwd = process.cwd();
+    const originalEnv = { ...process.env };
+    try {
+      process.chdir(testDir);
+      process.env.OPEN_SPEC_INTERACTIVE = '0';
+      let err: any;
+      try {
+        execSync(`node ${bin} spec validate`, { encoding: 'utf-8' });
+      } catch (e) { err = e; }
+      expect(err).toBeDefined();
+      expect(err.status).not.toBe(0);
+      expect(err.stderr.toString()).toContain('Missing required argument <spec-id>');
+    } finally {
+      process.chdir(originalCwd);
+      process.env = originalEnv;
+    }
+  });
+});
+
+

test/commands/validate.enriched-output.test.ts

@@ -0,0 +1,53 @@
+import { describe, it, expect, beforeAll, beforeEach, afterEach } from 'vitest';
+import { promises as fs } from 'fs';
+import path from 'path';
+import { execSync } from 'child_process';
+
+describe('validate command enriched human output', () => {
+  const projectRoot = process.cwd();
+  const testDir = path.join(projectRoot, 'test-validate-enriched-tmp');
+  const changesDir = path.join(testDir, 'openspec', 'changes');
+  const bin = path.join(projectRoot, 'bin', 'openspec.js');
+
+  beforeAll(() => {
+    // Build once so the bin can resolve dist
+    try { execSync('pnpm -s build', { stdio: 'pipe' }); } catch {}
+  });
+
+  beforeEach(async () => {
+    await fs.mkdir(changesDir, { recursive: true });
+  });
+
+  afterEach(async () => {
+    await fs.rm(testDir, { recursive: true, force: true });
+  });
+
+  it('prints Next steps footer and guidance on invalid change', () => {
+    const changeContent = `# Test Change\n\n## Why\nThis is a sufficiently long explanation to pass the why length requirement for validation purposes.\n\n## What Changes\nThere are changes proposed, but no delta specs provided yet.`;
+    const changeId = 'c-next-steps';
+    const changePath = path.join(changesDir, changeId);
+    execSync(`mkdir -p ${changePath}`);
+    execSync(`bash -lc "cat > ${path.join(changePath, 'proposal.md')} <<'EOF'\n${changeContent}\nEOF"`);
+
+    const originalCwd = process.cwd();
+    try {
+      process.chdir(testDir);
+      let code = 0;
+      let stderr = '';
+      try {
+        execSync(`node ${bin} change validate ${changeId}`, { encoding: 'utf-8', stdio: 'pipe' });
+      } catch (e: any) {
+        code = e?.status ?? 1;
+        stderr = e?.stderr?.toString?.() ?? '';
+      }
+      expect(code).not.toBe(0);
+      expect(stderr).toContain('has issues');
+      expect(stderr).toContain('Next steps:');
+      expect(stderr).toContain('openspec change show');
+    } finally {
+      process.chdir(originalCwd);
+    }
+  });
+});
+
+

test/commands/validate.test.ts

@@ -0,0 +1,125 @@
+import { describe, it, expect, beforeAll, beforeEach, afterEach } from 'vitest';
+import { promises as fs } from 'fs';
+import path from 'path';
+import { execSync } from 'child_process';
+
+describe('top-level validate command', () => {
+  const projectRoot = process.cwd();
+  const testDir = path.join(projectRoot, 'test-validate-command-tmp');
+  const changesDir = path.join(testDir, 'openspec', 'changes');
+  const specsDir = path.join(testDir, 'openspec', 'specs');
+  const bin = path.join(projectRoot, 'bin', 'openspec.js');
+
+  beforeAll(() => {
+    execSync('pnpm -s build', { stdio: 'pipe' });
+  });
+
+  beforeEach(async () => {
+    await fs.mkdir(changesDir, { recursive: true });
+    await fs.mkdir(specsDir, { recursive: true });
+
+    // Create a valid spec
+    const specContent = `## Purpose
+Valid spec for testing.
+
+## Requirements
+
+### Requirement: Foo
+Text
+
+#### Scenario: Bar
+Given A\nWhen B\nThen C`;
+    await fs.mkdir(path.join(specsDir, 'alpha'), { recursive: true });
+    await fs.writeFile(path.join(specsDir, 'alpha', 'spec.md'), specContent, 'utf-8');
+
+    // Create a simple change with bullets (parser supports this)
+    const changeContent = `# Test Change\n\n## Why\nBecause reasons that are sufficiently long for validation.\n\n## What Changes\n- **alpha:** Add something`;
+    await fs.mkdir(path.join(changesDir, 'c1'), { recursive: true });
+    await fs.writeFile(path.join(changesDir, 'c1', 'proposal.md'), changeContent, 'utf-8');
+
+    // Duplicate name for ambiguity test
+    await fs.mkdir(path.join(changesDir, 'dup'), { recursive: true });
+    await fs.writeFile(path.join(changesDir, 'dup', 'proposal.md'), changeContent, 'utf-8');
+    await fs.mkdir(path.join(specsDir, 'dup'), { recursive: true });
+    await fs.writeFile(path.join(specsDir, 'dup', 'spec.md'), specContent, 'utf-8');
+  });
+
+  afterEach(async () => {
+    await fs.rm(testDir, { recursive: true, force: true });
+  });
+
+  it('prints a helpful hint when no args in non-interactive mode', () => {
+    const originalCwd = process.cwd();
+    const originalEnv = { ...process.env };
+    try {
+      process.chdir(testDir);
+      process.env.OPEN_SPEC_INTERACTIVE = '0';
+      let err: any;
+      try {
+        execSync(`node ${bin} validate`, { encoding: 'utf-8' });
+      } catch (e) { err = e; }
+      expect(err).toBeDefined();
+      expect(err.status).not.toBe(0);
+      expect(err.stderr.toString()).toContain('Nothing to validate. Try one of:');
+    } finally {
+      process.chdir(originalCwd);
+      process.env = originalEnv;
+    }
+  });
+
+  it('validates all with --all and outputs JSON summary', () => {
+    const originalCwd = process.cwd();
+    try {
+      process.chdir(testDir);
+      let outStr = '';
+      try {
+        outStr = execSync(`node ${bin} validate --all --json`, { encoding: 'utf-8' });
+      } catch (e: any) {
+        // If exit code is non-zero (e.g., on failures), still parse stdout JSON
+        outStr = e.stdout?.toString?.() ?? '';
+      }
+      const json = JSON.parse(outStr);
+      expect(Array.isArray(json.items)).toBe(true);
+      expect(json.summary?.totals?.items).toBeDefined();
+      expect(json.version).toBe('1.0');
+    } finally {
+      process.chdir(originalCwd);
+    }
+  });
+
+  it('validates only specs with --specs and respects --concurrency', () => {
+    const originalCwd = process.cwd();
+    try {
+      process.chdir(testDir);
+      let outStr = '';
+      try {
+        outStr = execSync(`node ${bin} validate --specs --json --concurrency 1`, { encoding: 'utf-8' });
+      } catch (e: any) {
+        outStr = e.stdout?.toString?.() ?? '';
+      }
+      const json = JSON.parse(outStr);
+      // All items should be specs
+      expect(json.items.every((i: any) => i.type === 'spec')).toBe(true);
+    } finally {
+      process.chdir(originalCwd);
+    }
+  });
+
+  it('errors on ambiguous item names and suggests type override', () => {
+    const originalCwd = process.cwd();
+    try {
+      process.chdir(testDir);
+      let err: any;
+      try {
+        execSync(`node ${bin} validate dup`, { encoding: 'utf-8' });
+      } catch (e) { err = e; }
+      expect(err).toBeDefined();
+      expect(err.stderr.toString()).toContain('Ambiguous item');
+      expect(err.status).not.toBe(0);
+    } finally {
+      process.chdir(originalCwd);
+    }
+  });
+});
+
+

test/core/archive.test.ts

@@ -569,14 +569,14 @@ E1 updated`);
       // Execute without change name
       await archiveCommand.execute(undefined, { yes: true });
       
-      // Verify select was called with correct options
-      expect(mockSelect).toHaveBeenCalledWith({
+      // Verify select was called with correct options (values matter, names may include progress)
+      expect(mockSelect).toHaveBeenCalledWith(expect.objectContaining({
         message: 'Select a change to archive',
-        choices: [
-          { name: change1, value: change1 },
-          { name: change2, value: change2 }
-        ]
-      });
+        choices: expect.arrayContaining([
+          expect.objectContaining({ value: change1 }),
+          expect.objectContaining({ value: change2 })
+        ])
+      }));
       
       // Verify the selected change was archived
       const archiveDir = path.join(tempDir, 'openspec', 'changes', 'archive');

test/core/list.test.ts

@@ -34,7 +34,7 @@ describe('ListCommand', () => {
     it('should handle missing openspec/changes directory', async () => {
       const listCommand = new ListCommand();
       
-      await expect(listCommand.execute(tempDir)).rejects.toThrow(
+      await expect(listCommand.execute(tempDir, 'changes')).rejects.toThrow(
         "No OpenSpec changes directory found. Run 'openspec init' first."
       );
     });
@@ -44,7 +44,7 @@ describe('ListCommand', () => {
       await fs.mkdir(changesDir, { recursive: true });
 
       const listCommand = new ListCommand();
-      await listCommand.execute(tempDir);
+      await listCommand.execute(tempDir, 'changes');
 
       expect(logOutput).toEqual(['No active changes found.']);
     });
@@ -61,7 +61,7 @@ describe('ListCommand', () => {
       );
 
       const listCommand = new ListCommand();
-      await listCommand.execute(tempDir);
+      await listCommand.execute(tempDir, 'changes');
 
       expect(logOutput).toContain('Changes:');
       expect(logOutput.some(line => line.includes('my-change'))).toBe(true);
@@ -85,7 +85,7 @@ Regular text that should be ignored
       );
 
       const listCommand = new ListCommand();
-      await listCommand.execute(tempDir);
+      await listCommand.execute(tempDir, 'changes');
 
       expect(logOutput.some(line => line.includes('2/5 tasks'))).toBe(true);
     });
@@ -100,7 +100,7 @@ Regular text that should be ignored
       );
 
       const listCommand = new ListCommand();
-      await listCommand.execute(tempDir);
+      await listCommand.execute(tempDir, 'changes');
 
       expect(logOutput.some(line => line.includes('✓ Complete'))).toBe(true);
     });
@@ -110,7 +110,7 @@ Regular text that should be ignored
       await fs.mkdir(path.join(changesDir, 'no-tasks'), { recursive: true });
 
       const listCommand = new ListCommand();
-      await listCommand.execute(tempDir);
+      await listCommand.execute(tempDir, 'changes');
 
       expect(logOutput.some(line => line.includes('no-tasks') && line.includes('No tasks'))).toBe(true);
     });

test/core/validation.enriched-messages.test.ts

@@ -0,0 +1,74 @@
+import { describe, it, expect, beforeEach, afterEach } from 'vitest';
+import { promises as fs } from 'fs';
+import path from 'path';
+import { Validator } from '../../src/core/validation/validator.js';
+
+describe('Validator enriched messages', () => {
+  const testDir = path.join(process.cwd(), 'test-validation-enriched-tmp');
+
+  beforeEach(async () => {
+    await fs.mkdir(testDir, { recursive: true });
+  });
+
+  afterEach(async () => {
+    await fs.rm(testDir, { recursive: true, force: true });
+  });
+
+  it('adds guidance for no deltas in change', async () => {
+    const changeContent = `# Test Change
+
+## Why
+This is a sufficiently long explanation to pass the why length requirement for validation purposes.
+
+## What Changes
+There are changes proposed, but no delta specs provided yet.`;
+    const changePath = path.join(testDir, 'proposal.md');
+    await fs.writeFile(changePath, changeContent);
+
+    const validator = new Validator();
+    const report = await validator.validateChange(changePath);
+    expect(report.valid).toBe(false);
+    const msg = report.issues.map(i => i.message).join('\n');
+    expect(msg).toContain('Change must have at least one delta');
+    expect(msg).toContain('Ensure your change has a specs/ directory');
+    expect(msg).toContain('## ADDED/MODIFIED/REMOVED/RENAMED Requirements');
+  });
+
+  it('adds guidance when spec missing Purpose/Requirements', async () => {
+    const specContent = `# Test Spec\n\n## Requirements\n\n### Requirement: Foo\nFoo SHALL ...\n\n#### Scenario: Bar\nWhen...`;
+    const specPath = path.join(testDir, 'spec.md');
+    await fs.writeFile(specPath, specContent);
+
+    const validator = new Validator();
+    const report = await validator.validateSpec(specPath);
+    expect(report.valid).toBe(false);
+    const msg = report.issues.map(i => i.message).join('\n');
+    expect(msg).toContain('Spec must have a Purpose section');
+    expect(msg).toContain('Expected headers: "## Purpose" and "## Requirements"');
+  });
+
+  it('warns with scenario conversion template when missing scenarios', async () => {
+    const specContent = `# Test Spec
+
+## Purpose
+This is a sufficiently long purpose section to avoid warnings about brevity.
+
+## Requirements
+
+### Requirement: Foo SHALL be described
+Text of requirement
+`;
+    const specPath = path.join(testDir, 'spec.md');
+    await fs.writeFile(specPath, specContent);
+
+    const validator = new Validator();
+    const report = await validator.validateSpec(specPath);
+    expect(report.valid).toBe(false);
+    const warn = report.issues.find(i => i.path.includes('requirements[0].scenarios'));
+    expect(warn?.message).toContain('Requirement must have at least one scenario');
+    expect(warn?.message).toContain('Scenarios must use level-4 headers');
+    expect(warn?.message).toContain('#### Scenario:');
+  });
+});
+
+

tsconfig.json

@@ -1,9 +1,9 @@
 {
   "compilerOptions": {
     "target": "ES2022",
-    "module": "ESNext",
+    "module": "NodeNext",
     "lib": ["ES2022"],
-    "moduleResolution": "node",
+    "moduleResolution": "NodeNext",
     "rootDir": "./src",
     "outDir": "./dist",
     "esModuleInterop": true,