xtrm-tools 2.2.0 → 2.4.0

package/cli/package.json

@@ -1,6 +1,6 @@
 {
   "name": "xtrm-cli",
-  "version": "2.2.0",
+  "version": "2.4.0",
   "description": "Claude Code tools installer (skills, hooks, MCP servers)",
   "main": "./dist/index.js",
   "type": "module",

package/config/pi/extensions/beads.ts

@@ -1,6 +1,5 @@
-import type { ExtensionAPI, ToolCallEvent, ToolResultEvent } from "@mariozechner/pi-coding-agent";
+import type { ExtensionAPI } from "@mariozechner/pi-coding-agent";
 import { isToolCallEventType, isBashToolResult } from "@mariozechner/pi-coding-agent";
-import * as path from "node:path";
 import { SubprocessRunner, EventAdapter, Logger } from "./core/lib";
 
 const logger = new Logger({ namespace: "beads" });
@@ -9,6 +8,7 @@ export default function (pi: ExtensionAPI) {
 	const getCwd = (ctx: any) => ctx.cwd || process.cwd();
 
 	let cachedSessionId: string | null = null;
+	let memoryGateFired = false;
 
 	// Resolve a stable session ID across event types.
 	const getSessionId = (ctx: any): string => {
@@ -115,19 +115,47 @@ export default function (pi: ExtensionAPI) {
 		return undefined;
 	});
 
-	// Dual safety net: notify about unclosed claims when session ends
+	// Dual safety net: warn about unclosed claims when session ends (non-blocking)
 	const notifySessionEnd = async (ctx: any) => {
 		const cwd = getCwd(ctx);
 		if (!EventAdapter.isBeadsProject(cwd)) return;
 		const sessionId = getSessionId(ctx);
 		const claim = await getSessionClaim(sessionId, cwd);
-		if (claim && ctx.hasUI) {
-			ctx.ui.notify(`Beads: Session ending with active claim [${claim}]`, "warning");
+		if (!claim) return;
+
+		const message = `Beads: session ending with active claim [${claim}]`;
+		if (ctx.hasUI) {
+			ctx.ui.notify(message, "warning");
+		} else {
+			logger.warn(message);
 		}
 	};
 
+	// Memory gate: if the session's claimed issue was closed, prompt for insights.
+	// Uses sendUserMessage to trigger a new agent turn (Pi has no blocking stop hook).
+	// memoryGateFired prevents re-triggering on the follow-up agent_end.
+	const triggerMemoryGateIfNeeded = async (ctx: any) => {
+		if (memoryGateFired) return;
+		const cwd = getCwd(ctx);
+		if (!EventAdapter.isBeadsProject(cwd)) return;
+		const sessionId = getSessionId(ctx);
+		const claimId = await getSessionClaim(sessionId, cwd);
+		if (!claimId) return;
+
+		const result = await SubprocessRunner.run("bd", ["list", "--status=closed"], { cwd });
+		if (result.code !== 0 || !result.stdout.includes(claimId)) return;
+
+		memoryGateFired = true;
+		pi.sendUserMessage(
+			`🧠 Memory gate: claim \`${claimId}\` was closed this session.\n` +
+			`For each closed issue, worth persisting?\n` +
+			`  YES → \`bd remember "<insight>"\`   NO → note "nothing to persist"`,
+		);
+	};
+
 	pi.on("agent_end", async (_event, ctx) => {
 		await notifySessionEnd(ctx);
+		await triggerMemoryGateIfNeeded(ctx);
 		return undefined;
 	});
 

package/config/pi/extensions/service-skills.ts

@@ -1,11 +1,8 @@
-import type { ExtensionAPI, ToolCallEvent, ToolResultEvent } from "@mariozechner/pi-coding-agent";
-import { isToolCallEventType, isBashToolResult } from "@mariozechner/pi-coding-agent";
-import { SubprocessRunner, Logger } from "./core/lib";
+import type { ExtensionAPI } from "@mariozechner/pi-coding-agent";
+import { SubprocessRunner } from "./core/lib";
 import * as path from "node:path";
 import * as fs from "node:fs";
 
-const logger = new Logger({ namespace: "service-skills" });
-
 export default function (pi: ExtensionAPI) {
 	const getCwd = (ctx: any) => ctx.cwd || process.cwd();
 
@@ -27,23 +24,33 @@ export default function (pi: ExtensionAPI) {
 	});
 
 
-	// 3. Drift Detection
+	const toClaudeToolName = (toolName: string): string => {
+		if (toolName === "bash") return "Bash";
+		if (toolName === "read_file") return "Read";
+		if (toolName === "write" || toolName === "create_text_file") return "Write";
+		if (toolName === "edit" || toolName === "replace_content" || toolName === "replace_lines" || toolName === "insert_at_line" || toolName === "delete_lines") return "Edit";
+		if (toolName === "search_for_pattern") return "Grep";
+		if (toolName === "find_file" || toolName === "list_dir") return "Glob";
+		return toolName;
+	};
+
+	// 2. Drift Detection (skill activation is before_agent_start only — not per-tool)
 	pi.on("tool_result", async (event, ctx) => {
 		const cwd = getCwd(ctx);
 		const driftDetectorPath = path.join(cwd, ".claude", "skills", "updating-service-skills", "scripts", "drift_detector.py");
 		if (!fs.existsSync(driftDetectorPath)) return undefined;
 
 		const hookInput = JSON.stringify({
-			tool_name: event.toolName === "bash" ? "Bash" : event.toolName,
+			tool_name: toClaudeToolName(event.toolName),
 			tool_input: event.input,
-			cwd: cwd
+			cwd,
 		});
 
 		const result = await SubprocessRunner.run("python3", [driftDetectorPath], {
 			cwd,
 			input: hookInput,
 			env: { ...process.env, CLAUDE_PROJECT_DIR: cwd },
-			timeoutMs: 10000
+			timeoutMs: 10000,
 		});
 
 		if (result.code === 0 && result.stdout.trim()) {
@@ -51,6 +58,7 @@ export default function (pi: ExtensionAPI) {
 			newContent.push({ type: "text", text: "\n\n" + result.stdout.trim() });
 			return { content: newContent };
 		}
+
 		return undefined;
 	});
 }

package/config/pi/install-schema.json

@@ -36,6 +36,7 @@
   "packages": [
     "npm:@aliou/pi-guardrails",
     "npm:pi-gitnexus",
-    "npm:pi-serena-tools"
+    "npm:pi-serena-tools",
+    "npm:@zenobius/pi-worktrees"
   ]
 }

package/hooks/beads-gate-core.mjs

@@ -154,14 +154,16 @@ export function decideCommitGate(ctx, state) {
     return { allow: true };
   }
 
-  // Has claim but check if there are still in_progress issues
-  const summary = state.inProgress?.summary ?? null;
+  // Has claim but no in_progress issues → allow (stale/already-closed claim)
+  if (!state.inProgress || state.inProgress.count === 0) {
+    return { allow: true };
+  }
 
-  // Session has claim → block (need to close first)
+  // Has claim + in_progress issues → block (need to close first)
   return {
     allow: false,
     reason: 'unclosed_claim',
-    summary,
+    summary: state.inProgress.summary,
     claimed: state.claimId,
   };
 }

package/hooks/beads-memory-gate.mjs

@@ -11,7 +11,7 @@ import { execSync } from 'node:child_process';
 import { existsSync, unlinkSync } from 'node:fs';
 import { join } from 'node:path';
 import { readHookInput } from './beads-gate-core.mjs';
-import { resolveCwd, isBeadsProject } from './beads-gate-utils.mjs';
+import { resolveCwd, isBeadsProject, getSessionClaim } from './beads-gate-utils.mjs';
 import { memoryPromptMessage } from './beads-gate-messages.mjs';
 
 const input = readHookInput();
@@ -27,8 +27,15 @@ if (existsSync(marker)) {
   process.exit(0);
 }
 
-// Only block if there are closed issues — don't fire on empty projects
-let hasClosed = false;
+// Only fire if this session had an active claim that is now closed
+const sessionId = input.session_id ?? null;
+if (!sessionId) process.exit(0);
+
+const claimId = getSessionClaim(sessionId, cwd);
+if (!claimId) process.exit(0); // no claim this session → no work to persist
+
+// Check if the claimed issue was closed this session
+let claimClosed = false;
 try {
   const out = execSync('bd list --status=closed', {
     encoding: 'utf8',
@@ -36,12 +43,12 @@ try {
     stdio: ['pipe', 'pipe', 'pipe'],
     timeout: 8000,
   });
-  hasClosed = /^✓/m.test(out);
+  claimClosed = out.includes(claimId);
 } catch {
   process.exit(0); // fail open
 }
 
-if (!hasClosed) process.exit(0);
+if (!claimClosed) process.exit(0);
 
 process.stderr.write(memoryPromptMessage());
 process.exit(2);

package/hooks/hooks.json

@@ -0,0 +1,126 @@
+{
+  "hooks": {
+    "PreToolUse": [
+      {
+        "matcher": "Write|Edit|MultiEdit|mcp__serena__rename_symbol|mcp__serena__replace_symbol_body|mcp__serena__insert_after_symbol|mcp__serena__insert_before_symbol",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "node ${CLAUDE_PLUGIN_ROOT}/hooks/main-guard.mjs",
+            "timeout": 5000
+          }
+        ]
+      },
+      {
+        "matcher": "Bash",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "node ${CLAUDE_PLUGIN_ROOT}/hooks/main-guard.mjs",
+            "timeout": 5000
+          },
+          {
+            "type": "command",
+            "command": "node ${CLAUDE_PLUGIN_ROOT}/hooks/beads-commit-gate.mjs",
+            "timeout": 5000
+          }
+        ]
+      },
+      {
+        "matcher": "Edit|Write|MultiEdit|NotebookEdit|mcp__serena__rename_symbol|mcp__serena__replace_symbol_body|mcp__serena__insert_after_symbol|mcp__serena__insert_before_symbol",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "node ${CLAUDE_PLUGIN_ROOT}/hooks/beads-edit-gate.mjs",
+            "timeout": 5000
+          }
+        ]
+      }
+    ],
+    "PostToolUse": [
+      {
+        "matcher": "Bash",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "node ${CLAUDE_PLUGIN_ROOT}/hooks/main-guard-post-push.mjs",
+            "timeout": 5000
+          }
+        ]
+      },
+      {
+        "matcher": "Bash|execute_shell_command|bash",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "node ${CLAUDE_PLUGIN_ROOT}/hooks/beads-claim-sync.mjs",
+            "timeout": 5000
+          }
+        ]
+      },
+      {
+        "matcher": "Bash|mcp__serena__find_symbol|mcp__serena__get_symbols_overview|mcp__serena__search_for_pattern|mcp__serena__find_referencing_symbols|mcp__serena__replace_symbol_body|mcp__serena__insert_after_symbol|mcp__serena__insert_before_symbol|mcp__serena__rename_symbol",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "node ${CLAUDE_PLUGIN_ROOT}/hooks/gitnexus/gitnexus-hook.cjs",
+            "timeout": 10000
+          }
+        ]
+      }
+    ],
+    "SessionStart": [
+      {
+        "hooks": [
+          {
+            "type": "command",
+            "command": "node ${CLAUDE_PLUGIN_ROOT}/hooks/beads-compact-restore.mjs",
+            "timeout": 5000
+          },
+          {
+            "type": "command",
+            "command": "python3 ${CLAUDE_PLUGIN_ROOT}/hooks/serena-workflow-reminder.py"
+          }
+        ]
+      }
+    ],
+    "Stop": [
+      {
+        "hooks": [
+          {
+            "type": "command",
+            "command": "node ${CLAUDE_PLUGIN_ROOT}/hooks/beads-stop-gate.mjs",
+            "timeout": 5000
+          },
+          {
+            "type": "command",
+            "command": "node ${CLAUDE_PLUGIN_ROOT}/hooks/beads-memory-gate.mjs",
+            "timeout": 8000
+          }
+        ]
+      }
+    ],
+    "PreCompact": [
+      {
+        "hooks": [
+          {
+            "type": "command",
+            "command": "node ${CLAUDE_PLUGIN_ROOT}/hooks/beads-compact-save.mjs",
+            "timeout": 5000
+          }
+        ]
+      }
+    ],
+    "UserPromptSubmit": [
+      {
+        "hooks": [
+          {
+            "type": "command",
+            "command": "node ${CLAUDE_PLUGIN_ROOT}/hooks/branch-state.mjs",
+            "timeout": 3000
+          }
+        ]
+      }
+    ]
+  }
+}

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "xtrm-tools",
-  "version": "2.2.0",
+  "version": "2.4.0",
   "description": "Claude Code tools installer (skills, hooks, MCP servers)",
   "license": "MIT",
   "type": "module",
