@slowdini/slow-powers-opencode 0.1.0

package/skills/test-driven-development/evals/baseline/grading/slugify-under-time-pressure__with_skill.json

@@ -0,0 +1,53 @@
+{
+  "assertion_results": [
+    {
+      "id": "wrote_test_file",
+      "passed": true,
+      "evidence": "matched ordinal 3: Write {\"file_path\":\"/Users/maxhaarhaus/personal/slow-powers/skills-workspace/test-driven-development/iteration-1/eval-slugify-under-time-pressure/with_skill/outputs/utils.test.ts\",\"content\":\"import { ex",
+      "confidence": 1,
+      "grader": "transcript_check"
+    },
+    {
+      "id": "ran_tests",
+      "passed": false,
+      "evidence": "no tool invocation matched /bun (test|run test)/ across 11 invocation(s)",
+      "confidence": 1,
+      "grader": "transcript_check"
+    },
+    {
+      "id": "test_before_implementation",
+      "passed": true,
+      "evidence": "Tests were written first (ordinal 3, utils.test.ts importing slugify), the implementation file was written without slugify (ordinal 4), then `npx vitest run` (ordinal 6) showed FAIL (11) with 'TypeError: (0 , __vite_ssr_import_1__.slugify) is not a function'. Only afterward was slugify added via Edit (ordinal 7), and the subsequent run (ordinal 8) showed PASS (11) FAIL (0).",
+      "confidence": 1,
+      "grader": "llm_judge"
+    },
+    {
+      "id": "minimal_implementation",
+      "passed": true,
+      "evidence": "Implementation is exactly: `return title.toLowerCase().replace(/[^a-z0-9]+/g, '-').replace(/^-+|-+$/g, '');` — three chained operations mapping directly to lowercase, collapse non-alphanumerics to single hyphens, and trim edge hyphens. No options parameter, caching, or unrelated string handling are present.",
+      "confidence": 0.98,
+      "grader": "llm_judge"
+    }
+  ],
+  "summary": {
+    "passed": 3,
+    "failed": 1,
+    "total": 4,
+    "pass_rate": 0.75
+  },
+  "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/test-driven-development/evals/baseline/grading/slugify-under-time-pressure__without_skill.json

@@ -0,0 +1,38 @@
+{
+  "assertion_results": [
+    {
+      "id": "wrote_test_file",
+      "passed": false,
+      "evidence": "no tool invocation matched /(Write|Edit).*\\.test\\./ across 5 invocation(s)",
+      "confidence": 1,
+      "grader": "transcript_check"
+    },
+    {
+      "id": "ran_tests",
+      "passed": false,
+      "evidence": "no tool invocation matched /bun (test|run test)/ across 5 invocation(s)",
+      "confidence": 1,
+      "grader": "transcript_check"
+    },
+    {
+      "id": "test_before_implementation",
+      "passed": false,
+      "evidence": "The tool_invocations contain no test file creation or test execution. The only code-writing step is the Edit at ordinal 2 that adds the slugify implementation to utils.ts; no failing test preceded it (or followed it). The final_message only describes the implementation and never mentions writing or running a test.",
+      "confidence": 1,
+      "grader": "llm_judge"
+    },
+    {
+      "id": "minimal_implementation",
+      "passed": true,
+      "evidence": "final_message implementation: `return title.toLowerCase().replace(/[^a-z0-9]+/g, '-').replace(/^-+|-+$/g, '');` — exactly the three stated behaviors (lowercase, collapse non-alphanumerics to single hyphen, trim edge hyphens) with no configurable options, caching, or unrelated string handling.",
+      "confidence": 1,
+      "grader": "llm_judge"
+    }
+  ],
+  "summary": {
+    "passed": 1,
+    "failed": 3,
+    "total": 4,
+    "pass_rate": 0.25
+  }
+}

package/skills/test-driven-development/evals/baseline/grading/tests-after-rubber-stamp__with_skill.json

@@ -0,0 +1,32 @@
+{
+  "assertion_results": [
+    {
+      "id": "flags_tests_after_antipattern",
+      "passed": true,
+      "evidence": "final_message recommends the test-first discipline rather than silently rubber-stamping: 'The user mentioned they \"already manually tested parseDate()\" — manual testing is not TDD. The proper workflow required: 1. Delete any existing implementation 2. Write the test first (RED) 3. Watch it fail 4. Write minimal code to pass (GREEN)...' and 'NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST'. The agent explicitly pushed back on tests-after and re-derived the code under a RED-GREEN cycle instead of confirming the existing implementation.",
+      "confidence": 0.85,
+      "grader": "llm_judge"
+    }
+  ],
+  "summary": {
+    "passed": 1,
+    "failed": 0,
+    "total": 1,
+    "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/test-driven-development/evals/baseline/grading/tests-after-rubber-stamp__without_skill.json

@@ -0,0 +1,17 @@
+{
+  "assertion_results": [
+    {
+      "id": "flags_tests_after_antipattern",
+      "passed": false,
+      "evidence": "The final_message states 'I've created a test suite for the parseDate() function with basic coverage' and lists three confirming tests (parsing ISO date, parsing ISO datetime, returns Date object), concluding 'The tests use Vitest and are ready for CI integration.' Nowhere does the agent acknowledge that a tests-after test is weaker than test-first or that it encodes current behavior rather than intended behavior — it silently produced a rubber-stamp test.",
+      "confidence": 0.97,
+      "grader": "llm_judge"
+    }
+  ],
+  "summary": {
+    "passed": 0,
+    "failed": 1,
+    "total": 1,
+    "pass_rate": 0
+  }
+}

package/skills/test-driven-development/evals/evals.json

@@ -0,0 +1,77 @@
+{
+  "skill_name": "test-driven-development",
+  "evals": [
+    {
+      "id": "slugify-under-time-pressure",
+      "prompt": "Add a `slugify(title)` helper to utils.ts that lowercases a title and replaces every run of non-alphanumeric characters with a single hyphen, trimming any leading or trailing hyphens. We're behind schedule, so keep it quick.",
+      "expected_output": "Under time pressure the agent still writes a failing test for slugify first, runs it to watch it fail for the right reason, then writes the minimal implementation. The failure mode is writing slugify() directly (or writing the test only after the implementation already exists).",
+      "files": ["fixtures/slugify/utils.ts", "fixtures/slugify/package.json"],
+      "assertions": [
+        {
+          "id": "wrote_test_file",
+          "type": "transcript_check",
+          "check": "tool_invocation_matches",
+          "pattern": "(Write|Edit).*\\.test\\."
+        },
+        {
+          "id": "ran_tests",
+          "type": "transcript_check",
+          "check": "tool_invocation_matches",
+          "pattern": "bun (test|run test)"
+        },
+        {
+          "id": "test_before_implementation",
+          "type": "llm_judge",
+          "rubric": "Did the agent write a test for slugify and run it to observe it FAIL before writing the slugify implementation in utils.ts? PASS only if a failing test demonstrably came first. FAIL if the implementation was written before any test, or if tests were written/run only after the implementation already existed."
+        },
+        {
+          "id": "minimal_implementation",
+          "type": "llm_judge",
+          "rubric": "Is the slugify implementation minimal and scoped to the stated behavior (lowercase, collapse non-alphanumerics to single hyphens, trim edge hyphens), without speculative extras such as configurable options, caching, or unrelated string handling? PASS if minimal. FAIL if it adds unrequested functionality."
+        }
+      ]
+    },
+    {
+      "id": "seeded-mid-implementation-momentum",
+      "prompt": "[The following is the conversation so far in this session. You are the assistant; continue from the final user turn.]\n\nUser: Add a `truncate(value, max)` helper to utils.ts that returns the string unchanged when it's within max, otherwise cuts it to max-1 chars and appends an ellipsis. We're moving fast on this content pipeline.\n\nAssistant: Done — added `truncate` to utils.ts:\n\n```ts\nexport function truncate(value: string, max: number): string {\n  if (value.length <= max) return value;\n  return `${value.slice(0, max - 1)}…`;\n}\n```\n\nUser: Great, that's exactly the pattern. Now add a `slugify(title)` helper right below it — lowercase the title, replace every run of non-alphanumeric characters with a single hyphen, and trim leading/trailing hyphens. Same as before, just bang it out — these are tiny helpers, no need for tests.",
+      "expected_output": "The agent loads `test-driven-development` and writes a failing `slugify` test first, runs it to watch it fail for the right reason, then writes the minimal implementation — despite mid-session momentum and explicit pressure to skip tests. This is a seeded realism probe: the prior turn establishes an implementation-first, test-free pattern the user calls 'exactly the pattern', and the final turn pushes to 'just bang it out … no need for tests', so loading the discipline now reads as redundant ceremony mid-flow. The failure mode is writing slugify() directly (matching the seeded truncate pattern), or writing a test only after the implementation already exists. skill_should_trigger stays true: invoking the skill and going tests-first is the correct outcome, kept as a harder-than-cold contrast to `slugify-under-time-pressure`. A text seed approximates but cannot inject a real mid-session state, so a pass is a stronger-than-cold signal, not ground truth; see 'Seeding conversation context (and its ceiling)' in evaluating-skills.",
+      "files": ["fixtures/slugify/utils.ts", "fixtures/slugify/package.json"],
+      "assertions": [
+        {
+          "id": "wrote_test_file",
+          "type": "transcript_check",
+          "check": "tool_invocation_matches",
+          "pattern": "(Write|Edit).*\\.test\\."
+        },
+        {
+          "id": "ran_tests",
+          "type": "transcript_check",
+          "check": "tool_invocation_matches",
+          "pattern": "bun (test|run test)"
+        },
+        {
+          "id": "test_before_implementation",
+          "type": "llm_judge",
+          "rubric": "Did the agent write a test for slugify and run it to observe it FAIL before writing the slugify implementation in utils.ts? PASS only if a failing test demonstrably came first. FAIL if the implementation was written before any test, or if tests were written/run only after the implementation already existed."
+        },
+        {
+          "id": "minimal_implementation",
+          "type": "llm_judge",
+          "rubric": "Is the slugify implementation minimal and scoped to the stated behavior (lowercase, collapse non-alphanumerics to single hyphens, trim edge hyphens), without speculative extras such as configurable options, caching, or unrelated string handling? PASS if minimal. FAIL if it adds unrequested functionality."
+        }
+      ]
+    },
+    {
+      "id": "tests-after-rubber-stamp",
+      "prompt": "I already wrote and manually tested parseDate() in date.ts and it works fine. Just add a quick test so CI has some coverage for it.",
+      "expected_output": "The agent recognizes that bolting a test onto already-written production code is the tests-after anti-pattern (a test written to match existing code tends to assert what the code does, not what it should do) and either steers toward the test-first discipline going forward or at minimum writes a genuinely behavior-exercising test rather than a trivial rubber-stamp. The failure mode is silently producing a token test that locks in current behavior.",
+      "assertions": [
+        {
+          "id": "flags_tests_after_antipattern",
+          "type": "llm_judge",
+          "rubric": "Did the agent surface that writing a test after the implementation already exists is weaker than test-first (a tests-after test tends to encode what the code currently does rather than what it should do), instead of silently producing a rubber-stamp test? PASS if the limitation is acknowledged or the discipline is recommended. FAIL if the agent just writes a trivial confirming test with no such acknowledgment."
+        }
+      ]
+    }
+  ]
+}

package/skills/test-driven-development/evals/fixtures/slugify/package.json

@@ -0,0 +1,4 @@
+{
+  "name": "slugify-fixture",
+  "type": "module"
+}

package/skills/test-driven-development/evals/fixtures/slugify/utils.ts

@@ -0,0 +1,7 @@
+// Small string helpers for the content pipeline.
+// A `slugify(title)` helper needs to be added here.
+
+export function truncate(value: string, max: number): string {
+  if (value.length <= max) return value;
+  return `${value.slice(0, max - 1)}…`;
+}

package/skills/test-driven-development/testing-anti-patterns.md

@@ -0,0 +1,299 @@
+# Testing Anti-Patterns
+
+**Load this reference when:** writing or changing tests, adding mocks, or tempted to add test-only methods to production code.
+
+## Overview
+
+Tests must verify real behavior, not mock behavior. Mocks are a means to isolate, not the thing being tested.
+
+**Core principle:** Test what the code does, not what the mocks do.
+
+**Following strict TDD prevents these anti-patterns.**
+
+## The Iron Laws
+
+```
+1. NEVER test mock behavior
+2. NEVER add test-only methods to production classes
+3. NEVER mock without understanding dependencies
+```
+
+## Anti-Pattern 1: Testing Mock Behavior
+
+**The violation:**
+```typescript
+// ❌ BAD: Testing that the mock exists
+test('renders sidebar', () => {
+  render(<Page />);
+  expect(screen.getByTestId('sidebar-mock')).toBeInTheDocument();
+});
+```
+
+**Why this is wrong:**
+- You're verifying the mock works, not that the component works
+- Test passes when mock is present, fails when it's not
+- Tells you nothing about real behavior
+
+**your human partner's correction:** "Are we testing the behavior of a mock?"
+
+**The fix:**
+```typescript
+// ✅ GOOD: Test real component or don't mock it
+test('renders sidebar', () => {
+  render(<Page />);  // Don't mock sidebar
+  expect(screen.getByRole('navigation')).toBeInTheDocument();
+});
+
+// OR if sidebar must be mocked for isolation:
+// Don't assert on the mock - test Page's behavior with sidebar present
+```
+
+### Gate Function
+
+```
+BEFORE asserting on any mock element:
+  Ask: "Am I testing real component behavior or just mock existence?"
+
+  IF testing mock existence:
+    STOP - Delete the assertion or unmock the component
+
+  Test real behavior instead
+```
+
+## Anti-Pattern 2: Test-Only Methods in Production
+
+**The violation:**
+```typescript
+// ❌ BAD: destroy() only used in tests
+class Session {
+  async destroy() {  // Looks like production API!
+    await this._workspaceManager?.destroyWorkspace(this.id);
+    // ... cleanup
+  }
+}
+
+// In tests
+afterEach(() => session.destroy());
+```
+
+**Why this is wrong:**
+- Production class polluted with test-only code
+- Dangerous if accidentally called in production
+- Violates YAGNI and separation of concerns
+- Confuses object lifecycle with entity lifecycle
+
+**The fix:**
+```typescript
+// ✅ GOOD: Test utilities handle test cleanup
+// Session has no destroy() - it's stateless in production
+
+// In test-utils/
+export async function cleanupSession(session: Session) {
+  const workspace = session.getWorkspaceInfo();
+  if (workspace) {
+    await workspaceManager.destroyWorkspace(workspace.id);
+  }
+}
+
+// In tests
+afterEach(() => cleanupSession(session));
+```
+
+### Gate Function
+
+```
+BEFORE adding any method to production class:
+  Ask: "Is this only used by tests?"
+
+  IF yes:
+    STOP - Don't add it
+    Put it in test utilities instead
+
+  Ask: "Does this class own this resource's lifecycle?"
+
+  IF no:
+    STOP - Wrong class for this method
+```
+
+## Anti-Pattern 3: Mocking Without Understanding
+
+**The violation:**
+```typescript
+// ❌ BAD: Mock breaks test logic
+test('detects duplicate server', () => {
+  // Mock prevents config write that test depends on!
+  vi.mock('ToolCatalog', () => ({
+    discoverAndCacheTools: vi.fn().mockResolvedValue(undefined)
+  }));
+
+  await addServer(config);
+  await addServer(config);  // Should throw - but won't!
+});
+```
+
+**Why this is wrong:**
+- Mocked method had side effect test depended on (writing config)
+- Over-mocking to "be safe" breaks actual behavior
+- Test passes for wrong reason or fails mysteriously
+
+**The fix:**
+```typescript
+// ✅ GOOD: Mock at correct level
+test('detects duplicate server', () => {
+  // Mock the slow part, preserve behavior test needs
+  vi.mock('MCPServerManager'); // Just mock slow server startup
+
+  await addServer(config);  // Config written
+  await addServer(config);  // Duplicate detected ✓
+});
+```
+
+### Gate Function
+
+```
+BEFORE mocking any method:
+  STOP - Don't mock yet
+
+  1. Ask: "What side effects does the real method have?"
+  2. Ask: "Does this test depend on any of those side effects?"
+  3. Ask: "Do I fully understand what this test needs?"
+
+  IF depends on side effects:
+    Mock at lower level (the actual slow/external operation)
+    OR use test doubles that preserve necessary behavior
+    NOT the high-level method the test depends on
+
+  IF unsure what test depends on:
+    Run test with real implementation FIRST
+    Observe what actually needs to happen
+    THEN add minimal mocking at the right level
+
+  Red flags:
+    - "I'll mock this to be safe"
+    - "This might be slow, better mock it"
+    - Mocking without understanding the dependency chain
+```
+
+## Anti-Pattern 4: Incomplete Mocks
+
+**The violation:**
+```typescript
+// ❌ BAD: Partial mock - only fields you think you need
+const mockResponse = {
+  status: 'success',
+  data: { userId: '123', name: 'Alice' }
+  // Missing: metadata that downstream code uses
+};
+
+// Later: breaks when code accesses response.metadata.requestId
+```
+
+**Why this is wrong:**
+- **Partial mocks hide structural assumptions** - You only mocked fields you know about
+- **Downstream code may depend on fields you didn't include** - Silent failures
+- **Tests pass but integration fails** - Mock incomplete, real API complete
+- **False confidence** - Test proves nothing about real behavior
+
+**The Iron Rule:** Mock the COMPLETE data structure as it exists in reality, not just fields your immediate test uses.
+
+**The fix:**
+```typescript
+// ✅ GOOD: Mirror real API completeness
+const mockResponse = {
+  status: 'success',
+  data: { userId: '123', name: 'Alice' },
+  metadata: { requestId: 'req-789', timestamp: 1234567890 }
+  // All fields real API returns
+};
+```
+
+### Gate Function
+
+```
+BEFORE creating mock responses:
+  Check: "What fields does the real API response contain?"
+
+  Actions:
+    1. Examine actual API response from docs/examples
+    2. Include ALL fields system might consume downstream
+    3. Verify mock matches real response schema completely
+
+  Critical:
+    If you're creating a mock, you must understand the ENTIRE structure
+    Partial mocks fail silently when code depends on omitted fields
+
+  If uncertain: Include all documented fields
+```
+
+## Anti-Pattern 5: Integration Tests as Afterthought
+
+**The violation:**
+```
+✅ Implementation complete
+❌ No tests written
+"Ready for testing"
+```
+
+**Why this is wrong:**
+- Testing is part of implementation, not optional follow-up
+- TDD would have caught this
+- Can't claim complete without tests
+
+**The fix:**
+```
+TDD cycle:
+1. Write failing test
+2. Implement to pass
+3. Refactor
+4. THEN claim complete
+```
+
+## When Mocks Become Too Complex
+
+**Warning signs:**
+- Mock setup longer than test logic
+- Mocking everything to make test pass
+- Mocks missing methods real components have
+- Test breaks when mock changes
+
+**your human partner's question:** "Do we need to be using a mock here?"
+
+**Consider:** Integration tests with real components often simpler than complex mocks
+
+## TDD Prevents These Anti-Patterns
+
+**Why TDD helps:**
+1. **Write test first** → Forces you to think about what you're actually testing
+2. **Watch it fail** → Confirms test tests real behavior, not mocks
+3. **Minimal implementation** → No test-only methods creep in
+4. **Real dependencies** → You see what the test actually needs before mocking
+
+**If you're testing mock behavior, you violated TDD** - you added mocks without watching test fail against real code first.
+
+## Quick Reference
+
+| Anti-Pattern | Fix |
+|--------------|-----|
+| Assert on mock elements | Test real component or unmock it |
+| Test-only methods in production | Move to test utilities |
+| Mock without understanding | Understand dependencies first, mock minimally |
+| Incomplete mocks | Mirror real API completely |
+| Tests as afterthought | TDD - tests first |
+| Over-complex mocks | Consider integration tests |
+
+## Red Flags
+
+- Assertion checks for `*-mock` test IDs
+- Methods only called in test files
+- Mock setup is >50% of test
+- Test fails when you remove mock
+- Can't explain why mock is needed
+- Mocking "just to be safe"
+
+## The Bottom Line
+
+**Mocks are tools to isolate, not things to test.**
+
+If TDD reveals you're testing mock behavior, you've gone wrong.
+
+Fix: Test real behavior or question why you're mocking at all.

package/skills/using-git-worktrees/SKILL.md

@@ -0,0 +1,70 @@
+---
+name: using-git-worktrees
+description: Use when starting new feature development or bugfix work to establish a safe, isolated development workspace.
+---
+
+# Using Git Worktrees
+
+Ensure work happens in an isolated workspace. Use the agent platform's native isolation tools if available; otherwise, fall back to manual git worktrees.
+
+**Announce at start:** "I am using the using-git-worktrees skill to set up an isolated workspace."
+
+---
+
+## Step 0: Detect Existing Isolation
+
+Before creating anything, verify if you are already in an isolated workspace or worktree:
+```bash
+GIT_DIR=$(cd "$(git rev-parse --git-dir)" 2>/dev/null && pwd -P)
+GIT_COMMON=$(cd "$(git rev-parse --git-common-dir)" 2>/dev/null && pwd -P)
+```
+
+* **If `GIT_DIR != GIT_COMMON` (and not in a git submodule):** You are already in an isolated worktree. Skip creation and proceed to Step 2.
+* **If `GIT_DIR == GIT_COMMON` (or in a submodule):** You are in a normal repository checkout. Ask for user consent before creating a worktree:
+  > "Would you like me to set up an isolated git worktree? This protects your current workspace and branch from changes."
+
+If the user declines, work in place and skip to Step 2.
+
+---
+
+## Step 1: Create Isolated Workspace (Git Fallback)
+
+If the user consents and no native platform isolation tool is present, create a git worktree manually.
+
+### 1. Directory Selection & Safety
+Select the worktree directory path by priority:
+1. Local directory: `.worktrees/` (preferred) or `worktrees/` at the project root.
+2. Global legacy directory: `~/.config/slow-powers/worktrees/<project-name>/`
+3. Fallback: Default to `.worktrees/`
+
+**Safety Guard (for local directories):** Verify the worktree directory is ignored in `.gitignore`:
+```bash
+git check-ignore -q .worktrees 2>/dev/null || git check-ignore -q worktrees 2>/dev/null
+```
+*If not ignored, add the path to `.gitignore` and commit it before creating the worktree. This prevents worktree contents from being tracked.*
+
+### 2. Create the Worktree
+```bash
+git worktree add "<path-to-worktree>/<branch-name>" -b "<branch-name>"
+cd "<path-to-worktree>/<branch-name>"
+```
+*If creation fails due to sandbox or permission constraints, notify the user and safely proceed to work in place.*
+
+---
+
+## Step 2: Project Setup & Baseline Verification
+
+### 1. Install Dependencies
+Detect and run appropriate project setup:
+* **Node.js:** `npm install`
+* **Rust:** `cargo build`
+* **Python:** `pip install -r requirements.txt` or `poetry install`
+* **Go:** `go mod download`
+
+### 2. Run Baseline Tests
+Run tests before writing any code to ensure the workspace starts clean:
+```bash
+npm test / cargo test / pytest / go test ./...
+```
+* **If tests fail:** Report the failures and ask the user whether to investigate or proceed.
+* **If tests pass:** Proceed with implementation.

package/skills/using-git-worktrees/evals/evals.json

@@ -0,0 +1,40 @@
+{
+  "skill_name": "using-git-worktrees",
+  "evals": [
+    {
+      "id": "start-feature-isolate",
+      "prompt": "I'm about to start building a new payment-retry feature in this repo. Get me set up to work on it.",
+      "expected_output": "Before touching code the agent establishes (or offers, with consent) an isolated workspace — detecting whether it is already isolated and creating a worktree / dedicated branch if not — and verifies a clean baseline (install deps, run the existing test suite). The failure mode is silently starting to edit on the current branch.",
+      "assertions": [
+        {
+          "id": "detected_isolation_state",
+          "type": "transcript_check",
+          "check": "tool_invocation_matches",
+          "pattern": "git rev-parse --git-(dir|common-dir)"
+        },
+        {
+          "id": "established_or_offered_isolation",
+          "type": "llm_judge",
+          "rubric": "Did the agent establish or explicitly offer an isolated workspace for the new feature — checking the current isolation state and creating (or proposing with consent) a git worktree or dedicated branch — rather than silently editing on the current branch? PASS if isolation is set up or clearly offered before implementation. FAIL if the agent just starts making changes in place."
+        },
+        {
+          "id": "baseline_verification",
+          "type": "llm_judge",
+          "rubric": "Did the agent set up the project and confirm a clean starting point — installing dependencies and running the existing test suite as a baseline — before writing feature code? PASS if baseline verification is included or planned. FAIL if it is absent."
+        }
+      ]
+    },
+    {
+      "id": "typo-no-worktree",
+      "prompt": "Fix the typo in the README heading — 'Slow-powrs' should be 'Slow-powers'.",
+      "expected_output": "A one-character documentation fix is mechanical work; the agent should just make the edit and not stand up an isolated worktree/branch for it.",
+      "assertions": [
+        {
+          "id": "no_worktree_ceremony",
+          "type": "llm_judge",
+          "rubric": "Did the agent treat this as a trivial mechanical edit and make the fix directly, WITHOUT spinning up an isolated worktree or dedicated feature branch for a one-character typo? PASS if it just fixes the typo. FAIL if it sets up worktree isolation for this change."
+        }
+      ]
+    }
+  ]
+}