Speckit Orchestrator

Table of Contents

• Overview
• Persistent Presence Lens
• When to Use
• Core Workflow
• Session Initialization
• Command-Skill Matrix
• Progress Tracking Items
• Exit Criteria
• Related Skills

Speckit Orchestrator

Overview

Coordinates the Spec Driven Development workflow, skill loading, and progress tracking throughout the command lifecycle.

Persistent Presence Lens

Treat SDD as a minimal, testable "self-modeling" loop:

• World model: repo + speckit artifacts (spec.md, plan.md, tasks.md)
• Agent model: loaded skills/plugins + constraints (especially .specify/memory/constitution.md) + progress state

This mirrors patterns from open-ended embodied agents (e.g., Voyager/MineDojo) that compound capability via a curriculum (tasks.md) and a skill library (reusable plugin skills and superpowers methodology skills).

When To Use

• Starting any /speckit-* command.
• Coordinating multi-phase development workflows.
• Tracking progress across specification, planning, and implementation.
• Ensuring skill dependencies are loaded.

When NOT To Use

• Single-phase work (just specify, or just plan)
• Non-spec-driven projects

Core Workflow

Session Initialization

1. Verify Repository Context

• Confirm working directory is a speckit-enabled project.
• Check for .specify/ directory structure.
• Validate required scripts exist.

2. Load Persistent State ("presence")

• Read .specify/memory/constitution.md for constraints/principles.
• Load current spec.md / plan.md / tasks.md context if present.

3. Load Command Dependencies

• Match current command to required skills.
• Load complementary superpowers skills.

4. Initialize Progress Tracking

• Create TodoWrite items for workflow phases.
• Track completion status.

Command-Skill Matrix

Quick reference for command-to-skill mappings:

For detailed patterns: See modules/command-skill-matrix.md for complete mappings and loading rules.

See modules/writing-plans-extensions.md for plan authoring patterns.

Progress Tracking Items

For each workflow session, track:

• [ ] Repository context verified.
• [ ] Prerequisites validated.
• [ ] Command-specific skills loaded.
• [ ] Artifacts created/updated.
• [ ] Verification completed.

For detailed patterns: See modules/progress-tracking.md for TodoWrite patterns and metrics.

Exit Criteria

• Active command completed successfully.
• All required artifacts exist and are valid.
• Progress tracking reflects current state.
• No unresolved blockers.

Related Skills

• spec-writing: Specification creation and refinement.
• task-planning: Task generation and planning.
• superpowers:brainstorming: Idea refinement.
• superpowers:writing-plans: Implementation planning.
• superpowers:executing-plans: Task execution.

Spec-Kit Artifact Structure

Overview

Spec-kit uses a step-by-step approach to organizing specification, planning, and implementation artifacts. This document defines the purpose and structure of each artifact type.

Directory Structure

project-root/
├── .specify/                    # Spec-kit infrastructure
│   ├── scripts/                 # Workflow automation scripts
│   ├── templates/               # Artifact templates
│   └── memory/                  # Project context and constitution
│
└── specs/                       # Feature specifications
    └── {N}-{short-name}/        # Feature directory
        ├── spec.md              # What & Why (user-focused)
        ├── plan.md              # How (technical design)
        ├── tasks.md             # Implementation tasks
        ├── checklists/          # Quality validation checklists
        │   ├── requirements.md  # Spec quality validation
        │   ├── ux.md           # UX requirements validation
        │   ├── api.md          # API requirements validation
        │   └── security.md     # Security requirements validation
        ├── research.md          # Technical research & decisions
        ├── data-model.md        # Entity definitions
        ├── quickstart.md        # Test scenarios
        └── contracts/           # API contracts
            ├── openapi.yaml
            └── graphql/

Note: Claude Code Plan Mode Namespace

>

Claude Code's native Plan Mode (v2.0.51+) creates a plan.md file at the

project root when users enter plan mode via Shift+Tab or --permission-mode plan.

Spec-kit plans are intentionally stored in specs/{feature}/plan.md to avoid

collision. When searching for scope artifacts:

