@crewpilot/agent 2.0.0 → 3.0.0

package/prompts/skills/insights-pattern-detection/SKILL.md

@@ -1,142 +1,142 @@
-# Pattern Detection
-
-> **Pillar**: Insights | **ID**: `insights-pattern-detection`
-
-## Purpose
-
-Codebase-wide pattern mining and anti-pattern identification. Analyzes structural health, detects recurring issues, tracks technical debt, and identifies emerging trends across the project.
-
-## Activation Triggers
-
-- "codebase health", "find patterns", "anti-patterns", "tech debt"
-- "what patterns are we using", "code trends", "structural analysis"
-- Automatically triggered when `root-cause-analysis` finds a systemic issue
-
-## Methodology
-
-### Process Flow
-
-```dot
-digraph pattern_detection {
-    rankdir=TB;
-    node [shape=box];
-
-    structure [label="Phase 1\nStructure Scan"];
-    mining [label="Phase 2\nPattern Mining"];
-    antipattern [label="Phase 3\nAnti-Pattern Detection"];
-    debt [label="Phase 4\nTechnical Debt Inventory"];
-    trends [label="Phase 5\nTrend Analysis", shape=diamond];
-    report [label="Report", shape=doublecircle];
-
-    structure -> mining;
-    mining -> antipattern;
-    antipattern -> debt;
-    debt -> trends;
-    trends -> report [label="historical\ndata available"];
-    debt -> report [label="no historical data"];
-}
-```
-
-### Phase 1 — Structure Scan
-1. Map the project structure: directories, modules, layers
-2. Identify architectural patterns in use:
-   - MVC, MVVM, Clean Architecture, Hexagonal
-   - Microservices vs. monolith vs. modular monolith
-   - API patterns: REST, GraphQL, RPC
-3. Detect organizational patterns: feature-based vs. layer-based vs. hybrid
-
-### Phase 2 — Pattern Mining
-Scan for recurring code patterns:
-
-| Category | Patterns to Detect |
-|---|---|
-| **Error handling** | Try-catch styles, error propagation, error types |
-| **Data access** | ORM patterns, raw queries, repository pattern |
-| **State management** | Global state, dependency injection, singletons |
-| **API design** | Route organization, middleware chains, validation |
-| **Testing** | Test structure, mock strategies, fixture patterns |
-| **Configuration** | Env vars, config objects, feature flags |
-
-For each pattern found:
-- **Frequency**: How often it appears
-- **Consistency**: Are there deviations from the pattern?
-- **Quality**: Is this a good pattern for this context?
-
-### Phase 3 — Anti-Pattern Detection
-Flag known anti-patterns:
-
-| Anti-Pattern | Symptoms |
-|---|---|
-| **God Object/File** | Single file > 500 lines with mixed responsibilities |
-| **Circular Dependencies** | Module A imports B imports A |
-| **Shotgun Surgery** | Small change requires touching 5+ files |
-| **Feature Envy** | Function uses more of another module's data than its own |
-| **Dead Code** | Unreachable functions, unused exports |
-| **Copy-Paste** | Near-duplicate code blocks across files |
-| **Primitive Obsession** | Strings/numbers used where domain types belong |
-| **Configuration Drift** | Same setting configured differently in multiple places |
-
-### Phase 4 — Technical Debt Inventory
-For each anti-pattern or inconsistency:
-1. Estimate effort to fix (T-shirt size)
-2. Assess impact on team velocity
-3. Rate urgency: address now vs. track vs. accept
-
-### Phase 5 — Trend Analysis
-If `catalyst_knowledge_search` has historical data:
-1. Compare current patterns vs. previous scans
-2. Identify patterns that are spreading (good or bad)
-3. Flag entropy increase — growing inconsistency over time
-
-## Tools Required
-
-- `codebase` — Full project scan
-- `terminal` — Run static analysis tools
-- `catalyst_metrics_complexity` — Complexity metrics per module
-- `catalyst_knowledge_search` — Historical pattern data
-- `catalyst_knowledge_store` — Record findings for future comparison
-
-## Output Format
-
-```
-## [Catalyst → Pattern Detection]
-
-### Architecture
-{detected patterns and organization style}
-
-### Code Patterns
-| Pattern | Category | Frequency | Consistency | Quality |
-|---|---|---|---|---|
-| {pattern} | {category} | {count} | {high/medium/low} | {good/acceptable/poor} |
-
-### Anti-Patterns
-| Anti-Pattern | Locations | Severity | Fix Effort |
-|---|---|---|---|
-| {anti-pattern} | {files/modules} | {high/med/low} | {T-shirt} |
-
-### Technical Debt
-| Item | Impact | Urgency | Effort |
-|---|---|---|---|
-| {debt item} | {velocity/quality/security} | {now/track/accept} | {T-shirt} |
-
-### Trends (if historical data available)
-{getting better / getting worse / stable}
-
-### Summary
-Codebase health: {score}/10
-Top concern: {most impactful issue}
-Quick wins: {list of low-effort improvements}
-```
-
-## Chains To
-
-- `code-quality` — Deep review of flagged anti-pattern locations
-- `architecture-planner` — Restructure if systemic issues found
-- `knowledge-base` — Store scan results for trend tracking
-
-## Anti-Patterns (meta)
-
-- Do NOT flag patterns as anti-patterns based on ideology — evaluate in context
-- Do NOT report dead code without verifying it's truly unreachable
-- Do NOT recommend rewrites for working code with manageable debt
-- Do NOT present a massive list without prioritization
+# Pattern Detection
+
+> **Pillar**: Insights | **ID**: `insights-pattern-detection`
+
+## Purpose
+
+Codebase-wide pattern mining and anti-pattern identification. Analyzes structural health, detects recurring issues, tracks technical debt, and identifies emerging trends across the project.
+
+## Activation Triggers
+
+- "codebase health", "find patterns", "anti-patterns", "tech debt"
+- "what patterns are we using", "code trends", "structural analysis"
+- Automatically triggered when `root-cause-analysis` finds a systemic issue
+
+## Methodology
+
+### Process Flow
+
+```dot
+digraph pattern_detection {
+    rankdir=TB;
+    node [shape=box];
+
+    structure [label="Phase 1\nStructure Scan"];
+    mining [label="Phase 2\nPattern Mining"];
+    antipattern [label="Phase 3\nAnti-Pattern Detection"];
+    debt [label="Phase 4\nTechnical Debt Inventory"];
+    trends [label="Phase 5\nTrend Analysis", shape=diamond];
+    report [label="Report", shape=doublecircle];
+
+    structure -> mining;
+    mining -> antipattern;
+    antipattern -> debt;
+    debt -> trends;
+    trends -> report [label="historical\ndata available"];
+    debt -> report [label="no historical data"];
+}
+```
+
+### Phase 1 — Structure Scan
+1. Map the project structure: directories, modules, layers
+2. Identify architectural patterns in use:
+   - MVC, MVVM, Clean Architecture, Hexagonal
+   - Microservices vs. monolith vs. modular monolith
+   - API patterns: REST, GraphQL, RPC
+3. Detect organizational patterns: feature-based vs. layer-based vs. hybrid
+
+### Phase 2 — Pattern Mining
+Scan for recurring code patterns:
+
+| Category | Patterns to Detect |
+|---|---|
+| **Error handling** | Try-catch styles, error propagation, error types |
+| **Data access** | ORM patterns, raw queries, repository pattern |
+| **State management** | Global state, dependency injection, singletons |
+| **API design** | Route organization, middleware chains, validation |
+| **Testing** | Test structure, mock strategies, fixture patterns |
+| **Configuration** | Env vars, config objects, feature flags |
+
+For each pattern found:
+- **Frequency**: How often it appears
+- **Consistency**: Are there deviations from the pattern?
+- **Quality**: Is this a good pattern for this context?
+
+### Phase 3 — Anti-Pattern Detection
+Flag known anti-patterns:
+
+| Anti-Pattern | Symptoms |
+|---|---|
+| **God Object/File** | Single file > 500 lines with mixed responsibilities |
+| **Circular Dependencies** | Module A imports B imports A |
+| **Shotgun Surgery** | Small change requires touching 5+ files |
+| **Feature Envy** | Function uses more of another module's data than its own |
+| **Dead Code** | Unreachable functions, unused exports |
+| **Copy-Paste** | Near-duplicate code blocks across files |
+| **Primitive Obsession** | Strings/numbers used where domain types belong |
+| **Configuration Drift** | Same setting configured differently in multiple places |
+
+### Phase 4 — Technical Debt Inventory
+For each anti-pattern or inconsistency:
+1. Estimate effort to fix (T-shirt size)
+2. Assess impact on team velocity
+3. Rate urgency: address now vs. track vs. accept
+
+### Phase 5 — Trend Analysis
+If `crewpilot_knowledge_search` has historical data:
+1. Compare current patterns vs. previous scans
+2. Identify patterns that are spreading (good or bad)
+3. Flag entropy increase — growing inconsistency over time
+
+## Tools Required
+
+- `codebase` — Full project scan
+- `terminal` — Run static analysis tools
+- `crewpilot_metrics_complexity` — Complexity metrics per module
+- `crewpilot_knowledge_search` — Historical pattern data
+- `crewpilot_knowledge_store` — Record findings for future comparison
+
+## Output Format
+
+```
+## [CrewPilot → Pattern Detection]
+
+### Architecture
+{detected patterns and organization style}
+
+### Code Patterns
+| Pattern | Category | Frequency | Consistency | Quality |
+|---|---|---|---|---|
+| {pattern} | {category} | {count} | {high/medium/low} | {good/acceptable/poor} |
+
+### Anti-Patterns
+| Anti-Pattern | Locations | Severity | Fix Effort |
+|---|---|---|---|
+| {anti-pattern} | {files/modules} | {high/med/low} | {T-shirt} |
+
+### Technical Debt
+| Item | Impact | Urgency | Effort |
+|---|---|---|---|
+| {debt item} | {velocity/quality/security} | {now/track/accept} | {T-shirt} |
+
+### Trends (if historical data available)
+{getting better / getting worse / stable}
+
+### Summary
+Codebase health: {score}/10
+Top concern: {most impactful issue}
+Quick wins: {list of low-effort improvements}
+```
+
+## Chains To
+
+- `code-quality` — Deep review of flagged anti-pattern locations
+- `architecture-planner` — Restructure if systemic issues found
+- `knowledge-base` — Store scan results for trend tracking
+
+## Anti-Patterns (meta)
+
+- Do NOT flag patterns as anti-patterns based on ideology — evaluate in context
+- Do NOT report dead code without verifying it's truly unreachable
+- Do NOT recommend rewrites for working code with manageable debt
+- Do NOT present a massive list without prioritization

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.)
+- `crewpilot_knowledge_search` — Retrieve prior architecture decisions
+
+## Output Format
+
+```
+## [CrewPilot → 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