fix: dev config cleanup — hook infra, stale MCP, gitignore

.claude/commands/audit.md

@@ -0,0 +1,123 @@
+---
+allowed-tools: Bash(crosslink *), Bash(git *), Bash(ls *), Read
+description: Full context dump for debugging — use when stuck or disoriented
+---
+
+## Context
+
+- Session status: !`crosslink session status`
+- Open issues: !`crosslink issue list -s open`
+- Active locks: !`crosslink locks list 2>/dev/null`
+- Current branch: !`git branch --show-current`
+- Working tree: !`git status --short`
+
+## Your task
+
+You are stuck, confused, or need to re-orient. This skill dumps all available context so you can diagnose the problem. Run through each section and print the results.
+
+### 1. Project grounding (same as /preflight)
+
+Read core rules:
+```
+Read .crosslink/rules/global.md
+```
+
+Detect languages and read relevant rule files (check for `Cargo.toml`, `package.json`, `tsconfig.json`, `pyproject.toml`, `go.mod`, etc.).
+
+Read project-specific rules:
+```
+Read .crosslink/rules/project.md
+```
+
+Read tracking rules based on current mode:
+```bash
+crosslink config get tracking_mode
+```
+Then read `.crosslink/rules/tracking-<mode>.md`.
+
+### 2. Project tree scan
+
+```bash
+ls -1
+```
+
+Scan the project tree (max depth 3, max 50 entries) to ground yourself on actual paths.
+
+### 3. Dependency versions
+
+Read the primary manifest file to confirm actual dependency versions.
+
+### 4. Session state
+
+```bash
+crosslink session status
+```
+
+What issue are you working on? What was the last action?
+
+### 5. Active issue details
+
+If working on an issue, get full details:
+
+```bash
+crosslink issue show <issue-id>
+```
+
+Review all comments, especially plan and decision comments.
+
+### 6. Related issues and blockers
+
+```bash
+crosslink issue blocked
+crosslink issue ready
+```
+
+Are there blocking dependencies? What's unblocked and available?
+
+### 7. Lock state
+
+```bash
+crosslink locks list 2>/dev/null
+```
+
+Are any issues locked by other agents?
+
+### 8. Recent interventions
+
+Check if there have been recent hook blocks or driver redirects by reviewing recent issue comments.
+
+### 9. Hook configuration
+
+```bash
+crosslink config show
+```
+
+What tracking mode is active? What commands are blocked/gated?
+
+### 10. Git state
+
+```bash
+git status
+git log --oneline -5
+git diff --stat HEAD
+```
+
+What's the current branch state? Any uncommitted changes?
+
+### 11. Print diagnostic summary
+
+```
+Audit summary:
+  Session:    active / working on #<id>
+  Branch:     <branch>
+  Tracking:   <mode>
+  Languages:  <list>
+  Open issues: <count>
+  Blocked:    <count>
+  Locks:      <count>
+  Uncommitted: <count> files changed
+
+Loaded rules: global.md, <lang>.md, tracking-<mode>.md, project.md
+```
+
+You are now fully re-oriented. Decide your next action based on this context.

.claude/commands/check.md

@@ -1,41 +1,87 @@
 ---
-allowed-tools: Bash(tmux *), Bash(cat *), Bash(test *), Bash(ls *), Bash(git *), Bash(tail *)
-description: Check on a background feature agent running in a tmux session
+allowed-tools: Bash(tmux *), Bash(docker *), Bash(crosslink *), Bash(cat *), Bash(test *), Bash(ls *), Bash(git *), Bash(tail *), Bash(grep *)
+description: Check on background feature agents running in containers or tmux sessions
 ---
 
 ## Context
 
-- Active tmux sessions: !`tmux list-sessions 2>/dev/null || echo "no tmux server running"`
+- Running containers: !`docker ps --filter label=crosslink-agent=true --format 'table {{.Names}}\t{{.Status}}' 2>/dev/null`
+- Active tmux sessions: !`tmux list-sessions 2>/dev/null`
 - Current worktrees: !`git worktree list`
 
 ## Your task
 
-The user optionally provides a tmux session name (e.g. `feat-add-batch-retry`). If no session name is given, check **all** active `feat-*` tmux sessions and report a summary for each.
+The user optionally provides an agent name (e.g. `crosslink-task-add-batch-retry` or `feat-add-batch-retry`). If no name is given, check **all** active feature agents (both containers and tmux sessions) and report a summary for each.
 
