@crewpilot/agent 1.0.0 → 2.0.0

package/prompts/skills/engineer-root-cause-analysis/SKILL.md

@@ -1,150 +1,150 @@
-# Root Cause Analysis
-
-> **Pillar**: Engineer | **ID**: `engineer-root-cause-analysis`
-
-## Purpose
-
-Systematic debugging that finds the actual root cause, not just the symptom. Uses a structured hypothesis-test-eliminate approach with a maximum attempt budget to prevent rabbit holes.
-
-## Activation Triggers
-
-- "debug this", "fix this error", "why is this crashing", "investigate"
-- "root cause", "not working", "broken", "unexpected behavior"
-- Any error message, stack trace, or unexpected output
-
-## Methodology
-
-### Process Flow
-
-```dot
-digraph root_cause_analysis {
-    rankdir=TB;
-    node [shape=box];
-
-    symptoms [label="Phase 1\nSymptom Collection"];
-    hypotheses [label="Phase 2\nHypothesis Generation\n(2-3 ranked)"];
-    eliminate [label="Phase 3\nSystematic Elimination", shape=diamond];
-    root_cause [label="Phase 4\nRoot Cause Identified"];
-    fix [label="Phase 5\nFix Implementation"];
-    prevent [label="Phase 6\nPrevention", shape=doublecircle];
-    escalate [label="Escalate to Human", shape=octagon, style=filled, fillcolor="#ff9999"];
-
-    symptoms -> hypotheses;
-    hypotheses -> eliminate;
-    eliminate -> root_cause [label="confirmed"];
-    eliminate -> hypotheses [label="all eliminated\nrefine"];
-    eliminate -> escalate [label="max_attempts\nreached"];
-    root_cause -> fix;
-    fix -> prevent;
-}
-```
-
-### Phase 1 — Symptom Collection
-1. Gather all available evidence:
-   - Error message / stack trace
-   - Steps to reproduce
-   - When it started (recent changes?)
-   - Environment details (dev/staging/prod, OS, runtime version)
-2. Reproduce the issue if possible (run the failing code/test)
-3. Check git log for recent changes to affected files
-
-### Phase 2 — Hypothesis Generation
-Generate 2-3 ranked hypotheses:
-
-| # | Hypothesis | Likelihood | Evidence | How to Test |
-|---|---|---|---|---|
-| H1 | {most likely cause} | High | {what points here} | {test strategy} |
-| H2 | {alternative cause} | Medium | {what points here} | {test strategy} |
-| H3 | {edge case cause} | Low | {what points here} | {test strategy} |
-
-### Phase 3 — Systematic Elimination
-For each hypothesis (highest likelihood first):
-1. **Test**: Run the specific validation (add logging, modify input, check state)
-2. **Observe**: What happened? Does it confirm or eliminate?
-3. **Record**: Document result before moving to next hypothesis
-4. **Refine**: If partially confirmed, narrow the hypothesis
-
-Track progress:
-```
-Attempt 1/5: Testing H1 — {result} → {confirmed/eliminated/narrowed}
-Attempt 2/5: Testing H2 — {result} → {confirmed/eliminated/narrowed}
-```
-
-Stop at `max_attempts` from config (default: 5). If root cause not found, report what was eliminated and recommend next steps.
-
-### Phase 4 — Root Cause Identification
-When found:
-1. State the root cause in one sentence
-2. Explain the causal chain: trigger → intermediate effects → symptom
-3. Explain WHY the code was vulnerable to this (design gap, missing validation, etc.)
-
-### Phase 5 — Fix Implementation
-
-<HARD-GATE>
-Do NOT implement a fix until the root cause has been identified in Phase 4.
-Do NOT fix symptoms — the fix MUST address the root cause.
-If the root cause is still unknown after max_attempts, escalate to human instead of guessing.
-</HARD-GATE>
-
-1. Implement the minimal fix
-2. Add a regression test that fails without the fix
-3. Run the full test suite to verify no regressions
-4. If the fix reveals a systemic issue, note it for `pattern-detection`
-
-### Phase 6 — Prevention
-1. Identify what would have caught this earlier (better tests, type safety, validation)
-2. Suggest ONE concrete prevention measure
-
-## Tools Required
-
-- `codebase` — Read failing code, trace call chains
-- `terminal` — Run code, execute tests, check logs
-- `catalyst_git_log` — Check recent changes
-- `catalyst_git_diff` — Compare working vs. broken state
-
-## Output Format
-
-```
-## [Catalyst → Root Cause Analysis]
-
-### Symptom
-{error/behavior description}
-
-### Investigation
-{hypothesis table}
-
-### Elimination Log
-{attempt-by-attempt results}
-
-### Root Cause
-**{one sentence}**
-
-Causal chain:
-{trigger} → {intermediate} → {symptom}
-
-**Design gap**: {why code was vulnerable}
-
-### Fix
-{code change with explanation}
-
-### Regression Test
-{test that validates the fix}
-
-### Prevention
-{one concrete measure}
-```
-
-## Chains To
-
-- `test-first` — Write the regression test
-- `code-quality` — Review the fix for quality
-- `pattern-detection` — If this reveals a systemic issue
-- `knowledge-base` — Store the root cause for future reference
-
-## Anti-Patterns
-
-- Do NOT guess the fix without testing hypotheses
-- Do NOT exceed max_attempts — report what you know and escalate
-- Do NOT fix the symptom without finding the root cause
-- Do NOT skip the regression test
-- Do NOT modify code while investigating (observe first, fix after)
+# Root Cause Analysis
+
+> **Pillar**: Engineer | **ID**: `engineer-root-cause-analysis`
+
+## Purpose
+
+Systematic debugging that finds the actual root cause, not just the symptom. Uses a structured hypothesis-test-eliminate approach with a maximum attempt budget to prevent rabbit holes.
+
+## Activation Triggers
+
+- "debug this", "fix this error", "why is this crashing", "investigate"
+- "root cause", "not working", "broken", "unexpected behavior"
+- Any error message, stack trace, or unexpected output
+
+## Methodology
+
+### Process Flow
+
+```dot
+digraph root_cause_analysis {
+    rankdir=TB;
+    node [shape=box];
+
+    symptoms [label="Phase 1\nSymptom Collection"];
+    hypotheses [label="Phase 2\nHypothesis Generation\n(2-3 ranked)"];
+    eliminate [label="Phase 3\nSystematic Elimination", shape=diamond];
+    root_cause [label="Phase 4\nRoot Cause Identified"];
+    fix [label="Phase 5\nFix Implementation"];
+    prevent [label="Phase 6\nPrevention", shape=doublecircle];
+    escalate [label="Escalate to Human", shape=octagon, style=filled, fillcolor="#ff9999"];
+
+    symptoms -> hypotheses;
+    hypotheses -> eliminate;
+    eliminate -> root_cause [label="confirmed"];
+    eliminate -> hypotheses [label="all eliminated\nrefine"];
+    eliminate -> escalate [label="max_attempts\nreached"];
+    root_cause -> fix;
+    fix -> prevent;
+}
+```
+
+### Phase 1 — Symptom Collection
+1. Gather all available evidence:
+   - Error message / stack trace
+   - Steps to reproduce
+   - When it started (recent changes?)
+   - Environment details (dev/staging/prod, OS, runtime version)
+2. Reproduce the issue if possible (run the failing code/test)
+3. Check git log for recent changes to affected files
+
+### Phase 2 — Hypothesis Generation
+Generate 2-3 ranked hypotheses:
+
+| # | Hypothesis | Likelihood | Evidence | How to Test |
+|---|---|---|---|---|
+| H1 | {most likely cause} | High | {what points here} | {test strategy} |
+| H2 | {alternative cause} | Medium | {what points here} | {test strategy} |
+| H3 | {edge case cause} | Low | {what points here} | {test strategy} |
+
+### Phase 3 — Systematic Elimination
+For each hypothesis (highest likelihood first):
+1. **Test**: Run the specific validation (add logging, modify input, check state)
+2. **Observe**: What happened? Does it confirm or eliminate?
+3. **Record**: Document result before moving to next hypothesis
+4. **Refine**: If partially confirmed, narrow the hypothesis
+
+Track progress:
+```
+Attempt 1/5: Testing H1 — {result} → {confirmed/eliminated/narrowed}
+Attempt 2/5: Testing H2 — {result} → {confirmed/eliminated/narrowed}
+```
+
+Stop at `max_attempts` from config (default: 5). If root cause not found, report what was eliminated and recommend next steps.
+
+### Phase 4 — Root Cause Identification
+When found:
+1. State the root cause in one sentence
+2. Explain the causal chain: trigger → intermediate effects → symptom
+3. Explain WHY the code was vulnerable to this (design gap, missing validation, etc.)
+
+### Phase 5 — Fix Implementation
+
+<HARD-GATE>
+Do NOT implement a fix until the root cause has been identified in Phase 4.
+Do NOT fix symptoms — the fix MUST address the root cause.
+If the root cause is still unknown after max_attempts, escalate to human instead of guessing.
+</HARD-GATE>
+
+1. Implement the minimal fix
+2. Add a regression test that fails without the fix
+3. Run the full test suite to verify no regressions
+4. If the fix reveals a systemic issue, note it for `pattern-detection`
+
+### Phase 6 — Prevention
+1. Identify what would have caught this earlier (better tests, type safety, validation)
+2. Suggest ONE concrete prevention measure
+
+## Tools Required
+
+- `codebase` — Read failing code, trace call chains
+- `terminal` — Run code, execute tests, check logs
+- `catalyst_git_log` — Check recent changes
+- `catalyst_git_diff` — Compare working vs. broken state
+
+## Output Format
+
+```
+## [Catalyst → Root Cause Analysis]
+
+### Symptom
+{error/behavior description}
+
+### Investigation
+{hypothesis table}
+
+### Elimination Log
+{attempt-by-attempt results}
+
+### Root Cause
+**{one sentence}**
+
+Causal chain:
+{trigger} → {intermediate} → {symptom}
+
+**Design gap**: {why code was vulnerable}
+
+### Fix
+{code change with explanation}
+
+### Regression Test
+{test that validates the fix}
+
+### Prevention
+{one concrete measure}
+```
+
+## Chains To
+
+- `test-first` — Write the regression test
+- `code-quality` — Review the fix for quality
+- `pattern-detection` — If this reveals a systemic issue
+- `knowledge-base` — Store the root cause for future reference
+
+## Anti-Patterns
+
+- Do NOT guess the fix without testing hypotheses
+- Do NOT exceed max_attempts — report what you know and escalate
+- Do NOT fix the symptom without finding the root cause
+- Do NOT skip the regression test
+- Do NOT modify code while investigating (observe first, fix after)

