@crewpilot/agent 1.0.0 → 2.0.0

package/prompts/skills/strategize-architecture-planner/SKILL.md

@@ -1,141 +1,141 @@
-# Architecture Planner
-
-> **Pillar**: Strategize | **ID**: `strategize-architecture-planner`
-
-## Purpose
-
-Transform decisions into concrete architecture plans with component diagrams, API contracts, data flow, and implementation roadmaps. Produces living design documents that evolve with the codebase.
-
-## Activation Triggers
-
-- "plan the architecture", "design the system", "create an RFC", "structure this"
-- "how should I organize", "component diagram", "data flow", "API design"
-- After `solution-design` selects an approach that needs detailing
-
-## Methodology
-
-### Process Flow
-
-```dot
-digraph architecture_planner {
-    rankdir=TB;
-    node [shape=box];
-
-    scope [label="Phase 1\nScope Definition"];
-    components [label="Phase 2\nComponent Design"];
-    dataflow [label="Phase 3\nData Flow"];
-    roadmap [label="Phase 4\nImplementation Roadmap"];
-    adr [label="Phase 5\nADR", shape=diamond, style=filled, fillcolor="#ffcccc"];
-    feature [label="feature-builder\n(Milestone M1)", shape=doublecircle];
-
-    scope -> components;
-    components -> dataflow;
-    dataflow -> roadmap;
-    roadmap -> adr;
-    adr -> feature [label="approved"];
-    adr -> components [label="user requests\nrevisions"];
-}
-```
-
-### Phase 1 — Scope Definition
-1. Identify system boundaries — what's in scope vs. out of scope
-2. List actors (users, services, external systems)
-3. Define key quality attributes: scalability, latency, availability, consistency
-4. Read existing codebase structure to understand current architecture
-
-### Phase 2 — Component Design
-1. Decompose into components/modules with clear responsibilities
-2. Define interfaces between components (API contracts, event schemas)
-3. Identify shared dependencies and data stores
-4. Map to existing code structure where applicable
-
-Output as a component table:
-
-| Component | Responsibility | Inputs | Outputs | Dependencies |
-|---|---|---|---|---|
-| | | | | |
-
-### Phase 3 — Data Flow
-1. Trace the primary user journey through the system
-2. Identify data transformations at each step
-3. Mark synchronous vs. asynchronous boundaries
-4. Identify potential bottlenecks and failure points
-
-Produce a numbered flow:
-```
-1. User → API Gateway (HTTPS)
-2. API Gateway → Auth Service (validate token)
-3. Auth Service → User DB (query)
-...
-```
-
-### Phase 4 — Implementation Roadmap
-1. Break into milestones (each independently deployable/testable)
-2. Order by dependency graph — foundations first
-3. Estimate effort per milestone (T-shirt sizes)
-4. Identify the critical path
-5. Mark "go/no-go" decision points
-
-### Phase 5 — ADR (Architecture Decision Record)
-
-<HARD-GATE>
-Do NOT begin implementation until the architecture plan (components, data flow, roadmap) has been presented to and approved by the user.
-If the user has not explicitly confirmed the architecture, do NOT proceed.
-</HARD-GATE>
-
-If `require_adr` is true in config, generate:
-
-```markdown
-# ADR-{NNN}: {Title}
-
-## Status: Proposed
-## Context: {why this decision is needed}
-## Decision: {what was decided}
-## Consequences: {positive and negative}
-## Alternatives Considered: {options rejected and why}
-```
-
-## Tools Required
-
-- `codebase` — Analyze existing project structure and dependencies
-- `terminal` — Run dependency analysis commands (package.json, imports, etc.)
-- `catalyst_knowledge_search` — Retrieve prior architecture decisions
-
-## Output Format
-
-```
-## [Catalyst → Architecture Planner]
-
-### Scope
-{boundaries, actors, quality attributes}
-
-### Components
-{component table}
-
-### Data Flow
-{numbered flow}
-
-### Implementation Roadmap
-| Milestone | Description | Effort | Dependencies |
-|---|---|---|---|
-| M1 | | | |
-
-### Critical Path
-{sequence}
-
-### ADR (if enabled)
-{ADR document}
-```
-
-## Chains To
-
-- `feature-builder` — Start implementing milestone M1
-- `test-first` — Write integration tests for component interfaces
-- `doc-governance` — Ensure architecture docs stay synchronized
-
-## Anti-Patterns
-
-- Do NOT design in a vacuum — always scan the existing codebase first
-- Do NOT create components with unclear responsibilities (god-service smell)
-- Do NOT skip the roadmap — architecture without sequencing is just a diagram
-- Do NOT ignore existing patterns — evolve, don't replace, unless explicitly asked
+# Architecture Planner
+
+> **Pillar**: Strategize | **ID**: `strategize-architecture-planner`
+
+## Purpose
+
+Transform decisions into concrete architecture plans with component diagrams, API contracts, data flow, and implementation roadmaps. Produces living design documents that evolve with the codebase.
+
+## Activation Triggers
+
+- "plan the architecture", "design the system", "create an RFC", "structure this"
+- "how should I organize", "component diagram", "data flow", "API design"
+- After `solution-design` selects an approach that needs detailing
+
+## Methodology
+
+### Process Flow
+
+```dot
+digraph architecture_planner {
+    rankdir=TB;
+    node [shape=box];
+
+    scope [label="Phase 1\nScope Definition"];
+    components [label="Phase 2\nComponent Design"];
+    dataflow [label="Phase 3\nData Flow"];
+    roadmap [label="Phase 4\nImplementation Roadmap"];
+    adr [label="Phase 5\nADR", shape=diamond, style=filled, fillcolor="#ffcccc"];
+    feature [label="feature-builder\n(Milestone M1)", shape=doublecircle];
+
+    scope -> components;
+    components -> dataflow;
+    dataflow -> roadmap;
+    roadmap -> adr;
+    adr -> feature [label="approved"];
+    adr -> components [label="user requests\nrevisions"];
+}
+```
+
+### Phase 1 — Scope Definition
+1. Identify system boundaries — what's in scope vs. out of scope
+2. List actors (users, services, external systems)
+3. Define key quality attributes: scalability, latency, availability, consistency
+4. Read existing codebase structure to understand current architecture
+
+### Phase 2 — Component Design
+1. Decompose into components/modules with clear responsibilities
+2. Define interfaces between components (API contracts, event schemas)
+3. Identify shared dependencies and data stores
+4. Map to existing code structure where applicable
+
+Output as a component table:
+
+| Component | Responsibility | Inputs | Outputs | Dependencies |
+|---|---|---|---|---|
+| | | | | |
+
+### Phase 3 — Data Flow
+1. Trace the primary user journey through the system
+2. Identify data transformations at each step
+3. Mark synchronous vs. asynchronous boundaries
+4. Identify potential bottlenecks and failure points
+
+Produce a numbered flow:
+```
+1. User → API Gateway (HTTPS)
+2. API Gateway → Auth Service (validate token)
+3. Auth Service → User DB (query)
+...
+```
+
+### Phase 4 — Implementation Roadmap
+1. Break into milestones (each independently deployable/testable)
+2. Order by dependency graph — foundations first
+3. Estimate effort per milestone (T-shirt sizes)
+4. Identify the critical path
+5. Mark "go/no-go" decision points
+
+### Phase 5 — ADR (Architecture Decision Record)
+
+<HARD-GATE>
+Do NOT begin implementation until the architecture plan (components, data flow, roadmap) has been presented to and approved by the user.
+If the user has not explicitly confirmed the architecture, do NOT proceed.
+</HARD-GATE>
+
+If `require_adr` is true in config, generate:
+
+```markdown
+# ADR-{NNN}: {Title}
+
+## Status: Proposed
+## Context: {why this decision is needed}
+## Decision: {what was decided}
+## Consequences: {positive and negative}
+## Alternatives Considered: {options rejected and why}
+```
+
+## Tools Required
+
+- `codebase` — Analyze existing project structure and dependencies
+- `terminal` — Run dependency analysis commands (package.json, imports, etc.)
+- `catalyst_knowledge_search` — Retrieve prior architecture decisions
+
+## Output Format
+
+```
+## [Catalyst → Architecture Planner]
+
+### Scope
+{boundaries, actors, quality attributes}
+
+### Components
+{component table}
+
+### Data Flow
+{numbered flow}
+
+### Implementation Roadmap
+| Milestone | Description | Effort | Dependencies |
+|---|---|---|---|
+| M1 | | | |
+
+### Critical Path
+{sequence}
+
+### ADR (if enabled)
+{ADR document}
+```
+
+## Chains To
+
+- `feature-builder` — Start implementing milestone M1
+- `test-first` — Write integration tests for component interfaces
+- `doc-governance` — Ensure architecture docs stay synchronized
+
+## Anti-Patterns
+
+- Do NOT design in a vacuum — always scan the existing codebase first
+- Do NOT create components with unclear responsibilities (god-service smell)
+- Do NOT skip the roadmap — architecture without sequencing is just a diagram
+- Do NOT ignore existing patterns — evolve, don't replace, unless explicitly asked

