Claud-itect-Skill

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

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

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

Convert Claude'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.

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.

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.

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.

Use when starting feature work that needs isolation from current workspace or before executing implementation plans - ensures an isolated workspace exists via native tools or git worktree fallback

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 Claude Code skills for visibility flags, deterministic vs non-deterministic steps, and composability opportunities. Reads .claude/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.

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.

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.

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.

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.

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 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.

Triage issues through a state machine driven by triage roles. Use when user wants to create an issue, triage issues, review incoming bugs or feature requests, prepare issues for an AFK agent, or manage issue workflow.

Command set for the project wiki (Obsidian vault). Handles read, approve, reject, add, search, and graph subcommands against the docs/Obsidian Vault/ directory. Use when reading or modifying wiki content, approving suggestions from _suggestions/, or exploring wiki structure.

Inference engine for the project wiki. Scans source files (skills, hooks, agents, ADRs, codebase) against existing wiki pages, identifies undocumented content, and generates PENDING suggestion files in _suggestions/ for human review. Assigns HIGH/MEDIUM/LOW confidence based on evidence strength.

Sets up an `## Agent skills` block in AGENTS.md/CLAUDE.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.

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 (CLAUDE.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 Claude Code 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.

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

Set up Claude Code 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 Claude Code.

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".

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

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.

Interactive first-run experience for new Claude-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.

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