paulnsorensen

Dead-code forensics and spec cross-reference. Finds unreachable, orphaned, missing, or dormant code and classifies it DEAD, ZOMBIE, GHOST, or DORMANT. Use when the user says "find dead code", "what's unused", "what can I delete", "stale specs", "spec drift", "orphaned implementations", "find zombie code", or asks what's wired up vs sitting unused. Do NOT use for code-quality review (/age) or NIH/reinvented-wheel detection (/nih-audit).

Build lasting understanding of an unfamiliar codebase via a four-pillar model (Building Blocks, Entry Points, Infrastructure, Egress) plus an adaptive Socratic quiz, using tilth and Context7. Use when the user says "help me understand this codebase", "grok this repo", "onboard me", "learn this project", "memorize this codebase", "study this code", "walk me through this code", or "quiz me on this repo". Do NOT use for single-file scripts, repos under 500 LOC, or editing tasks — understanding only.

Map a concept end-to-end through a layered codebase — find the entry point, follow callers/callees layer by layer, and cross-check the impact radius. Use when the user says "trace this through", "map the X flow", "blast radius for Y", "what touches Z", "find the entry point for", "what's affected by (tilth), filesystem search (/scout), or dead-code detection (/ghostbuster).

Query coding-agent session logs (Claude, Codex, opencode) via DuckDB for usage analytics, tool patterns, error forensics, and routing decisions. Use when the user says "session analytics", "query my logs", "tool usage", "how often do I use", "check my sessions", "analyze my usage", or asks about tool/agent/skill behavior across sessions. Do NOT use for debugging current code, reading a single transcript, or questions about Claude's capabilities.

Render or apply a "routine env" — a named bundle of Claude Code plugins + MCP servers + skill packs defined in `envs/<name>.yaml` — into a setup-script body for Claude Cloud (Claude Code on the web), or apply it to the local machine. Use when the user says "set up a routine env", "provision my Claude Cloud environment", "install my cheese env", "render the setup script for <env>", "update my env", "scaffold a new env", or invokes "/routine-env". Do NOT use for cloud cron/scheduled agents that open PRs (that is `routine-scaffold`) or for a personal CLAUDE.md preferences overlay in a contributed repo (that is `claude-local`) — routine-env is about plugin/MCP/skill provisioning only.

Verify a spec's implementation against its requirements using Serena structural analysis, build verification, and test coverage. Use when the user says "verify the spec", "check spec implementation", "does this match the spec", "spec coverage", "verify acceptance criteria", or invokes /spec-verify; also after /cure to validate the result. Do NOT use for writing code or for general code review — use /age.

Detect and fix AI-generated code anti-patterns ("slop") across Rust, Python, TypeScript, Go, and Shell. Use whenever you generate or edit code, when the user says "de-slop", "clean up AI code", "remove AI slop", or during /simplify and /cook flows. Also trigger proactively as a pre-commit checklist on AI-written changes. Do NOT use for correctness or bug review — use /age or /code-review.

Detect and fix weak test assertions that pass even when code is broken, across Rust, Python, TypeScript, Go, and Shell. Use whenever you write or review tests, when the user says "strengthen assertions" or "fix weak tests", or during /cook, /press, and /simplify flows. Trigger proactively on test generation and review.

Converge a fuzzy idea or half-formed feature into an approved spec through an iterative, grounded design dialogue. Use when the user has a fuzzy idea or design direction — phrases like "let's design X", "I'm thinking about Y", "what should the API for Z look like", "shape this into a spec", "what would it take to build/set up X", "I want to add a feature that…", "/mold". Use even when the user is "just thinking out loud" if they want the dialogue to leave behind a written artifact. Do NOT use for free-form discussion with no artifact intent (`/culture`), direct implementation (`/cook`), or research-only questions (`/briesearch`).

Triage a PR's review comments and failing CI (plus merge conflicts) through the /age lens, deciding which claims are worth acting on. Use when the user says "respond to PR comments", "handle review feedback", "affinage the PR", "/affinage <pr>", "fix the failing build", "resolve the conflicts and respond". Do NOT use for a bare diff with no PR (route to /age).