-### 1. Identify sessions to check
+### 1. Identify agents to check
 
-- If the user provided a session name, use that single session.
-- If no session name was provided, list all tmux sessions whose names start with `feat-`: `tmux list-sessions -F '#{session_name}' 2>/dev/null | grep '^feat-'`
-- If no `feat-*` sessions exist, report "No active feature agent sessions found."
+#### a. Find container-based agents
 
-### 2. For each session, perform these checks:
+1. Get this repo's worktree paths: `git worktree list --porcelain | grep '^worktree ' | sed 's/^worktree //'`
+2. List crosslink containers: `docker ps -a --filter label=crosslink-agent=true --format '{{.Names}} {{.Status}} {{.Label "crosslink-task"}}' 2>/dev/null`
+3. Match containers to this repo: for each container, check if its `crosslink-task` label value matches any of this repo's worktree directory names (the last path component)
+4. If the user provided a name starting with `crosslink-task-`, filter to that specific container
 
-#### a. Check the sentinel file
+#### b. Find tmux-based agents
 
-Find the worktree path for this session by checking `git worktree list` and matching the session name to a feature branch. The session name `feat-<slug>` corresponds to branch `feature/<slug>`.
+1. Get `feat-*` tmux sessions: `tmux list-sessions -F '#{session_name} #{session_path}' 2>/dev/null | grep '^feat-'`
+2. Only include sessions whose `session_path` matches one of this repo's worktree paths
+3. If the user provided a name starting with `feat-`, filter to that specific session
+
+If no agents found in either mode, report "No active feature agents for this repo."
+
+### 2. For each agent, perform these checks:
+
+#### For container-based agents:
+
+##### a. Check the sentinel file
+
+Get the worktree path by matching the container's `crosslink-task` label to a worktree directory name from `git worktree list`.
+
+- Check: `cat <worktree-path>/.kickoff-status 2>/dev/null`
+- If it contains `DONE`, mark as finished.
+- If it contains `CI_FAILED`, mark as CI failure.
+
+##### b. Check container status
+
+```bash
+docker inspect --format '{{.State.Status}} (exit {{.State.ExitCode}})' <container-name>
+```
+
+Possible states: `running`, `exited` (check exit code), `restarting`, `paused`.
+
+##### c. Capture recent output
+
+```bash
+docker logs --tail 80 <container-name> 2>&1
+```
+
+##### d. Analyze state
+
+- **Working**: Container status is `running`, no sentinel file, recent tool calls visible in logs
+- **Idle**: Container is `running` but no recent output changes — may be thinking or waiting for API
+- **Error**: Container `exited` with non-zero exit code, or error messages in recent logs
+- **Done**: Sentinel file says `DONE`, or container exited with code 0
+- **CI Failed**: Sentinel file says `CI_FAILED`
+
+#### For tmux-based agents:
+
+##### a. Check the sentinel file
+
+Get the worktree path for this session from tmux: `tmux display-message -t <session-name> -p '#{session_path}'`. Alternatively, match the session name to a feature branch in `git worktree list`.
 
 - Check if `.kickoff-status` exists in the worktree: `cat <worktree-path>/.kickoff-status 2>/dev/null`
 - If it contains `DONE`, mark this session as finished.
 
-#### b. Capture the terminal state
+##### b. Capture the terminal state
 
 ```bash
 tmux capture-pane -t <session-name> -p -S -80
 ```
 
 This captures the last ~80 lines of visible output.
 
-#### c. Analyze state
+##### c. Analyze state
 
 Read the captured output and determine the agent's current state:
 
@@ -46,38 +92,49 @@ Read the captured output and determine the agent's current state:
 
 ### 3. Report
 
-When checking **multiple sessions**, use a compact table format:
+When checking **multiple agents**, use a compact table format with a backend indicator:
 
 ```
 Feature Agents:
 
-  feat-add-retry       Working    Implementing retry logic in _sources.py
-  feat-fix-lens-bug    Done       All changes committed and reviewed
-  feat-new-cli-cmd     Waiting    Asking about CLI argument format
+  crosslink-task-add-retry    [container]  Working    Implementing retry logic in _sources.py
+  crosslink-task-fix-lens     [container]  Done       All changes committed and reviewed
+  feat-new-cli-cmd            [tmux]       Waiting    Asking about CLI argument format
 ```
 