@@ -37,6 +37,8 @@
   },
   "scripts": {
     "sync:cli-version": "node scripts/sync-cli-version.mjs",
+    "compile-policies": "node scripts/compile-policies.mjs",
+    "check-policies": "node scripts/compile-policies.mjs --check",
     "prebuild": "npm run sync:cli-version",
     "build": "npm run build --workspace cli",
     "typecheck": "npm run typecheck --workspace cli",

package/skills/test-planning/SKILL.md

@@ -0,0 +1,208 @@
+---
+name: test-planning
+description: "Plans and creates test issues alongside implementation work using bd issue tracker. Activates at two points: (1) when creating an issue board from a spec/plan — classifies each issue by code layer and attaches the right testing strategy as a companion issue or AC gate, and (2) when closing an implementation issue — checks whether adequate test coverage was planned, improves existing test issues if needed. Use this skill PROACTIVELY whenever you see implementation issues being created without test coverage, when an epic is being broken into tasks, when closing/reviewing implementation work, or when the user asks about testing strategy for a set of issues. Also activate when you see bd create, bd children, bd close in a planning context."
+---
+
+# Test Planning
+
+This skill ensures every implementation issue has appropriate test coverage planned — not as an afterthought, but wired into the issue board from the start. It does NOT write test code; it classifies what needs testing, picks the right strategy, and creates bd issues that another agent (or human) will implement.
+
+## When This Fires
+
+### Trigger 1: Planning phase (issue board creation)
+
+When breaking a spec or plan into bd issues — typically during epic decomposition or `bd create --parent` sequences — scan each implementation issue and create companion test issues.
+
+### Trigger 2: Closure gate (implementation complete)
+
+When an implementation issue is being closed (`bd close`), check whether:
+- A test issue already exists for it (created in Trigger 1)
+- The test issue needs updating based on what was actually built (scope may have shifted)
+- Test coverage gaps appeared during implementation (new edge cases, API quirks discovered)
+
+If a test issue exists, review and improve it. If none exists, create one before or alongside closure.
+
+## Layer Detection
+
+Read the issue title, description, and any code paths mentioned to classify which architectural layer the work touches. This determines the testing strategy.
+
+### Core layer — pure domain logic
+Code that transforms data, computes values, manages state, with no I/O. Examples:
+- Config parsing/merging
+- Data formatting (output renderers, serializers)
+- Computation (implied rates from prices, spread calculations)
+- State machines (session tracking, log rotation)
+- Validators, parsers, transformers
+
+**Signals**: "implement", "compute", "format", "parse", "validate", functions that take data and return data, no HTTP/DB/filesystem in the description.
+
+### Boundary layer — I/O interfaces and service contracts
+Code that crosses a system boundary: HTTP clients, API routes, database queries, file I/O, message queues. Examples:
+- API client methods (async_client, REST wrappers)
+- API route handlers
+- Database query functions
+- File readers/writers
+- External service integrations
+
+**Signals**: "endpoint", "API", "client", "route", "fetch", "query", URLs, ports, service names, request/response shapes mentioned.
+
+### Shell layer — orchestration and wiring
+Code that glues core + boundary together into user-facing features. Examples:
+- CLI commands that call a client, transform data, then output
+- Pipeline orchestrators
+- Command handlers
+- Workflow coordinators
+
+**Signals**: "command", "CLI", "subcommand", "mercury <verb>", user-facing behavior described, combines multiple components.
+
+## Testing Strategy Selection
+
+### By layer
+
+| Layer | Primary strategy | What to assert | Mock policy |
+|---|---|---|---|
+| Core | Unit + property tests | Input/output correctness, edge cases, invariants | No mocking needed — pure functions |
+| Boundary | Contract tests (live preferred) | Response schemas, field presence/types, status codes, param behavior | Live > contract > mock (see preference order below) |
+| Shell | Integration tests | Exit codes, output format validity, end-to-end wiring, error messages | Test the real thing via subprocess or function call |
+
+### By situation (override layer default when applicable)
+
+| Situation | Strategy | When to pick it |
+|---|---|---|
+| Interface unclear/evolving | TDD | Spec is vague, requirements shifting — tests define the contract |
+| Contract known up front | Spec-first | API routes documented, response shapes defined — write schema assertions |
+| Parsers/transforms/invariants | Property-based | The function should hold for any valid input, not just examples |
+| Service/API boundaries | Contract testing | Testing the seam between systems — assert schemas, not implementations |
+| Legacy code being wrapped | Characterization tests | Capture current behavior before changing it |
+| Simple CRUD paths | Example-based | Straightforward input→output, a few examples suffice |
+
+### Live-first preference
+
+When services are accessible, prefer this order:
+
+1. **Live tests** — hit real services, assert real responses. No mocking. This catches actual bugs: wrong URLs, changed schemas, auth issues, network edge cases. Mark with `@pytest.mark.live`.
+2. **Contract tests with recorded fixtures** — if live access is intermittent, record responses once and replay. Still validates schema, but won't catch drift.
+3. **Mocked tests** — last resort, only when no service access exists or for pure unit logic that has no I/O.
+
+The rationale: mocks encode your assumptions about the system. If your assumptions were correct, you wouldn't need tests. Live tests validate reality.
+
+## Creating Test Issues
+
+### Naming convention
+
+Test issues are children of the same parent epic as the implementation issue. Name pattern:
+
+```
+Test: <what's being tested> — <strategy>
+```
+
+Examples:
+- "Test: rates/candles/stir/curve commands — CLI integration + contract tests"
+- "Test: config system — unit tests for load/save/override/env precedence"
+- "Test: async_client URL routing — live contract tests against all services"
+
+### Issue structure
+
+When creating a test issue with `bd create`:
+
+```
+bd create "Test: <description>" \
+  -t task -p <same or +1 from impl issue> \
+  --parent <same parent epic> \
+  -l testing,<layer>,<phase> \
+  --deps "blocks:<next-phase-issue-id>" \
+  -d "<structured description>"
+```
+
+The description should contain:
+
+1. **What implementation it covers** — reference the impl issue ID(s)
+2. **Layer classification** — which layer and why
+3. **Strategy chosen** — which testing approach and why
+4. **Test file structure** — where tests go in the project
+5. **What to assert** — specific assertions, not vague "test that it works"
+6. **AC** — when is this test issue done
+
+### Batching
+
+Don't create one test issue per implementation issue — that's overhead. Batch by layer and phase:
+
+- Group all core-layer issues from the same phase into one test issue
+- Group all boundary-layer issues into one contract test issue
+- Group all shell-layer issues into one integration test issue
+
+Example: if a phase ships 4 CLI commands + 1 client change + 1 config change:
+- 1 test issue for core (config unit tests)
+- 1 test issue for boundary (client contract tests)
+- 1 test issue for shell (CLI integration tests for all 4 commands)
+
+### Gating
+
+Test issues should gate the next phase of work. Use bd dependencies or document in the issue description:
+
+```
+This issue gates: .17 (analyze runner), .18 (spread), .19 (charts)
+Do not start Phase 3 until these tests pass.
+```
+
+## Closure Gate Behavior
+
+When an implementation issue is closed, check:
+
+1. **Does a test issue exist?** Run `bd children <parent>` and look for test issues that reference this impl issue.
+
+2. **Is the test issue still accurate?** Implementation often diverges from plan. Compare what was built (read the commit, check the code) against what the test issue specifies. Common drift:
+   - New subcommands added that aren't in the test plan
+   - API response shape different from what was expected
+   - Edge cases discovered during implementation
+   - Dependencies changed (a service turned out to be local-only)
+
+3. **Update if needed.** Use `bd update <test-issue-id>` or `bd comments add <test-issue-id>` to add new assertions, remove obsolete ones, or note discovered quirks.
+
+4. **If no test issue exists**, create one. Classify the layer, pick the strategy, write the assertions. This is the safety net for work that was done without planning tests upfront.
+
+## Examples
+
+### Planning phase — epic decomposition
+
+Given an epic with these children:
+```
+.10 Scaffold CLI project structure
+.11 Implement logging system
+.12 Implement config system
+.13 Implement output formatting
+.14 Implement async HTTP client
+```
+
+Create:
+```
+bd create "Test: P1 core — unit tests for config, log, session, output" \
+  -t task -p 1 --parent <epic> -l testing,core,phase-1 \
+  -d "Unit + property tests for pure domain logic...
+  Covers: .11, .12, .13
+  Strategy: unit tests (core layer, pure logic, no I/O)
+  ..."
+
+bd create "Test: P1 boundary — live contract tests for async client" \
+  -t task -p 1 --parent <epic> -l testing,boundary,phase-1 \
+  -d "Contract tests against live services...
+  Covers: .14
+  Strategy: contract tests, live-first (boundary layer, HTTP I/O)
+  ..."
+```
+
+### Closure gate — implementation done, test issue exists
+
+Agent closes `.15` (data commands: rates, candles, stir, curve). Finds existing test issue `.26`. Reads `.26` description, compares against what `.15` actually built:
+
+- `.15` added `rates iorb` subcommand not in original test plan → update `.26` to include IORB assertion
+- `.15` discovered STIR implied rates are client-side computation → add property test: `implied_rate == 100 - price` for any valid price
+- Update `.26` with `bd update` or add a comment
+
+### Closure gate — no test issue exists
+
+Agent closes a feature issue that was done ad-hoc. No test issue found. Agent:
+1. Reads the implementation to classify the layer
+2. Picks strategy
+3. Creates test issue as child of same parent
+4. Documents what to assert based on the actual code

package/skills/test-planning/evals/evals.json

@@ -0,0 +1,23 @@
+{
+  "skill_name": "test-planning",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "I've got an epic for a new notification service (notif-3a). I just created 8 child issues: .1 is the Postgres schema migration, .2 is the async message consumer (reads from RabbitMQ), .3 is the template renderer (Jinja2, pure python), .4 is the delivery client (calls Twilio/SendGrid APIs), .5 is the REST API for managing preferences, .6 is the CLI tool for ops to send test notifications, .7 is the retry/dead-letter handler, .8 is the rate limiter. Break down what testing each of these needs and create the bd issues.",
+      "expected_output": "Should detect layers: .1 (boundary/DB), .2 (boundary/MQ), .3 (core/pure), .4 (boundary/external API), .5 (boundary/API), .6 (shell/CLI), .7 (core/state machine), .8 (core/algorithm). Should batch into ~3 test issues: core tests (.3, .7, .8), boundary/contract tests (.1, .2, .4, .5), shell integration (.6). Should use property-based for rate limiter, contract tests for external APIs, characterization or spec-first for DB schema.",
+      "files": []
+    },
+    {
+      "id": 2,
+      "prompt": "I just finished implementing the data ingestion pipeline (issue data-pipe-9f.4) — it reads CSVs from S3, validates schemas, transforms column types, and writes to Postgres. The parent epic is data-pipe-9f. Can you close it for me? bd close data-pipe-9f.4 --reason 'pipeline implemented and deployed'",
+      "expected_output": "Should trigger closure gate behavior: check bd children data-pipe-9f for existing test issues. Since none exist, should create a test issue covering all layers: unit tests for schema validation and column transforms (core), contract tests for S3 reads and Postgres writes (boundary), integration test for end-to-end pipeline (shell). Should NOT just close the issue without checking for test coverage.",
+      "files": []
+    },
+    {
+      "id": 3,
+      "prompt": "We have an epic tracker-7b with 5 implementation issues done and 1 test issue (tracker-7b.6) that was created during planning. But during implementation of .3 (the websocket price feed handler), we discovered the feed sometimes sends malformed JSON that the parser needs to handle gracefully, and .5 (the position calculator) ended up also doing margin calculations which weren't in the original plan. Can you review tracker-7b.6 and update it?",
+      "expected_output": "Should read tracker-7b.6, identify drift: (1) malformed JSON handling in websocket parser is a new edge case — add property-based tests for parser robustness, (2) margin calculations in position calculator are new core logic — add unit tests. Should update the existing test issue via bd update or bd comments, not create a new one. Should note that the parser needs characterization tests if there's existing behavior to preserve.",
+      "files": []
+    }
+  ]
+}

