skills

Audit and improve AGENTS.md files in repositories, keeping CLAUDE.md as a one-line @AGENTS.md reference so the same project memory works across tools (Claude Code, Codex, Gemini CLI, …). Use when user asks to check, audit, update, improve, or fix AGENTS.md (or CLAUDE.md) files. Scans for all such files, evaluates quality against templates, outputs quality report, then makes targeted updates. Also use when the user mentions "AGENTS.md maintenance" or cross-tool "project memory optimization".

Graph a skill's flow — steps, artifacts, invocations — render it with draw-graphology, and report checkable weak links — each verified by two independent subagents — as a handoff file of lessons for improve-skills.

Summarize the CURRENT Claude session's work into a very concise 3P (Progress/Plans/Problems) Slack status report, draft it to the user for review, then place it as a native Slack draft for a final look before they send. User-invoked mid-session (`/slack-comm`) when you need to report what you just did in a tight, matter-of-fact format. Not for org-scale newsletters or pulling other people's updates.

Fold one lesson into one existing skill, behind a confirmation gate.

Unattended cleanup loop — scan the codebase for readability debt and run up to N targets (default 5) through a cleaner/reviewer/tester trio; verified cleanups land as per-target refactor commits on a clean-loop/<date> branch. Not a performance tool (pair-ratchet) and not for polishing just-written code (simplify-python).

Create data-driven network graph visualizations with graphology + sigma.js. Use when the user wants to visualize a network, dependency graph, knowledge graph, call graph, org/relationship map, communities/clusters, or any node-edge dataset too large to place by hand.

Use AFTER writing or editing Python to make it read better without changing behavior — idiomatic rewrites (comprehensions, enumerate/zip, f-strings, pathlib, dataclasses), flattened control flow (guard clauses, de-nesting, boolean logic), and removed cruft (dead code, redundant conditionals, pointless intermediates). High-confidence, behavior-preserving rules only; each carries an anti-rule for when NOT to apply it. Trigger when the user asks to "simplify", "clean up", "tidy", "de-nest", or make recently written Python more idiomatic/Pythonic. Not a performance tool (use pair-optimize) and not a behavior-changing refactor.

Fast in-session second opinion — an internal Claude subagent (default fable) reviews your proposal over N bounded rounds, then you decide. The single-engine, no-external-peer sibling of pair-consult.

Use when the user wants a measured speedup or cost reduction for something concrete and runnable — a DuckDB/SQL query, a hot Python path, an endpoint, a pipeline step — with a second agent (Claude ↔ Codex) challenging the numbers, rather than vibes-based tuning. Also use when invoked as the peer ("Resume the pair-optimize skill"). Hard rule — no optimization is kept unless it is measured faster/cheaper AND produces output identical to the baseline.

Phase 2 of dual-haul. Turns .dualhaul/UNDERSTANDING.md into a /goal-ready completion condition — one measurable end state, a stated transcript-demonstrable check, the constraints that must hold, and a turn cap — written to .dualhaul/GOAL.md plus the literal /goal line for the user to run. Use after dual-understand, or standalone to craft a good /goal condition from a clear improvement target.

Auto-chaining orchestrator for goal-driven improvement. Understand what the user wants improved, forge a /goal completion condition, then race a different-model Claude against Codex (each in its own git worktree) round by round until the goal is met, summarize, and open a PR. Use when the user wants something existing measurably improved with two independent agents racing under a verifiable goal — not a one-shot edit.

Phase 3 of dual-haul — the per-turn race. Under an active /goal, each turn the orchestrator commissions two independent implementers (a Claude on a chosen model + Codex on a chosen model), each in its own git worktree off the current base commit, then judges both against the goal's stated check and merges the winning diff into the main tree. Use as the iteration phase of a dual-haul run; before round 1 it asks the user which model each racer uses.

Phase 4 of dual-haul. Fires once the /goal condition is met (the goal auto-clears) or the round cap is hit. Reports goal-vs-achieved with the final check numbers, which racer won each round and why, the net diff that was kept, and what's still open. Writes .dualhaul/SUMMARY.md. Use after dual-loop concludes a dual-haul run.

Phase 5 of dual-haul — the finishing move. Commits the kept improvement on a feature branch, opens a PR (body drawn from .dualhaul/SUMMARY.md), and tears down the dual-haul worktrees and state. Always confirms the branch name and PR body with the user before pushing. Use as the last phase of a dual-haul run, after dual-report.

Phase 1 of dual-haul. Improvement-focused brainstorming — assumes the user wants something existing made better, and digs for what's deficient now, what "better" means concretely, and the measurable success signal. Produces .dualhaul/UNDERSTANDING.md. Use as the first phase of a dual-haul run, or standalone when you need to sharpen a vague "make X better" into a verifiable target before setting a goal.