Review a diff, PR, branch, or path across ten orthogonal dimensions (correctness, security, encapsulation, spec, complexity, deslop, assertions, NIH, efficiency, telemetry) and emit a severity-grouped findings report. Use when the user wants a code review — phrases like "review this", "/age", "is this safe to merge", "find bugs", "spot security issues", "check for slop", "review my PR", "what's wrong with this code". Use even when the user only asks for one dimension — the report scopes itself. Do NOT use for applying fixes (route to /cure) or test hardening (route to /press).

Research questions external to the codebase across library docs (Context7), the web (Tavily), local code (cheez-search), GitHub examples (gh), and the repo wiki (hallouminate), then synthesize with explicit confidence. Use whenever the user asks to research, look up, compare, or investigate something — phrases like "research X", "look up the API for Y", "compare libraries", "what does the doc say about Z", "find examples of how to do W", "is this library maintained", or "before I implement, what's the right approach". Use even when the user only mentions a library name without saying "research". Do NOT use for a single obvious file lookup or when the user already has enough evidence.

Route any dropped-in input — idea, spec path, file path, PR or issue, stack trace, bug report, or bare `/cheese` — to the right workflow skill. Use as the unified entry point — phrases include "/cheese", "what should I do with this", "help me get started", "route this", or any opening message that does not already name a downstream skill.

Implement an approved spec or focused unambiguous task, editing through cheez-write. Use when the user wants code written — "implement this", "cook this spec", "/cook .cheese/specs/<slug>.md", or "fix this bug" when the fix is clear; also when the user just says "go" or "ship it" with a spec or clear acceptance criteria in scope. Runs standalone on an unambiguous task — a spec helps but is not required. Do NOT use for fuzzy planning (`/mold`), no-write discussion (`/culture`), or review-only work (`/age`).

Apply fixes from an /age report, finding list, or CI failure, then run the project's test/lint/build gates and hand a clean cure to /plate for commit/publication. Use when the user wants selected findings resolved. Do NOT use for review (route to /age), test authoring (route to /press), or direct publication (route to /plate).

Metacognitive vibecheck gate before code is shared for review — make the author explain the diff's causal logic, graded by a fresh-context judge against the SOLO Taxonomy. Use when the user wants this gate — phrases like "/hard-cheese", "/cheese --hard", "gate this before I push", "vibecheck me", "make sure I understand this diff", "epistemic-debt check". Use standalone before opening a PR, or as the `--hard` flag propagated through the pipeline. Do NOT use for code review (`/age`), test hardening (`/press`), or fix application (`/cure`).

Use when the user says "copilot review", "review with copilot", "delegate to copilot", "have copilot fix this", "copilot agent task", "set up copilot", "generate copilot instructions", "bootstrap copilot for this repo", or invokes `/copilot`. Three modes: `review` (run a code review on a PR and route fixes to Copilot via inline `@copilot fix this` comments), `delegate` (create a `gh agent-task`, poll until the coding agent opens a PR, optionally hand off to review), and `setup` (one-time bootstrap that writes `.github/copilot-instructions.md` and the per-role `.github/instructions/*.instructions.md` files). `review` and `delegate` are routine; `setup` is a one-time repo bootstrap loaded on demand from `references/setup.md` only when the user explicitly asks. Do NOT use for plain GitHub PR work — that is `/gh`'s job.

One-time GitHub repository configuration via the `gh` CLI: enable a merge queue on the default branch, lock merging to squash-only with PR-title commit messages, wire required CI status checks, scaffold automatically-generated release notes (`.github/release.yml`), and optionally add a tag-driven release workflow. Use when the user says "set up the repo", "configure the merge queue", "enable squash merging", "lock down main", "set up branch protection", "configure release notes", "scaffold releases", "set up release tagging", or invokes /gh-bootstrap on a fresh or loosely-configured GitHub repository. Idempotent — safe to re-run on already-configured repos to bring missing pieces in line. Distinct from /gh, which handles per-task PR / issue / CI ops; this skill is for one-time repo policy.