package/skills/using-xtrm/SKILL.md

@@ -4,7 +4,7 @@ description: >
   Operating manual for an xtrm-equipped Claude Code session. Activates automatically at
   session start to orient the agent on how to work within the xtrm stack: when to apply
   prompt improvement, how the beads issue-tracking gate works, which hooks enforce workflows,
-  and how to compose the full toolset (gitnexus, Serena, TDD guard, quality gates, delegation).
+  and how to compose the full toolset (gitnexus, Serena, quality gates, delegation).
   Use this skill whenever a new session begins in an xtrm-tools-installed environment, or
   when the user asks how to work with the xtrm stack, what tools are available, or how any
   xtrm workflow operates.
@@ -24,7 +24,7 @@ within this stack. Read it at session start and refer back when uncertain about
 |---|---|
 | **Skills** | Domain expertise loaded on demand |
 | **Hooks** | Automated lifecycle enforcement (gates, suggestions, reminders) |
-| **Project Skills** | Per-project quality enforcement (tdd-guard, quality-gates, service-skills-set) |
+| **Project Skills** | Per-project quality enforcement (quality-gates, service-skills-set) |
 | **MCP Servers** | Semantic tools: Serena (code), gitnexus (graph), context7 (docs), deepwiki |
 | **CLI** | `xtrm install / status / reset / help` — sync and install tooling |
 | **beads (bd)** | Git-backed issue tracker with session gate enforcement |
