/blueprint

name: blueprint
description: "Generate an implementation plan with system architecture design and dependency-ordered task breakdown from a specification."
usage: /attune:blueprint [--input FILE] [--component NAME]

Attune Plan Command

Transform specifications into executable implementation plans with system architecture, component design, and dependency-ordered task breakdown.

When To Use

Use this command when you need to:

• Convert specification into implementation plan
• Design system architecture from requirements
• Break down work into dependency-ordered tasks
• Estimate effort and plan sprints
• Define component interfaces and data flow
• Create concrete roadmap for execution

When NOT To Use

Avoid this command if:

• No specification exists yet (use `/attune:specify` first)
• Still defining requirements (complete specification phase)
• Ready to execute existing plan (use `/attune:execute` instead)
• Adjusting running project (update plan incrementally)

Usage

# Create plan from specification
/attune:blueprint

# Plan with custom input
/attune:blueprint --input docs/specification.md

# Focus on specific component
/attune:blueprint --component "authentication"

What This Command Does

1. **Loads specification** from specify phase 2. **Invokes planning skill** with superpowers integration 3. **Designs system architecture** (components, interfaces, data flow) 4. **Breaks down into tasks** with dependencies and estimates 5. **Produces implementation plan** for execution phase

Integration with Superpowers

When superpowers plugin is available:

• Uses `Skill(superpowers:writing-plans)` for structured planning
• Applies dependency analysis
• Creates checkpoint-based execution flow

Without superpowers:

• Falls back to attune's native planning skill
• Provides similar step-by-step approach
• Documents tasks systematically

Workflow

# 1. Invoke planning skill
Skill(attune:project-planning)

# 2. Design architecture:
#    - System components
#    - Component interfaces
#    - Data flow diagrams
#    - Technology selections

# 3. Break down into tasks:
#    - Development tasks with dependencies
#    - Testing tasks
#    - Deployment tasks
#    - Documentation tasks

# 4. Generate implementation plan
#    - Saved to docs/implementation-plan.md
#    - Includes architecture + task breakdown

# 5. Workflow auto-continues (see below)

Workflow Continuation Protocol (MANDATORY)

**After planning completes successfully**, auto-proceed to the next phase unless `--standalone` was specified:

1. **Verify artifact**: Confirm `docs/implementation-plan.md` exists and is non-empty 2. **Checkpoint message**: Display brief summary to user:

   Implementation plan complete. Saved to docs/implementation-plan.md.
   Proceeding to execution phase...

3. **Auto-invoke next phase**:

   Skill(attune:project-execution)

**Bypass Conditions** (skip auto-continuation if ANY true):

• `--standalone` flag was provided
• `docs/implementation-plan.md` does not exist or is empty
• User explicitly requests to stop after planning

Plan Structure

Section 1: Architecture Design

**Components**:

## System Architecture

### Component Diagram

┌─────────────┐ ┌──────────────┐ ┌─────────────┐ │ Web UI │─────▶│ API Server │─────▶│ Database │ │ (React) │ │ (FastAPI) │ │ (Postgres) │ └─────────────┘ └──────────────┘ └─────────────┘ │ ▼ ┌──────────────┐ │ GitHub API │ └──────────────┘

### Components

#### Component 1: Web UI
**Responsibility**: User interface for debt tracking
**Technology**: React 18 + TypeScript + Vite
**Interfaces**:
- REST API client
- OAuth callback handler
**Data**: Client-side state management (React Context)

#### Component 2: API Server
**Responsibility**: Business logic and GitHub integration
**Technology**: FastAPI + Python 3.10
**Interfaces**:
- REST API endpoints
- GitHub webhook receiver
- Database access layer
**Data**: Issue cache, user sessions

#### Component 3: Database
**Responsibility**: Persistent data storage
**Technology**: PostgreSQL 14
**Schema**:
- users (id, github_id, access_token)
- repositories (id, owner, name)
- debt_items (id, repo_id, issue_number, type, priority)

Section 2: Task Breakdown

**Task Format**: task IDs use the spec-kit `TNNN` form (`T001`), zero-padded to three digits and numbered in sequence across phases.

### T001: [Task Name]

**Description**: Clear description of what needs to be done

**Type**: Implementation | Testing | Documentation | Deployment
**Priority**: P0 (Critical) | P1 (High) | P2 (Medium) | P3 (Low)
**Estimate**: [Story points or hours]
**Dependencies**: T002, T005
**Assignee**: [Team member or TBD]

**Acceptance Criteria**:
- [ ] Criterion 1
- [ ] Criterion 2

**Technical Notes**:
- Implementation detail 1
- Implementation detail 2

**Testing Requirements**:
- Unit tests for X
- Integration tests for Y

Section 3: Development Phases

**Phase 1: Foundation** (Weeks 1-2)

• Project initialization
• Database schema
• GitHub OAuth setup
• Basic API scaffolding

**Phase 2: Core Features** (Weeks 3-6)

• Issue discovery
• Prioritization algorithm
• Dashboard implementation

**Phase 3: Polish** (Weeks 7-8)

• Error handling
• Performance optimization
• Documentation

**Phase 4: Launch** (Week 9)

• Deployment
• User testing
• Feedback collection

Arguments

• `--input <path>` - Input specification (default: docs/specification.md)
• `--output <path>` - Output plan (default: docs/implementation-plan.md)
• `--component <name>` - Focus on specific component
• `--detailed` - Generate detailed task breakdown with code examples
• `--standalone` - Run only this phase; do not auto-proceed to execution

Examples

Example 1: Full Project Plan

/attu