-When checking a **single session**, use the detailed format:
+When checking a **single agent**, use the detailed format:
 
 ```
-Session: <name>
-Status:  <Working | Waiting | Done | Error>
+Agent:    <name>
+Backend:  <container|tmux>
+Status:   <Working | Idle | Waiting | Done | Error>
 
 <2-3 sentence summary of what the agent is currently doing or has accomplished>
 ```
 
+For container agents, also show resource usage:
+```bash
+docker stats --no-stream --format '  CPU: {{.CPUPerc}}  Memory: {{.MemUsage}}' <container-name> 2>/dev/null
+```
+
 ### 4. Offer actions
 
-Based on the status of each session, suggest relevant next steps:
+#### For container agents:
+
+- **If working/idle**: "Check back later, or view live logs: `crosslink container logs <name> -f`"
+- **If done**: "Agent finished. Review the changes: `cd <worktree-path> && git log --oneline <base-branch>..HEAD`"
+- **If error**: Show the relevant error output. Suggest: "Debug with: `crosslink container shell <name>` or view full logs: `crosslink container logs <name> --tail 500`"
+- **If exited (non-zero)**: "Container exited with error. View logs: `crosslink container logs <name>`. Restart with: `crosslink container kill <name> && crosslink container start <worktree-path>`"
+
+#### For tmux agents:
 
 - **If working**: "Check back later, or attach directly: `tmux attach -t <name>`"
 - **If waiting for input**: Read the question, and ask the user what to answer. If the user provides an answer, send it: `tmux send-keys -t <session-name> "<response>" Enter`
-- **If done**: "Agent finished. Review the changes: `cd <worktree-path> && git log --oneline develop..HEAD`"
+- **If done**: "Agent finished. Review the changes: `cd <worktree-path> && git log --oneline <base-branch>..HEAD`"
 - **If error**: Show the relevant error output and suggest the user attach to debug: `tmux attach -t <name>`
 
-When multiple sessions are reported, only show detailed actions for sessions that need attention (Waiting or Error).
-
 ## Constraints
 
 - Do not modify any files in the worktree — this is a read-only check.
-- Do not kill the tmux session unless the user explicitly asks.
-- When relaying a user's answer to a waiting prompt, send exactly what the user provides — do not embellish or modify.
+- Do not kill containers or tmux sessions unless the user explicitly asks.
+- When relaying a user's answer to a waiting tmux prompt, send exactly what the user provides — do not embellish or modify.

.claude/commands/commit.md

@@ -0,0 +1,65 @@
+---
+allowed-tools: Bash(git *), Bash(crosslink *)
+description: Commit changes and auto-document the result on the active crosslink issue
+---
+
+## Context
+
+- Working tree status: !`git status --short`
+- Current branch: !`git branch --show-current`
+- Active session: !`crosslink session status 2>/dev/null`
+
+## Your task
+
+The user wants to commit their current changes. You will create a well-formed git commit AND automatically record a result comment on the active crosslink issue.
+
+### 1. Review changes
+
+Run `git diff --cached --stat` and `git diff --stat` to see staged and unstaged changes. If nothing is staged, stage the relevant files (ask the user if unclear which files to include). Never use `git add -A` blindly — stage specific files.
+
+### 2. Write the commit message
+
+- Summarize what changed and why (1-2 sentences)
+- Follow conventional commit style if the project uses it
+- Include the crosslink issue reference if an active issue exists (e.g. `[CL-5]`)
+
+### 3. Create the commit
+
+```bash
+git commit -m "<message>"
+```
+
+### 4. Auto-document the result on the active crosslink issue
+
+After a successful commit, check if there's an active crosslink session with an active issue:
+
+```bash
+crosslink session status
+```
+
+If an active issue exists, record the commit as a result comment:
+
+```bash
+crosslink issue comment <issue-id> "Committed: <first line of commit message> | Files: <shortstat summary>" --kind result
+```
+
+For example:
+```bash
+crosslink issue comment 5 "Committed: Add typed comment support to schema | Files: 14 files changed, 312 insertions(+), 48 deletions(-)" --kind result
+```
+
+If no active session or issue, skip the comment silently.
+
+### 5. Show summary
+
+Display:
+- The commit hash and message
+- Files changed summary
+- Whether the result was recorded on a crosslink issue
+
+## Constraints
+
+- Never force-push or amend commits without explicit user request.
+- Never use `git add -A` or `git add .` without confirming with the user.
+- Always record the result comment after a successful commit when an active issue exists.
+- If the commit fails (e.g. pre-commit hook), fix the issue and retry — do NOT record a result comment for failed commits.