skills

Use when starting work in an unfamiliar repository, resuming after context loss, needing to discover the real source of truth before editing code, or turning a rough onboarding prompt into an execution-ready repo-orientation prompt.

Create new agent skills with proper structure, progressive disclosure, and bundled resources. Use when user wants to create, write, or build a new skill.

Use when a local change may hide broader architectural coupling, naming drift, or complexity growth and you need to evaluate it in system context before proceeding.

Ultra-compressed communication mode. Cuts token usage ~75% by dropping filler, articles, and pleasantries while keeping full technical accuracy. Use when user says "caveman mode", "talk like caveman", "use caveman", "less tokens", "be brief", or invokes $caveman, /caveman.

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

Write, review, and fix GNU Make and Kbuild Makefiles for C/C++ projects, Linux kernel modules, and recursive monorepo builds. Use when the user mentions Makefile, GNU Make, Kbuild, obj-m, KERNELRELEASE, CFLAGS, phony targets, install or clean rules, or wants to create or repair a C/C++ build.

Use when a request is ambiguous, high-risk, or plausibly implementable in multiple valid ways, before making code changes or locking an execution plan.

Create a temporary handoff note for opening a new chat from a live MNHAT workstream. Use when the user explicitly asks to compact, hand off, or resume work in a fresh session without replacing `.mnhat` as the source of truth.

Use when implementing a feature or bugfix with test-first development and you want a disciplined red-green-refactor loop in small vertical slices.

Capture durable lessons and close out a finished or intentionally abandoned workstream. Use when review is complete and the session needs a canonical compounding report plus durable follow-up memory.

Diagnose blocked work and failures with evidence-first debugging. Use when implementation, verification, or integration work hits a blocker that needs reproducible root-cause analysis and a canonical `debug-report.md`.

Implement one approved current-work item or parent-assigned slice. Use when planning or swarming has already chosen the scope and the next step is to make the change, verify it, and report precisely.

Capture locked decisions for ambiguous work before planning. Use when a feature, bug fix, or workflow request still needs scope, boundaries, and a canonical `context.md` before implementation planning.

Record meaningful implementation decisions for an active MNHAT workstream. Use when a phase skill needs to append a canonical implementation record entry for a change, no-change decision, blocker, defer, or tradeoff.

Turn locked context into the smallest believable execution plan. Use when scope is clarified enough for planning, but the work still needs approach, work-shape, and current-story artifacts before implementation.

Run the final quality gate after implementation. Use when current work is implemented and needs findings, artifact verification, UAT, and a clear handoff into compounding or follow-up fixes.

Route repo work into the MNHAT workflow family and recover active runtime state. Use when starting or resuming a repo session, deciding the next MNHAT phase, or running the full MNHAT workflow.

Coordinate explicit parallel implementation for approved current work. Use when the user wants delegation or parallel workers and the work can be partitioned into bounded slices with clear ownership and verification.

Prove that planned current work is feasible before implementation. Use when planning artifacts exist and the next step needs repo-truth, evidence, and explicit approval instead of optimistic execution.

Use when a bug, flaky test, unexpected runtime behavior, or contradiction between code and observed output needs disciplined debugging before fixing.

Use when the user wants to turn a rough idea, vague task, feature wish, bug-fix intent, or Codex /goal objective into a clear verifiable goal prompt. Use when the user mentions goal mode, /goal, set_goal, long-running autonomous Codex work, or asks to be interviewed/grilled before creating a goal.

Use when working in a repository that uses bd or Beads for durable project task tracking, issue dependencies, blocker management, multi-session handoff, or shared work memory. Trigger when the user asks to find ready work, claim or close tasks, create follow-up work, inspect blockers, recover project context, or choose between local planning and persistent project tracking.