Complete GitHub tasks using the `gh` CLI — pull request inspection, review, and merge, issues, CI checks, releases, workflow runs, code search, repo and label management. Use when the user says "merge PR", "check CI", "list issues", "review PR", "PR status", "close issue", "trigger workflow", "view release", "search repos", or invokes /gh. Use `git` (log, diff, status) for read-only local context only. Do NOT use for committing, staging, pushing, or PR creation — use /plate for those. Do NOT use for code-quality review — use a dedicated review skill.

End-to-end release cutting for a GitHub repo: decide the next semantic version from the Conventional Commits since the last tag, draft proper release notes (GitHub auto-generated via `.github/release.yml`, or hand-curated grouped by change type with highlights and upgrade notes for breaking changes), create and push an annotated tag, publish the GitHub release, and optionally update `CHANGELOG.md`. Use when the user says "cut a release", "tag a release", "publish a release", "ship vX.Y.Z", "bump the version", "what version should this be", "write the release notes", "draft the changelog", or invokes /release. Distinct from /gh-bootstrap (which scaffolds the `.github/release.yml` + release workflow plumbing once) and /gh (raw per-command `gh release` ops): this skill runs the actual release ceremony — version decision, notes, tag, publish. Run after the work is merged to the default branch.

Triage PR review comments by confidence score and act — fix the high-scoring ones, push back on the low-scoring ones, and ask about the borderline. Handles both inline review threads (anchored to diff lines) and PR-level review body comments (summaries submitted with reviews, like Age tables or Copilot overviews). First checks the PR's build and merge state and fixes those before processing comments. Use when the user says "respond to PR comments", "handle review feedback", "address PR reviews", "fix the build", "fix CI", "fix merge conflicts", or invokes /respond with a PR number. Also trigger when the user mentions a specific PR and wants to deal with reviewer suggestions — Copilot, human, or bot. Every reply this skill posts ends with an "agent on behalf of;" attribution line so reviewers can tell the comment came from an agent on behalf of the human, not the human directly. Do NOT use to generate a new review — that is /copilot-review's job.

Set up GitHub's `safe-settings` (a Probot-based GitHub App from the github org) for declarative, org-wide repository policy as code. Use when the user says "settings as code", "safe-settings", "manage repos declaratively", "centralize repo settings", "org-level branch protection", "scaffold an admin repo", "github settings app", or invokes /safe-settings on an org that wants to manage repo settings, branch protection, rulesets, labels, teams, environments, and collaborators from one admin repo. Scaffolds the admin-repo layout (`settings.yml` + `suborgs/` + `repos/`), the GitHub App installation steps, and a scheduled `full-sync` GitHub Actions workflow. Distinct from /gh (per-task ops) and /gh-bootstrap (one-shot `gh api` config of a single repo) — this skill is for **org-scale settings as code** that reconciles continuously.

Create or migrate to a justfile (casey/just command runner) for any project. Use this skill when the user asks to add a justfile, replace a Makefile, set up project commands, create task runners, or mentions "just" in the context of build/dev workflows. Also trigger when you see a project with a Makefile that would benefit from just's simpler syntax, or when setting up a new project that needs common dev commands (build, test, lint, fmt). Covers Rust, Python, TypeScript/JavaScript, Go, and Ruby ecosystems. Do NOT use for CI pipeline configuration, Dockerfiles, or actual build system setup (cargo, webpack, etc.).

Write, review, or refactor Bash scripts into concise, idiomatic shell code. Use this skill whenever the user is editing a `.sh`, `.bash`, or `bash`-fenced block with a Bash shebang (or no shebang in a Bash-only context), mentions "shorten this script", "make this more idiomatic", "clean up this bash", "this script is too long", "is there a shorter way to do this in bash", or asks for a code review of shell scripts. Also trigger when generating new Bash scripts from scratch — produce idiomatic patterns the first time instead of refactoring later. Covers parameter expansion, brace expansion, process substitution, arithmetic contexts, function patterns, pipelines vs temp files, heredocs, associative arrays, parallel execution, and CSV/IFS parsing — 51 techniques total. Refuses cryptic one-liners when shortening would hurt readability. Do NOT use for fish, zsh, or POSIX-only `/bin/sh` scripts where bashisms would break portability.