1. Always check specs/*/plan.md first (spec-kit feature plans)

2. Then check root plan.md (may be Claude Plan Mode artifact)

>

The two systems are complementary: Claude Plan Mode is for exploratory planning,

while spec-kit plans are structured implementation blueprints.

Core Artifacts

spec.md - Feature Specification

Purpose: Define WHAT users need and WHY, without implementation details.

Audience: Business stakeholders, product managers, non-technical reviewers.

Structure:

# Feature Name

## Overview
- Problem statement
- User value proposition

## User Scenarios
- Who uses it
- Primary flows
- User goals

## Functional Requirements
- What must it do (testable)
- Acceptance criteria

## Success Criteria
- Measurable outcomes
- Technology-agnostic metrics
- User-facing goals

## Success Criteria (Optional)
- Performance expectations
- Security considerations
- Accessibility needs

## Edge Cases (Optional)
- Boundary conditions
- Error scenarios
- Fallback behaviors

## Dependencies & Assumptions (Optional)
- External dependencies
- Documented assumptions

Key Principles:

• No technology choices (no "React", "PostgreSQL", "REST API")
• Focus on user value, not system internals
• Measurable, testable requirements
• Maximum 3 [NEEDS CLARIFICATION] markers

plan.md - Implementation Plan

Purpose: Define HOW to build the feature technically.

Audience: Developers, technical leads, architects.

Structure:

# Implementation Plan: Feature Name

## Technical Context
- Tech stack decisions
- Architecture choices
- Libraries and frameworks

## Constitution Check
- Alignment with project principles
- Gate evaluation

## Phase 0: Research
- Technical unknowns
- Best practices research
- Decision rationale

## Phase 1: Design
- Data model
- API contracts
- Integration points

## Phase 2: Implementation
- Component structure
- Service layer
- Infrastructure needs

Key Principles:

• Technology-specific
• Includes research and decisions
• Maps to project constitution
• Generates tasks.md

tasks.md - Implementation Tasks

Purpose: Concrete, dependency-ordered tasks for implementation.

Audience: Developers executing the feature.

Structure:

# Implementation Tasks: Feature Name

## Overview
- Total tasks
- Parallelization opportunities
- MVP scope

## Dependencies
- User story completion order
- Blocking prerequisites

## Phase 1: Setup
- [ ] T001 Project initialization
- [ ] T002 [P] Configure tooling

## Phase 2: Foundational
- [ ] T010 Shared infrastructure

## Phase 3: User Story 1 (P1)
- [ ] T020 [US1] Model creation
- [ ] T021 [P] [US1] Service implementation
- [ ] T022 [US1] Endpoint implementation

## Phase 4: User Story 2 (P2)
- [ ] T030 [US2] Feature implementation

## Final Phase: Polish
- [ ] T090 Cross-cutting concerns
- [ ] T091 Documentation

Task Format:

- [ ] [TaskID] [P?] [Story?] Description with file path

Key Principles:

• Organized by user story
• Sequential task IDs
• Clear parallelization markers [P]
• Story labels [US1], [US2], etc.
• Explicit file paths

checklists/ - Quality Validation

Purpose: "Unit tests for requirements" - validate requirement quality.

Audience: Spec authors, reviewers, QA.

Structure: Multiple domain-specific checklists:

• requirements.md - Overall spec quality
• ux.md - UX requirements validation
• api.md - API requirements validation
• security.md - Security requirements validation
• performance.md - Performance requirements validation

Checklist Item Format:

- [ ] CHK001 Are [requirements] defined for [scenario]? [Dimension, Reference]

Key Principles:

• Test requirements quality, NOT implementation
• Focus on completeness, clarity, consistency
• ≥80% traceability to spec sections
• Question format, not verification statements

Supporting Artifacts

research.md

Documents technical research, decisions, and alternatives considered during Phase 0.

data-model.md

Defines entities, fields, relationships, validation rules, and state transitions.

quickstart.md

Test scenarios and acceptance testing guides for the feature.

contracts/

API contracts (OpenAPI, GraphQL schemas) generated from functional requirements.

Workflow Progression

1. Specify: Create spec.md (user-focused, no tech) 2. Clarify: Resolve [NEEDS CLARIFICATION] markers 3. Checklist: Validate spec quality with requirements.md checklist 4. Plan: Create plan.md (technical design) 5. Tasks: Generate tasks.md (concrete implementation) 6. Implement: Execute tasks, mark complete 7. Validate: Domain-specific checklists (ux.md, api.md, etc.)

Artifact Relationships

spec.md (WHAT/WHY)
    ↓
checklists/requirements.md (validate spec)
    ↓
plan.md (HOW)
    ↓
tasks.md (DO)
    ↓
checklists/[domain].md (validate implementation requirements)

Usage in Commands

• /speckit-specify → Creates spec.md, checklists/requirements.md
• /speckit-clarify → Resolves [NEEDS CLARIFICATION] in spec.md
• /speckit-plan → Creates plan.md, research.md, data-model.md, contracts/
• /speckit-tasks → Generates tasks.md from plan.md + spec.md
• /speckit-checklist → Creates domain-specific checklists (ux.md, api.md, etc.)
• /speckit-implement → Executes tasks.md
• /speckit-analyze → Cross-artifact consistency validation

Command-Skill Matrix

Overview

The Command-Skill Matrix defines which skills are required for each speckit command, ensuring proper dependencies are loaded and coordinated throughout the workflow.

Complete Mapping

Specification Phase

`/speckit-specify`

• Primary Skill: spec-writing
• Complementary Skills: superpowers:brainstorming
• Loading Order: brainstorming → spec-writing
• When to Load: At command start, before any specification work
• Purpose: Create or refine feature specifications with collaborative ideation

`/speckit-clarify`

• Primary Skill: spec-writing
• Complementary Skills: superpowers:brainstorming
• Loading Order: brainstorming → spec-writing
• When to Load: When specification needs refinement or has gaps
• Purpose: Identify underspecified areas and encode clarifications

`/speckit-constitution`

• Primary Skill: spec-writing
• Complementary Skills: None required
• Loading Order: spec-writing only
• When to Load: Creating or updating project principles
• Purpose: Establish project governance and design principles

Planning Phase

`/speckit-plan`

• Primary Skill: task-planning
• Complementary Skills: superpowers:writing-plans
• Loading Order: task-planning → writing-plans
• When to Load: After specification is complete
• Purpose: Generate detailed implementation design artifacts

`/speckit-tasks`

• Primary Skill: task-planning
• Complementary Skills: superpowers:executing-plans
• Loading Order: task-planning → executing-plans
• When to Load: After planning artifacts exist
• Purpose: Generate dependency-ordered implementation tasks

Implementation Phase

`/speckit-implement`

• Primary Skill: None (uses loaded plan)
• Complementary Skills: superpowers:executing-plans, superpowers:systematic-debugging
• Loading Order: executing-plans → systematic-debugging (on-demand)
• When to Load: When executing tasks from tasks.md
• Purpose: Execute implementation tasks with error handling

Verification Phase

`/speckit-analyze`

• Primary Skill: None (analysis only)
• Complementary Skills: superpowers:systematic-debugging, superpowers:verification-before-completion
• Loading Order: Load both at analysis start
• When to Load: After task generation or implementation
• Purpose: Cross-artifact consistency and quality analysis

`/speckit-checklist`

• Primary Skill: None (generation only)
• Complementary Skills: superpowers:verification-before-completion
• Loading Order: verification-before-completion only
• When to Load: When generating feature-specific checklists
• Purpose: Create custom verification checklists

`/speckit-startup`

• Primary Skill: None (bootstrap only)
• Complementary Skills: None required
• Loading Order: N/A
• When to Load: Session initialization
• Purpose: Bootstrap workflow and verify environment

Skill Loading Priorities

High Priority (Always Load First)

1. spec-writing - For any specification work 2. task-planning - For any planning work

Medium Priority (Load After Primary)

3. superpowers:brainstorming - For ideation phases 4. superpowers:writing-plans - For detailed planning 5. superpowers:executing-plans - For implementation

Low Priority (Load On-Demand)

6. superpowers:systematic-debugging - When errors occur 7. superpowers:verification-before-completion - For final checks

Conditional Loading Rules

• Brainstorming: Only load if specification is new or incomplete
• Systematic Debugging: Only load if implementation encounters errors
• Verification: Only load for analyze/checklist commands or before completion
• Writing Plans: Only load if creating new implementation plans

Skill Interaction Patterns

Specification → Planning

• Specification skills complete → task-planning loads
• Hand off spec.md to planning phase

Planning → Implementation

• Planning skills complete → executing-plans loads
• Hand off tasks.md to implementation phase

Implementation → Verification

• Implementation errors → systematic-debugging loads
• Implementation complete → verification-before-completion loads

Progress Tracking

Overview

Defines TodoWrite item patterns and progress tracking strategies for speckit workflows. validates consistent status reporting and verification throughout all workflow phases.

TodoWrite Item Patterns

Universal Workflow Items

For every speckit command session:

- [ ] Verify repository context and .specify/ structure
- [ ] Validate prerequisites (scripts, dependencies, templates)
- [ ] Load command-specific skills
- [ ] Execute command workflow
- [ ] Verify artifacts created/updated
- [ ] Complete progress tracking

Specification Phase Items

`/speckit-specify`

- [ ] Load spec-writing and brainstorming skills
- [ ] Analyze feature description and requirements
- [ ] Generate/update spec.md with template
- [ ] Verify spec.md contains all required sections
- [ ] Validate frontmatter metadata

`/speckit-clarify`

- [ ] Read existing spec.md
- [ ] Identify underspecified areas
- [ ] Ask targeted clarification questions (max 5)
- [ ] Encode answers back into spec.md
- [ ] Verify improved specification completeness

`/speckit-constitution`

- [ ] Gather project principles (interactive or provided)
- [ ] Create/update constitution.md
- [ ] Sync dependent templates with constitution
- [ ] Verify template consistency

Planning Phase Items

`/speckit-plan`

- [ ] Load task-planning and writing-plans skills
- [ ] Read spec.md and constitution.md
- [ ] Execute planning template workflow
- [ ] Generate plan.md with design artifacts
- [ ] Verify plan completeness and consistency

`/speckit-tasks`

- [ ] Read all available design artifacts (spec, plan, constitution)
- [ ] Analyze dependencies and ordering constraints
- [ ] Generate tasks.md with concrete tasks
- [ ] Verify task ordering and completeness
- [ ] Mark tasks ready for implementation

Implementation Phase Items

`/speckit-implement`

- [ ] Load executing-plans skill
- [ ] Read and parse tasks.md
- [ ] Execute tasks in dependency order
- [ ] Track completion status per task
- [ ] Handle errors with systematic-debugging
- [ ] Verify all tasks completed successfully

Verification Phase Items

`/speckit-analyze`

- [ ] Read spec.md, plan.md, tasks.md
- [ ] Check cross-artifact consistency
- [ ] Identify quality issues
- [ ] Generate analysis report
- [ ] Provide concrete recommendations with evidence

`/speckit-checklist`

- [ ] Read feature requirements from spec.md
- [ ] Generate custom verification checklist
- [ ] Output checklist in markdown format
- [ ] Verify checklist completeness

Workflow Phase Tracking

Phase States

1. Not Started: Prerequisites not yet validated 2. In Progress: Command executing, artifacts being created 3. Blocked: Waiting for user input or error resolution 4. Completed: Artifacts created, verification passed 5. Failed: Unrecoverable error, manual intervention needed

Phase Transitions

Not Started → In Progress: When prerequisites validated
In Progress → Blocked: When user input or clarification needed
In Progress → Failed: When unrecoverable error occurs
In Progress → Completed: When all exit criteria met
Blocked → In Progress: When blocker resolved

Status Reporting

After each phase transition, report:

• Current phase and status
• Artifacts created/modified
• Outstanding blockers (if any)
• Next steps

Completion Verification Patterns

Specification Phase Verification

• [ ] spec.md exists and is valid markdown
• [ ] All required frontmatter fields present
• [ ] All template sections completed
• [ ] No placeholder text remains
• [ ] Acceptance criteria are testable

Planning Phase Verification

• [ ] plan.md exists and follows template
• [ ] Design decisions documented with rationale
• [ ] Architecture diagrams/descriptions present
• [ ] Technical approach is clear
• [ ] Risks and mitigations identified

Task Generation Verification

• [ ] tasks.md exists with concrete tasks
• [ ] Tasks are dependency-ordered
• [ ] Each task has clear completion criteria
• [ ] File paths and locations specified
• [ ] Verification steps included

Implementation Phase Verification

• [ ] All tasks in tasks.md completed
• [ ] Code compiles/runs successfully
• [ ] Tests pass (if applicable)
• [ ] No unresolved TODOs or FIXMEs
• [ ] Documentation updated

Cross-Artifact Verification

• [ ] spec.md requirements match plan.md design
• [ ] plan.md design matches tasks.md implementation
• [ ] tasks.md tasks align with spec.md acceptance criteria
• [ ] No conflicting information across artifacts
• [ ] Version/date metadata is consistent

Progress Persistence

Session Continuity

• Track progress in TodoWrite for current session
• Save state to artifacts (spec.md, plan.md, tasks.md)
• Use frontmatter metadata for phase tracking
• Enable /catchup recovery across sessions

Recovery Patterns

After Session Interruption: 1. Read artifact frontmatter to determine last phase 2. Check artifact completeness vs. expected state 3. Resume from last verified checkpoint 4. Re-validate prerequisites if needed

After Error: 1. Mark current phase as blocked 2. Document error and attempted solutions 3. Load systematic-debugging if needed 4. Clear blocker, then resume progress

Metrics and Reporting

Track Per Session

• Total workflow duration
• Time per phase
• Number of iterations (clarify, refactor)
• Artifact sizes (lines, tokens)
• User interactions required

Quality Metrics

• Specification completeness score
• Plan-spec alignment score
• Task-plan alignment score
• Cross-artifact consistency score

Writing-Plans Extensions for Spec-kit

Overview

This document defines the extensions that spec-kit provides to enhance the superpowers:writing-plans skill with specification-driven artifact management, quality validation, and workflow integration.

Extension Categories

1. Artifact Management Extensions

Artifact Lifecycle Management

class ArtifactManager:
    def track_artifact_lifecycle(self, artifact_path: str) -> ArtifactStatus
    def validate_artifact_consistency(self, artifacts: List[str]) -> ConsistencyReport
    def generate_artifact_summary(self, phase: str) -> ArtifactSummary
    def detect_artifact_changes(self, since_timestamp: datetime) -> ChangeReport

Specification-Driven Artifact Generation

• Templates: Use spec-kit templates for consistent artifact structure
• Cross-References: Maintain bidirectional links between artifacts
• Version Control: Track artifact versions and changes
• Quality Gates: Apply spec-kit quality validation to all artifacts

Artifact Types Managed

1. spec.md - Feature specifications with user stories 2. plan.md - Implementation plans with tech decisions 3. data-model.md - Entity relationships and validation 4. contracts/ - API specifications and schemas 5. research.md - Technical decisions and rationale 6. tasks.md - Dependency-ordered implementation tasks 7. checklists/ - Quality validation checklists

2. Quality Validation Extensions

Specification-Driven Quality Gates

class QualityGateValidator:
    def validate_specification_completeness(self, spec_path: str) -> SpecQualityReport
    def validate_plan_consistency(self, plan_path: str, spec_path: str) -> ConsistencyReport
    def validate_task_completeness(self, tasks_path: str, plan_path: str) -> TaskQualityReport
    def validate_cross_artifact_alignment(self, artifacts: Dict[str, str]) -> AlignmentReport

Quality Criteria

• Specification Quality: No implementation details, measurable success criteria
• Plan Consistency: Tech decisions align with specifications
• Task Completeness: All requirements have corresponding tasks
• Cross-Artifact Alignment: No contradictions between artifacts

Validation Reports

{
  "validation_timestamp": "2025-12-08T13:45:00Z",
  "overall_status": "pass",
  "artifact_validations": {
    "spec.md": {
      "status": "pass",
      "issues": [],
      "completeness_score": 0.95
    },
    "plan.md": {
      "status": "pass",
      "issues": [],
      "consistency_score": 0.98
    }
  },
  "cross_artifact_issues": [],
  "recommendations": []
}

3. Workflow Integration Extensions

Phase Transition Management

class WorkflowOrchestrator:
    def transition_to_planning(self, spec_path: str) -> PlanningContext
    def transition_to_implementation(self, tasks_path: str) -> ImplementationContext
    def validate_phase_completion(self, phase: str, artifacts: List[str]) -> CompletionReport
    def generate_phase_summary(self, phase: str) -> PhaseSummary

Session Persistence

• State Management: Maintain workflow state across sessions
• Progress Tracking: Track completion of workflow phases
• Context Restoration: Restore session state on restart
• Checkpoint System: Create and restore checkpoints

Skill Coordination

• Loading Order: Optimize skill loading for maximum efficiency
• State Sharing: Coordinate state between skills
• Conflict Resolution: Handle conflicts between skill outputs
• Resource Management: Optimize resource usage across skills

4. Enhanced Planning Extensions

Specification-Driven Task Generation

class SpecificationDrivenPlanner:
    def extract_user_stories(self, spec_path: str) -> List[UserStory]
    def map_entities_to_stories(self, data_model_path: str, stories: List[UserStory]) -> Mapping
    def generate_story_based_tasks(self, stories: List[UserStory], plan_path: str) -> List[Task]
    def create_dependency_graph(self, tasks: List[Task]) -> DependencyGraph

User Story Organization

• Story-Based Phases: Organize tasks by user story
• Independent Testing: Create testable story increments
• MVP Identification: Identify minimum viable product scope
• Parallel Execution: Identify parallelizable tasks within stories

Enhanced Task Features

• Strict Formatting: Enforce spec-kit task formatting standards
• File Path Precision: Include exact file paths for all tasks
• Dependency Clarity: Explicit dependency specification
• Parallel Markers: Clear identification of parallelizable tasks

5. Traceability Extensions

Requirement Traceability Matrix

class TraceabilityManager:
    def create_requirement_traceability(self, spec_path: str, tasks_path: str) -> TraceabilityMatrix
    def validate_implementation_coverage(self, spec_path: str, implementation_path: str) -> CoverageReport
    def generate_impact_analysis(self, requirement_change: str) -> ImpactReport

Traceability Features

• Bidirectional Links: Links from requirements to tasks and vice versa
• Change Impact: Analyze impact of requirement changes
• Coverage Analysis: Verify all requirements are implemented
• Validation Mapping: Map tests back to requirements

Traceability Reports

# Requirement Traceability Matrix

| Requirement ID | User Story | Tasks | Test Cases | Status |
|---------------|------------|-------|------------|--------|
| REQ-001 | US1 | T001, T002, T003 | TC-001, TC-002 | Implemented |
| REQ-002 | US2 | T004, T005 | TC-003 | In Progress |

6. Template Integration Extensions

Template Enhancement

• Writing-Plans Integration: Enhance spec-kit templates with writing-plans methodology
• Dynamic Content: Generate template content based on context
• Validation Rules: Embed validation rules in templates
• Best Practices: Include writing-plans best practices in templates

Custom Template Features

class TemplateEnhancer:
    def enhance_plan_template(self, base_template: str, writing_plans_context: dict) -> str
    def generate_contextual_content(self, template_section: str, context: dict) -> str
    def apply_best_practices(self, content: str, domain: str) -> str
    def validate_template_output(self, generated_content: str) -> ValidationReport

Integration Benefits

For Writing-Plans Skill

1. Specification Context: Access to detailed specifications for better planning 2. Quality Assurance: Built-in validation and quality gates 3. Artifact Management: Automatic artifact generation and tracking 4. Workflow Integration: smooth integration into spec-kit workflow

For Spec-kit Plugin

1. Enhanced Planning: Access to writing-plans' detailed methodology 2. Better Task Generation: More detailed and accurate task breakdown 3. Improved Quality: Better validation and consistency checking 4. Session Management: Enhanced session persistence and coordination

Usage Examples

Enhanced Planning Session

# Start enhanced session
/speckit-startup.wrapped

# Generate specification with writing-plans refinement
/speckit-specify "Add user authentication system"

# Create enhanced plan with writing-plans methodology
/speckit-plan.wrapped

# Generate detailed tasks with specification-driven organization
/speckit-tasks.wrapped

Quality Validation

# Run detailed quality validation
quality_report = validator.validate_cross_artifact_alignment({
    'spec.md': '/specs/1-user-auth/spec.md',
    'plan.md': '/specs/1-user-auth/plan.md',
    'tasks.md': '/specs/1-user-auth/tasks.md'
})

print(f"Overall quality: {quality_report.overall_status}")
print(f"Issues found: {len(quality_report.cross_artifact_issues)}")

Configuration

Extension Activation

# .specify/config/extensions.yml
writing_plans_extensions:
  enabled: true
  artifact_management: true
  quality_validation: true
  workflow_integration: true
  traceability: true
  template_enhancement: true

Quality Gate Configuration

quality_gates:
  specification:
    completeness_threshold: 0.9
    max_clarifications: 3
    success_criteria_required: true

  planning:
    consistency_threshold: 0.85
    dependency_validation: true
    task_formatting: strict

  implementation:
    coverage_threshold: 0.95
    test_coverage: true
    quality_checks: automated

This specification provides the foundation for integrating spec-kit's artifact management and quality validation capabilities with the superpowers:writing-plans skill, creating a detailed planning and execution system.