package/prompts/skills/engineer-test-first/SKILL.md

@@ -1,148 +1,148 @@
-# Test First
-
-> **Pillar**: Engineer | **ID**: `engineer-test-first`
-
-## Purpose
-
-Test-Driven Development enforcement. Write tests before implementation, use tests as specification, achieve meaningful coverage — not vanity metrics.
-
-## Activation Triggers
-
-- "write tests", "TDD", "test first", "unit test", "test coverage"
-- "add test cases", "what should I test"
-- Automatically chained before `feature-builder` when enforcement is `strict`
-
-## Methodology
-
-### Process Flow
-
-```dot
-digraph test_first {
-    rankdir=LR;
-    node [shape=box];
-
-    strategy [label="Phase 1\nTest Strategy"];
-    design [label="Phase 2\nTest Case Design"];
-    red [label="Phase 3\nRED\nWrite Failing Tests", style=filled, fillcolor="#ffcccc"];
-    green [label="Phase 4\nGREEN\nMinimal Implementation", style=filled, fillcolor="#ccffcc"];
-    refactor [label="Phase 5\nREFACTOR\nClean Up", style=filled, fillcolor="#ccccff"];
-    coverage [label="Phase 6\nCoverage Check"];
-    next [label="Next behavior", shape=ellipse];
-
-    strategy -> design;
-    design -> red;
-    red -> red [label="test passes\nimmediately?\nfix test"];
-    red -> green [label="test fails\ncorrectly"];
-    green -> green [label="test still fails?\nfix code"];
-    green -> refactor [label="all pass"];
-    refactor -> green [label="test broke?\nfix"];
-    refactor -> coverage;
-    coverage -> next [label="more behaviors"];
-    next -> red;
-}
-```
-
-### Phase 1 — Test Strategy
-1. Identify what's being tested: function, class, API endpoint, workflow
-2. Determine test type needed:
-   - **Unit**: Isolated function/method behavior
-   - **Integration**: Component interactions, API calls, DB queries
-   - **E2E**: Full user journey (only when explicitly requested)
-3. Follow existing test patterns in the project (framework, naming, file location)
-4. Locate the test runner config and understand the test command
-
-### Phase 2 — Test Case Design
-For each function/component, design test cases across:
-
-| Category | Examples |
-|---|---|
-| **Happy path** | Valid inputs producing expected outputs |
-| **Edge cases** | Empty inputs, boundary values, single element, max size |
-| **Error cases** | Invalid inputs, null/undefined, malformed data |
-| **State transitions** | Before/after, concurrent access, cleanup |
-
-Present as a test plan:
-```
-describe('{subject}')
-  ✓ should {expected behavior} when {condition}
-  ✓ should {expected behavior} when {edge case}
-  ✗ should throw/return error when {invalid condition}
-```
-
-### Phase 3 — Red (Write Failing Tests)
-
-<HARD-GATE>
-Do NOT write any production/implementation code until failing tests exist.
-If you find yourself writing implementation first, STOP, delete it, and write the test.
-Tests MUST fail before any implementation begins. No exceptions.
-</HARD-GATE>
-
-1. Write the test cases with proper assertions
-2. Use descriptive test names that read as specifications
-3. Set up fixtures/mocks using the project's existing patterns
-4. Run the tests — they MUST fail (red phase)
-5. If tests pass immediately, they're not testing new behavior
-
-### Phase 4 — Green (Minimal Implementation)
-1. Write the minimum code to make tests pass
-2. No optimization, no elegance — just make it work
-3. Run tests — all must pass
-
-### Phase 5 — Refactor
-1. Clean up the implementation while tests stay green
-2. Remove duplication
-3. Improve naming
-4. Extract helpers if needed
-5. Run tests after each refactor step
-
-### Phase 6 — Coverage Check
-1. Run coverage tool
-2. Check against `min_coverage` from config (default: 80%)
-3. Identify uncovered branches — add tests only for meaningful gaps
-4. Do NOT chase 100% — test behavior, not lines
-
-## Tools Required
-
-- `codebase` — Find existing test patterns, test config
-- `findTestFiles` — Locate related test files
-- `terminal` — Run tests, run coverage
-- `catalyst_metrics_coverage` — Get coverage report
-
-## Output Format
-
-```
-## [Catalyst → Test First]
-
-### Test Strategy
-- Type: {unit/integration/e2e}
-- Framework: {detected framework}
-- Test file: {path}
-
-### Test Plan
-{describe/it outline}
-
-### Results
-| Phase | Status |
-|---|---|
-| Red (failing tests) | {N} tests written, all fail ✓ |
-| Green (passing) | All {N} pass ✓ |
-| Refactor | Clean, tests still pass ✓ |
-| Coverage | {%} (target: {min_coverage}%) |
-
-### Tests Written
-{list of test files created/modified}
-```
-
-## Chains To
-
-- `feature-builder` — After tests are written, implement the feature
-- `code-quality` — Review the implementation after TDD cycle
-- `change-management` — Commit the TDD cycle
-
-## Anti-Patterns
-
-- Do NOT write tests after implementation and call it TDD
-- Do NOT mock everything — test real behavior where feasible
-- Do NOT write tests that test the framework instead of your code
-- Do NOT skip the red phase — every test must fail first
-- Do NOT chase coverage numbers with meaningless assertions
+# Test First
+
+> **Pillar**: Engineer | **ID**: `engineer-test-first`
+
+## Purpose
+
+Test-Driven Development enforcement. Write tests before implementation, use tests as specification, achieve meaningful coverage — not vanity metrics.
+
+## Activation Triggers
+
+- "write tests", "TDD", "test first", "unit test", "test coverage"
+- "add test cases", "what should I test"
+- Automatically chained before `feature-builder` when enforcement is `strict`
+
+## Methodology
+
+### Process Flow
+
+```dot
+digraph test_first {
+    rankdir=LR;
+    node [shape=box];
+
+    strategy [label="Phase 1\nTest Strategy"];
+    design [label="Phase 2\nTest Case Design"];
+    red [label="Phase 3\nRED\nWrite Failing Tests", style=filled, fillcolor="#ffcccc"];
+    green [label="Phase 4\nGREEN\nMinimal Implementation", style=filled, fillcolor="#ccffcc"];
+    refactor [label="Phase 5\nREFACTOR\nClean Up", style=filled, fillcolor="#ccccff"];
+    coverage [label="Phase 6\nCoverage Check"];
+    next [label="Next behavior", shape=ellipse];
+
+    strategy -> design;
+    design -> red;
+    red -> red [label="test passes\nimmediately?\nfix test"];
+    red -> green [label="test fails\ncorrectly"];
+    green -> green [label="test still fails?\nfix code"];
+    green -> refactor [label="all pass"];
+    refactor -> green [label="test broke?\nfix"];
+    refactor -> coverage;
+    coverage -> next [label="more behaviors"];
+    next -> red;
+}
+```
+
+### Phase 1 — Test Strategy
+1. Identify what's being tested: function, class, API endpoint, workflow
+2. Determine test type needed:
+   - **Unit**: Isolated function/method behavior
+   - **Integration**: Component interactions, API calls, DB queries
+   - **E2E**: Full user journey (only when explicitly requested)
+3. Follow existing test patterns in the project (framework, naming, file location)
+4. Locate the test runner config and understand the test command
+
+### Phase 2 — Test Case Design
+For each function/component, design test cases across:
+
+| Category | Examples |
+|---|---|
+| **Happy path** | Valid inputs producing expected outputs |
+| **Edge cases** | Empty inputs, boundary values, single element, max size |
+| **Error cases** | Invalid inputs, null/undefined, malformed data |
+| **State transitions** | Before/after, concurrent access, cleanup |
+
+Present as a test plan:
+```
+describe('{subject}')
+  ✓ should {expected behavior} when {condition}
+  ✓ should {expected behavior} when {edge case}
+  ✗ should throw/return error when {invalid condition}
+```
+
+### Phase 3 — Red (Write Failing Tests)
+
+<HARD-GATE>
+Do NOT write any production/implementation code until failing tests exist.
+If you find yourself writing implementation first, STOP, delete it, and write the test.
+Tests MUST fail before any implementation begins. No exceptions.
+</HARD-GATE>
+
+1. Write the test cases with proper assertions
+2. Use descriptive test names that read as specifications
+3. Set up fixtures/mocks using the project's existing patterns
+4. Run the tests — they MUST fail (red phase)
+5. If tests pass immediately, they're not testing new behavior
+
+### Phase 4 — Green (Minimal Implementation)
+1. Write the minimum code to make tests pass
+2. No optimization, no elegance — just make it work
+3. Run tests — all must pass
+
+### Phase 5 — Refactor
+1. Clean up the implementation while tests stay green
+2. Remove duplication
+3. Improve naming
+4. Extract helpers if needed
+5. Run tests after each refactor step
+
+### Phase 6 — Coverage Check
+1. Run coverage tool
+2. Check against `min_coverage` from config (default: 80%)
+3. Identify uncovered branches — add tests only for meaningful gaps
+4. Do NOT chase 100% — test behavior, not lines
+
+## Tools Required
+
+- `codebase` — Find existing test patterns, test config
+- `findTestFiles` — Locate related test files
+- `terminal` — Run tests, run coverage
+- `catalyst_metrics_coverage` — Get coverage report
+
+## Output Format
+
+```
+## [Catalyst → Test First]
+
+### Test Strategy
+- Type: {unit/integration/e2e}
+- Framework: {detected framework}
+- Test file: {path}
+
+### Test Plan
+{describe/it outline}
+
+### Results
+| Phase | Status |
+|---|---|
+| Red (failing tests) | {N} tests written, all fail ✓ |
+| Green (passing) | All {N} pass ✓ |
+| Refactor | Clean, tests still pass ✓ |
+| Coverage | {%} (target: {min_coverage}%) |
+
+### Tests Written
+{list of test files created/modified}
+```
+
+## Chains To
+
+- `feature-builder` — After tests are written, implement the feature
+- `code-quality` — Review the implementation after TDD cycle
+- `change-management` — Commit the TDD cycle
+
+## Anti-Patterns
+
+- Do NOT write tests after implementation and call it TDD
+- Do NOT mock everything — test real behavior where feasible
+- Do NOT write tests that test the framework instead of your code
+- Do NOT skip the red phase — every test must fail first
+- Do NOT chase coverage numbers with meaningless assertions