The-QUESTION

Create, review, audit, and list Architectural Decision Records for any software project. Trigger on: "create an ADR", "document this decision", "ADR for...", "what ADRs exist", "review this ADR", "update INDEX.md", architectural trade-offs, or design pivots affecting multiple layers or files. Project-agnostic -- works with any tech stack. Backed by Karpathy principles: think before deciding, simplest sufficient ADR, surgical scope.

Audit Codex skills for visibility flags, deterministic vs non-deterministic steps, and composability opportunities. Reads .Codex/skills/ (or a user-specified path), produces a punch list per skill, then shows proposed rewrites with a changelog. Trigger on: "audit my skills", "review my skill files", "which skills auto-fire?", "find duplicated logic in my skills", "should any skills be internal-only?", or any request to review, improve, or rationalize a set of SKILL.md files. Never modifies any file -- proposes changes and waits for approval.

You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.

Decision guide for delegating to caveman-style subagents. Tells the main thread WHEN to spawn `cavecrew-investigator` (locate code), `cavecrew-builder` (1-2 file edit), or `cavecrew-reviewer` (diff review) instead of doing the work inline or using vanilla `Explore`. Subagent output is caveman-compressed so the tool-result injected back into main context is ~60% smaller -- main context lasts longer across long sessions. Trigger: "delegate to subagent", "use cavecrew", "spawn investigator/builder/reviewer", "save context", "compressed agent output".

Ultra-compressed commit message generator. Cuts noise from commit messages while preserving intent and reasoning. Conventional Commits format. Subject ≤50 chars, body only when "why" isn't obvious. Use when user says "write a commit", "commit message", "generate commit", "/commit", or invokes /caveman-commit. Auto-triggers when staging changes.

Compress natural language memory files (AGENTS.md, todos, preferences) into caveman format to save input tokens. Preserves all technical substance, code, URLs, and structure. Compressed version overwrites the original file. Human-readable backup saved as FILE.original.md. Trigger: /caveman-compress FILEPATH or "compress memory file"

Quick-reference card for all caveman modes, skills, and commands. One-shot display, not a persistent mode. Trigger: /caveman-help, "caveman help", "what caveman commands", "how do I use caveman".

Ultra-compressed code review comments. Cuts noise from PR feedback while preserving the actionable signal. Each comment is one line: location, problem, fix. Use when user says "review this PR", "code review", "review the diff", "/review", or invokes /caveman-review. Auto-triggers when reviewing pull requests.

Ultra-compressed communication mode. Cuts token usage ~75% by speaking like caveman while keeping full technical accuracy. Supports intensity levels: lite, full (default), ultra, wenyan-lite, wenyan-full, wenyan-ultra. Use when user says "caveman mode", "talk like caveman", "use caveman", "less tokens", "be brief", or invokes /caveman. Also auto-triggers when token efficiency is requested.

Show real token usage and estimated savings for the current session. Reads directly from the Codex session log -- no AI estimation. Triggers on /caveman-stats. Output is injected by the mode-tracker hook; the model itself does not compute the numbers.

Disciplined diagnosis loop for hard bugs and performance regressions. Reproduce -> minimise -> hypothesise -> instrument -> fix -> regression-test. Use when user says "diagnose this" / "debug this", reports a bug, says something is broken/throwing/failing, or describes a performance regression.

Use when facing 2+ independent tasks that can be worked on without shared state or sequential dependencies

Edit and improve articles by restructuring sections, improving clarity, and tightening prose. Use when user wants to edit, revise, or improve an article draft.

Use when you have a written implementation plan to execute in a separate session with review checkpoints

Use when implementation is complete, all tests pass, and you need to decide how to integrate the work - guides completion of development work by presenting structured options for merge, PR, or cleanup

Set up Codex hooks to block dangerous git commands (push, reset --hard, clean, branch -D, etc.) before they execute. Use when user wants to prevent destructive git operations, add git safety hooks, or block git push/reset in Codex.

Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Use when user wants to stress-test a plan, get grilled on their design, or mentions "grill me".

Grilling session that challenges your plan against the existing domain model, sharpens terminology, and updates documentation (CONTEXT.md, ADRs) inline as decisions crystallise. Use when user wants to stress-test a plan against their project's language and documented decisions.

Compact the current conversation into a handoff document for another agent to pick up.