Staff Engineer code review orchestrator. Runs nine orthogonal LLM dimensions over a diff and emits a stake-weighted report plus hash-anchored sidecar JSON.

Finish what /age started. Loads both sidecars (fixes + suggestions), renders a unified stake table, gates on user approval, routes each approved item to the right handler (/cleanup or a cook sub-agent), then re-ages the touched paths up to a hard 3-turn cap.

Iterative thinking amplifier for fuzzy ideas. Routes input to the right starting mode (Explore, Ground, Shape, Sketch, Grill, Diagnose), runs Validate Cycles to anchor claims, locks down interfaces in pseudocode, and only curdles a spec (and optional issues) after a two-key handshake plus a coherence self-check.

Scan a codebase for custom code that duplicates what open-source libraries already do, then recommend which libraries to adopt. Detects hand-rolled utility functions, custom retry logic, manual validation, DIY date handling, home-grown argument parsers, and other reinvented wheels. Cross-checks against installed dependencies and open specs. Returns scored migration recommendations with effort estimates. Use when the user mentions reinventing the wheel, asks if there is a library for something they built, wants a build-vs-buy audit, asks "should we just use lodash for this", or wants to find dependency opportunities.

AST-aware code search using tilth MCP. Finds definitions first, then usages. Use tree-sitter structural matching instead of blind text grep. Understand dependencies and call graphs. Use when: finding where symbols are defined, tracing call chains, understanding code structure, finding all callers of a function. Do NOT use for reading files — use cheez-read. Do NOT use for editing — use cheez-write. Examples: "find where handleAuth is defined", "what calls validateToken?", "trace the ServeHTTP, HandlersChain, Next functions", "find all implementations of the UserService interface".

Mechanical apply of /age's hash-anchored sidecar fixes via tilth_edit. The cleanup-wolf sub-agent is the only LLM in the path, fired per anchor mismatch.

Multi-source research orchestrator that routes questions across Context7 library docs, Tavily web research, codebase analysis, and GitHub examples, then returns a compact synthesis with confidence scoring.

Use the Milknado MCP tools to pick and execute the next ready node from the Mikado graph, apply file changes, and run quality gates.

Unified hook creation entry point that routes natural language descriptions to the right specialist agent. Use when the user wants to enforce behavior in Claude Code sessions. Trigger when the user says "add a hook", "create a hook", "new hook", "enforce X", "guard against X", "block X", "prevent X", "detect when Claude does X", "catch X", "stop Claude from X", "add enforcement", "quality gate for X", or describes any behavior to enforce. This skill routes to vaudeville:hard-hook-writer (JS/Python/Bash) or vaudeville:slm-rule-writer (SLM/YAML) based on whether the enforcement is structural or semantic. Also trigger when the user says "add a rule", "new rule", "create a detector", "SLM rule for X", or describes behavior requiring semantic classification. Do NOT use for suggesting hooks from usage data (use vaudeville:hook-suggester), querying session analytics (use vaudeville:session-analytics), checking daemon status (use `vaudeville:status` skill), or debugging existing hooks.

Analyze Claude Code session history to suggest hooks tailored to the user's actual usage patterns. Mines vaudeville:session-analytics data for dangerous commands, tool misuse, high error rates, permission friction, missing quality gates, broken hooks, and repeated automatable patterns — then generates concrete hook implementations via vaudeville:add-hook. Use when the user asks "what hooks should I add", "suggest hooks", "analyze my usage for hooks", "what should I enforce", "improve my hooks", "hook suggestions", or wants to discover enforcement opportunities they haven't thought of. Also trigger for "vaudeville suggestions", "hook recommendations", "what am I doing wrong", "what hooks do I need", "hook audit", "analyze my hooks", "optimize my workflow", "what's failing in my sessions", "guard against", or any question about optimizing their Claude Code workflow through hooks. Do NOT use for creating a specific known hook (use vaudeville:add-hook), querying raw session data (use vaudeville:session-analytics)

