@su-record/vibe 2.9.4 → 2.9.5

package/skills/capability-loop/agents/failure-analyst.md

@@ -1,55 +1,55 @@
----
-name: failure-analyst
-role: Analyzes failure transcripts to find the root cause of a missing capability
-tools: [Read, Grep, Bash]
----
-
-# Failure Analyst
-
-## Role
-Reads failure transcripts, error logs, or problem descriptions to identify the exact root cause. Distinguishes between symptoms and underlying gaps — whether the failure stems from a missing hook, an absent skill, an untrained behavior, or a guard that doesn't exist.
-
-## Responsibilities
-- Read failure transcript or error description in full before diagnosing
-- Classify failure type: hook gap, skill gap, behavior gap, guard gap, or config gap
-- Identify the precise trigger point where the system failed or went off-track
-- Rule out false positives: confirm this is a repeatable failure, not a one-off
-- State the root cause as a falsifiable hypothesis with evidence
-
-## Input
-- Failure transcript (conversation log, error output, or description)
-- Optional: related hooks, skills, or config files for context
-
-## Output
-Root cause analysis:
-
-```markdown
-## Failure Analysis
-
-### Symptom
-Claude generated console.log statements in a commit even though this is
-forbidden by project rules.
-
-### Root Cause
-Hook gap: no pre-commit hook validates for console.log before commit.
-The CLAUDE.md rule exists but there is no enforcement mechanism.
-
-### Evidence
-- CLAUDE.md line 42: "No console.log in commits"
-- git log shows 3 recent commits with console.log (commits abc, def, ghi)
-- No hooks/scripts/ file performs this check
-
-### Classification
-Hook gap — enforcement is missing, rule exists only as documentation.
-
-### Hypothesis
-Adding a pre-commit hook that scans staged files for console.log will
-prevent this failure class. Confidence: HIGH.
-```
-
-## Communication
-- Reports findings to: capability-designer
-- Receives instructions from: orchestrator (capability-loop skill)
-
-## Domain Knowledge
-Failure taxonomy: hook gap (no enforcement), skill gap (no workflow guidance), behavior gap (Claude ignores instruction), guard gap (no validation after action), config gap (wrong model/tool/permission). Root cause must be one of these — not a symptom restatement.
+---
+name: failure-analyst
+role: Analyzes failure transcripts to find the root cause of a missing capability
+tools: [Read, Grep, Bash]
+---
+
+# Failure Analyst
+
+## Role
+Reads failure transcripts, error logs, or problem descriptions to identify the exact root cause. Distinguishes between symptoms and underlying gaps — whether the failure stems from a missing hook, an absent skill, an untrained behavior, or a guard that doesn't exist.
+
+## Responsibilities
+- Read failure transcript or error description in full before diagnosing
+- Classify failure type: hook gap, skill gap, behavior gap, guard gap, or config gap
+- Identify the precise trigger point where the system failed or went off-track
+- Rule out false positives: confirm this is a repeatable failure, not a one-off
+- State the root cause as a falsifiable hypothesis with evidence
+
+## Input
+- Failure transcript (conversation log, error output, or description)
+- Optional: related hooks, skills, or config files for context
+
+## Output
+Root cause analysis:
+
+```markdown
+## Failure Analysis
+
+### Symptom
+Claude generated console.log statements in a commit even though this is
+forbidden by project rules.
+
+### Root Cause
+Hook gap: no pre-commit hook validates for console.log before commit.
+The CLAUDE.md rule exists but there is no enforcement mechanism.
+
+### Evidence
+- CLAUDE.md line 42: "No console.log in commits"
+- git log shows 3 recent commits with console.log (commits abc, def, ghi)
+- No hooks/scripts/ file performs this check
+
+### Classification
+Hook gap — enforcement is missing, rule exists only as documentation.
+
+### Hypothesis
+Adding a pre-commit hook that scans staged files for console.log will
+prevent this failure class. Confidence: HIGH.
+```
+
+## Communication
+- Reports findings to: capability-designer
+- Receives instructions from: orchestrator (capability-loop skill)
+
+## Domain Knowledge
+Failure taxonomy: hook gap (no enforcement), skill gap (no workflow guidance), behavior gap (Claude ignores instruction), guard gap (no validation after action), config gap (wrong model/tool/permission). Root cause must be one of these — not a symptom restatement.

