113 lines
4.5 KiB
Markdown
113 lines
4.5 KiB
Markdown
---
|
|
name: using-spectacular
|
|
description: Use when starting any conversation in a project using spectacular - establishes mandatory workflows for spec-anchored development, including when to use /spectacular commands and how to work with constitutions
|
|
---
|
|
|
|
<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>
|