Promote, demote, or edit vaudeville rule tiers. Use when the user says "promote rule", "demote rule", "move rule to warn", "move rule to block", "rule-admin", "change tier", "promote to warn", "promote to block", "demote to shadow", "delete rule", "enable rule", "disable rule", or invokes /rule-admin. Typically used after /tier-advisor produces recommendations. Do NOT use for analysis — use /tier-advisor for that.

Audit existing vaudeville rules for design-level usefulness. Distinct from /tier-advisor (which audits eval data for promotion). This skill asks: does the rule's event × tier combination produce useful behavior change *at any reachable tier*? Surfaces rules that are useless by design — rules whose violations cannot be acted on in a future turn, rules stuck at SLM model ceilings, rules whose max-useful tier is below their current tier, rules duplicated by other rules, and rules that should be hard hooks instead of SLM rules. Use when the user says "audit my rules", "find useless rules", "are my rules useful", "review rule design", "rule audit", "which rules should I delete", "do my rules make sense", "design audit", or invokes /rule-audit. Do NOT use for promotion analysis (use /tier-advisor) or modifying tiers (use /rule-admin).

Query Claude Code's own JSONL session logs via DuckDB for usage analytics, tool patterns, error forensics, hook impact analysis, and routing decisions. Use when the user asks about their Claude usage patterns, tool frequencies, error rates, permission denials, agent routing, skill invocations, MCP server usage, session timelines, hook effectiveness, or any question about "how has Claude been working". Also trigger when the user says "session analytics", "query my logs", "tool usage", "how often do I use", "check my sessions", "analyze my usage", "hook stats", "what hooks fired", or asks about specific tool/agent/skill/hook behavior across sessions. Also trigger for "vaudeville hook analytics", "hook effectiveness", "hook firing rate", "enforcement stats", or any question about how vaudeville hooks are performing. This skill turns raw JSONL into a queryable DuckDB database — use it instead of writing ad-hoc Python scripts to parse logs. Do NOT use for debugging current code issues, reading individual session t

Tune a single vaudeville SLM rule to meet precision/recall/f1 targets. Runs `vaudeville tune <rule>` which launches a ralphify autonomous agent loop to iteratively improve the rule's prompt until it meets accuracy thresholds. The loop exits early when thresholds are met via completion promise. Use when the user says "tune rule", "fix rule accuracy", "improve rule precision", "reduce false positives", "recall is too low", "tune violation-detector", or wants to iterate on an SLM rule prompt until it meets accuracy targets.

Analyze vaudeville warn logs and eval data to recommend rule tier promotions and demotions. Use when the user says "promote rule", "tier advisor", "warn log analysis", "should we enforce", "demote rule", "rule metrics", "tier recommendation", "warn to block", "shadow to warn", "rule performance", "check rule health", "evaluate rule tiers", "promotion analysis", or invokes /tier-advisor. Do NOT use for editing rule files — use /rule-admin for that.

Check vaudeville daemon health — socket alive, model loaded, rules count, hook wiring, and recent verdicts. Use when the user asks "is vaudeville running", "daemon status", "check hooks", "why isn't my hook firing", "vaudeville health", "is the model loaded", "what rules are active", "check daemon", "health check", "is the daemon up", "status", or any question about whether vaudeville is working correctly. Also trigger when troubleshooting hook failures — a dead daemon is the most common cause.

Install hallouminate and bootstrap the user's first LLM-authored per-repo wiki. Use when the user runs /install from the hallouminate skill pack, or asks to "install hallouminate", "set up hallouminate", "get hallouminate working", or "start a hallouminate wiki" on a machine without a working install. Do NOT use when the binary already works — route a brand-new wiki to wiki-init and new content to wiki-ingest.

Fold new knowledge into an existing hallouminate wiki — route each new fact to the page it extends, merge it in, create a page only when genuinely novel, and never blend contradictions. Use when there's source material to absorb or a fact to record — "add this to the wiki", "ingest these docs", "update the wiki with what we learned", "remember this", "record this decision", "/wiki-ingest <path|topic>". Do NOT use to bootstrap an empty wiki (use wiki-init) or to answer a question (use wiki-query).