Phase 2 of long-haul. Turn .longhaul/SPEC.md into a /goal-ready completion condition — one measurable end state, a stated transcript-demonstrable check, the constraints that must hold, and a round cap — written to .longhaul/GOAL.md plus the literal /goal line for the user to run. If the end state isn't clear or measurable, iterate with the user one question at a time until it is. Use after haul-spec, or standalone to craft a good /goal condition from a clear spec.

Phase 3 of long-haul — the per-turn loop. Under an active /goal, each turn run exactly one round: decide explore (a fresh approach off the base commit) vs exploit (refine the incumbent), implement the attempt in a git worktree following the /implement contract, run the goal's stated check, and keep the attempt only if it beats the incumbent — a ratchet that never regresses. Writes R<N>.md, surfaces the check output in chat. Pass --background to detach the whole haul into a nohup'd driver that survives terminal/session close (for overnight/remote runs), logging a structured block per loop to PROGRESS.log. Use as the iteration phase of a long-haul run.

Phase 4 of long-haul — the finishing move. Fires once the /goal condition is met (the goal auto-clears) or the round cap trips. Reports goal-vs-achieved with the final check output, the explore/exploit path each round took, and the net kept diff; then commits the incumbent on a feature branch and opens a PR. Always confirms the branch and PR body with the user before pushing. Use as the last phase of a long-haul run.

Phase 1 of long-haul. Turn the user's ask into a well-defined spec — a located deliverable, a transcript-demonstrable success signal, the toolbox of skills + MCP the haul may use, constraints, and out-of-scope. If the ask is vague, grill it first. Produces .longhaul/SPEC.md. Use as the first phase of a long-haul run, or standalone to harden a fuzzy ask into something buildable before setting a goal.

Auto-chaining orchestrator for a solo long-horizon goal loop. Sharpen a spec (grill it if vague), forge a /goal completion condition, then haul toward it turn after turn in a git worktree — each turn deciding explore (a fresh approach off the base) vs exploit (refine the incumbent), keeping only measured wins, until the goal holds. Use when the user wants one agent driven relentlessly toward a verifiable target over many turns — not a one-shot edit. Reach for it when the user says "keep working until", "loop until done", "long haul", or hands a spec to be built to completion.

Fetch a public Loom video's transcript from its share link and summarize it.

Rewrite text to strip the tells of AI-generated writing (em dashes, rule of three, AI vocabulary, sycophancy, filler, and ~30 more patterns) so it reads as human-written. Use when the user wants to humanize or "de-slop" a draft, asks why something reads as AI-written, or wants prose edited to sound natural or matched to their own voice.

Bounded multi-round consultation (default 5 rounds, set with --number) between Claude Code and Codex on a single user question or small coding task — A proposes, B reviews, A responds, B re-reviews, A synthesizes and asks the user. Use when a single coding question warrants a tight structured back-and-forth ending in user confirmation, rather than a full spec→plan→code workflow.

Use when the user wants to optimize a whole hot path, module, or pipeline — not one isolated query — keeping every measured win and moving to the next bottleneck until none yields a measured win. Loops pair-optimize sessions back-to-back; each session's kept win becomes the next session's baseline (a ratchet that only tightens), stopping when the well is dry or a session cap is hit. Delegates each session to pair-optimize and never restates its contract; not itself a cold-woken peer.

DEPRECATED — use the pair-* skill series (e.g. pair-consult / pair-optimize) instead. Evaluates inline feedback annotations on a markdown plan by verifying each critique against the codebase and context using subagents.

DEPRECATED — use the pair-* skill series (e.g. pair-consult / pair-optimize) instead. Review a premade markdown plan by section, using subagents to independently validate each section or step and then annotating the plan with concrete inline fixes. Use when a user provides a written plan, implementation plan, migration plan, rollout plan, or checklist in markdown and asks Codex to critique it, pressure-test the steps, or rewrite flawed sections with `[Model name]` notes that explain what is wrong and how to fix it.

Scan every installed skill across all sources, collapse double-installs, cluster the rest into overlap groups, show a terminal dashboard, then resolve each group with the user one at a time — disabling the non-keepers reversibly. Use when the user wants to find duplicate or overlapping skills, audit or trim an over-grown skill set, or asks which installed skills do the same job.

Scans all skill installations and MCP server configs across Claude Code, Claude Desktop, Cursor, Windsurf, Codex, and Gemini CLI at global and project scopes. Visualizes the current state, detects issues (duplicates, broken symlinks, security risks, inconsistencies), and suggests cleanup actions.

Create Excalidraw diagram JSON files that make visual arguments. Use when the user wants to visualize workflows, architectures, or concepts.