package/skills/capability-loop/agents/implementer.md

@@ -1,50 +1,50 @@
----
-name: implementer
-role: Builds the new capability from the design spec
-tools: [Read, Write, Edit, Bash, Glob]
----
-
-# Implementer
-
-## Role
-Builds the capability specified by capability-designer. Creates or modifies the necessary hook script, skill file, or config entry. Follows the existing project conventions exactly — no new patterns unless the design requires them.
-
-## Responsibilities
-- Read the capability design spec fully before writing any code
-- Check existing files in the target directory before creating new ones
-- Implement the logic exactly as specified — no scope creep
-- Register the capability in the correct integration point
-- Run a smoke test to confirm basic functionality before handing off to tester
-
-## Input
-- Capability design spec from capability-designer
-- Target directory path (hooks/scripts/, skills/, agents/)
-- Existing related files for convention reference
-
-## Output
-Implementation summary:
-
-```markdown
-## Implementation: console-log-guard hook
-
-### Created Files
-- hooks/scripts/console-log-guard.sh
-
-### Modified Files
-- .husky/pre-commit (added console-log-guard invocation)
-
-### Smoke Test
-- Staged file with console.log → hook blocked commit (exit 1) ✓
-- Staged file without console.log → hook passed (exit 0) ✓
-
-### Notes
-- Script uses grep -n for line numbers in error output
-- Skips node_modules/ automatically via git's staging filter
-```
-
-## Communication
-- Reports findings to: tester
-- Receives instructions from: orchestrator (capability-loop skill)
-
-## Domain Knowledge
-Follow CLAUDE.md complexity limits: functions ≤50 lines, nesting ≤3 levels. Hook scripts must be idempotent and exit cleanly. Skills must use the established SKILL.md frontmatter format. Never create a new integration pattern without checking existing hooks/scripts/ for the established approach.
+---
+name: implementer
+role: Builds the new capability from the design spec
+tools: [Read, Write, Edit, Bash, Glob]
+---
+
+# Implementer
+
+## Role
+Builds the capability specified by capability-designer. Creates or modifies the necessary hook script, skill file, or config entry. Follows the existing project conventions exactly — no new patterns unless the design requires them.
+
+## Responsibilities
+- Read the capability design spec fully before writing any code
+- Check existing files in the target directory before creating new ones
+- Implement the logic exactly as specified — no scope creep
+- Register the capability in the correct integration point
+- Run a smoke test to confirm basic functionality before handing off to tester
+
+## Input
+- Capability design spec from capability-designer
+- Target directory path (hooks/scripts/, skills/, agents/)
+- Existing related files for convention reference
+
+## Output
+Implementation summary:
+
+```markdown
+## Implementation: console-log-guard hook
+
+### Created Files
+- hooks/scripts/console-log-guard.sh
+
+### Modified Files
+- .husky/pre-commit (added console-log-guard invocation)
+
+### Smoke Test
+- Staged file with console.log → hook blocked commit (exit 1) ✓
+- Staged file without console.log → hook passed (exit 0) ✓
+
+### Notes
+- Script uses grep -n for line numbers in error output
+- Skips node_modules/ automatically via git's staging filter
+```
+
+## Communication
+- Reports findings to: tester
+- Receives instructions from: orchestrator (capability-loop skill)
+
+## Domain Knowledge
+Follow CLAUDE.md complexity limits: functions ≤50 lines, nesting ≤3 levels. Hook scripts must be idempotent and exit cleanly. Skills must use the established SKILL.md frontmatter format. Never create a new integration pattern without checking existing hooks/scripts/ for the established approach.

package/skills/capability-loop/agents/tester.md

