leodearden
@leodearden
Public Skills
escalation-watcher-auto
by leodearden
"Autonomous level-1 escalation watcher. Acts as the L1 consumer and triage funnel to the human (L2): handles admin-class escalations directly (scope_violation, dependency_discovered, cleanup_needed), performs shallow root-cause analysis to detect causal clusters, and promotes judgement-class items — single or clustered — to L2 via promote_to_l2 so the human receives a pre-formed hypothesis with evidence and concrete options. When promote_to_l2 is unavailable (graceful degradation), falls back to the legacy leave-pending + digest mode. Runs until ROTATION_ESCALATIONS or ROTATION_HOURS is reached, then exits cleanly. This is a fully autonomous, no-terminal skill — do NOT use it for interactive unblocking."
escalation-watcher
by leodearden
"Watch for and handle level-2 escalations from the dark-factory orchestrator in a long-running loop. Under the 3-tier escalation ladder (L0→per-task steward, L1→escalation-watcher-auto, L2→human), this skill is the L2 consumer. Use this skill when the user wants to monitor escalations, says 'watch escalations', 'handle escalations', 'babysit the orchestrator', or wants a long-running session to catch and triage issues that the auto-watcher couldn't resolve. Also trigger when the user starts an orchestrator run and asks you to keep an eye on it, mentions escalations piling up, or wants automated escalation handling. This is a continuous loop skill that runs until stopped."
spawn
by leodearden
"Spawn a new Claude Code CLI session in a new terminal window with a given prompt. Use when another skill (such as escalation-watcher) needs to hand a task off to a fresh interactive Claude session running in its own terminal — for example, spawning /unblock <task> so a human can drive it. Triggers on phrases like 'spawn a claude session', 'open a new terminal with claude', 'launch /unblock in a new window'. NOT for: running arbitrary shell commands in a new terminal, or invoking Claude inside the current session (use a sub-agent for that)."
unblock
by leodearden
"Unblock a stuck orchestrator task — whether blocked on review issues, merge failures, or agent escalations. Use this skill when the user mentions a blocked or stuck task, wants to resolve review issues in a worktree, handle an escalation for a specific task, or says things like 'unblock task 64', 'task 107 is stuck', 'fix the review issues', or '/unblock <number>'. Also trigger when the user references a specific task number alongside words like 'blocked', 'stuck', 'failed', 'escalated', or 'review issues' — even if they don't say 'unblock' explicitly."
orchestrate
by leodearden
"Implement software from a PRD or task tree using the dark-factory orchestrator. Use this skill when the user wants to: run the orchestrator against a PRD, check orchestrator/task status, resolve blocked tasks, resume stalled work, or manage concurrent TDD workflows. Trigger on mentions of PRDs, orchestrating implementation, running tasks through the pipeline, checking task status, or resolving blocked/failed tasks — even if the user doesn't say 'orchestrator' explicitly."
recon-escalation-watcher
by leodearden
"Watch and close fused-memory's RECONCILIATION escalation queue (port 8103) in a long-running loop. This is the consumer for the recon queue — the integrity/operational findings the reconciliation harness files, NOT the orchestrator's task-pipeline escalations (those are escalation-watcher's job, ports 8100/8102). Use when the user says 'watch recon escalations', 'monitor the fused-memory escalation queue', 'babysit reconciliation', mentions the 8103 queue, recon_integrity_issue / recon_failure / recon_stale_run findings piling up, or wants the reconciliation queue triaged and closed. This is a continuous loop skill; the watcher is the SOLE closer of the recon queue (recon never resolves its own findings). This is NOT for orchestrator task escalations, blocked tasks, merge failures, or worktrees."
review-all
by leodearden
"Deep, infrequent, human-attended review of a WHOLE project's architectural and code quality against docs/code-quality.md — pins one tree, takes a whole-repo metrics snapshot (a report, never a gate), refreshes the stale instruments in delta mode (/hotspot-survey --refresh, /review --since) and consumes the census codebook, then runs a heuristic-driven architecture pass: one seat per area judging all fourteen heuristics and both stances, cross-area seats for SPOT / layering / orthogonal dimensions / stateless interactions, a skeptic per seat blinded to proposals, a synthesis joined by finding key with every prior instrument's open findings, and a critic of that synthesis; ends in deliberation with the human, a program doc and /prd per stream, and files the completion-driven trigger for the next run. ALWAYS use this skill for: '/review-all', 'review the whole project against the quality heuristics', 'whole-repo architecture and code-quality review', 'what should we refactor across the whole codebase', 'the quarterly factory self-review', or when the human gate task 'Run /review-all on <project>' dispatches. This is a serious commitment — the first dark-factory run measured 22.9M subagent tokens (8.6M of them in the Phase 2 instrument refreshes), 8 h of machine time for phases 1–4 and one full deliberation sitting plus the /prd work — so state the cost, Phase 2 included, and get a go before phase 2 (--full or --yes skips only the wait, never the posting). NOT for: does-it-run correctness of landed work (/review), bug-history hotspots alone (/hotspot-survey), confusion sightings (/census), one module (/study), one bug (/deb), authoring the remediation PRDs (/prd — fed by this skill's program doc), or anything unattended."
review-briefing
by leodearden
"Create and maintain the review briefing — a project-specific context file that tells the /review skill what matters about a project: purpose, important scenarios, architectural decisions, conventions, and known gaps. The briefing captures durable truths that can't be inferred from code alone — not code structure (which goes stale). ALWAYS use this skill for: /review-briefing commands, creating or updating review/briefing.yaml, setting up review context for a project, when the user says 'create a review briefing' or 'update the briefing', and when /review suggests running /review-briefing because no briefing exists. Also use when the user wants to validate their existing briefing or see what's changed. This is NOT for: running the actual review (/review), implementing code, or fixing issues found during review."
unblock-auto
by leodearden
"Autonomous dry-run version of /unblock. Investigate a blocked orchestrator task and emit a proposed action — read-only. Use this skill when you need to automatically assess a blocked task without human interaction. Never modifies any state; only reads worktree artifacts, git history, and task metadata to produce a structured proposal for review."
unblock-low-risk
by leodearden
"Autonomous, NON-INTERACTIVE unblock of a single blocked task — but ONLY when the orchestrator's at-block-time dry-run investigation labelled the fix risk_label == 'low'. This is the unattended counterpart to /unblock, built for AFK windows: the L2 escalation-watcher launches it as a sub-agent (no terminal) for task_failure/review_issues escalations whose latest metadata.dry_run_proposals[-1] is low-risk and fresh. It re-derives the fix from the proposal prose, applies it scoped to files_referenced, runs the project verify suite, and merges via the orchestrator merge queue — aborting cleanly (leaving the escalation pending for a human) on ANY doubt: non-low risk, stale proposal, scope creep, rebase conflict, verify failure, or a merge-queue result other than done. A merge the worker has already picked up and is still live at the polling ceiling is handed back to the watcher (outcome handed_off), never cancelled. It NEVER touches main directly, never --no-verify, never retries. NOT for: medium / human-review-required proposals, interactive unblocking (use /unblock), any task without a low-risk dry-run proposal, or post-merge-red-main fix-forward tasks (block reason starts with 'Post-merge unscoped type-check failed' — b3_gate.check_proposal hard-ABORTs this entire class regardless of risk_label; see task 1680)."
merge-queue
by leodearden
"Merge a task branch to main via the orchestrator's merge queue using the submit→poll protocol. Use this skill whenever you need to merge a completed task branch into main and the orchestrator might be running — it submits via merge_request(wait_secs=100) then polls merge_status until the outcome is terminal, preventing races without blocking indefinitely. Trigger this when an agent says 'merge to main', 'submit merge', 'merge task branch', finishes fixing a blocked task and needs to merge, or any time code on a task branch is ready to land on main. If the escalation MCP isn't reachable, the skill falls back to direct merge. Prefer this over raw git merge --no-ff whenever working in the dark-factory repo."
review
by leodearden
"Deep, multi-phase code review — runs tests/lint/typecheck, audits architecture for stubs, broken wiring and quality-heuristic violations against docs/code-quality.md, then routes findings into tasks or deliberation. Incremental by default: re-reviews what changed since the last committed review report and re-verifies that report's open findings. ALWAYS use this skill for: /review commands, requests to verify software actually works end-to-end, post-orchestrator quality checks ('the tasks are done but does it actually work?'), finding stubs/NotImplementedError/placeholders, checking integration health across modules, finding dead code or orphan modules, auditing cross-module consistency after merges, running the full test suite with analysis (not just 'run pytest'), qualitative test coverage analysis ('are the tests just mocking everything?'), and a dispatched 'Run /review on <project>' human gate. This is NOT for: single-file PR reviews, creating review briefings (/review-briefing), historical bug-hotspot mining (/hotspot-survey), deciding which quality instrument to run (/review-all), unblocking tasks, explaining code, fixing lint, running tests without analysis, or implementing tasks. When in doubt about whether the user wants a deep project-wide review vs a simpler action, USE this skill — it handles scoping internally."
hotspot-survey
by leodearden
"Multi-agent historical bug-hotspot survey — mines git history, fix-task history, and postmortems for where bugs have clustered, deep-reviews each hotspot cluster for the root structural cause against docs/code-quality.md, adversarially verifies every finding against the code, and synthesizes cross-system improvement proposals into a ranked report + keyed findings JSON (docs/quality-findings-contract.md) that feeds deliberation and then /prd. Runs in REFRESH mode by default when a previous survey report exists (mines only the commits since its as_of_sha, re-verifies its open findings, re-reviews only materially changed clusters); --full re-derives everything. ALWAYS use this skill for: /hotspot-survey commands, 'conduct a systematic survey for bug hotspots', 'which parts of the code have been buggy historically', 'mine git history for where bugs cluster', 'what should we refactor next based on bug history', refreshing a previous hotspot survey, or a /review-all run asking for a hotspot refresh. Long-running and many-agent (full: ~28 agents, ~2.5M subagent tokens, 60-90 min; refresh: sized from the prior report in the cost gate) — state the cost up front, and if the ask is vague ('are there bugs here?') confirm scope before launching. NOT for: current-state correctness review (/review), comprehension of a single target (/study), root-causing one specific problem (/deb), authoring the remediation PRDs (/prd — feed it this skill's report), or a project's deterministic detector sweep (e.g. reify /audit)."
team
by leodearden
"Run a piece of work as an agent team — decompose it into seats, route every seat to the model tier (haiku / sonnet / opus / fable) and reasoning effort (low → max) its brief actually rewards, dispatch through the Workflow tool (or the Agent tool for small, adaptive teams), then integrate and verify the results as the lead. ALWAYS use this for: /team commands (/team --fable pre-authorises fable seats for the run), 'use an agent team', 'fan this out to agents', 'parallelise this with subagents', 'run this as a team and use cheap models where you can', 'put haiku/sonnet on the grunt work', or any request to do work with several agents at task-appropriate model and effort levels. NOT for: single-chain work you can do inline, the purpose-built multi-agent surveys (/hotspot-survey), handing a decision to a fresh context (/do), or the dark-factory orchestrator (/orchestrate)."
census
by leodearden
"Run an operator-initiated LEGIBILITY CENSUS: an attended first census for a newly-enabled project (run with cost caps and review-before-filing, before the nightly trickle auto-fires an unattended one), or an ad-hoc forced census on demand (e.g. after a big remediation wave). ALWAYS use this skill for: '/census <project-root>', 'run a census', 'run a legibility census', 'first census for <project>', 'force a census now'. Recurring census runs need NO skill — the nightly trickle's evaluate_census_step launches scripts/legibility/census.py automatically when census_trigger fires; this skill covers only the cases where a human kicks it off by hand. NOT in scope: editing scripts/legibility/* code, the nightly trickle, or the census trigger logic itself — this is an operator run-and-verify skill, not a dev skill."
curate-fused-memories
by leodearden
"Run the memory-consolidation curation sitting: batch-rule the backlog of 'Human gate: consolidate duplicate cluster' tasks and execute the resulting consolidations against the fused-memory Mem0 corpus under the gate-3200 retain-and-tag shape. Use when the user says 'run the curation sitting', 'consolidate duplicate memories', 'batch-rule the consolidation gates', 'clean up the Mem0 corpus', 'curate memories', 'adjudicate the duplicate-cluster gates', or wants the memory-consolidation backlog (task 3524 / esc-3524-1) worked. This is NOT for: ordinary memory writes (use /memory), the reconciliation escalation queues (recon-escalation-watcher), unblocking stuck tasks (/unblock), or a single ad-hoc near-exact dedup that recon Stage 1/2 can absorb inline — per the 2026-08-02 policy, new clusters route through inline Stage 1/2 consolidation, not new gate tasks."
reflect
by leodearden
"End-of-session reflection that captures decisions, discoveries, surprises, and insights to fused-memory. Use this skill when the user wants to wrap up a session, reflect on what happened, save learnings, or says things like 'let's wrap up', 'end of session', 'save what we learned', 'reflect on this session', or '/reflect'. Also trigger when a session has been substantive and the user signals they're done."
factory-init
by leodearden
"Onboard a software project — new or existing — as a dark-factory orchestrator target. Use whenever the user wants to 'factory-init' a repo, 'set up' or 'wire up' a project for the orchestrator, 'make this repo a dark-factory target', 'register a new project', or 'onboard <repo> into the factory' — or points at a directory and asks to get it ready for autonomous development, even if they don't say 'factory-init'. It confirms dark-factory is installed (installing it is out of scope), ensures a git repo, picks a hyphen-free project_id and a free escalation port, writes the per-project config, and registers the project with fused-memory reconciliation, then routes to review-briefing→review (existing code) or a goals discussion→/prd batch (greenfield), optionally adding a supervised systemd unit. NOT for: installing dark-factory itself (a separate skill), running the orchestrator (/orchestrate), writing a single PRD (/prd), creating a review briefing (/review-briefing), or unblocking a task (/unblock)."
/do — package this decision, then execute it in a fresh context
by leodearden
"Hand the direction just agreed in this conversation off to a fresh context for autonomous execution. ONLY runs when the user explicitly types /do — never auto-invoke it. Enters plan mode, distills the whole preceding discussion into a self-contained plan, and appends the user's fixed execution protocol (implement in a worktree → /merge-queue → /reflect) so the plan runs end-to-end after 'Clear Context and Follow Plan'."
prd
by leodearden
"Author and decompose PRDs under implementation-chain-completeness gates that prevent incomplete/ill-formed work from reaching the orchestrator. ALWAYS use this skill for: /prd commands, authoring a new PRD, decomposing a committed PRD into tasks, queueing tasks from a PRD into the orchestrator. Triggers on requests like 'let's write a PRD for X', 'draft a PRD', 'decompose this PRD', 'queue tasks from <prd>.md', or any mention of starting/finishing PRD-shaped work. Walks G1 (consumer named), G2 (user-observable leaf signal), G3 (assumed-substrate verified), G4 (cross-PRD seam ownership), G5 (design-first when stakes are high), G6 (premise validity), and the meta-gate 'would this PRD produce a complete/coherent/cohesive/good design under decompose-and-queue without further oversight?' before saving or queueing. Adapts to the current project via an optional overlay at .claude/skills/prd/project.md. This is NOT for: editing existing PRDs without re-running gates, running tasks (use /orchestrate), reviewing landed code (use /review), unblocking tasks (use /unblock)."
warm
by leodearden
"Claim a warm, CoW-seeded git worktree for ad-hoc interactive work — 'put me in a warm worktree now' for work that doesn't go through /do. ONLY runs when the user explicitly types /warm — never auto-invoke it. Claims an _iact-* worktree on a task/<slug> branch via the escalation MCP's claim_warm_worktree, whose target/ build cache is seeded from the orchestrator's warm base so the first build recompiles near-zero; cold-falls-back to a plain EnterWorktree worktree (never errors) when the orchestrator/escalation MCP is unreachable or the claim fails."
study
by leodearden
Load a deep, discussion-ready understanding of a specific piece of code into context BEFORE reasoning about it. Use whenever the goal is comprehension and readiness rather than an immediate edit — triggers like "read the code for X in detail and get ready to discuss it", "study how X works", "get a deep understanding of X before we talk", or any time the user is about to explore a subtle aspect, do an authoritative analysis of some behaviour/logic, or design a tricky feature/change/refactor. Reach for this even when the user doesn't say "study": any request to get primed on a specific function, class, module, subsystem, or feature ahead of a hard conversation should pull this in.