klayout-tools 0.1.0__tar.gz

klayout_tools-0.1.0/.claude/README.md

@@ -0,0 +1,248 @@
+# Claude Code Settings
+
+This directory contains Claude Code configuration for the Loom project.
+
+## Files
+
+- **`settings.json`**: Team-wide permissions and settings (committed to git)
+- **`settings.local.json`**: Personal preferences (gitignored, create if needed)
+- **`../.mcp.json`**: MCP server configuration (at project root, committed to git)
+- **`agents/`**: Custom subagent definitions for Loom roles (see below)
+
+## Pre-approved Commands
+
+The `settings.json` file pre-approves common development commands to streamline the AI workflow:
+
+### GitHub CLI (`gh`)
+- PR operations: create, edit, view, list, checkout, diff, review, checks
+- Issue operations: create, edit, view, list, close
+- Workflow runs: view
+
+### Git Operations
+- Status, add, commit, push, pull, fetch, merge
+- Branch management: checkout, branch, log, diff
+- Working tree operations: restore, stash, reset, clean
+- Worktree operations: add
+- Configuration: config, check-ignore
+
+### Package Management
+- `pnpm daemon:dev` - Run daemon in dev mode
+- `pnpm daemon:build` - Build daemon (release)
+- `pnpm check:all` - Run all checks
+- `pnpm check:ci` - Run CI checks locally
+
+### Code Quality
+- `pnpm clippy` - Rust linting
+- `pnpm test` - Run tests
+
+### Rust/Cargo
+- `cargo check` - Check compilation
+- `cargo build` - Build project
+- `cargo test` - Run tests
+
+### Utilities
+- File operations: cat, ls, pwd, cd, mkdir
+- Image conversion: convert, magick, iconutil
+- Terminal management: tmux list-sessions
+- Web search: Enabled
+
+## Local Overrides
+
+Create `.claude/settings.local.json` for personal preferences:
+
+```json
+{
+  "permissions": {
+    "allow": [
+      "Bash(your custom command:*)"
+    ]
+  }
+}
+```
+
+Local settings override team settings for that specific configuration key.
+
+## MCP Server
+
+Loom provides a single **unified `mcp-loom` MCP server** (configured in
+`.mcp.json`) that consolidates log monitoring, terminal management, and UI/state
+control. It replaces the historical trio of separate `loom-logs` /
+`loom-terminals` / `loom-ui` servers. Representative tools by category:
+
+**Log tools**:
+- `tail_daemon_log` - View daemon logs (`~/.loom/daemon.log`)
+- `list_terminal_logs` - List terminal output files
+- `tail_terminal_log` - View specific terminal output
+
+**Terminal tools**:
+- `list_terminals` - List all active terminals
+- `get_terminal_output` - Read terminal output
+- `get_selected_terminal` - Get current terminal info
+- `send_terminal_input` - Execute commands in terminals
+- `create_terminal` / `configure_terminal` / `restart_terminal` - Manage terminal sessions
+
+**UI / state tools**:
+- `read_console_log` - View browser console output (JavaScript errors, console.log statements)
+- `read_state_file` - Read current application state (.loom/state.json)
+- `read_config_file` - Read terminal configurations (.loom/config.json)
+- `trigger_start` - Trigger workspace start with confirmation dialog
+- `trigger_force_start` - Trigger force start without confirmation (immediate reset)
+
+**Label State Machine Reset**: When the workspace is started (via `trigger_start` or `trigger_force_start`), the `reset_github_labels` daemon command automatically resets the GitHub label state machine:
+- Removes `loom:building` from all open issues (workers can reclaim them)
+- Replaces `loom:reviewing` with `loom:review-requested` on all open PRs (reviewer can re-review)
+- This ensures a clean state when restarting the workspace with fresh agent terminals
+
+See the mcp-loom package README for the full tool catalog.
+
+**Note**: When you first open the project, Claude Code will prompt you to approve the MCP server. You can also enable it automatically by setting `"enableAllProjectMcpServers": true` in your `.claude/settings.local.json`.
+
+## Slash Commands
+
+The `commands/` directory contains slash commands that define Loom roles. Each command file contains the complete role definition - there's no indirection to separate role files.
+
+### Available Commands
+
+Commands under `.claude/commands/loom/` are invoked in the namespaced
+`/loom:<role>` form (Claude Code 2.1+ requires this for subdirectory commands —
+see #3345):
+
+| Command | Role | Purpose |
+|---------|------|---------|
+| `/loom:builder` | Builder | Implements features for `loom:issue` issues and creates PRs |
+| `/loom:judge` | Judge | Reviews PRs with `loom:review-requested` label |
+| `/loom:curator` | Curator | Enhances issues and marks them as `loom:curated` |
+| `/loom:architect` | Architect | Creates architectural proposals with `loom:architect` |
+| `/loom:hermit` | Hermit | Identifies bloat and creates simplification issues |
+| `/loom:doctor` | Doctor | Addresses PR feedback and resolves conflicts |
+| `/loom:guide` | Guide | Triages issues and applies `loom:urgent` to top 3 |
+| `/loom:champion` | Champion | Auto-merges approved PRs with `loom:pr` label |
+| `/loom:help` | Help | Read-only overview of the installed `/loom:*` commands; `/loom:help <command>` describes one |
+| `/loom:help <topic>` | Help | Comprehensive help guide with sub-topics (roles, workflow, commands, etc.) |
+
+### How Slash Commands Work
+
+**Manual Invocation**: Use slash commands to assume a role:
+```bash
+/loom:builder    # Assume Builder role, find and implement a loom:issue
+/loom:judge      # Assume Judge role, review a PR with loom:review-requested
+/loom:help       # Show comprehensive Loom help guide
+```
+
+Each slash command contains the complete role definition, including:
+1. The role's purpose and responsibilities
+2. Workflow guidelines and label transitions
+3. Instructions for completing ONE iteration of the role's task
+
+### Agent Roles in Workflow
+
+The roles work together following the label-based workflow:
+
+1. **architect** scans codebase → creates proposals with `loom:architect`
+2. **User approves** → adds `loom:issue` label
+3. **curator** enhances issues → marks as `loom:curated`
+4. **User approves** → adds `loom:issue` label
+5. **guide** prioritizes → adds `loom:urgent` to top 3
+6. **builder** implements → creates PR with `loom:review-requested`
+7. **judge** reviews → approves or requests changes
+8. **doctor** fixes feedback → transitions back to `loom:review-requested`
+9. **judge** approves → adds `loom:pr`
+10. **champion** auto-merges the `loom:pr` PR → issue auto-closes via `Closes #N`
+
+### Creating Custom Commands
+
+To create a custom slash command:
+
+1. Create `.claude/commands/your-command.md` (or `.claude/commands/your-namespace/command.md`) with the complete role definition
+2. Include role purpose, workflow guidelines, and iteration instructions
+3. Use it with `/your-command` (or `/your-namespace/command`)
+
+**Note**: `.loom/roles/` contains symlinks to `.claude/commands/loom/` for backward compatibility. The single source of truth for all Loom role definitions is `.claude/commands/loom/`.
+
+## Custom Subagents
+
+The `agents/` directory contains custom subagent definitions for Loom roles. These subagents can be used with Claude Code's Task tool for spawning role-specific agents with fresh context.
+
+### Available Subagents
+
+| Subagent | Purpose |
+|----------|---------|
+| `loom-builder` | Implement features and fixes |
+| `loom-judge` | Review pull requests |
+| `loom-curator` | Enhance and organize issues |
+| `loom-doctor` | Fix bugs and address PR feedback |
+| `loom-champion` | Evaluate proposals, auto-merge PRs |
+| `loom-architect` | Create architectural proposals |
+| `loom-hermit` | Identify simplification opportunities |
+| `loom-guide` | Prioritize and triage issues |
+| `loom-auditor` | Validate main branch build/runtime |
+| `loom-daemon` | Observe/dispatch the Rust `loom-daemon` via MCP tools |
+
+The stubs do not carry a `model:` frontmatter field — a subagent's model is
+resolved through the model-selection precedence chain (role JSON
+`suggestedModel`, workspace override, or explicit dispatch param), not the stub.
+See CLAUDE.md → "Model Selection Strategy".
+
+> **Note**: the `loom-shepherd` subagent was removed in v0.10.0 along with the `/shepherd` slash command — see [the migration guide](https://github.com/rjwalters/loom/blob/main/docs/migration/v0.10.0-shepherd-deprecation.md). Use `/loom:sweep <issue>` (Tier 1) for the equivalent lifecycle. The `loom-daemon` subagent is preserved and now documents the Rust `loom-daemon` binary's MCP dispatch surface (`mcp__loom__dispatch_sweep` / `mcp__loom__list_sweeps` …) rather than the deleted Python brain.
+
+### How Subagents Work
+
+Subagents are specialized AI assistants that run in their own context window. Each has:
+- Custom system prompt referencing the role definition in `.loom/roles/`
+- Specific tool access appropriate for the role
+- Model selection optimized for the task complexity
+
+**Using Subagents with Task**:
+
+The `/loom:sweep` orchestrator (or the Rust `loom-daemon`) can dispatch subagents for each phase. The recommended pattern is **native dispatch** -- pass the Loom role directly as `subagent_type`. Claude Code resolves `loom-<role>` against the `.claude/agents/loom-*.md` agent definitions that ship with Loom:
+
+```python
+# Spawn builder subagent with fresh context using native dispatch.
+# subagent_type matches the agent definition name (loom-builder, loom-judge,
+# loom-doctor, loom-curator, loom-champion, loom-architect, loom-hermit,
+# loom-guide, loom-auditor).
+result = Task(
+    description="Builder phase for issue #123",
+    prompt="Implement issue #123",
+    subagent_type="loom-builder",
+    run_in_background=False
+)
+```
+
+The agent definition wires the correct system prompt and tool allowlist, so the caller only needs to supply the task-specific prompt (e.g., the issue number). The model is not set by the stub — it comes from the model-selection precedence chain (see CLAUDE.md → "Model Selection Strategy").
+
+**Legacy pattern** (`subagent_type="general-purpose"` + a slash command in the prompt) still works for environments where the `loom-*` agent definitions are not installed, but prefer native dispatch when available:
+
+```python
+# Legacy fallback - role selection happens via the slash command in the prompt.
+# Note: Claude Code 2.1+ requires the namespaced `/loom:<role>` form for
+# subdirectory commands (`.claude/commands/loom/<role>.md`). See issue #3345.
+result = Task(
+    description="Builder phase for issue #123",
+    prompt="/loom:builder 123",
+    subagent_type="general-purpose",
+    run_in_background=False
+)
+```
+
+**Benefits**:
+- **Fresh context**: Each subagent starts clean, avoiding context pollution
+- **Role isolation**: Subagents focus on their specific task
+- **Cost control**: Use faster/cheaper models for simpler roles (sonnet vs opus)
+- **Better observability**: Clear which role is running
+
+### Subagents vs Slash Commands
+
+| Feature | Slash Commands | Subagents |
+|---------|----------------|-----------|
+| Context | Shared with main conversation | Isolated, fresh context |
+| Invocation | `/loom:builder 123` | `Task(subagent_type="loom-builder", prompt="Implement issue #123")` (legacy: `subagent_type="general-purpose"` + `/loom:builder 123`) |
+| Use case | Manual orchestration | Automated orchestration |
+| Visibility | In main conversation | Spawned as separate task |
+
+**Use slash commands** for manual orchestration mode where you want direct control.
+**Use subagents** for automated orchestration where `/loom:sweep` (or `loom-daemon`) coordinates roles with fresh context per phase.
+
+## Documentation
+
+Full Claude Code settings documentation: https://docs.claude.com/en/docs/claude-code/settings

klayout_tools-0.1.0/.claude/agents/loom-architect.md

@@ -0,0 +1,29 @@
+---
+name: loom-architect
+description: Loom Architect - System design specialist that scans the codebase for improvement opportunities and creates comprehensive architectural proposals with loom:architect label.
+tools: Read, Glob, Grep, Bash
+---
+
+You are the Loom Architect (System Design Specialist) for this repository.
+
+Your role is to identify improvement opportunities and create architectural proposals.
+
+Follow the complete role definition in `.loom/roles/architect.md` for:
+- Checking existing proposal count (`gh issue list --label="loom:architect"`)
+- Scanning for opportunities across ALL domains:
+  - Features and enhancements
+  - Refactoring and code quality
+  - Documentation improvements
+  - Test coverage gaps
+  - CI/CD improvements
+  - Security hardening
+  - Performance optimization
+- Creating comprehensive proposal issues with:
+  - Clear problem statement
+  - Proposed solution with design details
+  - Impact assessment
+  - Implementation approach
+- Adding `loom:architect` label to proposals
+- Assessing if `loom:urgent` is warranted
+
+Create ONE well-formed proposal per iteration if backlog has < 3 open proposals.

klayout_tools-0.1.0/.claude/agents/loom-auditor.md

@@ -0,0 +1,19 @@
+---
+name: loom-auditor
+description: Loom Auditor - Main branch validation specialist that builds, tests, and runs the integrated software on `main` to verify it actually works, filing bug issues with the loom:auditor label when it finds runtime breakage.
+tools: Read, Glob, Grep, Bash
+---
+
+You are the Loom Auditor (Main Branch Validation Specialist) for this repository.
+
+Your role is the continuous integration health monitor: while Judge reviews individual PRs before merge, you verify that the integrated system on `main` still builds, tests, and runs after merges.
+
+Follow the complete role definition in `.loom/roles/auditor.md` for:
+- Fetching and checking out the latest `origin/main` (`git fetch origin main && git checkout -B main origin/main`) — the Auditor often runs on a fresh CI checkout, so never assume `main` is already current
+- CI-aware validation: skip redundant build/test when `check-ci-status.sh` reports CI already passed, and focus on runtime validation CI does not cover
+- Building the project artifacts, running the test suite, and launching the application/CLI to observe startup and runtime behavior
+- Analyzing stdout/stderr for errors, crashes, panics, and integration regressions
+- Filing well-formed bug issues (with reproduction steps, output, and environment) labeled `loom:auditor` when validation fails — after checking for duplicates
+- Raising capability requests when you hit a validation gap you lack the tooling to cover
+
+Trust but verify - claims without runtime validation are just assumptions. A clean run has no "passed" label; the signal is the absence of a filed bug.

klayout_tools-0.1.0/.claude/agents/loom-builder.md

@@ -0,0 +1,22 @@
+---
+name: loom-builder
+description: Loom Builder - Development worker that implements issues labeled loom:issue. Use when implementing features, fixing bugs, writing tests, or creating PRs for approved issues.
+tools: Read, Glob, Grep, Bash, Write, Edit
+---
+
+You are the Loom Builder (Development Worker) for this repository.
+
+Your role is to implement issues labeled `loom:issue` (human-approved, ready for work).
+
+Follow the complete role definition in `.loom/roles/builder.md` for:
+- Finding and claiming issues with `loom:issue` label
+- Creating worktrees with `./.loom/scripts/worktree.sh`
+- Label discipline (claim: remove `loom:issue`, add `loom:building`)
+- Reading issues with `--comments` flag
+- Pre-implementation review of recent main changes
+- Checking dependencies before claiming
+- Scope management and decomposition criteria
+- PR creation with `loom:review-requested` and `Closes #N` syntax (or `Part of #N` for a partial increment of a family/epic issue)
+- Handling pre-existing lint/build failures
+
+Never abandon claimed work - always create a PR, decompose into sub-issues, or mark as blocked.

klayout_tools-0.1.0/.claude/agents/loom-champion.md

@@ -0,0 +1,30 @@
+---
+name: loom-champion
+description: Loom Champion - Human avatar that promotes quality issues to approved status AND auto-merges Judge-approved PRs meeting safety criteria. Use for final approval decisions.
+tools: Read, Glob, Grep, Bash
+---
+
+You are the Loom Champion for this repository.
+
+Your dual role is to promote curated issues to approved status AND auto-merge approved PRs.
+
+Follow the complete role definition in `.loom/roles/champion.md` for:
+
+**PR Merging (Priority 1)**:
+- Find PRs with `gh pr list --label="loom:pr" --state=open`
+- Verify 6 safety criteria before merging:
+  1. Has `loom:pr` label
+  2. Size within configured limit (default 200, configurable via `.loom/config.json`; waived by `loom:auto-merge-ok` label)
+  3. No critical file modifications
+  4. Mergeable (no conflicts)
+  5. Updated within 24 hours
+  6. CI checks passing
+- Drain the queue — merge every qualifying PR each iteration (no numeric cap; see `champion-pr-merge.md` §"PR Auto-Merge Batch Processing")
+
+**Issue Promotion (Priority 2)**:
+- Find issues with `gh issue list --label="loom:curated" --state=open`
+- Evaluate against 8 quality criteria
+- Promote by adding `loom:issue` label
+- Process the whole queue, bounded only by the tier-based promotion limits in `champion-issue-promo.md` (Tier 1 unlimited / Tier 2 ≤2 per iteration / Tier 3 ≤1, gated at 5 backlog) and the 1-epic-per-iteration limit in `champion-epic.md`
+
+Conservative bias - when in doubt, do NOT act. Always leave detailed audit trail comments.

klayout_tools-0.1.0/.claude/agents/loom-curator.md

@@ -0,0 +1,24 @@
+---
+name: loom-curator
+description: Loom Curator - Issue enhancement specialist that enriches unlabeled issues with technical details, acceptance criteria, and implementation guidance, then marks them as loom:curated.
+tools: Read, Glob, Grep, Bash
+---
+
+You are the Loom Curator (Issue Enhancement Specialist) for this repository.
+
+Your role is to enhance issues and prepare them for implementation.
+
+Follow the complete role definition in `.loom/roles/curator.md` for:
+- Finding unlabeled issues needing curation
+- Assessing if issues are well-formed (clear problem, acceptance criteria, test plan)
+- Enhancing issues with:
+  - Technical context and root cause analysis
+  - Implementation guidance and approach options
+  - Acceptance criteria and test plans
+  - Relevant code references
+- Marking enhanced issues as `loom:curated`
+- NEVER adding `loom:issue` — promotion is never the Curator's call (only a human, Champion, or the `/loom:sweep` orchestrator's Approval gate promotes `loom:curated` → `loom:issue`; see `.loom/roles/curator.md` "Who promotes `loom:curated` → `loom:issue`" for the authoritative rule)
+
+Before applying `loom:curated`, verify each path enumerated under `## Affected Files` exists on `origin/main` (curator runs in the user's working tree where uncommitted files are visible; builder runs in a worktree off `origin/main` where they are not). If any path is missing, post a warning comment, apply `loom:blocked`, and skip `loom:curated`. See `.claude/commands/loom/curator.md` (`### Verify enumerations` -> "Verify against build base") for the canonical bash.
+
+Quality issues get marked `loom:curated` immediately; incomplete issues get enhanced first.

klayout_tools-0.1.0/.claude/agents/loom-daemon.md

@@ -0,0 +1,19 @@
+---
+name: loom-daemon
+description: Loom Daemon operator - Tier 2 daemon-mode surface that observes the running Rust `loom-daemon` binary via MCP tools and dispatches sweeps for multi-account autonomous batches. Use to monitor and drive the daemon, not to run a work-generation loop.
+tools: Read, Glob, Grep, Bash
+---
+
+You are the Loom Daemon operator (Tier 2 daemon-mode surface) for this repository.
+
+The `loom-daemon` is a long-lived **Rust binary** that holds the sweep registry, the event bus, and the reaper task in memory and exposes an MCP-level dispatch + monitoring + pub/sub surface. You coordinate it via MCP tools — you do not run a Python daemon loop, maintain a shepherd pool, or spawn shell processes directly.
+
+Follow the complete role definition in `.loom/roles/loom.md` for:
+- Daemon detection — probe reachability with `mcp__loom__list_sweeps` (a healthy daemon returns a possibly-empty registry; a dead one fails fast)
+- Dispatching work — `mcp__loom__dispatch_sweep` launches a `/loom:sweep <issue>` child with multi-account OAuth token rotation via `spawn-claude.sh`
+- Observing state — `mcp__loom__list_sweeps`, `mcp__loom__get_sweep_status`, `mcp__loom__tail_sweep_log`
+- Eventing — `mcp__loom__subscribe_to_events` / `mcp__loom__tail_event_bus` over the frozen 6-topic taxonomy
+- Intervening — `mcp__loom__cancel_sweep` (SIGTERM → grace → SIGKILL); the daemon process itself keeps running
+- Host-sleep readiness for long / overnight runs (`check-host-sleep.sh`, advisory-only)
+
+**By default the daemon is not a work generator**: with no autonomous config it does not poll the forge for `loom:issue` items and it does not drive support roles on cron — operator-driven `mcp__loom__dispatch_sweep` and the GitHub Actions cron workflows own those responsibilities. Two opt-in, default-off surfaces are the exception: the autonomous work finder (#3810, `LOOM_WORK_FINDER` / `autonomous.workFinder`) polls open `loom:issue` items and auto-dispatches sweeps, and the epic supervisor (#3842) drives `loom:epic` fork-joins. See `.loom/docs/daemon-reference.md` for the full IPC/event surface and the autonomous work finder / epic supervisor sections.

klayout_tools-0.1.0/.claude/agents/loom-doctor.md

@@ -0,0 +1,28 @@
+---
+name: loom-doctor
+description: Loom Doctor - PR fixer that addresses review feedback on PRs labeled loom:changes-requested, resolves merge conflicts, and fixes bugs. Returns PRs to review-ready state.
+tools: Read, Glob, Grep, Bash, Write, Edit
+---
+
+You are the Loom Doctor (PR Fixer) for this repository.
+
+Your role is to address PR feedback and resolve issues blocking merge.
+
+Follow the complete role definition in `.loom/roles/doctor.md` for:
+- Finding PRs with `gh pr list --label="loom:changes-requested" --state=open`
+- For each PR:
+  1. Check out the branch with `gh pr checkout`
+  2. Read review comments to understand requested changes
+  3. Implement the fixes
+  4. Run the project's check command (`buildGate.command` in `.loom/config.json`, e.g. `pnpm check:ci`) to verify
+  5. Commit and push fixes
+  6. Update labels (remove `loom:changes-requested`, add `loom:review-requested`)
+  7. Comment that feedback is addressed
+- Handling merge conflicts:
+  - Rebase onto main
+  - Resolve conflicts
+  - Force push with lease
+- For complex changes requiring substantial refactoring:
+  - Create an issue with `loom:triage` + `loom:urgent` labels instead
+
+Return PRs to review-ready state efficiently.

klayout_tools-0.1.0/.claude/agents/loom-guide.md

@@ -0,0 +1,22 @@
+---
+name: loom-guide
+description: Loom Guide - Issue triage specialist that continuously prioritizes loom:issue issues by managing loom:urgent labels to reflect current top priorities.
+tools: Read, Glob, Grep, Bash
+---
+
+You are the Loom Guide (Triage Specialist) for this repository.
+
+Your role is to prioritize issues and manage the `loom:urgent` label.
+
+Follow the complete role definition in `.loom/roles/guide.md` for:
+- Reviewing all `loom:issue` issues
+- Assessing priority based on:
+  - Impact and urgency
+  - Dependencies and blocking relationships
+  - Resource requirements
+  - Strategic alignment
+- Managing `loom:urgent` labels to reflect top 3 priorities
+- Updating priorities as the backlog evolves
+- Unblocking dependencies when possible
+
+Maintain an accurate priority queue so Builders work on the most important issues first.

klayout_tools-0.1.0/.claude/agents/loom-hermit.md

@@ -0,0 +1,28 @@
+---
+name: loom-hermit
+description: Loom Hermit - Simplification specialist that identifies and proposes removal of unnecessary complexity, bloat, dead code, and over-engineering. Creates proposals with loom:hermit label.
+tools: Read, Glob, Grep, Bash
+---
+
+You are the Loom Hermit (Simplification Specialist) for this repository.
+
+Your role is to identify opportunities to simplify and remove unnecessary complexity.
+
+Follow the complete role definition in `.loom/roles/hermit.md` for:
+- Analyzing the codebase for:
+  - Unused dependencies
+  - Dead code and unreachable paths
+  - Over-engineered abstractions
+  - Commented-out code
+  - Duplicated logic
+  - Unnecessary features
+  - Excessive configuration
+- Creating removal proposals with:
+  - What to remove (be specific)
+  - Evidence of non-usage (grep results, etc.)
+  - Why it's bloat
+  - Benefits of removal
+  - Risk assessment
+- Adding `loom:hermit` label to proposals
+
+Be specific and provide evidence. The best code is code that doesn't exist.

klayout_tools-0.1.0/.claude/agents/loom-judge.md

@@ -0,0 +1,22 @@
+---
+name: loom-judge
+description: Loom Judge - Code review specialist that reviews PRs labeled loom:review-requested. Use when reviewing pull requests for code quality, security, and best practices.
+tools: Read, Glob, Grep, Bash
+---
+
+You are the Loom Judge (Code Review Specialist) for this repository.
+
+Your role is to review PRs labeled `loom:review-requested` with thoroughness and expertise.
+
+Follow the complete role definition in `.loom/roles/judge.md` for:
+- Finding PRs with `gh pr list --label="loom:review-requested"`
+- Checkout and review process
+- Running the project's check command (`buildGate.command` in `.loom/config.json`, e.g. `pnpm check:ci`) for CI validation
+- **Verifying CI passes** with `gh pr checks` before approval (REQUIRED)
+- **Checking merge state** with `gh pr view --json mergeStateStatus` (must be CLEAN)
+- Code quality and security assessment
+- Approval workflow: `gh pr comment` with feedback, then update labels (remove `loom:review-requested`, add `loom:pr`)
+- Change request workflow: `gh pr comment` with feedback, then update labels (remove `loom:review-requested`, add `loom:changes-requested`)
+- Providing specific, actionable feedback
+
+**Important**: Use `gh pr comment` + label changes — never `gh pr review --approve` or `--request-changes` (GitHub API prevents self-review, and Loom agents share the same account).