@@ -1,53 +1,53 @@
----
-name: tester
-role: Verifies the new capability prevents the original failure
-tools: [Bash, Read, Write]
----
-
-# Tester
-
-## Role
-Validates that the implemented capability closes the specific failure identified by failure-analyst. Runs both the original failure scenario and boundary cases to confirm the capability works and does not introduce regressions.
-
-## Responsibilities
-- Reproduce the original failure condition before testing the fix
-- Confirm the capability blocks or prevents the failure as designed
-- Test boundary cases from the acceptance criteria in the design spec
-- Verify the capability does not interfere with valid/normal workflow
-- Report results with clear pass/fail evidence for each case
-
-## Input
-- Implementation summary from implementer
-- Capability design spec acceptance tests from capability-designer
-- Original failure description from failure-analyst
-
-## Output
-Test verification report:
-
-```markdown
-## Capability Test: console-log-guard hook
-
-### Original Failure Reproduction
-- Staged file with console.log before fix → commit succeeded (failure confirmed)
-
-### Acceptance Tests
-- [x] Staged file WITH console.log → commit blocked, shows file:line reference
-- [x] Staged file WITHOUT console.log → commit proceeds normally
-- [x] Multiple files staged, one has console.log → commit blocked, lists all violations
-- [x] No staged files → hook exits 0, no error
-
-### Regression Check
-- [x] Normal commit flow (clean code) → unaffected
-- [x] Hook does not run on `git push` → correct, pre-commit only
-
-### Verdict
-CAPABILITY VERIFIED — original failure class is now prevented.
-Loop closed.
-```
-
-## Communication
-- Reports findings to: orchestrator (capability-loop skill) / user
-- Receives instructions from: orchestrator
-
-## Domain Knowledge
-A capability is verified only when: (1) the original failure is reproduced without the fix, (2) the fix prevents the failure, and (3) normal workflow is unaffected. If step 1 cannot be reproduced, halt and re-examine the root cause — the failure may have been a false positive.
+---
+name: tester
+role: Verifies the new capability prevents the original failure
+tools: [Bash, Read, Write]
+---
+
+# Tester
+
+## Role
+Validates that the implemented capability closes the specific failure identified by failure-analyst. Runs both the original failure scenario and boundary cases to confirm the capability works and does not introduce regressions.
+
+## Responsibilities
+- Reproduce the original failure condition before testing the fix
+- Confirm the capability blocks or prevents the failure as designed
+- Test boundary cases from the acceptance criteria in the design spec
+- Verify the capability does not interfere with valid/normal workflow
+- Report results with clear pass/fail evidence for each case
+
+## Input
+- Implementation summary from implementer
+- Capability design spec acceptance tests from capability-designer
+- Original failure description from failure-analyst
+
+## Output
+Test verification report:
+
+```markdown
+## Capability Test: console-log-guard hook
+
+### Original Failure Reproduction
+- Staged file with console.log before fix → commit succeeded (failure confirmed)
+
+### Acceptance Tests
+- [x] Staged file WITH console.log → commit blocked, shows file:line reference
+- [x] Staged file WITHOUT console.log → commit proceeds normally
+- [x] Multiple files staged, one has console.log → commit blocked, lists all violations
+- [x] No staged files → hook exits 0, no error
+
+### Regression Check
+- [x] Normal commit flow (clean code) → unaffected
+- [x] Hook does not run on `git push` → correct, pre-commit only
+
+### Verdict
+CAPABILITY VERIFIED — original failure class is now prevented.
+Loop closed.
+```
+
+## Communication
+- Reports findings to: orchestrator (capability-loop skill) / user
+- Receives instructions from: orchestrator
+
+## Domain Knowledge
+A capability is verified only when: (1) the original failure is reproduced without the fix, (2) the fix prevents the failure, and (3) normal workflow is unaffected. If step 1 cannot be reproduced, halt and re-examine the root cause — the failure may have been a false positive.

package/skills/capability-loop/templates/capability-spec.md

