paulnsorensen
83 verified skills166 total stars
lsp
Check LSP plugin status and troubleshoot language server issues. All 7 LSP plugins are enabled globally — this skill shows what's running, verifies binaries, and diagnoses issues. Use when the user says "LSP not working", "language server down", "hover not working", "no type info", "check LSP", "types missing", or invokes /lsp. Also trigger when LSP operations return errors or empty results.
tools2
tool-efficiency
Audit how a tool, command, or MCP server is actually used across coding-agent sessions and produce calibrated recommendations — tool-vs-task fit, error forensics, fix recommendations, permission friction, MCP health, and token economics. Use when the user says "tool efficiency", "am I using X efficiently", "audit tool usage", "why does X keep failing", "how do I fix this error", "what should I change", "permission friction", "is this MCP worth it", "tool error rate", "fix recommendations", or invokes /tool-efficiency. Do NOT use for auditing a skill or agent definition (that is /skill-improver) or for one-off interactive log queries (that is /session-analytics).
tools2
work-recovery
Reconstruct what a past coding-agent session was doing so you can resume it — goal, files touched, last verified state, and the next step — by querying the session logs. Use when the user says "what was I working on", "recover that session", "reconstruct where I left off", "resume my last session", "what did that session change", "rebuild context from logs", or invokes /work-recovery. Report-only — it never scores or judges. Do NOT use for usage scoring (that is /skill-improver, /tool-efficiency, /prompt-analytics) or one-off interactive log queries (that is /session-analytics).
tools2
wiki-curator
Curate this repo's hallouminate wiki (.hallouminate/wiki/, the repo:dotfiles:wiki corpus) — add or update architecture pages, per-harness docs, and gotchas. Use when the user says "update the wiki", "document this in the wiki", "refresh the harness docs", "add a wiki page", "curate the wiki", "the wiki is stale", or invokes /wiki-curator. Also use at session end to write back a non-obvious decision or gotcha worth preserving. Grounds the existing wiki first, follows one-topic-per-file conventions, verifies every external doc URL before writing, and reindexes. Do NOT use for general code search (that is cheez-search) or for editing AGENTS.md command reference.
development2
session-analytics
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.
tools2
prompt-analytics
Analyze how prompts and skill routing behave across coding-agent sessions and produce calibrated recommendations — prompt-pattern analysis, routing accuracy, and knowledge gaps. Use when the user says "analyze my prompts", "prompt patterns", "is routing working", "which skill should have fired", "knowledge gaps", "what do I keep asking", or invokes /prompt-analytics. Do NOT use for auditing a single skill/agent definition (that is /skill-improver), tool/MCP efficiency (that is /tool-efficiency), or one-off interactive log queries (that is /session-analytics).
tools2
harness-doctor
Diagnose and self-heal harness-config drift between what's live on this machine (~/.claude, ~/.codex, ~/.config/opencode, ~/.cursor, ~/.copilot) and what `ap` renders from the registries — the post-migration target state. Use when the user says "harness doctor", "check my harness config", "is my settings drifted", "audit the dotfiles config", "why is this hook firing twice", "diagnose my agent config", or invokes /harness-doctor; also after an `ap`/registry change to verify the live config converged. Grounds the wiki + git history for intended state, diffs live vs `ap` render, classifies each drift (stale remnant / dotfiles bug / expected local), self-heals safe remnants via ap's renderers (ClaudeRenderer._clean_legacy_settings_hooks / CodexRenderer._clean_legacy_config_toml_hooks) during ap install / dots sync, opens deduped gh issues for confirmed dotfiles bugs, and writes new drift patterns back to the wiki. Do NOT use for general code review (/age), single-file permission cleanup (/settings-clean), or app-level debugging.
development2
skill-improver
Audit and improve agent and skill definitions — calibration, tool scoping, context budget, activation quality, and output format. Use when the user says "improve this skill", "audit this agent", "optimize this agent", "review agent definition", "fix trigger rate", "skill not activating", or invokes /skill-improver with a path. Also trigger when an agent is producing poor results and needs prompt tuning, or when a skill isn't triggering reliably. Covers: confidence and severity calibration, tool scoping, sub-agent delegation, fork vs inline, context budgets, and activation optimization. Do NOT use for creating new skills from scratch — use /skill-creator for that.
tools2
ghostbuster
Dead code forensics and spec cross-reference. Finds unreachable functions, orphaned implementations, specs pointing at deleted code, and transitive dead code chains. Categorizes as DEAD (safe to delete), ZOMBIE (in spec but unwired), GHOST (spec references nonexistent code), or DORMANT (entry point is dead, taking dependents with it). Use when the user says "find dead code", "what's unused", "clean up unused functions", "are there stale specs", "what code can I delete", "check for orphaned implementations", "spec drift", "what's incomplete", "find zombie code", or asks about code that was started but never finished. Also use when reviewing a module and wanting to know what's wired up vs what's just sitting there. Do NOT use for code quality review (/age), NIH/reinvented-wheel detection (/nih-audit), or security scanning (/audit).
development2
lookup
Code intelligence router — decides which tool to use when you need to understand a symbol, type, API, or code relationship. Language-agnostic: works for Rust, Python, TypeScript, Go, Ruby, Java, and any language with LSP support. Prevents wasteful brute-force lookup anti-patterns: cargo doc + grep, grepping dependency caches (node_modules, site-packages, .cargo/registry, go/pkg/mod, .m2), go doc + grep, python help() + grep, and multi-step find chains. Use this skill BEFORE reaching for bash when the question is "what does X do?", "what's the signature of Y?", "who calls Z?", or "how do I use this API?". Routes to the right tool: LSP for types and cross-refs, ast-grep for structural patterns, Context7 for external docs, gh CLI for GitHub code search. If you catch yourself about to grep a dependency cache or generate docs just to search them — stop and use this instead.
tools2
spec-verify
Verify that a spec's implementation matches its requirements using LSP structural analysis, build verification, and test coverage checking. 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 with a spec path. Also trigger after /fromage or /fromagerie completes to validate the result against the original spec. Do NOT use for writing code — this is verification only. Do NOT use for general code review — use /age or /code-review for that.
development2
version-doctor
Diagnose and fix library version mismatches, dependency conflicts, and build file inheritance issues. Use this skill when encountering version resolution failures, workspace inheritance problems, or when the user says "fix versions", "version mismatch", "dependency conflict", "why won't this build", or "update dependencies". Also trigger proactively when a build fails due to version constraints — the right fix is almost always updating a version number, not restructuring the build. If you catch yourself about to rewrite a build config or bypass workspace inheritance because of a version error, stop and use this skill instead.
development2
claude-local
Distill the user's global ~/.claude/CLAUDE.md into a project-scoped CLAUDE.local.md (gitignored) for repos they're contributing to but don't own. Detects the project's languages and build system, keeps only the relevant subset of global preferences (coding principles, complexity budget, skill delegation table, self-eval checklist, language-gated style notes), drops the personal-flair sections and architectural opinions that shouldn't bleed into a contributed repo. Ensures CLAUDE.local.md is covered by the user's GLOBAL gitignore — never the project's .gitignore — so the contribution stays clean. Use when the user says "set up CLAUDE.local", "scaffold local claude config", "drop my preferences in this repo", "I'm contributing to this repo and want my preferences applied", "claude-local.md", or invokes /claude-local. Also use proactively when the user opens a shell in an unfamiliar repo and says they want to start contributing.
development2
self-eval
Run the Self-Evaluation Checklist against your last response or recent changes. Use this skill when the user says "self-eval", "self-evaluate", "check my response", "quality check", "evaluate response", or when you want to proactively verify response quality before finishing. Also trigger when the user expresses doubt about your output ("did you actually test that?", "are you sure?", "that seems incomplete"). This skill cross-references with /de-slop and /tdd-assertions for items that have dedicated tooling.
tools2
update
Review active (non-overdue) Todoist tasks for completion, irrelevance, or rewording. Incremental hygiene, not bankruptcy. Use when the user says 'update tasks', 'review my tasks', 'task hygiene', 'check what I've done', 'mark tasks done', 'clean up active tasks', or when they want a project-by-project walkthrough of current work.
testing2
lsp
Check LSP plugin status and troubleshoot language server issues. All 7 LSP plugins are enabled globally — this skill shows what's running, verifies binaries, and diagnoses issues. Use when the user says "LSP not working", "language server down", "hover not working", "no type info", "check LSP", "types missing", or invokes /lsp. Also trigger when LSP operations return errors or empty results.
tools2
make
You cannot run build commands (cargo check, cargo clippy, go build, npm run build, just check, tsc, pytest, etc.) directly — hooks will block them and raw compiler output floods your context window. This skill is the ONLY way to verify code compiles, run linters, execute tests, or check formatting. It runs in a forked subagent that absorbs all verbose output and returns only structured file:line:col errors. Auto-detects build system (just, cargo, npm, go, make, cmake, gradle, maven, uv/python). Triggers automatically when you need to: check if code compiles after edits, verify a refactor didn't break anything, run clippy/eslint/ruff, run tests, check formatting, clean build artifacts, or fix a CI failure. Also triggers on /make, /build, /check, /compile. Subcommands: /make test, /make lint, /make fmt, /make clean. If a hook blocks a build command, invoke this skill immediately.
tools2
respond
Respond to PR review comments with confidence-rated triage. Also checks and fixes build failures and merge conflicts before processing comments. 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). 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 — whether from Copilot, human reviewers, or bots. Checks CI status and mergeability first, then reads all unresolved review threads and review bodies, scores each suggestion 0-100, and presents a triage table. High-confidence fixes (>= 50) execute immediately while the user reviews uncertain items. Do NOT use to generate a new review — use /copilot-review for that.
development2
skill-improver
Audit and improve agent and skill definitions for better calibration, tool scoping, context management, activation quality, and output format. Use when the user says "improve this skill", "audit this agent", "optimize this agent", "review agent definition", "fix trigger rate", "skill not activating", or invokes /skill-improver with a path. Also trigger when an agent is producing poor results and needs prompt tuning, or when a skill isn't triggering reliably. Covers: calibrated confidence scoring, tool scoping, sub-agent delegation, fork vs inline, context budgets, and activation optimization. Do NOT use for creating new skills from scratch — use /skill-creator for that.
tools2
wt-git
Run git and GitHub operations inside a worktree without triggering Claude Code's safety heuristics. Use this skill whenever you need to commit, push, create PRs, or run any git command in a worktree you're not currently inside — especially from orchestrator agents, /fromage, /move-my-cheese, or /cheese-convoy. Also use when you catch yourself about to write "cd <path> && git" or "gh pr create --body" with a heredoc. This skill exists because Claude Code's Seatbelt sandbox blocks two legitimate patterns: compound cd+git commands ("bare repository attack" heuristic) and heredoc PR bodies with markdown headers ("# hides arguments" heuristic).
development2
scout
Filesystem exploration with human-friendly eza tree views and git status; delegates content/code search to cheez-search (AST-aware via tilth). Use when the user says "search files", "find by metadata", "tree view", "list directory with git status", or invokes /scout. Do NOT use for symbol, usage, or structural code search — that's cheez-search.
development2
steel-thread
Map a concept end-to-end through a layered codebase using the code-review-graph (CRG) MCP. Always rebuilds and re-embeds the graph before answering so semantic search reflects current code. Prefers CRG's native `Flow` primitive (which IS a steel thread) over hand-rolled traversal. Queries along both behaviour and surface vocabularies when no flow matches, traverses from the densest hub, cross-checks with impact radius, and routes via `get_minimal_context_tool`'s `suggested_tools` array. Use when the user asks to trace a concept, find an entry point, map a feature across layers, estimate blast radius of a planned change, find which contract/route/handler reaches a given service, or asks "did you check whether I just added X". Triggers on: /steel-thread, "trace this through", "map the X flow", "blast radius for Y", "what touches Z", "find the entry point for", "where does X get called from", "is there a new endpoint I added", "what's affected by this change". Do NOT use for single-symbol lookups (use /lookup), filesystem search (use /scout), or dead code detection (use /ghostbuster).
tools2
settings-clean
Clean up bloated .claude/settings.local.json by removing redundant, stale, and junk permission entries, and ensure hook-redirected skills are allowed. Use when the user says "clean settings", "prune settings", "settings cleanup", or invokes /settings-clean. Also trigger proactively when you notice a settings.local.json with more than 30 permission entries, or after extended sessions where many one-off Bash permissions have accumulated. This skill only touches settings.local.json (gitignored), never settings.json (committed).
tools2
cargo-workflow
Standard cargo workflow for build/test/lint cycles.
development2
explore
Code exploration orchestrator. Takes a free-form query and dispatches four parallel leaf sub-agents (graph, tilth, tokei, LSP) for structural, token-budgeted, statistical, and type-aware perspectives. Synthesizes into a structured XML artifact with codebase map, business context per module, and change callstack. Use when the user says "explore," "how does X work," "explain this codebase," "map the architecture," "what needs to change for X," "where is Y implemented," or invokes /explore. Do NOT use for implementation (fromage-cook), dead-code audits (ghostbuster), PR review (age), or onboarding narratives (onboard).
development2
scout
Filesystem exploration. Delegates content/code search to cheese-flow's cheez-search (AST-aware via tilth MCP). Keeps eza directory listings for human-friendly tree views with git status. Use when the user says "search files", "find by metadata", "tree view", "list directory with git status", or invokes /scout. For symbol/usage/structural search, the work is done by cheez-search — this skill is a thin pointer.
tools2
commit
Stage and commit changes to git following conventional commits format. Use when asked to commit, create a commit, or save changes. Drafts meaningful commit messages by understanding the why, not just the what. Never amends published commits, never skips hooks, never uses git add -A. Stages specific files by name. Does not push — that is the gh skill's job.
development2
diff
Quick pre-commit smoke test of staged or unstaged changes. Scans for blockers (secrets, debug statements, commented code, silent failures) and warnings (oversized functions/files, deep nesting, domain leakage). Use when asked to review staged changes, run a pre-commit check, or when the /diff command is invoked.
development2
fetch
Fetch external documentation or code while protecting the main context window. Use Context7 (preferred, free) for library docs. Use Tavily for technical concepts and best practices. Use Serper for factual lookups and Google SERP features. Use `gh` CLI for GitHub operations. Cost-aware routing: free → cheap → expensive. Governs: when to skip and use training data, when to fetch inline vs delegate to a subagent.
tools2
gh
Complete GitHub tasks using the GitHub MCP plugin. Use for any GitHub operation — PRs, issues, CI checks, repo management, releases, code search. Use git commands (log, diff, status) for local context. Prefer MCP tools over gh CLI — they bypass sandbox/TLS issues. Use when the user says "create PR", "merge PR", "check CI", "list issues", "review PR", "PR status", "close issue", or invokes /gh. Do NOT use for local git operations like commit, stage, or push — use /commit for those. Do NOT use for code quality review — use /age or /code-review.
tools2
lint
Run project linters (shellcheck, yamllint, jsonlint, prettier, eslint, clippy, etc.) and report findings. Use when the user says "lint", "check code quality", "run linters", "lint shell scripts", or wants to validate syntax/style in a project. Supports multi-language projects: shell, YAML, JSON, TOML, JavaScript, Python, Rust. Aggregates findings into a summary report with file/line references for easy fixing.
tools2
justfile
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.).
development2
prek
Onboard prek (Rust-powered pre-commit) into any project and suggest hooks tailored to the language/framework. Use when the user says "add prek", "set up pre-commit hooks", "configure prek", "what hooks should I use", or when you notice a project without a prek.toml that would benefit from pre-commit checks. Also trigger when the user wants to add new hooks to an existing prek.toml, audit their hook config, or migrate from pre-commit to prek. Covers Rust, Python, TypeScript/JavaScript, Go, Ruby, and Shell projects. Do NOT use for husky, lint-staged, or CI pipeline hook configuration — this skill is specifically for prek.
development2
merge-resolve
Resolve merge conflicts, rebase conflicts, and cherry-pick failures using mergiraf (AST-aware structural merge), git rerere, and kdiff3. Activate when: merge failed, rebase conflict, cherry-pick failed, CONFLICT in file, "resolve conflicts", "fix merge", "merge conflict", "conflict resolution", or git output shows CONFLICT markers. Also use for mergiraf diagnostics, rerere management, gitattributes regeneration, or batch conflict resolution across multiple files. Covers the full resolution chain: mergiraf (structural auto-resolve) → rerere (replay remembered fixes) → kdiff3 (manual). Do NOT use for general git operations without conflicts — those go to the commit or gh skills.
development2
respond
Respond to PR review comments with confidence-rated triage. Also checks and fixes build failures and merge conflicts before processing comments. 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). 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 — whether from Copilot, human reviewers, or bots. Checks CI status and mergeability first, then reads all unresolved review threads and review bodies, scores each suggestion 0-100, and presents a triage table. High-confidence fixes (>= 50) execute immediately while the user reviews uncertain items. Do NOT use to generate a new review — use /copilot-review for that.
development2
ralphify-spec
Generate a ralphify-approved ralph directory (RALPH.md + optional scripts) from a plain-English description of repetitive or iterative work. Use this skill whenever the user says "ralphify", "create a ralph", "ralph wiggum", "autonomous loop", "/ralphify", references Geoffrey Huntley's Ralph Wiggum method, or asks to wrap iterative work in ralphify (test-until-green, refactor-until-done, lint-until-clean, coverage-until-90, burn-down-todos, resolve-review-comments). Trigger even when the user does not explicitly name ralphify but describes an open-ended loop ("keep fixing tests until they pass", "port files one by one until the directory is done"). Do not trigger for one-shot tasks — ralphs exist for work that benefits from running N times against a stop condition.
development2
lookup
Code intelligence router — decides which tool to use when you need to understand a symbol, type, API, or code relationship. Language-agnostic: works for Rust, Python, TypeScript, Go, Ruby, Java, and any language with LSP support. Prevents wasteful brute-force lookup anti-patterns: cargo doc + grep, grepping dependency caches (node_modules, site-packages, .cargo/registry, go/pkg/mod, .m2), go doc + grep, python help() + grep, and multi-step find chains. Use this skill BEFORE reaching for bash when the question is "what does X do?", "what's the signature of Y?", "who calls Z?", or "how do I use this API?". Routes to the right tool: LSP for types and cross-refs, ast-grep for structural patterns, Context7 for external docs, gh CLI for GitHub code search. If you catch yourself about to grep a dependency cache or generate docs just to search them — stop and use this instead.
tools2
ralphify-spec
Generate a ralphify-approved ralph directory (RALPH.md + optional scripts) from a plain-English description of repetitive or iterative work. Use this skill whenever the user says "ralphify", "create a ralph", "ralph wiggum", "autonomous loop", "/ralphify", references Geoffrey Huntley's Ralph Wiggum method, or asks to wrap iterative work in ralphify (test-until-green, refactor-until-done, lint-until-clean, coverage-until-90, burn-down-todos, resolve-review-comments). Trigger even when the user does not explicitly name ralphify but describes an open-ended loop ("keep fixing tests until they pass", "port files one by one until the directory is done"). Do not trigger for one-shot tasks — ralphs exist for work that benefits from running N times against a stop condition.
development2
tdd-assertions
Detect and fix weak test assertions that AI generates across Rust, Python, TypeScript, Go, and Shell. Use this skill whenever you write or review tests, when the user says "strengthen assertions", "fix weak tests", or during /wreck, /fromage, and /simplify flows. Also use as a mental checklist before committing test code — AI assistants systematically produce assertions that pass when the code is broken, which is the cardinal sin of TDD. Trigger proactively on test generation and test review.
development2
todoist
Todoist dashboard and router. Shows inbox count, overdue count, project health, and routes to the right sub-skill. Use when the user says 'todoist', 'check my tasks', 'task overview', 'what's on my plate', 'show me my todos', or any general Todoist inquiry that doesn't clearly map to triage/organize/update/extract.
testing2
age
Staff Engineer code review orchestrator. Spawns 6 parallel review sub-agents (safety, arch, encap, yagni, history, spec), merges findings with history-based score modifiers, and produces a unified Age Report. Two modes: focused (changes) and comprehensive (full audit). Use when the user invokes /age, or when a command needs code review (fromage Phase 8, move-my-cheese, copilot-review, fromagerie). This is a SKILL, not an agent — it runs inline in the caller's context so the 6 sub-agents are first-level agents, avoiding nested-agent depth issues. Do NOT use for implementation (fromage-cook), cleanup fixes (simplify/de-slop), or PR comment triage (respond/copilot-review).
development2
commit
Stage and commit changes to git following conventional commits format. Use when asked to commit, create a commit, or save changes. Drafts meaningful commit messages by understanding the why, not just the what. Never amends published commits, never skips hooks, never uses git add -A. Stages specific files by name. Does not push — that is the gh skill's job.
development2
justfile
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.).
development2
de-slop
Detect and fix AI-generated code anti-patterns ("slop") across Rust, Python, TypeScript, Go, and Shell. Use this skill whenever you generate or edit code, when the user says "de-slop", "clean up AI code", "remove AI slop", or during /simplify and /fromage flows. Also use as a mental checklist before committing any code — AI assistants produce systematically predictable mistakes and this skill is the antidote. Trigger proactively on code review, post-generation cleanup, and pre-commit checks. If code was just written or modified by an AI (including you), this skill applies.
development2
diff
Quick pre-commit smoke test of staged or unstaged changes. Scans for blockers (secrets, debug statements, commented code, silent failures) and warnings (oversized functions/files, deep nesting, domain leakage). Use when asked to review staged changes, run a pre-commit check, or when the /diff command is invoked.
development2
extract
Find Todoist tasks that are really reference material (not actionable) and export them as structured markdown for Dropbox or other storage. Use when the user says 'extract references', 'find non-actionable tasks', 'clean up reference tasks', 'move to dropbox', 'todoist to dropbox', 'separate reference from tasks', or when /todoist dashboard flags many noun-only or URL tasks.
data-ai2
fetch
Fetch external documentation or code while protecting the main context window. Use Context7 (preferred, free) for library docs. Use Tavily for technical concepts and best practices. Use Serper for factual lookups and Google SERP features. Use `gh` CLI for GitHub operations. Cost-aware routing: free → cheap → expensive. Governs: when to skip and use training data, when to fetch inline vs delegate to a subagent.
tools2
gh
Complete GitHub tasks using the GitHub MCP plugin. Use for any GitHub operation — PRs, issues, CI checks, repo management, releases, code search. Use git commands (log, diff, status) for local context. Prefer MCP tools over gh CLI — they bypass sandbox/TLS issues. Use when the user says "create PR", "merge PR", "check CI", "list issues", "review PR", "PR status", "close issue", or invokes /gh. Do NOT use for local git operations like commit, stage, or push — use /commit for those. Do NOT use for code quality review — use /age or /code-review.
tools2
git-hygiene
Guardrail for proper git tool usage. Prevents reading file contents via git show <ref>:<path> or git cat-file, which bypass the Read tool and file access controls. Triggers when planning git commands that read file contents from other branches or commits, or when colon syntax appears in git commands. Use when about to construct "git show ref:path" or "git cat-file" commands. Do NOT use for normal git operations like commit, push, log, or diff.
tools2
merge-resolve
Resolve merge conflicts, rebase conflicts, and cherry-pick failures using mergiraf (AST-aware structural merge), git rerere, and kdiff3. Activate when: merge failed, rebase conflict, cherry-pick failed, CONFLICT in file, "resolve conflicts", "fix merge", "merge conflict", "conflict resolution", or git output shows CONFLICT markers. Also use for mergiraf diagnostics, rerere management, gitattributes regeneration, or batch conflict resolution across multiple files. Covers the full resolution chain: mergiraf (structural auto-resolve) → rerere (replay remembered fixes) → kdiff3 (manual). Do NOT use for general git operations without conflicts — those go to the commit or gh skills.
development2
lint
Run project linters (shellcheck, yamllint, jsonlint, prettier, eslint, clippy, etc.) and report findings. Use when the user says "lint", "check code quality", "run linters", "lint shell scripts", or wants to validate syntax/style in a project. Supports multi-language projects: shell, YAML, JSON, TOML, JavaScript, Python, Rust. Aggregates findings into a summary report with file/line references for easy fixing.
tools2
nih-audit
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 this skill when the user mentions reinventing the wheel, asks if there's a library for something they built, wants a build vs buy audit, says "what are we maintaining that we shouldn't be", asks about library alternatives for custom code, wonders if their utils/ folder has redundant implementations, or wants to find dependency opportunities. Also use when the user asks to compare their custom implementation against existing packages, or says things like "should we just use lodash for this" or "is there a crate that does what our helper does". Do NOT use for security vulnerability scanning (/audit), code quality review (/age), or dead code removal (/simplifier).
tools2
organize
Audit and restructure Todoist projects, labels, sections, and filters. Proposes changes with approval before executing. Use when the user says 'organize todoist', 'restructure projects', 'clean up projects', 'fix my todoist structure', 'audit labels', 'create filters', or when /todoist dashboard shows structural issues (too many projects, empty projects, missing filters).
testing2
prek
Onboard prek (Rust-powered pre-commit) into any project and suggest hooks tailored to the language/framework. Use when the user says "add prek", "set up pre-commit hooks", "configure prek", "what hooks should I use", or when you notice a project without a prek.toml that would benefit from pre-commit checks. Also trigger when the user wants to add new hooks to an existing prek.toml, audit their hook config, or migrate from pre-commit to prek. Covers Rust, Python, TypeScript/JavaScript, Go, Ruby, and Shell projects. Do NOT use for husky, lint-staged, or CI pipeline hook configuration — this skill is specifically for prek.
development2
session-analytics
Query Claude Code's own JSONL session logs via DuckDB for usage analytics, tool patterns, error forensics, 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, 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", or asks about specific tool/agent/skill behavior across sessions. This skill turns ~900MB of 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 transcripts, or questions about Claude's capabilities — this skill is for aggregate usage analytics across historical sessions.
tools2
xray
Interactive design verification via dependency graph traversal. Replaces /notebook. Use when reviewing large modules, verifying agent output, auditing design decisions, or when you need to understand whether code does what it should. Point it at a module, spec, or PR. Triggers on: /xray, "review this module", "verify the design", "is this the right architecture", "check this code against the spec", "what does this module actually do", design review, code audit.
development2
triage
Interactive triage of overdue and stale Todoist tasks. Presents tasks in batches, user decides fate of each: complete, reschedule, delete, someday, or skip. Use when the user says 'triage', 'process overdue tasks', 'clean up todoist', 'deal with overdue', 'task triage', 'inbox zero', or when /todoist dashboard shows high overdue count.
testing2
tui-design
Create distinctive, production-grade terminal user interfaces with high usability and professional polish. Use this skill when the user asks to build TUI applications, terminal dashboards, interactive CLI tools, or any full-screen terminal interface (system monitors, git clients, database explorers, log viewers, file managers, REPL wrappers). Supports Rust (ratatui/crossterm) and Python (Textual/Rich). Use when the user says "build a dashboard", "terminal UI", "interactive CLI", "TUI app", "system monitor", "log viewer", or invokes /tui-design.
tools2
worktree
Create an isolated git worktree for a Claude Code task, keeping main clean. Use when asked to create or resume a worktree, set up an isolated branch for a task, or when the /worktree command is invoked. Requires a task slug.
development2
settings-clean
Clean a bloated .claude/settings.local.json by removing redundant, stale, and junk permission entries and ensuring hook-redirected skills are allowed. Use when the user says "clean settings", "prune settings", "settings cleanup", or invokes /settings-clean; also proactively when settings.local.json exceeds ~30 entries. Only touches settings.local.json (gitignored), never settings.json (committed).
tools2
design-doc
Use when the user wants to draft, revise, critique, or shepherd a design document, RFC, ADR, tech spec, or design proposal. Triggers on "write a design doc", "draft an RFC", "ADR for X", "design proposal", "tech spec", "review my design doc", "tighten this design doc", "critique my draft". Drives a spine-first, anti-slop workflow where YOU author Context / Problem / Goals / Non-Goals / Alternatives / Risks and the AI is restricted to critique, expansion, and copyedit. Use even when the user says "help me write a design doc" — the help is procedural, not authorial.
development2
grok-codebase
Use when the user wants deep, multi-session internalization of an unfamiliar codebase — not just an orientation, but the goal of being able to explain it on a whiteboard and answer "what breaks if I change X" without re-checking. Triggers on "grok this repo", "onboard me", "memorize this project", "lock this codebase into memory", "quiz me on this repo", "help me understand this codebase deeply". Runs a four-pillar march (Building Blocks → Entry Points → Infrastructure → Egress) plus a trace-one-request exercise and an adaptive Socratic quiz; persists artifacts to .cheese/grok/<repo>/. Read-only stance — DO NOT propose edits unless explicitly asked. For a quick single-session orientation ("tour this repo", "trace how X works"), use `/tour` instead. Especially tuned for TS/JS monorepos and Next.js / Express / NestJS / Fastify apps; methodology is stack-agnostic. Do NOT use for single-file scripts, repos under 500 LOC, or editing tasks.
development2
research
Multi-source research orchestrator scoped to the todoist-flow plugin so profiles like `dots profile launch claude todo` can do fact checks without enabling cheese-flow. Spawns parallel fetch sub-agents for Context7 (library docs), Tavily (technical content), Serper (facts/SERP), and `gh` CLI (GitHub patterns). Fetchers write findings to scratch files; a single synthesis sub-agent reads them and returns a compact answer, keeping the caller's context clean. Use when the user is mid-task-triage and needs external facts before deciding whether to keep, reword, or extract a Todoist task, or invokes /todoist-flow:research directly. Do NOT use for single-source lookups (use Context7 directly for library docs alone). For coding sessions outside the todo profile, prefer cheese-flow's /briesearch instead.
tools2
tui-design
Create distinctive, production-grade terminal UIs and full-screen interactive CLI tools in Rust (ratatui/crossterm) or Python (Textual/Rich). Use when the user says "build a dashboard", "terminal UI", "interactive CLI", "TUI app", "system monitor", "log viewer", "file manager", or invokes /tui-design.
tools2
tdd-assertions
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 /wreck, /cook, /press, and /simplify flows. Trigger proactively on test generation and review.
development2
grok-codebase
Build lasting understanding of an unfamiliar codebase via a four-pillar model (Building Blocks, Entry Points, Infrastructure, Egress) plus an adaptive Socratic quiz, orchestrating code-review-graph, Serena, 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.
development2
serena-project-config
Tune per-repo Serena MCP config (.serena/project.yml) when the auto-bootstrap isn't enough — monorepos, wrong language detection, heavy generated dirs, or review-only setups. Use when the user says "configure serena for this repo", "serena project config", "monorepo serena", "serena wrong language", or "review-only serena". Do NOT trigger on general "use serena" routing, and never enable memory tools or onboarding (disabled by design).
tools2
test-sandbox
Run Python test code in an isolated .claude/testing sandbox (via sub-agent) without polluting the main context, reporting only pass/fail counts and assertion details. Use when the user says "run a quick test", "verify this works", "sanity check", "test this snippet", or invokes /test-sandbox; supports --sweep to clean stale test files. Do NOT use for the project's real test suite — this is for quick snippets.
development2
worktree
Create or resume an isolated git worktree for a Claude Code task, keeping main clean. Use when asked to "create a worktree", "resume a worktree", set up an isolated branch for a task, or when /worktree is invoked. Requires a task slug.
development2
self-eval
Run the Self-Evaluation Checklist against your last response or recent code changes. Use when the user says "self-eval", "self-evaluate", "check my response", "quality check", "evaluate response", or expresses doubt ("did you actually test that?", "are you sure?", "that seems incomplete"), or proactively before finishing code edits. Cross-references /de-slop and /tdd-assertions for items with dedicated tooling.
tools2
de-slop
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.
development2
claude-local
Distill the user's global ~/.claude/CLAUDE.md into a gitignored CLAUDE.local.md for repos they contribute to but don't own — keeping only repo-relevant instructions and dropping personal flair. Use when the user says "set up CLAUDE.local", "scaffold local claude config", "drop my preferences in this repo", "I'm contributing and want my preferences applied", "claude-local.md", or invokes /claude-local. Also use proactively when they open an unfamiliar repo and want to start contributing.
data-ai2
spec-verify
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.
development2
xray
Interactive design verification via dependency-graph traversal (replaces /notebook) — point it at a module, spec, or PR. Use when reviewing large modules, verifying agent output, or auditing design, or when the user says "review this module", "verify the design", "is this the right architecture", "check this code against the spec", "what does this module actually do", or invokes /xray.
development2
version-doctor
Diagnose and fix library version mismatches, dependency conflicts, and build file inheritance issues. Use when the user says "fix versions", "version mismatch", "dependency conflict", "why won't this build", or "update dependencies", and proactively when a build fails on version constraints — the fix is almost always a version bump, not restructuring the build. Use this before rewriting a build config or bypassing workspace inheritance.
development2
nih-audit
Scan for custom code that duplicates well-supported libraries, then recommend migrations with effort estimates. Detects hand-rolled utilities, retry logic, validation, date handling, and DIY parsers. Use when the user mentions reinventing the wheel, asks "is there a library/crate for this", wants a build vs buy audit, says "what are we maintaining that we shouldn't be", or "should we just use lodash for this". Do NOT use for code-quality review (/age) or dead-code removal (/simplify or /ghostbuster).
development2
git-hygiene
Guardrail against git commands that read file contents outside the Read tool — especially `git show <ref>:<path>` and `git cat-file`, which bypass file-access controls. Triggers when constructing git commands with colon ref:path syntax or cat-file to read another branch or commit. Do NOT use for normal git operations like status, log, diff, commit, or push.
tools2
steel-thread
Map a concept end-to-end through a layered codebase using the code-review-graph MCP — rebuilding the graph, preferring its Flow primitive, and cross-checking 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 this change", or invokes /steel-thread. Do NOT use for single-symbol lookups (Serena), filesystem search (/scout), or dead-code detection (/ghostbuster).
tools2
ghostbuster
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).
development2
wt-git
Run git and GitHub operations inside a worktree you're not currently in, without tripping Claude Code's Seatbelt safety heuristics (compound cd+git, heredoc PR bodies). Use whenever you need to commit, push, or create PRs in another worktree — especially from orchestrators, /move-my-cheese, or /cheese-convoy — or when about to write "cd <path> && git" or a heredoc gh PR body.
development2
test-sandbox
Run Python test code in an isolated sandbox without polluting the main context. Writes test files to .claude/testing/ (gitignored), runs via sub-agent, and reports only pass/fail counts and assertion details. Use when you want to quickly verify code without writing inline python3 -c scripts. Also supports --sweep to clean stale test files. Use when the user says "run a quick test", "verify this works", "sanity check", "test this snippet", or invokes /test-sandbox.
development2
tour
Use when the user wants a quick, single-session read-only tour of an unfamiliar codebase or a specific feature — orientation, not memorization. Triggers on "tour this repo", "give me a tour", "give me a read-only tour", "what does this project do", "map the architecture", "trace how X works", "where is Y implemented", "show me how this works", "explain this codebase quickly". Output is a layered summary (project purpose → module map → call graph for the pointed-at thing) with file:line citations. Stops after answering — never volunteers refactors. For deeper multi-session internalization with an adaptive quiz, use `/grok-codebase` instead.
development2
read-mode-probe
Use when the user wants to interrogate an unfamiliar codebase with structured probes rather than a summary — invariants, data flow, error paths, hot paths, security surface. Triggers on "probe this", "what are the invariants here", "where does X flow", "find the risk in this code", "trace error paths", "what's on the hot path", "security audit this file/module", "what could go wrong here". Returns numbered findings with confidence + citations, never edits.
development2