dino-spec 13.6.1 → 14.0.0

package/dist/rules/index.js

@@ -5,864 +5,864 @@
  * that Claude Code reads for contextual guidance.
  */
 import { join } from 'path';
-import { FileSystem } from '../utils/file-system.js';
 import { VERSION } from '../core/config.js';
+import { FileSystem } from '../utils/file-system.js';
 /**
  * Generate session context rule content (merged with workflow-phases in v12.2.0)
  */
 function generateSessionContextRule() {
-    return `# Session Context Interpretation (dino-spec v${VERSION})
-
-## Reading session.md
-
-The \`.dino/session.md\` file contains live session state:
-
-### Focus Section
-\`\`\`markdown
-## Focus
-**src/commands/** (high confidence, directory-cluster)
-\`\`\`
-- Indicates current working area
-- Confidence: high/medium/low
-- Source: directory-cluster, feature-pair, entry-point, manual
-
-### Recent Changes
-\`\`\`markdown
-## Recent Changes
-- 10:30 [dependency] package.json
-- 10:25 [code] src/core/analyzer.ts
-\`\`\`
-- Categories: dependency, structural, config, test, code, documentation
-- Ordered by recency (newest first)
-- Last 10 changes shown
-
-### Test/Build/Lint Status
-\`\`\`markdown
-## Test Status
-**Status:** failing (2025-01-17 10:45)
-**Counts:** 23 passed, 2 failed, 1 skipped
-\`\`\`
-- Statuses: passing, failing, partial, unknown
-- Tracked automatically by hooks
-
-### Progress Signals
-\`\`\`markdown
-## Progress
-- 2025-01-17 10:45: build-fixed - Build now passing
-\`\`\`
-- Auto-detected state transitions
-- Types: tests-fixed, tests-broken, build-fixed, build-broken, lint-fixed
-
-### Blockers
-\`\`\`markdown
-## Blockers
-- Fix failing test: handle edge case
-\`\`\`
-- Active issues preventing completion
-- Auto-resolved when tests/build pass
-
-### Pending Actions
-\`\`\`markdown
-## Pending Actions
-- Run npm install after dependency changes
-\`\`\`
-- Auto-generated from change categories
-- dependency changes → npm install
-- structural changes → verify imports
-
-## Using Context
-
-1. **Check focus first** - Work within focus area when possible
-2. **Review blockers** - Address blockers before new work
-3. **Track pending actions** - Execute before testing
-4. **Note progress** - Build on recent progress signals
-
-## Phase Progression
-
-When working with dino-spec session context, follow these phase patterns:
-
-### Discovery Phase
-- Capture requirements from user prompts
-- Record in session.md under Notes
-- Ask clarifying questions before planning
-
-### Research Phase
-- Explore codebase for existing patterns
-- Document findings in session context
-- Identify reusable components
-
-### Clarification Phase
-- Use AskUserQuestion for ambiguities
-- Validate assumptions with user
-- Update session.md with decisions
-
-### Planning Phase
-- Enter plan mode for non-trivial tasks
-- Create structured implementation plan
-- Get user approval before proceeding
-
-### Breakdown Phase
-- Break plan into TodoWrite items
-- Create atomic, verifiable tasks
-- Mark dependencies between tasks
-
-### Implementation Phase
-- Execute todos sequentially
-- Update session.md focus area
-- Track progress signals
-
-### Verification Phase
-- Run tests after implementation
-- Verify build passes
-- Check lint status
-
-### Completion Phase
-- Archive completed work
-- Update session notes
-- Clear blockers
-
-## Auto-Detection
-
-The hook system automatically detects phase transitions:
-- File edits → Implementation phase
-- Test runs → Verification phase
-- Build runs → Verification phase
-- Session start → Discovery/Resume phase
-
-## Focus Management
-
-Focus is auto-detected from edit clustering:
-- \`high\` confidence: 70%+ edits in same directory
-- \`medium\` confidence: 50-70% clustering
-- \`low\` confidence: < 50% clustering
+    return `# Session Context Interpretation (dino-spec v${VERSION})
+
+## Reading session.md
+
+The \`.dino/session.md\` file contains live session state:
+
+### Focus Section
+\`\`\`markdown
+## Focus
+**src/commands/** (high confidence, directory-cluster)
+\`\`\`
+- Indicates current working area
+- Confidence: high/medium/low
+- Source: directory-cluster, feature-pair, entry-point, manual
+
+### Recent Changes
+\`\`\`markdown
+## Recent Changes
+- 10:30 [dependency] package.json
+- 10:25 [code] src/core/analyzer.ts
+\`\`\`
+- Categories: dependency, structural, config, test, code, documentation
+- Ordered by recency (newest first)
+- Last 10 changes shown
+
+### Test/Build/Lint Status
+\`\`\`markdown
+## Test Status
+**Status:** failing (2025-01-17 10:45)
+**Counts:** 23 passed, 2 failed, 1 skipped
+\`\`\`
+- Statuses: passing, failing, partial, unknown
+- Tracked automatically by hooks
+
+### Progress Signals
+\`\`\`markdown
+## Progress
+- 2025-01-17 10:45: build-fixed - Build now passing
+\`\`\`
+- Auto-detected state transitions
+- Types: tests-fixed, tests-broken, build-fixed, build-broken, lint-fixed
+
+### Blockers
+\`\`\`markdown
+## Blockers
+- Fix failing test: handle edge case
+\`\`\`
+- Active issues preventing completion
+- Auto-resolved when tests/build pass
+
+### Pending Actions
+\`\`\`markdown
+## Pending Actions
+- Run bun install after dependency changes
+\`\`\`
+- Auto-generated from change categories
+- dependency changes → bun install
+- structural changes → verify imports
+
+## Using Context
+
+1. **Check focus first** - Work within focus area when possible
+2. **Review blockers** - Address blockers before new work
+3. **Track pending actions** - Execute before testing
+4. **Note progress** - Build on recent progress signals
+
+## Phase Progression
+
+When working with dino-spec session context, follow these phase patterns:
+
+### Discovery Phase
+- Capture requirements from user prompts
+- Record in session.md under Notes
+- Ask clarifying questions before planning
+
+### Research Phase
+- Explore codebase for existing patterns
+- Document findings in session context
+- Identify reusable components
+
+### Clarification Phase
+- Use AskUserQuestion for ambiguities
+- Validate assumptions with user
+- Update session.md with decisions
+
+### Planning Phase
+- Enter plan mode for non-trivial tasks
+- Create structured implementation plan
+- Get user approval before proceeding
+
+### Breakdown Phase
+- Break plan into TodoWrite items
+- Create atomic, verifiable tasks
+- Mark dependencies between tasks
+
+### Implementation Phase
+- Execute todos sequentially
+- Update session.md focus area
+- Track progress signals
+
+### Verification Phase
+- Run tests after implementation
+- Verify build passes
+- Check lint status
+
+### Completion Phase
+- Archive completed work
+- Update session notes
+- Clear blockers
+
+## Auto-Detection
+
+The hook system automatically detects phase transitions:
+- File edits → Implementation phase
+- Test runs → Verification phase
+- Build runs → Verification phase
+- Session start → Discovery/Resume phase
+
+## Focus Management
+
+Focus is auto-detected from edit clustering:
+- \`high\` confidence: 70%+ edits in same directory
+- \`medium\` confidence: 50-70% clustering
+- \`low\` confidence: < 50% clustering
 `;
 }
 /**
  * Generate auto-context engineering rule content
  */
 function generateAutoContextEngineeringRule() {
-    return `# Auto Context Engineering (dino-spec v${VERSION})
-
-## Automatic Features
-
-All context engineering features are enabled by default:
-
-1. **MCP Tool Filtering** - Only phase-relevant tools loaded (~50-70% context savings)
-2. **Lazy Context Loading** - Resources deferred until needed
-3. **Session State Tracking** - Focus, blockers, progress auto-tracked
-
-## No Configuration Required
-
-Users do NOT need to:
-- Set environment variables
-- Pass special flags
-- Configure anything manually
-
-These features auto-apply via \`dino init\` and \`dino update\`.
-
-## Opt-Out (Not Recommended)
-
-To disable MCP tool filtering:
-\`\`\`bash
-DINO_AGGRESSIVE_FILTERING=false
-\`\`\`
-
-This is NOT recommended as it increases context overhead significantly.
-
-## Token Savings by Phase
-
-| Phase | Tools Loaded | Savings |
-|-------|-------------|---------|
-| Discovery | ~17 | ~60% |
-| Planning | ~22 | ~53% |
-| Implementation | ~23 | ~51% |
-| Completing | ~12 | ~74% |
-
-## Phase Auto-Detection
-
-Phase is auto-detected from:
-1. \`## Phase\` section in session.md
-2. Default: \`discovery\` if not set
-
-The MCP server parses session.md on each \`tools/list\` request to get the current phase.
+    return `# Auto Context Engineering (dino-spec v${VERSION})
+
+## Automatic Features
+
+All context engineering features are enabled by default:
+
+1. **MCP Tool Filtering** - Only phase-relevant tools loaded (~50-70% context savings)
+2. **Lazy Context Loading** - Resources deferred until needed
+3. **Session State Tracking** - Focus, blockers, progress auto-tracked
+
+## No Configuration Required
+
+Users do NOT need to:
+- Set environment variables
+- Pass special flags
+- Configure anything manually
+
+These features auto-apply via \`dino init\` and \`dino update\`.
+
+## Opt-Out (Not Recommended)
+
+To disable MCP tool filtering:
+\`\`\`bash
+DINO_AGGRESSIVE_FILTERING=false
+\`\`\`
+
+This is NOT recommended as it increases context overhead significantly.
+
+## Token Savings by Phase
+
+| Phase | Tools Loaded | Savings |
+|-------|-------------|---------|
+| Discovery | ~17 | ~60% |
+| Planning | ~22 | ~53% |
+| Implementation | ~23 | ~51% |
+| Completing | ~12 | ~74% |
+
+## Phase Auto-Detection
+
+Phase is auto-detected from:
+1. \`## Phase\` section in session.md
+2. Default: \`discovery\` if not set
+
+The MCP server parses session.md on each \`tools/list\` request to get the current phase.
 `;
 }
 /**
  * Generate effort guidance rule content
  */
 function generateEffortGuidanceRule() {
-    return `# Effort Parameter Guidance (dino-spec v${VERSION})
-
-## Overview
-
-The \`effort\` parameter guides Claude Code on how much thinking/reasoning to apply to a task. This maps to model selection and extended thinking token allocation.
-
-## Effort Levels
-
-| Level | Model | Thinking Tokens | Use Cases |
-|-------|-------|-----------------|-----------|
-| **low** | haiku | <2K tokens | Status checks, simple lookups, archival |
-| **medium** | sonnet | 2-5K tokens | Research, implementation, testing |
-| **high** | opus | 5K+ tokens | Planning, architecture, complex analysis |
-
-## When to Use Each Level
-
-### Low Effort
-- Quick status checks (\`/dino.status\`)
-- Simple lookups and reads
-- Archival tasks (\`/dino.fossil\`)
-- Focus changes (\`/dino.status --focus\`)
-- Clarification questions (\`/dino.sniff\`)
-- Loading handoff context (\`/dino.handoff\`)
-- Next step suggestions (\`/dino.status --next\`)
-- Context optimization guidance (\`/dino.status --tips\`)
-
-**Characteristics:**
-- Single-step operations
-- Minimal reasoning required
-- Speed is more important than depth
-- Read-heavy, write-light
-
-### Medium Effort
-- Research tasks (\`/dino.scout\`, \`/research\`)
-- Implementation execution (\`/dino.hunt\`)
-- Test verification (\`/dino.aging\`)
-- Task breakdown (\`/dino.hatch\`)
-- Release workflows (\`/dino.release\`)
-
-**Characteristics:**
-- Multi-step operations
-- Moderate reasoning required
-- Balance of speed and quality
-- Mix of reading and writing
-
-### High Effort
-- Architecture planning (\`/dino.nest\`)
-- Complex analysis
-- Design decisions
-- Multi-component changes
-
-**Characteristics:**
-- Deep reasoning required
-- Many interdependent decisions
-- Quality is more important than speed
-- Significant impact on codebase
-
-## Opus 4.5 Extended Thinking
-
-For high-effort tasks, Opus 4.5's extended thinking capabilities can be leveraged:
-
-\`\`\`yaml
-# In SKILL.md frontmatter
-effort: high  # Signals to use extended thinking
-\`\`\`
-
-**Extended thinking is useful for:**
-- Understanding complex requirements
-- Exploring multiple approaches
-- Identifying edge cases
-- Planning multi-file changes
-- Architectural decisions
-
-## Mapping to SKILL.md
-
-Each skill specifies its effort level in frontmatter:
-
-\`\`\`yaml
----
-description: Plan implementation with structured approach
-model: opus
-effort: high
-context: fork
----
-\`\`\`
-
-## Budget Considerations
-
-Effort level affects token budget:
-
-| Level | Typical Budget Impact | Cost Factor |
-|-------|----------------------|-------------|
-| low | ~1K tokens | 1x (cheapest) |
-| medium | ~5K tokens | 3x |
-| high | ~15K+ tokens | 10x |
-
-Use the lowest effort level that produces good results for the task.
-
-## Dynamic Effort Adjustment
-
-Consider increasing effort when:
-- Initial attempt fails or produces poor results
-- Task complexity is higher than expected
-- User feedback indicates need for deeper analysis
-
-Consider decreasing effort when:
-- Task is simpler than expected
-- Budget constraints are tight
-- Speed is prioritized over depth
+    return `# Effort Parameter Guidance (dino-spec v${VERSION})
+
+## Overview
+
+The \`effort\` parameter guides Claude Code on how much thinking/reasoning to apply to a task. This maps to model selection and extended thinking token allocation.
+
+## Effort Levels
+
+| Level | Model | Thinking Tokens | Use Cases |
+|-------|-------|-----------------|-----------|
+| **low** | haiku | <2K tokens | Status checks, simple lookups, archival |
+| **medium** | sonnet | 2-5K tokens | Research, implementation, testing |
+| **high** | opus | 5K+ tokens | Planning, architecture, complex analysis |
+
+## When to Use Each Level
+
+### Low Effort
+- Quick status checks (\`/dino.status\`)
+- Simple lookups and reads
+- Archival tasks (\`/dino.fossil\`)
+- Focus changes (\`/dino.status --focus\`)
+- Clarification questions (\`/dino.sniff\`)
+- Loading handoff context (\`/dino.handoff\`)
+- Next step suggestions (\`/dino.status --next\`)
+- Context optimization guidance (\`/dino.status --tips\`)
+
+**Characteristics:**
+- Single-step operations
+- Minimal reasoning required
+- Speed is more important than depth
+- Read-heavy, write-light
+
+### Medium Effort
+- Research tasks (\`/dino.scout\`, \`/research\`)
+- Implementation execution (\`/dino.hunt\`)
+- Test verification (\`/dino.aging\`)
+- Task breakdown (\`/dino.hatch\`)
+- Release workflows (\`/dino.release\`)
+
+**Characteristics:**
+- Multi-step operations
+- Moderate reasoning required
+- Balance of speed and quality
+- Mix of reading and writing
+
+### High Effort
+- Architecture planning (\`/dino.nest\`)
+- Complex analysis
+- Design decisions
+- Multi-component changes
+
+**Characteristics:**
+- Deep reasoning required
+- Many interdependent decisions
+- Quality is more important than speed
+- Significant impact on codebase
+
+## Opus 4.5 Extended Thinking
+
+For high-effort tasks, Opus 4.5's extended thinking capabilities can be leveraged:
+
+\`\`\`yaml
+# In SKILL.md frontmatter
+effort: high  # Signals to use extended thinking
+\`\`\`
+
+**Extended thinking is useful for:**
+- Understanding complex requirements
+- Exploring multiple approaches
+- Identifying edge cases
+- Planning multi-file changes
+- Architectural decisions
+
+## Mapping to SKILL.md
+
+Each skill specifies its effort level in frontmatter:
+
+\`\`\`yaml
+---
+description: Plan implementation with structured approach
+model: opus
+effort: high
+context: fork
+---
+\`\`\`
+
+## Budget Considerations
+
+Effort level affects token budget:
+
+| Level | Typical Budget Impact | Cost Factor |
+|-------|----------------------|-------------|
+| low | ~1K tokens | 1x (cheapest) |
+| medium | ~5K tokens | 3x |
+| high | ~15K+ tokens | 10x |
+
+Use the lowest effort level that produces good results for the task.
+
+## Dynamic Effort Adjustment
+
+Consider increasing effort when:
+- Initial attempt fails or produces poor results
+- Task complexity is higher than expected
+- User feedback indicates need for deeper analysis
+
+Consider decreasing effort when:
+- Task is simpler than expected
+- Budget constraints are tight
+- Speed is prioritized over depth
 `;
 }
 /**
  * Generate ralph loop rule content
  */
 function generateRalphLoopRule() {
-    return `# Ralph Loop Guidelines (dino-spec v${VERSION})
-
-## When to Use Ralph Loop
-
-Use \`/dino.ralph\` when:
-- Complexity score > 70
-- Task involves 10+ files
-- Multi-story feature work
-- Major refactoring
-- System-wide changes
-
-## Prerequisites
-
-Before starting ralph loop:
-1. Run \`/dino.spec\` to achieve 90%+ confidence
-2. Have clear PRD with stories
-3. Each story must have acceptance criteria
-4. Estimated scope should fit in one iteration
-
-## Iteration Guidelines
-
-Each iteration:
-1. Starts with FRESH context (no history accumulation)
-2. Creates git checkpoint before changes
-3. Focuses on ONE story only
-4. Runs tests after completion
-5. Records learnings for future iterations
-
-## Git as Memory
-
-Ralph uses git for persistence:
-- \`ralph-cp-{n}\`: Checkpoint commits
-- \`ralph: complete story {id}\`: Story completion commits
-- \`.dino/ralph-progress.md\`: Persistent state file
-
-## Maximum Iterations
-
-Hard limit: 10 iterations per ralph loop
-- If not complete after 10: Manual review required
-- Each story should ideally complete in 1-2 iterations
-
-## Backpressure Signals
-
-Tests/types/lints provide guidance:
-- Failing tests → Story not complete
-- Type errors → Implementation incomplete
-- Lint errors → Code quality issues
-
-Address these before marking story complete.
-
-## PRD Story Format
-
-Each story must have:
-\`\`\`markdown
-### Story: {title}
-**ID:** {unique_id}
-**Files:** {list of files to modify}
-**Acceptance Criteria:**
-- [ ] Criterion 1
-- [ ] Criterion 2
-**Test Command:** {command to verify}
-\`\`\`
-
-## Sub-Agent Context
-
-Each sub-agent receives ONLY:
-- Story requirements
-- Acceptance criteria
-- Relevant files (scoped)
-- Previous learnings
-- Test command
-
-NO conversation history, NO unrelated context.
+    return `# Ralph Loop Guidelines (dino-spec v${VERSION})
+
+## When to Use Ralph Loop
+
+Use \`/dino.ralph\` when:
+- Complexity score > 70
+- Task involves 10+ files
+- Multi-story feature work
+- Major refactoring
+- System-wide changes
+
+## Prerequisites
+
+Before starting ralph loop:
+1. Run \`/dino.spec\` to achieve 90%+ confidence
+2. Have clear PRD with stories
+3. Each story must have acceptance criteria
+4. Estimated scope should fit in one iteration
+
+## Iteration Guidelines
+
+Each iteration:
+1. Starts with FRESH context (no history accumulation)
+2. Creates git checkpoint before changes
+3. Focuses on ONE story only
+4. Runs tests after completion
+5. Records learnings for future iterations
+
+## Git as Memory
+
+Ralph uses git for persistence:
+- \`ralph-cp-{n}\`: Checkpoint commits
+- \`ralph: complete story {id}\`: Story completion commits
+- \`.dino/ralph-progress.md\`: Persistent state file
+
+## Maximum Iterations
+
+Hard limit: 10 iterations per ralph loop
+- If not complete after 10: Manual review required
+- Each story should ideally complete in 1-2 iterations
+
+## Backpressure Signals
+
+Tests/types/lints provide guidance:
+- Failing tests → Story not complete
+- Type errors → Implementation incomplete
+- Lint errors → Code quality issues
+
+Address these before marking story complete.
+
+## PRD Story Format
+
+Each story must have:
+\`\`\`markdown
+### Story: {title}
+**ID:** {unique_id}
+**Files:** {list of files to modify}
+**Acceptance Criteria:**
+- [ ] Criterion 1
+- [ ] Criterion 2
+**Test Command:** {command to verify}
+\`\`\`
+
+## Sub-Agent Context
+
+Each sub-agent receives ONLY:
+- Story requirements
+- Acceptance criteria
+- Relevant files (scoped)
+- Previous learnings
+- Test command
+
+NO conversation history, NO unrelated context.
 `;
 }
 /**
  * Generate ralph enforcement rule content (v13.1.0)
  */
 function generateRalphEnforcementRule() {
-    return `# Ralph Loop Enforcement (dino-spec v${VERSION})
-
-## CRITICAL: Mandatory Ralph Gate
-
-When a user requests Ralph Loop or any complex multi-story task, you MUST use the \`/dino.ralph-gate\` skill. This is NOT optional.
-
-## Trigger Keywords (Case Insensitive)
-
-IMMEDIATELY invoke \`/dino.ralph-gate\` when user message contains:
-
-| Keyword | Example |
-|---------|---------|
-| "ralph loop" | "Start ralph loop for this feature" |
-| "ralph" | "Use ralph for this" |
-| "/dino.ralph" | "/dino.ralph" |
-| "fresh context" + "iteration" | "Use fresh context iterations" |
-| "multi-story" | "This is multi-story work" |
-| "three agent" | "Use three agent system" |
-| "gated implementation" | "I want gated implementation" |
-
-## Complexity Auto-Trigger
-
-ALSO invoke \`/dino.ralph-gate\` when task analysis shows:
-- Complexity score > 70
-- File count > 10
-- Distinct parts >= 3
-- Breaking changes + scope >= 15
-
-## Forbidden Bypass
-
-You MUST NOT:
-- Skip directly to \`/dino.ralph\` without gating
-- Start implementation without auditor approval
-- Proceed with ambiguity score > 0
-- Accept confidence < 95% for Ralph-eligible tasks
-
-## Three-Agent Requirement
-
-ALL THREE agents must execute in sequence:
-
-\`\`\`
-1. SCOUT (Research)     -> Deep exploration, pattern mining
-       |
-2. AUDITOR (Gatekeeper) -> 95% score, zero ambiguity required
-       |
-3. RALPH (Executor)     -> Only after GATE: APPROVED
-\`\`\`
-
-If auditor rejects, loop back to scout/clarification. Max 3 cycles.
-
-## Skill Invocation
-
-When trigger detected, use Skill tool:
-
-\`\`\`
-Skill: dino.ralph-gate
-\`\`\`
-
-Do NOT use regular \`/dino.ralph\` for complex tasks - always use \`/dino.ralph-gate\`.
-
-## Exception: Simple Ralph
-
-For tasks that:
-- Already have complete PRD with stories
-- Already went through spec with 90%+ confidence
-- User explicitly says "skip gate" or "already specified"
-
-You MAY use \`/dino.ralph\` directly, but MUST confirm with user first.
-
-## Audit Trail
-
-All Ralph Gate executions produce:
-- \`.dino/ralph-gate/research-report.md\`
-- \`.dino/ralph-gate/audit-report.md\`
-- \`.dino/ralph-gate/validated-prd.md\`
-
-These files provide accountability and can be reviewed.
+    return `# Ralph Loop Enforcement (dino-spec v${VERSION})
+
+## CRITICAL: Mandatory Ralph Gate
+
+When a user requests Ralph Loop or any complex multi-story task, you MUST use the \`/dino.ralph-gate\` skill. This is NOT optional.
+
+## Trigger Keywords (Case Insensitive)
+
+IMMEDIATELY invoke \`/dino.ralph-gate\` when user message contains:
+
+| Keyword | Example |
+|---------|---------|
+| "ralph loop" | "Start ralph loop for this feature" |
+| "ralph" | "Use ralph for this" |
+| "/dino.ralph" | "/dino.ralph" |
+| "fresh context" + "iteration" | "Use fresh context iterations" |
+| "multi-story" | "This is multi-story work" |
+| "three agent" | "Use three agent system" |
+| "gated implementation" | "I want gated implementation" |
+
+## Complexity Auto-Trigger
+
+ALSO invoke \`/dino.ralph-gate\` when task analysis shows:
+- Complexity score > 70
+- File count > 10
+- Distinct parts >= 3
+- Breaking changes + scope >= 15
+
+## Forbidden Bypass
+
+You MUST NOT:
+- Skip directly to \`/dino.ralph\` without gating
+- Start implementation without auditor approval
+- Proceed with ambiguity score > 0
+- Accept confidence < 95% for Ralph-eligible tasks
+
+## Three-Agent Requirement
+
+ALL THREE agents must execute in sequence:
+
+\`\`\`
+1. SCOUT (Research)     -> Deep exploration, pattern mining
+       |
+2. AUDITOR (Gatekeeper) -> 95% score, zero ambiguity required
+       |
+3. RALPH (Executor)     -> Only after GATE: APPROVED
+\`\`\`
+
+If auditor rejects, loop back to scout/clarification. Max 3 cycles.
+
+## Skill Invocation
+
+When trigger detected, use Skill tool:
+
+\`\`\`
+Skill: dino.ralph-gate
+\`\`\`
+
+Do NOT use regular \`/dino.ralph\` for complex tasks - always use \`/dino.ralph-gate\`.
+
+## Exception: Simple Ralph
+
+For tasks that:
+- Already have complete PRD with stories
+- Already went through spec with 90%+ confidence
+- User explicitly says "skip gate" or "already specified"
+
+You MAY use \`/dino.ralph\` directly, but MUST confirm with user first.
+
+## Audit Trail
+
+All Ralph Gate executions produce:
+- \`.dino/ralph-gate/research-report.md\`
+- \`.dino/ralph-gate/audit-report.md\`
+- \`.dino/ralph-gate/validated-prd.md\`
+
+These files provide accountability and can be reviewed.
 `;
 }
 /**
  * Generate smart tests rule content (v12.3.0)
  */
 function generateSmartTestsRule() {
-    return `# Smart Test Optimization (dino-spec v${VERSION})
-
-## Overview
-
-Smart test optimization reduces test run times by 60-80% during typical development workflows. The system tracks test state, maps files to related tests, and makes intelligent decisions about when to skip, run targeted, or run full test suites.
-
-## Test Scope Levels
-
-| Scope | When Used | Duration |
-|-------|-----------|----------|
-| **SKIP** | No changes since passing tests | 0s |
-| **TARGETED** | Changes isolated to single feature | 10-30s |
-| **FULL** | Cross-cutting or high-impact changes | < 3 min |
-
-## Decision Tree
-
-\`\`\`
-File Changed?
-    |
-    +- No changes since last passing tests -> SKIP
-    |
-    +- dependency/structural/config changes -> FULL
-    |   (package.json, tsconfig.json, index.ts, etc.)
-    |
-    +- src/utils/ or src/core/ shared code -> FULL
-    |
-    +- Only code/test changes in single feature -> TARGETED
-    |
-    +- Only documentation -> SKIP
-\`\`\`
-
-## Files That Always Trigger FULL Tests
-
-- \`package.json\`, \`package-lock.json\`, lock files
-- \`tsconfig.json\`, \`vitest.config.ts\`, config files
-- \`index.ts\`, \`main.ts\`, entry points
-- Files in \`src/utils/\`, \`src/core/\`, \`src/lib/\`, \`src/shared/\`
-
-## Targeted Test Patterns
-
-Extract from focus area or changed files:
-
-| Focus/Changes | Pattern |
-|---------------|---------|
-| \`src/hooks/\` | \`hooks\` |
-| \`src/core/test-optimization/\` | \`test-optimization\` |
-| \`src/commands/provider.ts\` | \`provider\` |
-| Multiple features | FULL (no pattern) |
-
-## Usage in Skills
-
-### \`/dino.aging\`
-Uses smart test workflow to analyze scope before running tests.
-
-### \`/dino.release\`
-Uses smart test detection to optimize release verification.
-
-### \`/dino.hunt\`
-Uses incremental testing during implementation.
-
-## Performance Targets
-
-| Scenario | Target Duration |
-|----------|-----------------|
-| SKIP (no changes) | 0s |
-| TARGETED (single feature) | 10-30s |
-| FULL (must run all) | < 3 min |
+    return `# Smart Test Optimization (dino-spec v${VERSION})
+
+## Overview
+
+Smart test optimization reduces test run times by 60-80% during typical development workflows. The system tracks test state, maps files to related tests, and makes intelligent decisions about when to skip, run targeted, or run full test suites.
+
+## Test Scope Levels
+
+| Scope | When Used | Duration |
+|-------|-----------|----------|
+| **SKIP** | No changes since passing tests | 0s |
+| **TARGETED** | Changes isolated to single feature | 10-30s |
+| **FULL** | Cross-cutting or high-impact changes | < 3 min |
+
+## Decision Tree
+
+\`\`\`
+File Changed?
+    |
+    +- No changes since last passing tests -> SKIP
+    |
+    +- dependency/structural/config changes -> FULL
+    |   (package.json, tsconfig.json, index.ts, etc.)
+    |
+    +- src/utils/ or src/core/ shared code -> FULL
+    |
+    +- Only code/test changes in single feature -> TARGETED
+    |
+    +- Only documentation -> SKIP
+\`\`\`
+
+## Files That Always Trigger FULL Tests
+
+- \`package.json\`, \`package-lock.json\`, lock files
+- \`tsconfig.json\`, \`vitest.config.ts\`, config files
+- \`index.ts\`, \`main.ts\`, entry points
+- Files in \`src/utils/\`, \`src/core/\`, \`src/lib/\`, \`src/shared/\`
+
+## Targeted Test Patterns
+
+Extract from focus area or changed files:
+
+| Focus/Changes | Pattern |
+|---------------|---------|
+| \`src/hooks/\` | \`hooks\` |
+| \`src/core/test-optimization/\` | \`test-optimization\` |
+| \`src/commands/provider.ts\` | \`provider\` |
+| Multiple features | FULL (no pattern) |
+
+## Usage in Skills
+
+### \`/dino.aging\`
+Uses smart test workflow to analyze scope before running tests.
+
+### \`/dino.release\`
+Uses smart test detection to optimize release verification.
+
+### \`/dino.hunt\`
+Uses incremental testing during implementation.
+
+## Performance Targets
+
+| Scenario | Target Duration |
+|----------|-----------------|
+| SKIP (no changes) | 0s |
+| TARGETED (single feature) | 10-30s |
+| FULL (must run all) | < 3 min |
 `;
 }
 /**
  * Generate skill patterns rule content
  */
 function generateSkillPatternsRule() {
-    return `# Skill Patterns (dino-spec v${VERSION})
-
-## v13.1.0 Three-Agent Ralph Gate System
-
-New enforced Ralph Loop workflow with strict gating:
-
-| Skill | Agent Role | Description |
-|-------|------------|-------------|
-| \`/dino.ralph-gate\` | Orchestrator | Coordinates all three agents |
-| \`/dino.audit\` | Gatekeeper | Blocks until 95% score, zero ambiguity |
-| \`/dino.ralph\` | Executor | Only runs after gate approval |
-
-**Flow:** Scout -> Auditor -> Ralph (enforced sequence)
-
-See \`ralph-enforcement.md\` for trigger keywords.
-
-## v12.0.0 Skill Consolidation
-
-Several skills have been merged to reduce context overhead:
-
-| Old Skill | New Location | Usage |
-|-----------|-------------|-------|
-| \`/dino.next\` | \`/dino.status --next\` | Get next step suggestions |
-| \`/context-optimize\` | \`/dino.status --tips\` | Context optimization tips |
-| \`/dino.focus\` | \`/dino.status --focus\` | Set focus area |
-| \`/dino-statusline\` | HUD plugin | Use \`dino hud install\` |
-
-## Argument Shorthand
-
-Skills can accept positional arguments using shorthand:
-- \`$0\` - First argument
-- \`$1\` - Second argument
-- \`$ARGUMENTS[N]\` - Bracket syntax (equivalent)
-
-**Example:** \`/dino.status --focus src/core/\` passes focus to status
-
-## Frontmatter Fields
-
-| Field | Required | Values | Description |
-|-------|----------|--------|-------------|
-| description | Yes | string | One-line description |
-| model | Yes | haiku, sonnet, opus | Model to use |
-| effort | Yes | low, medium, high | Thinking budget |
-| context | Yes | inherit, fork | Context handling |
-| allowed-tools | Yes | Tool list | Permitted tools |
-| auto-approve | No | true | Skip permission prompts |
-
-## Context Handling
-
-| Value | Behavior |
-|-------|----------|
-| inherit | Continues in current context |
-| fork | Creates isolated sub-context |
-
-Use \`fork\` for:
-- Research tasks that accumulate context
-- Long-running operations
-- Tasks that might pollute main context
-
-## Model Selection by Effort
-
-| Effort | Model | Typical Use |
-|--------|-------|-------------|
-| low | haiku | Status checks, lookups |
-| medium | sonnet | Implementation, testing |
-| high | opus | Planning, architecture |
-
-## Example Skill Frontmatter
-
-\`\`\`yaml
----
-description: Quick reference for context optimization
-model: haiku
-effort: low
-context: inherit
-allowed-tools:
-  - Read
-auto-approve: true
----
-\`\`\`
-
-## Auto-Approval
-
-Skills marked with \`auto-approve: true\` run without permission prompts. This improves UX for read-only operations.
-
-### Qualifying Skills
-
-| Skill | Tools Used | Status |
-|-------|------------|--------|
-| \`/dino.sniff\` | Read, AskUserQuestion | Auto-approved |
-
-### Non-Qualifying Skills
-
-| Skill | Disqualifying Tool | Reason |
-|-------|-------------------|--------|
-| \`/dino.status\` | Bash | Git commands |
-| \`/dino.handoff\` | Bash | Git/file operations |
-| \`/dino.hunt\` | Edit, Write, Bash | Implementation |
-| \`/dino.fossil\` | Write | Archive updates |
-| \`/dino.ralph-gate\` | Write, Task | Orchestration, file writes |
-| \`/dino.ralph\` | Edit, Write, Bash | Implementation |
-
-### Qualifying Skills (Read-Only)
-
-| Skill | Tools Used | Status |
-|-------|------------|--------|
-| \`/dino.sniff\` | Read, AskUserQuestion | Auto-approved |
-| \`/dino.audit\` | Read, Grep, Glob, AskUserQuestion | Auto-approved |
-
-### Requirements for Auto-Approval
-
-A skill qualifies for \`auto-approve: true\` when:
-
-1. **No Bash tool** - Shell commands could have side effects
-2. **No Edit tool** - Modifying files requires approval
-3. **No Write tool** - Creating files requires approval
-4. **No NotebookEdit** - Notebook changes require approval
-
-### Allowed Tools for Auto-Approval
-
-- \`Read\` - Reading files
-- \`Glob\` - Finding files
-- \`Grep\` - Searching file contents
-- \`WebFetch\` - Fetching web content
-- \`WebSearch\` - Searching the web
-- \`Task\` (read-only subagents)
-- MCP tools (read-only)
-
-### Security Considerations
-
-Auto-approval is safe because:
-- Read-only operations cannot modify system state
-- No shell execution means no command injection risk
-- File system remains unchanged
-- Network operations are read-only (fetch, search)
-
-Users can still configure hooks to intercept any skill invocation regardless of auto-approval status.
+    return `# Skill Patterns (dino-spec v${VERSION})
+
+## v13.1.0 Three-Agent Ralph Gate System
+
+New enforced Ralph Loop workflow with strict gating:
+
+| Skill | Agent Role | Description |
+|-------|------------|-------------|
+| \`/dino.ralph-gate\` | Orchestrator | Coordinates all three agents |
+| \`/dino.audit\` | Gatekeeper | Blocks until 95% score, zero ambiguity |
+| \`/dino.ralph\` | Executor | Only runs after gate approval |
+
+**Flow:** Scout -> Auditor -> Ralph (enforced sequence)
+
+See \`ralph-enforcement.md\` for trigger keywords.
+
+## v12.0.0 Skill Consolidation
+
+Several skills have been merged to reduce context overhead:
+
+| Old Skill | New Location | Usage |
+|-----------|-------------|-------|
+| \`/dino.next\` | \`/dino.status --next\` | Get next step suggestions |
+| \`/context-optimize\` | \`/dino.status --tips\` | Context optimization tips |
+| \`/dino.focus\` | \`/dino.status --focus\` | Set focus area |
+| \`/dino-statusline\` | HUD plugin | Use \`dino hud install\` |
+
+## Argument Shorthand
+
+Skills can accept positional arguments using shorthand:
+- \`$0\` - First argument
+- \`$1\` - Second argument
+- \`$ARGUMENTS[N]\` - Bracket syntax (equivalent)
+
+**Example:** \`/dino.status --focus src/core/\` passes focus to status
+
+## Frontmatter Fields
+
+| Field | Required | Values | Description |
+|-------|----------|--------|-------------|
+| description | Yes | string | One-line description |
+| model | Yes | haiku, sonnet, opus | Model to use |
+| effort | Yes | low, medium, high | Thinking budget |
+| context | Yes | inherit, fork | Context handling |
+| allowed-tools | Yes | Tool list | Permitted tools |
+| auto-approve | No | true | Skip permission prompts |
+
+## Context Handling
+
+| Value | Behavior |
+|-------|----------|
+| inherit | Continues in current context |
+| fork | Creates isolated sub-context |
+
+Use \`fork\` for:
+- Research tasks that accumulate context
+- Long-running operations
+- Tasks that might pollute main context
+
+## Model Selection by Effort
+
+| Effort | Model | Typical Use |
+|--------|-------|-------------|
+| low | haiku | Status checks, lookups |
+| medium | sonnet | Implementation, testing |
+| high | opus | Planning, architecture |
+
+## Example Skill Frontmatter
+
+\`\`\`yaml
+---
+description: Quick reference for context optimization
+model: haiku
+effort: low
+context: inherit
+allowed-tools:
+  - Read
+auto-approve: true
+---
+\`\`\`
+
+## Auto-Approval
+
+Skills marked with \`auto-approve: true\` run without permission prompts. This improves UX for read-only operations.
+
+### Qualifying Skills
+
+| Skill | Tools Used | Status |
+|-------|------------|--------|
+| \`/dino.sniff\` | Read, AskUserQuestion | Auto-approved |
+
+### Non-Qualifying Skills
+
+| Skill | Disqualifying Tool | Reason |
+|-------|-------------------|--------|
+| \`/dino.status\` | Bash | Git commands |
+| \`/dino.handoff\` | Bash | Git/file operations |
+| \`/dino.hunt\` | Edit, Write, Bash | Implementation |
+| \`/dino.fossil\` | Write | Archive updates |
+| \`/dino.ralph-gate\` | Write, Task | Orchestration, file writes |
+| \`/dino.ralph\` | Edit, Write, Bash | Implementation |
+
+### Qualifying Skills (Read-Only)
+
+| Skill | Tools Used | Status |
+|-------|------------|--------|
+| \`/dino.sniff\` | Read, AskUserQuestion | Auto-approved |
+| \`/dino.audit\` | Read, Grep, Glob, AskUserQuestion | Auto-approved |
+
+### Requirements for Auto-Approval
+
+A skill qualifies for \`auto-approve: true\` when:
+
+1. **No Bash tool** - Shell commands could have side effects
+2. **No Edit tool** - Modifying files requires approval
+3. **No Write tool** - Creating files requires approval
+4. **No NotebookEdit** - Notebook changes require approval
+
+### Allowed Tools for Auto-Approval
+
+- \`Read\` - Reading files
+- \`Glob\` - Finding files
+- \`Grep\` - Searching file contents
+- \`WebFetch\` - Fetching web content
+- \`WebSearch\` - Searching the web
+- \`Task\` (read-only subagents)
+- MCP tools (read-only)
+
+### Security Considerations
+
+Auto-approval is safe because:
+- Read-only operations cannot modify system state
+- No shell execution means no command injection risk
+- File system remains unchanged
+- Network operations are read-only (fetch, search)
+
+Users can still configure hooks to intercept any skill invocation regardless of auto-approval status.
 `;
 }
 /**
  * Generate spec-kit rule content
  */
 function generateSpecKitRule() {
-    return `# Spec-Kit Auto-Specification (dino-spec v${VERSION})
-
-## Overview
-
-The \`/dino.spec\` skill provides intelligent prompt analysis and requirement clarification before implementation begins.
-
-## Auto-Trigger Conditions
-
-Spec-kit auto-triggers when:
-- Ambiguity score > 40 (vague verbs, missing details, unclear success)
-- User request involves implementation ("add", "create", "implement", "build", "fix")
-
-Spec-kit does NOT trigger for:
-- Status checks (\`/dino.status\`)
-- Simple queries ("what does X do?")
-- Explicit skip (\`--skip-spec\` or complexity < 30 with ambiguity < 20)
-
-## Modes
-
-| Mode | When | Behavior |
-|------|------|----------|
-| **Skip** | complexity < 30, ambiguity < 20 | Proceed directly to implementation |
-| **Lightweight** | complexity < 30, ambiguity >= 20 | Quick validation, one confirmation |
-| **Full** | complexity >= 30 | Thorough analysis with research/questions |
-
-## Confidence Gate
-
-Implementation is BLOCKED until:
-- Confidence reaches 80%
-- OR user explicitly validates assumptions after 5 question rounds
-
-## Multi-Part Request Handling
-
-When multiple requests detected ("add X and also Y"):
-1. Split into discrete tasks
-2. Present recommended order (quick wins first, foundational second)
-3. Analyze first task only
-4. Queue remaining tasks
-
-## Context Awareness
-
-Spec-kit checks existing session context:
-- If active focus exists: "Is this related to [focus]?"
-- If related: Build on context, skip redundant questions
-- If unrelated: Fresh analysis
-
-## Output Location
-
-Results written to \`.dino/session.md\` under \`## Spec-Kit Analysis\`
-
-## Recommended Flow
-
-\`\`\`
-User Request
-     ↓
-[ambiguity > 40?] ──no──→ Proceed to /dino.hunt
-     ↓ yes
-/dino.spec (auto)
-     ↓
-[confidence >= 80%?] ──no──→ More questions (max 5 rounds)
-     ↓ yes
-[complexity > 60?]
-     ↓ yes           ↓ no
-/dino.nest      /dino.hunt
-\`\`\`
-
-## Manual Invocation
-
-Always available via \`/dino.spec\` for:
-- Explicit thorough analysis
-- Complex features that need planning
-- When unsure about requirements
+    return `# Spec-Kit Auto-Specification (dino-spec v${VERSION})
+
+## Overview
+
+The \`/dino.spec\` skill provides intelligent prompt analysis and requirement clarification before implementation begins.
+
+## Auto-Trigger Conditions
+
+Spec-kit auto-triggers when:
+- Ambiguity score > 40 (vague verbs, missing details, unclear success)
+- User request involves implementation ("add", "create", "implement", "build", "fix")
+
+Spec-kit does NOT trigger for:
+- Status checks (\`/dino.status\`)
+- Simple queries ("what does X do?")
+- Explicit skip (\`--skip-spec\` or complexity < 30 with ambiguity < 20)
+
+## Modes
+
+| Mode | When | Behavior |
+|------|------|----------|
+| **Skip** | complexity < 30, ambiguity < 20 | Proceed directly to implementation |
+| **Lightweight** | complexity < 30, ambiguity >= 20 | Quick validation, one confirmation |
+| **Full** | complexity >= 30 | Thorough analysis with research/questions |
+
+## Confidence Gate
+
+Implementation is BLOCKED until:
+- Confidence reaches 80%
+- OR user explicitly validates assumptions after 5 question rounds
+
+## Multi-Part Request Handling
+
+When multiple requests detected ("add X and also Y"):
+1. Split into discrete tasks
+2. Present recommended order (quick wins first, foundational second)
+3. Analyze first task only
+4. Queue remaining tasks
+
+## Context Awareness
+
+Spec-kit checks existing session context:
+- If active focus exists: "Is this related to [focus]?"
+- If related: Build on context, skip redundant questions
+- If unrelated: Fresh analysis
+
+## Output Location
+
+Results written to \`.dino/session.md\` under \`## Spec-Kit Analysis\`
+
+## Recommended Flow
+
+\`\`\`
+User Request
+     ↓
+[ambiguity > 40?] ──no──→ Proceed to /dino.hunt
+     ↓ yes
+/dino.spec (auto)
+     ↓
+[confidence >= 80%?] ──no──→ More questions (max 5 rounds)
+     ↓ yes
+[complexity > 60?]
+     ↓ yes           ↓ no
+/dino.nest      /dino.hunt
+\`\`\`
+
+## Manual Invocation
+
+Always available via \`/dino.spec\` for:
+- Explicit thorough analysis
+- Complex features that need planning
+- When unsure about requirements
 `;
 }
 /**
  * Generate standard paths rule content
  */
 function generateStandardPathsRule() {
-    return `# Standard Paths (dino-spec v${VERSION})
-
-## CRITICAL: Always Use These Paths
-
-When creating or reading dino-spec files, you MUST use these standard paths:
-
-### Session State
-| Purpose | Path | Notes |
-|---------|------|-------|
-| Session state | \`.dino/session.md\` | Live session, auto-updated |
-| Config | \`.dino/config.json\` | Settings and features |
-| Structure | \`.dino/structure.json\` | Cached project analysis |
-
-### Working Files
-| Purpose | Path | Notes |
-|---------|------|-------|
-| Research | \`.dino/research/<topic-slug>.md\` | Research findings |
-| Handoffs | \`.dino/handoff/latest.md\` | Session handoff notes |
-| Plans | \`.dino/plans/active.json\` | Active implementation plan |
-| Tasks | \`.dino/tasks/\` | Task registry |
-| Checkpoints | \`.dino/checkpoints/\` | Git checkpoints |
-
-### Archive (Historical)
-| Purpose | Path | Notes |
-|---------|------|-------|
-| Old handoffs | \`.dino/archive/handoffs/\` | Completed handoffs |
-| Old sessions | \`.dino/archive/\` | Archived sessions |
-
-## Rules
-
-1. **NEVER create new top-level directories in \`.dino/\`** - Use existing paths
-2. **ALWAYS check if file exists** before creating a new one
-3. **Research files go in \`.dino/research/\`** - not root, not \`.claude/docs/\`
-4. **Handoff context goes in \`.dino/handoff/\`** - singular, not handoffs
-5. **Plans go in \`.dino/plans/\`** - with \`active.json\` for current plan
+    return `# Standard Paths (dino-spec v${VERSION})
+
+## CRITICAL: Always Use These Paths
+
+When creating or reading dino-spec files, you MUST use these standard paths:
+
+### Session State
+| Purpose | Path | Notes |
+|---------|------|-------|
+| Session state | \`.dino/session.md\` | Live session, auto-updated |
+| Config | \`.dino/config.json\` | Settings and features |
+| Structure | \`.dino/structure.json\` | Cached project analysis |
+
+### Working Files
+| Purpose | Path | Notes |
+|---------|------|-------|
+| Research | \`.dino/research/<topic-slug>.md\` | Research findings |
+| Handoffs | \`.dino/handoff/latest.md\` | Session handoff notes |
+| Plans | \`.dino/plans/active.json\` | Active implementation plan |
+| Tasks | \`.dino/tasks/\` | Task registry |
+| Checkpoints | \`.dino/checkpoints/\` | Git checkpoints |
+
+### Archive (Historical)
+| Purpose | Path | Notes |
+|---------|------|-------|
+| Old handoffs | \`.dino/archive/handoffs/\` | Completed handoffs |
+| Old sessions | \`.dino/archive/\` | Archived sessions |
+
+## Rules
+
+1. **NEVER create new top-level directories in \`.dino/\`** - Use existing paths
+2. **ALWAYS check if file exists** before creating a new one
+3. **Research files go in \`.dino/research/\`** - not root, not \`.claude/docs/\`
+4. **Handoff context goes in \`.dino/handoff/\`** - singular, not handoffs
+5. **Plans go in \`.dino/plans/\`** - with \`active.json\` for current plan
 `;
 }
 /**
  * Generate change categories rule content
  */
 function generateChangeCategoriesRule() {
-    return `# Change Categories (dino-spec v${VERSION})
-
-## File Classification
-
-Files are classified into categories based on path and name:
-
-### dependency (High Significance)
-Files that affect project dependencies:
-- \`package.json\`, \`package-lock.json\`, \`yarn.lock\`, \`pnpm-lock.yaml\`
-- \`requirements.txt\`, \`Pipfile\`, \`pyproject.toml\`
-- \`Cargo.toml\`, \`Cargo.lock\`
-- \`go.mod\`, \`go.sum\`
-- \`Gemfile\`, \`Gemfile.lock\`
-
-**Pending Action:** Run package manager install command
-
-### structural (High Significance)
-Files that affect project structure:
-- Entry points: \`index.ts\`, \`main.ts\`, \`app.ts\`
-- Configuration: \`tsconfig.json\`, \`webpack.config.js\`
-- Build configs: \`build.js\`, \`vite.config.ts\`
-- Directory additions/removals
-
-**Pending Action:** Verify import paths
-
-### config (Medium Significance)
-Configuration files:
-- \`.env\`, \`.env.*\`
-- \`*.config.js\`, \`*.config.ts\`
-- \`.eslintrc\`, \`.prettierrc\`
-- CI/CD files: \`.github/\`, \`.gitlab-ci.yml\`
-
-### test (Medium Significance)
-Test files:
-- \`*.test.ts\`, \`*.test.js\`
-- \`*.spec.ts\`, \`*.spec.js\`
-- \`test/\`, \`tests/\`, \`__tests__/\` directories
-
-### code (Low Significance)
-Source code files:
-- \`src/\`, \`lib/\` directories
-- Main programming language files
-- Utility and helper files
-
-### documentation (Low Significance)
-Documentation files:
-- \`*.md\`, \`README*\`
-- \`docs/\` directory
-- Code comments (when detected)
-
-## Impact on Workflow
-
-| Category | Run Tests | Run Build | Review |
-|----------|-----------|-----------|--------|
-| dependency | After install | Yes | Changelog |
-| structural | Yes | Yes | Imports |
-| config | Maybe | Maybe | Side effects |
-| test | Yes | No | Coverage |
-| code | Yes | Yes | Normal |
-| documentation | No | No | Spelling |
+    return `# Change Categories (dino-spec v${VERSION})
+
+## File Classification
+
+Files are classified into categories based on path and name:
+
+### dependency (High Significance)
+Files that affect project dependencies:
+- \`package.json\`, \`package-lock.json\`, \`yarn.lock\`, \`pnpm-lock.yaml\`
+- \`requirements.txt\`, \`Pipfile\`, \`pyproject.toml\`
+- \`Cargo.toml\`, \`Cargo.lock\`
+- \`go.mod\`, \`go.sum\`
+- \`Gemfile\`, \`Gemfile.lock\`
+
+**Pending Action:** Run package manager install command
+
+### structural (High Significance)
+Files that affect project structure:
+- Entry points: \`index.ts\`, \`main.ts\`, \`app.ts\`
+- Configuration: \`tsconfig.json\`, \`webpack.config.js\`
+- Build configs: \`build.js\`, \`vite.config.ts\`
+- Directory additions/removals
+
+**Pending Action:** Verify import paths
+
+### config (Medium Significance)
+Configuration files:
+- \`.env\`, \`.env.*\`
+- \`*.config.js\`, \`*.config.ts\`
+- \`.eslintrc\`, \`.prettierrc\`
+- CI/CD files: \`.github/\`, \`.gitlab-ci.yml\`
+
+### test (Medium Significance)
+Test files:
+- \`*.test.ts\`, \`*.test.js\`
+- \`*.spec.ts\`, \`*.spec.js\`
+- \`test/\`, \`tests/\`, \`__tests__/\` directories
+
+### code (Low Significance)
+Source code files:
+- \`src/\`, \`lib/\` directories
+- Main programming language files
+- Utility and helper files
+
+### documentation (Low Significance)
+Documentation files:
+- \`*.md\`, \`README*\`
+- \`docs/\` directory
+- Code comments (when detected)
+
+## Impact on Workflow
+
+| Category | Run Tests | Run Build | Review |
+|----------|-----------|-----------|--------|
+| dependency | After install | Yes | Changelog |
+| structural | Yes | Yes | Imports |
+| config | Maybe | Maybe | Side effects |
+| test | Yes | No | Coverage |
+| code | Yes | Yes | Normal |
+| documentation | No | No | Spelling |
 `;
 }
 /**