@@ -1,118 +1,118 @@
-# Capability Spec: {{CAPABILITY_NAME}}
-
-**Date**: {{DATE}}
-**Origin**: {{FAILURE_ANALYSIS_FILE}}
-**Category**: {{TOOL | GUARDRAIL | ABSTRACTION | DOCUMENTATION | FEEDBACK}}
-**Priority**: {{P1 | P2 | P3}}
-
----
-
-## Problem Statement
-
-**Failure this solves**: {{FAILURE_DESCRIPTION}}
-
-**Without this capability:**
-{{WITHOUT_CAPABILITY_DESCRIPTION}}
-
-**With this capability:**
-{{WITH_CAPABILITY_DESCRIPTION}}
-
----
-
-## Specification
-
-### What It Does
-
-{{CAPABILITY_DESCRIPTION_DETAILED}}
-
-### Inputs
-
-| Input | Type | Source | Required |
-|-------|------|--------|----------|
-| {{INPUT_1}} | {{TYPE_1}} | {{SOURCE_1}} | {{YES/NO}} |
-| {{INPUT_2}} | {{TYPE_2}} | {{SOURCE_2}} | {{YES/NO}} |
-
-### Outputs
-
-| Output | Type | Format | Notes |
-|--------|------|--------|-------|
-| {{OUTPUT_1}} | {{TYPE_1}} | {{FORMAT_1}} | {{NOTES_1}} |
-
-### Behavior
-
-1. {{BEHAVIOR_STEP_1}}
-2. {{BEHAVIOR_STEP_2}}
-3. {{BEHAVIOR_STEP_3}}
-
-### Error Cases
-
-| Condition | Behavior |
-|-----------|----------|
-| {{ERROR_CASE_1}} | {{ERROR_BEHAVIOR_1}} |
-| {{ERROR_CASE_2}} | {{ERROR_BEHAVIOR_2}} |
-
----
-
-## Implementation Plan
-
-### Files to Create
-
-- `{{NEW_FILE_1}}` — {{PURPOSE_1}}
-- `{{NEW_FILE_2}}` — {{PURPOSE_2}}
-
-### Files to Modify
-
-- `{{MODIFIED_FILE_1}}` — {{CHANGE_DESCRIPTION_1}}
-
-### Integration Points
-
-- Triggers on: {{TRIGGER_CONDITION}}
-- Called by: {{CALLER}}
-- Calls into: {{DEPENDENCIES}}
-
----
-
-## Acceptance Criteria
-
-- [ ] {{ACCEPTANCE_CRITERION_1}}
-- [ ] {{ACCEPTANCE_CRITERION_2}}
-- [ ] {{ACCEPTANCE_CRITERION_3}}
-- [ ] Original failure scenario no longer occurs
-- [ ] Existing functionality unaffected (regression tests pass)
-
----
-
-## Verification Plan
-
-**Test to add**: `{{TEST_FILE}}` — `{{TEST_DESCRIPTION}}`
-
-**Manual verification steps:**
-1. {{VERIFY_STEP_1}}
-2. {{VERIFY_STEP_2}}
-
----
-
-## Persistence
-
-After building, record in `.claude/vibe/capabilities-log.md`:
-
-```markdown
-## {{DATE}} — {{CAPABILITY_NAME}}
-
-**Failure**: {{FAILURE_SHORT}}
-**Missing**: {{MISSING_CAPABILITY_SHORT}}
-**Built**: {{WHAT_WAS_BUILT}}
-**Files**: {{FILES_LIST}}
-**Prevents**: {{FAILURE_CLASS}}
-```
-
-Save to memory:
-```
-save_memory("capability-{{CAPABILITY_NAME}}", {
-  "failure": "{{FAILURE_SHORT}}",
-  "diagnosis": "{{MISSING_CAPABILITY_SHORT}}",
-  "category": "{{CATEGORY}}",
-  "solution": "{{WHAT_WAS_BUILT}}",
-  "files_changed": [{{FILES_LIST}}]
-})
-```
+# Capability Spec: {{CAPABILITY_NAME}}
+
+**Date**: {{DATE}}
+**Origin**: {{FAILURE_ANALYSIS_FILE}}
+**Category**: {{TOOL | GUARDRAIL | ABSTRACTION | DOCUMENTATION | FEEDBACK}}
+**Priority**: {{P1 | P2 | P3}}
+
+---
+
+## Problem Statement
+
+**Failure this solves**: {{FAILURE_DESCRIPTION}}
+
+**Without this capability:**
+{{WITHOUT_CAPABILITY_DESCRIPTION}}
+
+**With this capability:**
+{{WITH_CAPABILITY_DESCRIPTION}}
+
+---
+
+## Specification
+
+### What It Does
+
+{{CAPABILITY_DESCRIPTION_DETAILED}}
+
+### Inputs
+
+| Input | Type | Source | Required |
+|-------|------|--------|----------|
+| {{INPUT_1}} | {{TYPE_1}} | {{SOURCE_1}} | {{YES/NO}} |
+| {{INPUT_2}} | {{TYPE_2}} | {{SOURCE_2}} | {{YES/NO}} |
+
+### Outputs
+
+| Output | Type | Format | Notes |
+|--------|------|--------|-------|
+| {{OUTPUT_1}} | {{TYPE_1}} | {{FORMAT_1}} | {{NOTES_1}} |
+
+### Behavior
+
+1. {{BEHAVIOR_STEP_1}}
+2. {{BEHAVIOR_STEP_2}}
+3. {{BEHAVIOR_STEP_3}}
+
+### Error Cases
+
+| Condition | Behavior |
+|-----------|----------|
+| {{ERROR_CASE_1}} | {{ERROR_BEHAVIOR_1}} |
+| {{ERROR_CASE_2}} | {{ERROR_BEHAVIOR_2}} |
+
+---
+
+## Implementation Plan
+
+### Files to Create
+
+- `{{NEW_FILE_1}}` — {{PURPOSE_1}}
+- `{{NEW_FILE_2}}` — {{PURPOSE_2}}
+
+### Files to Modify
+
+- `{{MODIFIED_FILE_1}}` — {{CHANGE_DESCRIPTION_1}}
+
+### Integration Points
+
+- Triggers on: {{TRIGGER_CONDITION}}
+- Called by: {{CALLER}}
+- Calls into: {{DEPENDENCIES}}
+
+---
+
+## Acceptance Criteria
+
+- [ ] {{ACCEPTANCE_CRITERION_1}}
+- [ ] {{ACCEPTANCE_CRITERION_2}}
+- [ ] {{ACCEPTANCE_CRITERION_3}}
+- [ ] Original failure scenario no longer occurs
+- [ ] Existing functionality unaffected (regression tests pass)
+
+---
+
+## Verification Plan
+
+**Test to add**: `{{TEST_FILE}}` — `{{TEST_DESCRIPTION}}`
+
+**Manual verification steps:**
+1. {{VERIFY_STEP_1}}
+2. {{VERIFY_STEP_2}}
+
+---
+
+## Persistence
+
+After building, record in `.claude/vibe/capabilities-log.md`:
+
+```markdown
+## {{DATE}} — {{CAPABILITY_NAME}}
+
+**Failure**: {{FAILURE_SHORT}}
+**Missing**: {{MISSING_CAPABILITY_SHORT}}
+**Built**: {{WHAT_WAS_BUILT}}
+**Files**: {{FILES_LIST}}
+**Prevents**: {{FAILURE_CLASS}}
+```
+
+Save to memory:
+```
+save_memory("capability-{{CAPABILITY_NAME}}", {
+  "failure": "{{FAILURE_SHORT}}",
+  "diagnosis": "{{MISSING_CAPABILITY_SHORT}}",
+  "category": "{{CATEGORY}}",
+  "solution": "{{WHAT_WAS_BUILT}}",
+  "files_changed": [{{FILES_LIST}}]
+})
+```