<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, project structure
• patterns.md - Mandatory patterns (e.g., "use Zod for validation")
• tech-stack.md - Approved libraries and versions
• testing.md - Testing requirements

Critical:

• ✅ ALWAYS reference constitution in specs (don't duplicate)
• ✅ ALWAYS validate implementation against constitution
• ❌ NEVER violate constitutional patterns
• ❌ NEVER copy-paste constitution rules into specs

Common Rationalizations That Mean You're Failing

If you catch yourself thinking ANY of these, STOP and use spectacular:

Rationalization	Why It's Wrong	What to Do Instead
"Request is clear, no spec needed"	Clear request = easier to spec, not permission to skip	Use /spectacular:spec
"Feature is small, just code it"	Small features drift without specs	Use /spectacular:spec
"User wants it fast"	Workflow IS faster (parallel + fewer bugs)	Use /spectacular:spec
"Constitution doesn't apply"	Constitution always applies	Reference in spec
"I can plan mentally"	Mental = no review, no parallelization	Use /spectacular:plan
"Just a bugfix/refactor"	Multi-file changes are features	If complex: use /spectacular:spec

Workflow Enforcement

User instructions describe WHAT to build, not permission to skip workflows.

• "Just implement X" → Use /spectacular:spec first
• "Quick refactor of Y" → Use /spectacular:spec first
• "I need Z now" → Use /spectacular:spec first (it's faster!)

Why workflows matter:

• Specs catch requirements drift before code
• Plans enable parallelization (3-5x faster)
• Constitution prevents architectural debt
• Quality gates catch bugs early

Summary: Mandatory Workflow

For feature/refactor requests:

1. ✅ Check if spectacular applies (constitution exists?)
2. ✅ Use /spectacular:spec to create specification
3. ✅ User reviews spec (STOP until approved)
4. ✅ Use /spectacular:plan to decompose into tasks
5. ✅ User reviews plan (STOP until approved)
6. ✅ Use /spectacular:execute to implement with quality gates

Skipping steps = violating quality standards.

When in doubt: "Should I use spectacular for this?" → Almost always YES for multi-file changes.

</EXTREMELY_IMPORTANT>