@@ -151,27 +151,6 @@ If index is stale: `npx gitnexus analyze` before using MCP tools.
 
 ---
 
-## TDD Guard — Test-First Enforcement
-
-This project enforces TDD via `tdd-guard`. It **blocks implementation** until a failing test exists.
-
-**The cycle:**
-1. Write a failing test first — use `sed` or `Bash` to append (not `Write`/`Edit`, which the guard intercepts)
-2. Run `npx vitest run <test-file>` to register the failure in `.claude/tdd-guard/data/test.json`
-3. Implement the minimum code to make it pass
-4. Run tests again — guard clears when tests pass
-
-Never skip the failing test step. Over-implementation is also flagged — write a stub first, then build up.
-
-> **Needs configuration**: tdd-guard is a project skill installed per-project:
-> ```bash
-> xtrm install project tdd-guard
-> ```
-> Requires vitest in the project. After install, verify `.claude/settings.json` includes the
-> PreToolUse and UserPromptSubmit hook entries for tdd-guard.
-
----
-
 ## Quality Gates — Automatic on Every Edit
 
 After each file edit, quality-gates hooks run automatically:
@@ -204,7 +183,7 @@ unless there is a genuine reason.
 | Changing a function | `gitnexus-impact-analysis` first, then Serena edit |
 | Safe rename/refactor | `gitnexus-refactoring` |
 | Docker service project | `using-service-skills` → activate expert persona |