package/prompts/skills/strategize-solution-design/SKILL.md

@@ -1,118 +1,118 @@
-# Solution Design
-
-> **Pillar**: Strategize | **ID**: `strategize-solution-design`
-
-## Purpose
-
-Structured ideation and trade-off analysis for technical decisions. Transforms vague questions into evaluated options with clear recommendations.
-
-## Activation Triggers
-
-- "brainstorm", "explore options", "what are the approaches", "tradeoffs", "should I use X or Y"
-- Any open-ended technical question with multiple viable paths
-
-## Methodology
-
-### Process Flow
-
-```dot
-digraph solution_design {
-    rankdir=TB;
-    node [shape=box];
-
-    frame [label="Phase 1\nProblem Framing"];
-    options [label="Phase 2\nOption Generation\n(3-4 approaches)"];
-    matrix [label="Phase 3\nTrade-off Matrix"];
-    recommend [label="Phase 4\nRecommendation", shape=diamond, style=filled, fillcolor="#ffcccc"];
-    arch [label="architecture-planner", shape=doublecircle];
-    build [label="feature-builder", shape=doublecircle];
-
-    frame -> options;
-    options -> matrix;
-    matrix -> recommend;
-    recommend -> arch [label="needs detailed design"];
-    recommend -> build [label="ready to implement"];
-    recommend -> options [label="user rejects\nall options"];
-}
-```
-
-### Phase 1 — Problem Framing
-1. Restate the problem in one sentence
-2. Identify constraints: time, team size, existing tech stack, scale requirements
-3. Ask 1-2 clarifying questions ONLY if the problem is genuinely ambiguous
-
-### Phase 2 — Option Generation
-1. Generate 3-4 distinct approaches (configurable via `max_options` in config)
-2. Each option must include:
-   - **Name**: Short memorable label
-   - **Approach**: 2-3 sentence description
-   - **Strengths**: What it does well
-   - **Risks**: What could go wrong
-   - **Effort**: T-shirt size (S/M/L/XL) with justification
-3. Options must be genuinely different — not variations of the same approach
-
-### Phase 3 — Trade-off Matrix
-Build a comparison table:
-
-| Criterion | Option A | Option B | Option C |
-|---|---|---|---|
-| Implementation effort | | | |
-| Maintainability | | | |
-| Performance | | | |
-| Team familiarity | | | |
-
-Rate each cell: `++` (strong), `+` (good), `~` (neutral), `-` (weak), `--` (poor)
-
-### Phase 4 — Recommendation
-
-<HARD-GATE>
-Do NOT proceed to implementation or architecture planning until the user has reviewed the trade-off matrix and confirmed the recommended option.
-Present the recommendation and wait for explicit approval or selection.
-</HARD-GATE>
-
-1. State the recommended option clearly
-2. Provide confidence level (1-10) with reasoning
-3. Identify the "decision reversal cost" — how hard is it to switch later
-4. List 1-2 things to validate before committing
-
-## Tools Required
-
-- `codebase` — Scan existing stack for constraints
-- `fetch` — Pull external docs/benchmarks when comparing technologies
-- `catalyst_knowledge_search` — Check if similar decisions were made before
-
-## Output Format
-
-```
-## [Catalyst → Solution Design]
-
-### Problem
-{one-sentence problem statement}
-
-### Options
-1. **{Name}** — {approach}
-   - Strengths: ...
-   - Risks: ...
-   - Effort: {T-shirt}
-
-### Trade-off Matrix
-{table}
-
-### Recommendation
-**{Option Name}** (Confidence: {N}/10)
-{reasoning}
-
-**Reversal cost**: {Low/Medium/High}
-**Validate first**: {list}
-```
-
-## Chains To
-
-- `architecture-planner` — When the recommended option needs detailed design
-- `feature-builder` — When the user wants to start implementing immediately
-
-## Anti-Patterns
-
-- Do NOT generate options just to fill a quota — 2 genuine options beat 4 padded ones
-- Do NOT recommend without stating confidence and reversal cost
-- Do NOT skip the trade-off matrix — it's the core value of this skill
+# Solution Design
+
+> **Pillar**: Strategize | **ID**: `strategize-solution-design`
+
+## Purpose
+
+Structured ideation and trade-off analysis for technical decisions. Transforms vague questions into evaluated options with clear recommendations.
+
+## Activation Triggers
+
+- "brainstorm", "explore options", "what are the approaches", "tradeoffs", "should I use X or Y"
+- Any open-ended technical question with multiple viable paths
+
+## Methodology
+
+### Process Flow
+
+```dot
+digraph solution_design {
+    rankdir=TB;
+    node [shape=box];
+
+    frame [label="Phase 1\nProblem Framing"];
+    options [label="Phase 2\nOption Generation\n(3-4 approaches)"];
+    matrix [label="Phase 3\nTrade-off Matrix"];
+    recommend [label="Phase 4\nRecommendation", shape=diamond, style=filled, fillcolor="#ffcccc"];
+    arch [label="architecture-planner", shape=doublecircle];
+    build [label="feature-builder", shape=doublecircle];
+
+    frame -> options;
+    options -> matrix;
+    matrix -> recommend;
+    recommend -> arch [label="needs detailed design"];
+    recommend -> build [label="ready to implement"];
+    recommend -> options [label="user rejects\nall options"];
+}
+```
+
+### Phase 1 — Problem Framing
+1. Restate the problem in one sentence
+2. Identify constraints: time, team size, existing tech stack, scale requirements
+3. Ask 1-2 clarifying questions ONLY if the problem is genuinely ambiguous
+
+### Phase 2 — Option Generation
+1. Generate 3-4 distinct approaches (configurable via `max_options` in config)
+2. Each option must include:
+   - **Name**: Short memorable label
+   - **Approach**: 2-3 sentence description
+   - **Strengths**: What it does well
+   - **Risks**: What could go wrong
+   - **Effort**: T-shirt size (S/M/L/XL) with justification
+3. Options must be genuinely different — not variations of the same approach
+
+### Phase 3 — Trade-off Matrix
+Build a comparison table:
+
+| Criterion | Option A | Option B | Option C |
+|---|---|---|---|
+| Implementation effort | | | |
+| Maintainability | | | |
+| Performance | | | |
+| Team familiarity | | | |
+
+Rate each cell: `++` (strong), `+` (good), `~` (neutral), `-` (weak), `--` (poor)
+
+### Phase 4 — Recommendation
+
+<HARD-GATE>
+Do NOT proceed to implementation or architecture planning until the user has reviewed the trade-off matrix and confirmed the recommended option.
+Present the recommendation and wait for explicit approval or selection.
+</HARD-GATE>
+
+1. State the recommended option clearly
+2. Provide confidence level (1-10) with reasoning
+3. Identify the "decision reversal cost" — how hard is it to switch later
+4. List 1-2 things to validate before committing
+
+## Tools Required
+
+- `codebase` — Scan existing stack for constraints
+- `fetch` — Pull external docs/benchmarks when comparing technologies
+- `catalyst_knowledge_search` — Check if similar decisions were made before
+
+## Output Format
+
+```
+## [Catalyst → Solution Design]
+
+### Problem
+{one-sentence problem statement}
+
+### Options
+1. **{Name}** — {approach}
+   - Strengths: ...
+   - Risks: ...
+   - Effort: {T-shirt}
+
+### Trade-off Matrix
+{table}
+
+### Recommendation
+**{Option Name}** (Confidence: {N}/10)
+{reasoning}
+
+**Reversal cost**: {Low/Medium/High}
+**Validate first**: {list}
+```
+
+## Chains To
+
+- `architecture-planner` — When the recommended option needs detailed design
+- `feature-builder` — When the user wants to start implementing immediately
+
+## Anti-Patterns
+
+- Do NOT generate options just to fill a quota — 2 genuine options beat 4 padded ones
+- Do NOT recommend without stating confidence and reversal cost
+- Do NOT skip the trade-off matrix — it's the core value of this skill