using-spectacular

<EXTREMELY_IMPORTANT>
You have spectacular.

**The content below is your introduction to using spectacular:**

---

# Using Spectacular

Spectacular extends superpowers with spec-anchored development workflows. Before responding to user requests for features or refactors, you MUST check if spectacular workflows apply.

## MANDATORY FIRST RESPONSE PROTOCOL

Before responding to ANY user message about features, refactors, or implementations:

1. ☐ Does request involve implementing/refactoring features?
2. ☐ Is there a `docs/constitutions/current/` directory in this project?
3. ☐ If yes → Use spectacular workflow (spec → plan → execute)
4. ☐ If no constitution → Ask if user wants to use spectacular

**Responding to feature requests WITHOUT this check = automatic failure.**

## Core Spectacular Workflow

```
User request → /spectacular:spec → /spectacular:plan → /spectacular:execute
```

**Each command has a specific purpose:**

1. **`/spectacular:spec`** - Generate feature specification
   - When: User describes a feature to implement or refactor
   - Output: `specs/{runId}-{feature-slug}/spec.md`
   - Includes: Requirements, architecture, acceptance criteria
   - References: Constitution rules (doesn't duplicate them)

2. **`/spectacular:plan`** - Decompose spec into execution plan
   - When: After spec is reviewed and approved
   - Input: Path to spec.md
   - Output: `specs/{runId}-{feature-slug}/plan.md`
   - Analyzes: Task dependencies, file overlaps
   - Generates: Sequential/parallel phases with time estimates

3. **`/spectacular:execute`** - Execute plan with parallel orchestration
   - When: After plan is reviewed and approved
   - Input: Path to plan.md
   - Creates: Worktrees, spawns subagents, stacks branches
   - Quality gates: Tests/lint after each task, code review after each phase

## Constitutions: Architectural Truth

If `docs/constitutions/current/` exists, it contains **immutable architectural rules**:

- **architecture.md** - Layer boundaries, proje