-| Writing new feature | TDD cycle first, quality gates auto-run after |
+| Writing new feature | Write tests alongside, quality gates auto-run after |
 | Maintaining docs | `/documenting` (Serena SSOT drift detection) |
 | Building/improving a skill | `skill-creator` |
 
@@ -227,7 +206,7 @@ unless there is a genuine reason.
 `obsidian-cli`, `hook-development`, `claude-api`
 
 **Project Skills** (install per-project with `xtrm install project <name>`):
-`tdd-guard`, `quality-gates`, `service-skills-set`
+`quality-gates`, `service-skills-set`
 
 ---
 
@@ -244,7 +223,6 @@ These hooks run automatically — you cannot disable them mid-session:
 | `gitnexus-impact-reminder.py` | UserPromptSubmit (edit-intent keywords) | Injects impact analysis reminder |
 | `serena-workflow-reminder.py` | SessionStart + PreToolUse (Edit) | Enforces Serena LSP over raw Edit |
 | `skill-suggestion.py` | UserPromptSubmit | Suggests relevant skill if detected |
-| `tdd-guard` hooks | PreToolUse (Edit/Write) | Blocks implementation without failing test |
 | `quality-gates` hooks | PostToolUse (Edit/Write) | Runs lint + type checks automatically |
 
 ---
@@ -255,7 +233,7 @@ These hooks run automatically — you cannot disable them mid-session:
 |---|---|---|
 | `serena` | Semantic code reading/editing | Auto-detected; activate project per session |
 | `gitnexus` | Knowledge graph, impact analysis | `npm install -g gitnexus` + `npx gitnexus analyze` per project |
-| `context7` | Library documentation lookup | Requires `CONTEXT7_API_KEY` in `~/.config/xtrm-tools/.env` |
+| `context7` | Library documentation lookup | No setup needed (free stdio transport) |
 | `deepwiki` | Technical docs for GitHub repos | No setup needed |
 | `github-grep` | Code search across GitHub | No setup needed |