| name | era-architecture |
| model | opus |
| description | Produces an Era Master Plan document defining shared vocabulary, architectural constraints, and a release roadmap across 3-7 releases. Use when: 'plan this era', 'define the architecture for multiple releases', 'create a multi-release vision', 'transition to a new product era', 'establish conceptual coherence across releases'. |
| category | continuous-learning |
| triggers | ["plan this era","define the architecture for multiple releases","create a multi-release vision","transition to a new product era","establish conceptual coherence across releases"] |
| tier | 1 |
| agents | ["primary"] |
| tool_dependencies | ["file_system"] |
| inputs | [{"name":"era_description","type":"string","description":"High-level description of the product era and its goals","required":true},{"name":"release_count","type":"number","description":"Number of releases to plan across (3-7)","required":false}] |
| outputs | [{"name":"era_master_plan","type":"ref","format":"cas-ref","description":"Era Master Plan document defining shared vocabulary, architectural constraints, and release roadmap"}] |
era-architecture
I. The Philosophy
An era is not a list of releases. It's a conceptual architecture that coordinates multiple releases under shared constraints.
When you go from "we need to rebuild the frontend" to "we need a complete multi-release era plan," you're making a qualitative shift. Instead of asking "what should v0.2.1 do?" you're asking "what vocabulary, architectural patterns, and design language will span all releases in this era?"
This shift matters because:
- Coherence: Without a shared architecture, releases drift apart. Release A uses one data model, Release B contradicts it.
- Dependency clarity: You can't plan releases independently. A shared design language in Release 1 enables faster work in Release 2.
- Decision efficiency: The era's conceptual architecture is the constitution that downstream decisions must obey. This prevents constant re-litigation of foundational choices.
The key insight: scouts explore the facets (not releases). From those explorations, you extract the era's architecture (not the other way around).
II. When to Use This Skill
Use era-architecture when:
- Planning a major product pivot that spans 3+ releases
- You need to define shared conceptual vocabulary before decomposing into releases
- Transitioning between product eras (e.g., engine-building → fresh shell → social layer)
- The scope is too large for one release but needs coherent vision across all releases
- You need cross-cutting architectural decisions (data model, design language, navigation patterns)
Do NOT use era-architecture when:
- Planning a single release → use
strategic-scout + parallel-tracks
- Writing specs → use
specification-writer or frontend-from-backend
- Converting specs to prompts → use
spec-constellation-to-prompt-suite or zenflow-prompt-writer
- Exploring one strategic question → use
strategic-scout
III. The Workflow (7 Steps)
Step 1: Name the Era and Its Predecessor
Give the era a name that captures its purpose (e.g., "The Fresh Shell", "The Engine", "The Social Layer").
Document what the previous era accomplished and what it leaves behind. Define the handoff: what assets/code/patterns carry forward, what gets archived.
This framing prevents the new era from being aimless. It grounds the work in what came before and what you're building toward.