Bootstrap a hallouminate wiki from scratch by interviewing the user with Socratic questioning, then writing the first entries. Use when a repo has no wiki yet or the corpus is near-empty — "start a wiki", "bootstrap the knowledge base", "interview me about this project", "set up the wiki", "/wiki-init". Do NOT use to answer questions (use wiki-query) or to fold new source docs into an existing wiki (use wiki-ingest).

Answer a question from a hallouminate wiki with grounded, cited detail. Use when the user asks something the wiki should know — "what does the wiki say about X", "how does Y work here", "look it up in the wiki", "/wiki-query", or any factual question about a repo whose knowledge lives in a hallouminate corpus. Every claim in the answer carries a `path:line` citation back to the corpus. Do NOT use to write or update wiki entries (use wiki-ingest) or to bootstrap a new wiki (use wiki-init).

Triage and repair a hallouminate ground-store mismatch at daemon startup. Use when hallouminate fails to start or complains about the store — "store schema stale", "store schema version ... is NEWER than this build expects", "embedding store mismatch", "/wiki-reindex", "reindex after upgrade", "ground store out of date". Do NOT use to bootstrap a new wiki (use wiki-init) or to fold new documents into an existing corpus (use wiki-ingest).

Author or extend a wiki roadmap in milknado's importable format — .hallouminate/wiki/roadmaps/<slug>/ with an index.md plus one goal file per goal. Use when the user wants execution-ready planning in the wiki — "create a roadmap", "add a roadmap", "add a goal to the roadmap", "plan the next milestone in the wiki", "/wiki-roadmap". Writes from the pack's roadmap templates (templates/roadmap/) so an installed milknado seeds the graph with `milknado roadmap import <slug>`, zero rework. Do NOT use to run or decompose the roadmap (milknado's load-roadmap and planner own execution) or to write outcomes back into goal files (milknado's harvest owns the Outcome block).

Configure milknado's per-flavor worker execution by interviewing the user and writing milknado.toml — agent_family, [milknado.worker.tools] allowlists, and [milknado.flavor.*] tables for named flavor presets (implement, spec, spike, prototype, research). Use when the user wants to set up or tune how milknado runs workers — phrases like "configure milknado flavors", "set up milknado.toml", "tune the research/spec/spike agent", "which model should milknado use for prototypes", "skip quality gates for spikes", "milknado worker tools", "per-flavor agent config". Interviews for agent family, then per-flavor model/agent, tools, quality gates, and brief prepend; writes the tables and validates them with `milknado agents check` plus a flavor resolution probe. Do NOT use for running graphs (milknado run) or planning (milknado plan).

Write, edit, refactor, or review Python with concise declarative contracts, idiomatic control flow, Sliced Bread boundaries, and the Python de-slop rules. Use for Python implementation work in this repository, especially when the user asks for Pythonic, succinct, LLM-optimized, de-slopped, Pydantic, dataclass, pattern-matching, or vertical-slice code.

Harvest milknado execution state back into the hallouminate-wiki roadmap goal files. Use when the user says "harvest the roadmap", "export results to the wiki", "sync milknado back to the wiki", "update the goal outcomes", "write the outcomes back", or "/harvest". Calls milknado_roadmap_export to rewrite each goal's harvest block plus status/last_synced, leaving human-authored Intent/Acceptance byte-identical; a goal node milknado discovered mid-run gets a fresh goal file created for it, and `hallouminate index` is refreshed best-effort. Do NOT use to import a roadmap into milknado (that is /load-roadmap) or to edit Intent/Acceptance text.

Import a hallouminate-wiki roadmap into milknado so its goals become executable nodes. Use when the user says "load the roadmap", "import roadmap <slug>", "pull the roadmap into milknado", "seed milknado from the wiki", or "/load-roadmap". Calls milknado_roadmap_import to seed one roadmap node plus one goal node per goal file (deterministic wiki_ref keys, idempotent re-import, no task nodes), then optionally kicks milknado_plan_batches to decompose goals into tasks. Do NOT use to write execution results back to the wiki (that is /harvest) or to author a brand-new roadmap from scratch.

Mikado-method execution with milknado: dependency graphs, parallel ralph loops in worktrees, and code-review-graph context. Use when planning goals, running autonomous loops, or inspecting graph state.