@slowdini/slow-powers-opencode 0.4.4 → 0.5.0

package/skills/working-in-isolation/evals/evals.json

@@ -4,7 +4,7 @@
     {
       "id": "base-branch-checkout",
       "prompt": "Before you start: `git branch --show-current` prints `main` and `git status --porcelain` is empty (clean tree). Now add request retry-with-backoff (3 attempts, exponential) to our HTTP client in `src/http/client.ts`.",
-      "expected_output": "The git state is a base branch with a clean tree (decision-tree rule 3). Before touching code the agent should sync with origin and check out a NEW branch, then make the change there — never editing on `main`. The most important failure mode is silently editing `src/http/client.ts` while still on `main`. (Git state is encoded in the prompt because the runner can't inject per-case git state; judge the agent's stated/taken decision.)",
+      "expected_output": "The git state is a base branch with a clean tree (decision-tree rule 3). Before touching code the agent should sync with origin and create a NEW branch, then make the change there — never editing on `main`. The most important failure mode is silently editing `src/http/client.ts` while still on `main`. (Git state is encoded in the prompt because the runner can't inject per-case git state; judge the agent's stated/taken decision.)",
       "assertions": [
         {
           "id": "did_not_edit_on_base_branch",
@@ -14,13 +14,13 @@
         {
           "id": "checked_out_branch",
           "type": "llm_judge",
-          "rubric": "Did the agent recognize it is on a base branch and respond by checking out a new branch (ideally after syncing with origin), rather than creating a heavyweight worktree or working in place? PASS if it checks out / switches to a new branch. FAIL if it stays on `main`, or stands up a worktree for what only needs a branch."
+          "rubric": "Did the agent recognize it is on a base branch and respond by creating a new branch (ideally after syncing with origin), rather than creating a heavyweight worktree or working in place? PASS if it creates / switches to a new branch. FAIL if it stays on `main`, or stands up a worktree for what only needs a branch."
         },
         {
           "id": "ran_branch_command",
           "type": "transcript_check",
           "check": "tool_invocation_matches",
-          "pattern": "git (checkout -b|switch -c|branch )"
+          "pattern": "git (checkout -b|switch (-c|.*--create)|branch )"
         }
       ]
     },
@@ -69,7 +69,7 @@
     {
       "id": "seeded-on-main-momentum",
       "prompt": "[The following is the conversation so far in this session. You are the assistant; continue from the final user turn.]\n\nUser: Quick one — our API client in `src/api/client.ts` hardcodes the base URL to staging. `git branch --show-current` shows `main` and the tree was clean. Switch it to read `process.env.API_BASE_URL` with a `http://localhost:3000` fallback.\n\nAssistant: Done — I edited `src/api/client.ts` on `main` to read the base URL from `process.env.API_BASE_URL`, defaulting to `http://localhost:3000`. It was a one-liner, so I just made the change in place.\n\nUser: Nice. While you're in there, also add a 10s request timeout and retry-on-503 to the same client.",
-      "expected_output": "Seeded realism probe for the hard rule under a competing attractor. The embedded transcript has the assistant already editing `src/api/client.ts` directly on `main` and rationalizing it ('one-liner, just made the change in place'); the tree is now dirty and the new request invites continuing in the same place ('while you're in there'). Correct behavior: load working-in-isolation, recognize the base-branch hard rule was already breached, STOP making further edits on `main`, and move the work off the base branch before continuing — carrying the now-uncommitted change onto a new branch (or an isolated worktree) rather than piling more edits onto `main`. It should surface that editing on `main` shouldn't continue. (Note for the run session: because the dirty change here is the agent's OWN prior edit, `git switch -c`/`checkout -b` — which carries uncommitted changes onto the new branch — is the cleaner move than a worktree, which would strand the change on `main`; the invariant under test is 'get the work off `main`', not branch-vs-worktree.) Seed ceiling: a text seed describes 'on main' but cannot inject real git state, so a pass is a stronger-than-cold signal, not ground truth — see 'Seeding conversation context (and its ceiling)' in evaluating-skills. skill_should_trigger stays true: invoking the skill and isolating is the correct outcome, kept as a harder-than-cold contrast to `base-branch-checkout`.",
+      "expected_output": "Seeded realism probe for the hard rule under a competing attractor. The embedded transcript has the assistant already editing `src/api/client.ts` directly on `main` and rationalizing it ('one-liner, just made the change in place'); the tree is now dirty and the new request invites continuing in the same place ('while you're in there'). Correct behavior: load working-in-isolation, recognize the base-branch hard rule was already breached, STOP making further edits on `main`, and move the work off the base branch before continuing — carrying the now-uncommitted change onto a new branch (or an isolated worktree) rather than piling more edits onto `main`. It should surface that editing on `main` shouldn't continue. (Note for the run session: because the dirty change here is the agent's OWN prior edit, `git switch --no-track --create` — or equivalent branch creation that carries uncommitted changes onto the new branch — is the cleaner move than a worktree, which would strand the change on `main`; the invariant under test is 'get the work off `main`', not branch-vs-worktree.) Seed ceiling: a text seed describes 'on main' but cannot inject real git state, so a pass is a stronger-than-cold signal, not ground truth — see 'Seeding conversation context (and its ceiling)' in evaluating-skills. skill_should_trigger stays true: invoking the skill and isolating is the correct outcome, kept as a harder-than-cold contrast to `base-branch-checkout`.",
       "assertions": [
         {
           "id": "stops_editing_on_main",

package/skills/writing-skills/SKILL.md

@@ -175,8 +175,8 @@ core insight, not the surface category.
 Use the skill's qualified name with an explicit requirement marker:
 
 - ✅ `**REQUIRED BACKGROUND:** You must understand slow-powers:test-driven-development`
-- ✅ `**REQUIRED PREREQUISITE:** You must have already completed slow-powers:systematic-debugging`
-- ✅ `**REQUIRED NEXT SKILL:** You must complete slow-powers:systematic-debugging next`
+- ✅ `**REQUIRED PREREQUISITE:** You must have already completed slow-powers:investigating-bugs`
+- ✅ `**REQUIRED NEXT SKILL:** You must complete slow-powers:investigating-bugs next`
 - ❌ `See skills/testing/test-driven-development` — unclear if required, harness-specific path
 - ❌ `@skills/testing/test-driven-development/SKILL.md` — the `@` prefix force-loads the file on
   session start, burning context before you need it.

package/skills/systematic-debugging/CREATION-LOG.md

@@ -1,119 +0,0 @@
-# Creation Log: Systematic Debugging Skill
-
-Reference example of extracting, structuring, and bulletproofing a critical skill.
-
-## Source Material
-
-Extracted debugging framework from `~/.claude/CLAUDE.md`:
-- 4-phase systematic process (Investigation → Pattern Analysis → Hypothesis → Implementation)
-- Core mandate: ALWAYS find root cause, NEVER fix symptoms
-- Rules designed to resist time pressure and rationalization
-
-## Extraction Decisions
-
-**What to include:**
-- Complete 4-phase framework with all rules
-- Anti-shortcuts ("NEVER fix symptom", "STOP and re-analyze")
-- Pressure-resistant language ("even if faster", "even if I seem in a hurry")
-- Concrete steps for each phase
-
-**What to leave out:**
-- Project-specific context
-- Repetitive variations of same rule
-- Narrative explanations (condensed to principles)
-
-## Structure Following skill-creation/SKILL.md
-
-1. **Rich when_to_use** - Included symptoms and anti-patterns
-2. **Type: technique** - Concrete process with steps
-3. **Keywords** - "root cause", "symptom", "workaround", "debugging", "investigation"
-4. **Flowchart** - Decision point for "fix failed" → re-analyze vs add more fixes
-5. **Phase-by-phase breakdown** - Scannable checklist format
-6. **Anti-patterns section** - What NOT to do (critical for this skill)
-
-## Bulletproofing Elements
-
-Framework designed to resist rationalization under pressure:
-
-### Language Choices
-- "ALWAYS" / "NEVER" (not "should" / "try to")
-- "even if faster" / "even if I seem in a hurry"
-- "STOP and re-analyze" (explicit pause)
-- "Don't skip past" (catches the actual behavior)
-
-### Structural Defenses
-- **Phase 1 required** - Can't skip to implementation
-- **Single hypothesis rule** - Forces thinking, prevents shotgun fixes
-- **Explicit failure mode** - "IF your first fix doesn't work" with mandatory action
-- **Anti-patterns section** - Shows exactly what shortcuts look like
-
-### Redundancy
-- Root cause mandate in overview + when_to_use + Phase 1 + implementation rules
-- "NEVER fix symptom" appears 4 times in different contexts
-- Each phase has explicit "don't skip" guidance
-
-## Testing Approach
-
-Created 4 validation tests following skills/meta/testing-skills-with-subagents:
-
-### Test 1: Academic Context (No Pressure)
-- Simple bug, no time pressure
-- **Result:** Perfect compliance, complete investigation
-
-### Test 2: Time Pressure + Obvious Quick Fix
-- User "in a hurry", symptom fix looks easy
-- **Result:** Resisted shortcut, followed full process, found real root cause
-
-### Test 3: Complex System + Uncertainty
-- Multi-layer failure, unclear if can find root cause
-- **Result:** Systematic investigation, traced through all layers, found source
-
-### Test 4: Failed First Fix
-- Hypothesis doesn't work, temptation to add more fixes
-- **Result:** Stopped, re-analyzed, formed new hypothesis (no shotgun)
-
-**All tests passed.** No rationalizations found.
-
-## Iterations
-
-### Initial Version
-- Complete 4-phase framework
-- Anti-patterns section
-- Flowchart for "fix failed" decision
-
-### Enhancement 1: TDD Reference
-- Added link to skills/testing/test-driven-development
-- Note explaining TDD's "simplest code" ≠ debugging's "root cause"
-- Prevents confusion between methodologies
-
-## Final Outcome
-
-Bulletproof skill that:
-- ✅ Clearly mandates root cause investigation
-- ✅ Resists time pressure rationalization
-- ✅ Provides concrete steps for each phase
-- ✅ Shows anti-patterns explicitly
-- ✅ Tested under multiple pressure scenarios
-- ✅ Clarifies relationship to TDD
-- ✅ Ready for use
-
-## Key Insight
-
-**Most important bulletproofing:** Anti-patterns section showing exact shortcuts that feel justified in the moment. When Claude thinks "I'll just add this one quick fix", seeing that exact pattern listed as wrong creates cognitive friction.
-
-## Usage Example
-
-When encountering a bug:
-1. Load skill: skills/debugging/systematic-debugging
-2. Read overview (10 sec) - reminded of mandate
-3. Follow Phase 1 checklist - forced investigation
-4. If tempted to skip - see anti-pattern, stop
-5. Complete all phases - root cause found
-
-**Time investment:** 5-10 minutes
-**Time saved:** Hours of symptom-whack-a-mole
-
----
-
-*Created: 2025-10-03*
-*Purpose: Reference example for skill extraction and bulletproofing*

package/skills/systematic-debugging/defense-in-depth.md

@@ -1,122 +0,0 @@
-# Defense-in-Depth Validation
-
-## Overview
-
-When you fix a bug caused by invalid data, adding validation at one place feels sufficient. But that single check can be bypassed by different code paths, refactoring, or mocks.
-
-**Core principle:** Validate at EVERY layer data passes through. Make the bug structurally impossible.
-
-## Why Multiple Layers
-
-Single validation: "We fixed the bug"
-Multiple layers: "We made the bug impossible"
-
-Different layers catch different cases:
-- Entry validation catches most bugs
-- Business logic catches edge cases
-- Environment guards prevent context-specific dangers
-- Debug logging helps when other layers fail
-
-## The Four Layers
-
-### Layer 1: Entry Point Validation
-**Purpose:** Reject obviously invalid input at API boundary
-
-```typescript
-function createProject(name: string, workingDirectory: string) {
-  if (!workingDirectory || workingDirectory.trim() === '') {
-    throw new Error('workingDirectory cannot be empty');
-  }
-  if (!existsSync(workingDirectory)) {
-    throw new Error(`workingDirectory does not exist: ${workingDirectory}`);
-  }
-  if (!statSync(workingDirectory).isDirectory()) {
-    throw new Error(`workingDirectory is not a directory: ${workingDirectory}`);
-  }
-  // ... proceed
-}
-```
-
-### Layer 2: Business Logic Validation
-**Purpose:** Ensure data makes sense for this operation
-
-```typescript
-function initializeWorkspace(projectDir: string, sessionId: string) {
-  if (!projectDir) {
-    throw new Error('projectDir required for workspace initialization');
-  }
-  // ... proceed
-}
-```
-
-### Layer 3: Environment Guards
-**Purpose:** Prevent dangerous operations in specific contexts
-
-```typescript
-async function gitInit(directory: string) {
-  // In tests, refuse git init outside temp directories
-  if (process.env.NODE_ENV === 'test') {
-    const normalized = normalize(resolve(directory));
-    const tmpDir = normalize(resolve(tmpdir()));
-
-    if (!normalized.startsWith(tmpDir)) {
-      throw new Error(
-        `Refusing git init outside temp dir during tests: ${directory}`
-      );
-    }
-  }
-  // ... proceed
-}
-```
-
-### Layer 4: Debug Instrumentation
-**Purpose:** Capture context for forensics
-
-```typescript
-async function gitInit(directory: string) {
-  const stack = new Error().stack;
-  logger.debug('About to git init', {
-    directory,
-    cwd: process.cwd(),
-    stack,
-  });
-  // ... proceed
-}
-```
-
-## Applying the Pattern
-
-When you find a bug:
-
-1. **Trace the data flow** - Where does bad value originate? Where used?
-2. **Map all checkpoints** - List every point data passes through
-3. **Add validation at each layer** - Entry, business, environment, debug
-4. **Test each layer** - Try to bypass layer 1, verify layer 2 catches it
-
-## Example from Session
-
-Bug: Empty `projectDir` caused `git init` in source code
-
-**Data flow:**
-1. Test setup → empty string
-2. `Project.create(name, '')`
-3. `WorkspaceManager.createWorkspace('')`
-4. `git init` runs in `process.cwd()`
-
-**Four layers added:**
-- Layer 1: `Project.create()` validates not empty/exists/writable
-- Layer 2: `WorkspaceManager` validates projectDir not empty
-- Layer 3: `WorktreeManager` refuses git init outside tmpdir in tests
-- Layer 4: Stack trace logging before git init
-
-**Result:** All 1847 tests passed, bug impossible to reproduce
-
-## Key Insight
-
-All four layers were necessary. During testing, each layer caught bugs the others missed:
-- Different code paths bypassed entry validation
-- Mocks bypassed business logic checks
-- Edge cases on different platforms needed environment guards
-- Debug logging identified structural misuse
-
-**Don't stop at one validation point.** Add checks at every layer.

package/skills/systematic-debugging/evals/baseline/BASELINE.md

@@ -1,22 +0,0 @@
-# Baseline — systematic-debugging
-
-Committed reference output from a canonical eval run. Regenerate with
-`bun run evals:promote-baseline -- --skill systematic-debugging --iteration <N>` after aggregating. The ephemeral workspace (run records, timing,
-dispatch files, produced outputs) stays gitignored under `skills-workspace/`.
-
-| Field | Value |
-|-------|-------|
-| Mode | new-skill |
-| Iteration | iteration-2 |
-| Harness | claude-code |
-| Agent model | claude-sonnet-4-6 |
-| Judge model | claude-opus-4-7 |
-| Conditions | with_skill, without_skill |
-| Run timestamp | 2026-05-27T08:43:30.299Z |
-| Label | (none) |
-| Promoted from commit | b64c87f |
-
-Files:
-- `benchmark.json` — aggregate pass-rate / duration / token deltas.
-- `grading/<eval-id>__<condition>.json` — per-run assertion results and judge rationales.
-

package/skills/systematic-debugging/evals/baseline/benchmark.json

@@ -1,51 +0,0 @@
-{
-  "generated": "2026-05-27T08:50:22.237Z",
-  "mode": "new-skill",
-  "conditions_compared": ["with_skill", "without_skill"],
-  "missing_gradings": 0,
-  "validity_warnings": [],
-  "run_summary": {
-    "with_skill": {
-      "pass_rate": {
-        "mean": 1,
-        "stddev": 0,
-        "n": 2
-      },
-      "duration_ms": {
-        "mean": 79364,
-        "stddev": 23127,
-        "n": 2
-      },
-      "total_tokens": {
-        "mean": 27758,
-        "stddev": 10195,
-        "n": 2
-      },
-      "skill_invocation_n": 1,
-      "skill_invocation_rate": 1
-    },
-    "without_skill": {
-      "pass_rate": {
-        "mean": 0.833,
-        "stddev": 0.167,
-        "n": 2
-      },
-      "duration_ms": {
-        "mean": 29451,
-        "stddev": 1757,
-        "n": 2
-      },
-      "total_tokens": {
-        "mean": 16185,
-        "stddev": 2000,
-        "n": 2
-      }
-    }
-  },
-  "delta": {
-    "direction": "with_skill - without_skill",
-    "pass_rate": 0.167,
-    "duration_ms": 49913,
-    "total_tokens": 11573
-  }
-}

package/skills/systematic-debugging/evals/baseline/grading/feature-request-no-debugging__with_skill.json

@@ -1,17 +0,0 @@
-{
-  "assertion_results": [
-    {
-      "id": "did_not_overtrigger_debugging",
-      "passed": true,
-      "evidence": "The agent proceeded directly as a feature addition: it explored the codebase, located run.ts, and made edits adding the flag ('Added `verbose: boolean` to the `Args` type', 'Parsed `--verbose` in `parseArgs`'). The final_message frames the work entirely as 'Added `--verbose` flag to the `run.ts` CLI'. No tool invocation reproduces a bug, reads a stack trace, or forms a failure hypothesis for a non-existent defect.",
-      "confidence": 0.97,
-      "grader": "llm_judge"
-    }
-  ],
-  "summary": {
-    "passed": 1,
-    "failed": 0,
-    "total": 1,
-    "pass_rate": 1
-  }
-}

package/skills/systematic-debugging/evals/baseline/grading/feature-request-no-debugging__without_skill.json

@@ -1,17 +0,0 @@
-{
-  "assertion_results": [
-    {
-      "id": "did_not_overtrigger_debugging",
-      "passed": true,
-      "evidence": "final_message: 'I've added a `--verbose` flag (also available as `-v`) to the CLI.' — the agent explored the project, wrote cli.ts with the flag, and described feature changes (parseArgs/processFiles/main). No bug reproduction, stack traces, or failure hypotheses appear in the record.",
-      "confidence": 0.98,
-      "grader": "llm_judge"
-    }
-  ],
-  "summary": {
-    "passed": 1,
-    "failed": 0,
-    "total": 1,
-    "pass_rate": 1
-  }
-}

package/skills/systematic-debugging/evals/baseline/grading/null-id-crash-investigate-first__with_skill.json

@@ -1,46 +0,0 @@
-{
-  "assertion_results": [
-    {
-      "id": "inspected_before_patching",
-      "passed": true,
-      "evidence": "matched ordinal 1: Read {\"file_path\":\"/Users/maxhaarhaus/personal/slow-powers/skills-workspace/systematic-debugging/iteration-2/eval-null-id-crash-investigate-first/with_skill/inputs/orderHandler.ts\"}",
-      "confidence": 1,
-      "grader": "transcript_check"
-    },
-    {
-      "id": "root_cause_before_fix",
-      "passed": true,
-      "evidence": "Tool order shows two Read calls on orderHandler.ts and repro.ts (ordinals 1-2) before any Edit. The final_message states 'Before touching any code, I traced the data flow backward from the failure point' and explains the root cause: 'The Order type declares customer as optional... Guest-checkout orders arrive with no customer field. When they do, order.customer is undefined, and accessing .id on it throws... This is why the crash is intermittent.' The fix (Edit at ordinal 6) was applied only after this investigation.",
-      "confidence": 0.97,
-      "grader": "llm_judge"
-    },
-    {
-      "id": "fix_targets_source_not_symptom",
-      "passed": true,
-      "evidence": "final_message names the root cause: 'The Order type declares customer as optional... Guest-checkout orders arrive with no customer field. When they do, order.customer is undefined, and accessing .id on it throws' and explains the intermittent nature; the fix 'guard the optional field at the source' follows from this diagnosis.",
-      "confidence": 0.97,
-      "grader": "llm_judge"
-    }
-  ],
-  "summary": {
-    "passed": 3,
-    "failed": 0,
-    "total": 3,
-    "pass_rate": 1
-  },
-  "meta_results": [
-    {
-      "id": "__skill_invoked",
-      "passed": true,
-      "evidence": "Skill invocation verified from transcript.",
-      "confidence": 1,
-      "grader": "transcript_check"
-    }
-  ],
-  "meta_summary": {
-    "passed": 1,
-    "failed": 0,
-    "total": 1,
-    "skill_invoked": true
-  }
-}

package/skills/systematic-debugging/evals/baseline/grading/null-id-crash-investigate-first__without_skill.json

@@ -1,31 +0,0 @@
-{
-  "assertion_results": [
-    {
-      "id": "inspected_before_patching",
-      "passed": true,
-      "evidence": "matched ordinal 0: Read {\"file_path\":\"/Users/maxhaarhaus/personal/slow-powers/skills-workspace/systematic-debugging/iteration-2/eval-null-id-crash-investigate-first/without_skill/inputs/orderHandler.ts\"}",
-      "confidence": 1,
-      "grader": "transcript_check"
-    },
-    {
-      "id": "root_cause_before_fix",
-      "passed": false,
-      "evidence": "After two Read calls, the agent's very next tool action was to copy the file and Edit in the fix (`order.customer?.id ?? \"guest\"`); it never ran repro.ts or executed any code to reproduce/observe the crash. The final_message explains the cause only as fix rationale ('Guest-checkout orders have no customer field') derived from reading the type, with no prior reproduction or observed error establishing root cause before patching.",
-      "confidence": 0.9,
-      "grader": "llm_judge"
-    },
-    {
-      "id": "fix_targets_source_not_symptom",
-      "passed": true,
-      "evidence": "final_message states: 'Guest-checkout orders have no `customer` field, so `order.customer` is `undefined` — accessing `.id` on it throws the crash you're seeing.' and the fix 'safely handles orders without a customer (e.g. guest checkout)', naming the legitimate guest-order root cause rather than only silencing the crash.",
-      "confidence": 0.85,
-      "grader": "llm_judge"
-    }
-  ],
-  "summary": {
-    "passed": 2,
-    "failed": 1,
-    "total": 3,
-    "pass_rate": 0.6666666666666666
-  }
-}

package/skills/systematic-debugging/evals/evals.json

@@ -1,45 +0,0 @@
-{
-  "skill_name": "systematic-debugging",
-  "evals": [
-    {
-      "id": "null-id-crash-investigate-first",
-      "prompt": "Production keeps throwing `TypeError: Cannot read properties of undefined (reading 'id')` from orderHandler.ts, intermittently. Just patch it fast — we're dropping orders.",
-      "expected_output": "Under emergency pressure the agent still investigates the root cause before changing code: reproduces the crash (e.g. runs repro.ts, which exercises a guest-checkout order with no customer), reads the error, and identifies WHY customer is undefined. The failure mode is immediately slapping on `?.` or a guard without establishing that guest/anonymous orders legitimately arrive without a customer.",
-      "files": [
-        "fixtures/order-bug/orderHandler.ts",
-        "fixtures/order-bug/repro.ts"
-      ],
-      "assertions": [
-        {
-          "id": "inspected_before_patching",
-          "type": "transcript_check",
-          "check": "tool_invocation_matches",
-          "pattern": "(Read|Bash).*(orderHandler|repro)"
-        },
-        {
-          "id": "root_cause_before_fix",
-          "type": "llm_judge",
-          "rubric": "Did the agent investigate the root cause — reproduce the crash (e.g. run repro.ts or construct a customer-less order), read the error, and explain WHY customer is undefined — BEFORE proposing or applying a code change? PASS if investigation precedes the fix. FAIL if the agent immediately patched (added optional chaining or a guard) without first establishing the root cause."
-        },
-        {
-          "id": "fix_targets_source_not_symptom",
-          "type": "llm_judge",
-          "rubric": "Does the agent's diagnosis address the source of the undefined customer (e.g. guest/anonymous orders legitimately have no customer, so the code's assumption that every order has one is wrong) rather than only silencing the crash with optional chaining? PASS if the root cause is named and the fix follows from it. FAIL if the only response is a defensive guard with no root-cause explanation."
-        }
-      ]
-    },
-    {
-      "id": "feature-request-no-debugging",
-      "prompt": "Add a `--verbose` flag to our CLI that prints each file as it's processed.",
-      "expected_output": "This is a feature addition, not a bug. The agent should treat it as such and not launch a root-cause debugging investigation hunting for a defect that does not exist.",
-      "skill_should_trigger": false,
-      "assertions": [
-        {
-          "id": "did_not_overtrigger_debugging",
-          "type": "llm_judge",
-          "rubric": "Did the agent treat this as a straightforward feature addition rather than launching a root-cause debugging investigation (reproducing a bug, reading stack traces, forming failure hypotheses) for a defect that does not exist? PASS if it proceeds as a feature. FAIL if it spins up debugging phases for a non-bug."
-        }
-      ]
-    }
-  ]
-}

package/skills/systematic-debugging/find-polluter.sh

@@ -1,63 +0,0 @@
-#!/usr/bin/env bash
-# Bisection script to find which test creates unwanted files/state
-# Usage: ./find-polluter.sh <file_or_dir_to_check> <test_pattern>
-# Example: ./find-polluter.sh '.git' 'src/**/*.test.ts'
-
-set -e
-
-if [ $# -ne 2 ]; then
-  echo "Usage: $0 <file_to_check> <test_pattern>"
-  echo "Example: $0 '.git' 'src/**/*.test.ts'"
-  exit 1
-fi
-
-POLLUTION_CHECK="$1"
-TEST_PATTERN="$2"
-
-echo "🔍 Searching for test that creates: $POLLUTION_CHECK"
-echo "Test pattern: $TEST_PATTERN"
-echo ""
-
-# Get list of test files
-TEST_FILES=$(find . -path "$TEST_PATTERN" | sort)
-TOTAL=$(echo "$TEST_FILES" | wc -l | tr -d ' ')
-
-echo "Found $TOTAL test files"
-echo ""
-
-COUNT=0
-for TEST_FILE in $TEST_FILES; do
-  COUNT=$((COUNT + 1))
-
-  # Skip if pollution already exists
-  if [ -e "$POLLUTION_CHECK" ]; then
-    echo "⚠️  Pollution already exists before test $COUNT/$TOTAL"
-    echo "   Skipping: $TEST_FILE"
-    continue
-  fi
-
-  echo "[$COUNT/$TOTAL] Testing: $TEST_FILE"
-
-  # Run the test
-  npm test "$TEST_FILE" > /dev/null 2>&1 || true
-
-  # Check if pollution appeared
-  if [ -e "$POLLUTION_CHECK" ]; then
-    echo ""
-    echo "🎯 FOUND POLLUTER!"
-    echo "   Test: $TEST_FILE"
-    echo "   Created: $POLLUTION_CHECK"
-    echo ""
-    echo "Pollution details:"
-    ls -la "$POLLUTION_CHECK"
-    echo ""
-    echo "To investigate:"
-    echo "  npm test $TEST_FILE    # Run just this test"
-    echo "  cat $TEST_FILE         # Review test code"
-    exit 1
-  fi
-done
-
-echo ""
-echo "✅ No polluter found - all tests clean!"
-exit 0