Find deepening opportunities in a codebase, informed by the domain language in CONTEXT.md and the decisions in docs/adr/. Use when the user wants to improve architecture, find refactoring opportunities, consolidate tightly-coupled modules, or make a codebase more testable and AI-navigable.

Apply Karpathy coding discipline to any task: think before coding, simplicity first, surgical changes only, goal-driven execution with verifiable success criteria. Invoke before any non-trivial implementation. Use /karpathy plan <task> to produce a verifiable step plan. Use /karpathy review to audit recent work. Auto-triggers when user asks to plan an approach, requests a step-by-step breakdown, or when the assistant is about to start a multi-file or multi-step change.

Set up and operate an LLM-maintained personal knowledge base wiki. Use when building a persistent, compounding knowledge base from source documents -- articles, papers, notes, transcripts, or any source material.

Convert Codex's persisted memory into a structured high-level outline and save it to the project Obsidian vault. Use to archive and organize accumulated session knowledge as a navigable vault note.

Migrate test files from `as` type assertions to @total-typescript/shoehorn. Use when user mentions shoehorn, wants to replace `as` in tests, or needs partial test data.

Search, create, and manage notes in the Obsidian vault with wikilinks and index notes. Use when user wants to find, create, or organize notes in Obsidian.

Interactive first-run experience for new Codex-ITect installs. Asks 3 short questions about workflow style, project type, and communication preference. Generates a personalized 5-skill starter roadmap. Runs once per install via sentinel file; re-run manually with /onboard --reset.

Track project phase lifecycle: status snapshots, transitions, and ADR impact analysis. Trigger on: "what phase are we in?", "is phase X unblocked?", "did ADR-### move any phase?", "give me a status snapshot", "what's next?", "what's blocked?", "phase status", creating or editing phase documents, or comparing phase state across plan revisions. Project-agnostic -- binds to any project with a Phase Registry. Backed by Karpathy principles: surface state truthfully, no silent assumptions.

Build a throwaway prototype to flesh out a design before committing to it. Routes between two branches -- a runnable terminal app for state/business-logic questions, or several radically different UI variations toggleable from one route. Use when the user wants to prototype, sanity-check a data model or state machine, mock up a UI, explore design options, or says "prototype this", "let me play with it", "try a few designs".

Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation

Use when completing tasks, implementing major features, or before merging to verify work meets requirements

Use when about to push to any git remote -- runs large-file, test, uncommitted-change, and diverged-history checks before pushing

Create exercise directory structures with sections, problems, solutions, and explainers that pass linting. Use when user wants to scaffold exercises, create exercise stubs, or set up a new course section.

Set up Husky pre-commit hooks with lint-staged (Prettier), type checking, and tests in the current repo. Use when user wants to add pre-commit hooks, set up Husky, configure lint-staged, or add commit-time formatting/typechecking/testing.

Sets up an `## Agent skills` block in AGENTS.md/AGENTS.md and `docs/agents/` so the engineering skills know this repo's issue tracker (GitHub or local markdown), triage label vocabulary, and domain doc layout. Run before first use of `to-issues`, `to-prd`, `triage`, `diagnose`, `tdd`, `improve-codebase-architecture`, or `zoom-out` -- or if those skills appear to be missing context about the issue tracker, triage labels, or domain docs.

Use when executing implementation plans with independent tasks in the current session

Use when encountering environment, config, infrastructure, CI, or build issues -- not application-layer bugs (use diagnose for those). Requires root cause investigation before any fix.

TDD discipline enforcement -- Iron Law, Red-Green-Refactor loop, rationalization resistance. Use when actively implementing features or bugfixes, before writing any production code. For TDD philosophy and planning discussion, use tdd-guide.

TDD philosophy, planning, and tracer-bullet vertical slice concept. Use when user asks how TDD works, wants to understand test-first thinking, plan which behaviors to test, or discuss tracer bullets. For active implementation enforcement, use tdd-enforce.

Fix the previous failed shell command. Trigger when a command errors out, user says "fix that command", "what should I have typed", "correct that", or types "fuck" as a message. Diagnoses the error, proposes corrected command, confirms before running.

Break a plan, spec, or PRD into independently-grabbable issues on the project issue tracker using tracer-bullet vertical slices. Use when user wants to convert a plan into issues, create implementation tickets, or break down work into issues.