⏩ thunderkit

Opinionated multi-model delegation for very large repos.

The thesis

Big work in big repos is won by decomposition + heterogeneity, not by one smart model. thunderkit turns a large change into disjoint parallel lanes and routes each to the best model and harness — asking you to pick the load-bearing ones.

Install

npx skills add thunderock/thunderkit -s '*' -g

Or one skill: npx skills add thunderock/thunderkit -s tk-router -g

Skills

tk-ask

Use when you need a harness or model to answer in a very limited set of simple words: enforces yes/no, one-word, number, or path answers with a hard word cap, so answers are checkable and cannot hide uncertainty in prose.

tk-audit

Use to check a milestone actually achieved its intent before archiving: aggregates every lane's verification, checks cross-lane integration and requirements coverage across all model families, and fails closed on orphaned or unverified requirements.

tk-debug

Use when a lane or verification fails and the cause isn't obvious: runs a scientific-method debug loop (symptoms, hypotheses, isolating probes, root cause, fix, regression proof) with state persisted so it survives context resets.

tk-discuss

Use before planning to capture implementation decisions and resolve gray areas: adaptive questioning that records choices and their rejected alternatives in CONTEXT.md so tk-plan and tk-execute inherit settled decisions.

tk-docs

Use to generate or refresh project documentation after a big change: fans parallel doc-writer lanes then verifies every factual claim against the live codebase with a second model family, so docs match reality instead of intent.

tk-execute

Use to run an accepted thunderkit plan: implements disjoint lanes in parallel across the fleet via portable CLI dispatch (claude/codex), each lane in its own git worktree with a captured resumable session id.

tk-grill

Use before planning when a request is vague or a plan has gray areas: interrogates the harness and the user with short closed questions (yes/no, one word, a number, a path) until the brief has no unknowns. Never a paragraph.

tk-handoff

Use to save or restore a work session in a portable format when a harness nears full context or you pause: save writes .thunderkit/HANDOFF.md (stage, lanes, resume ids, decisions, next action); restore reads north star plus handoff and resumes at the named stage.

tk-learn

Use to learn something the fleet doesn't know yet: researches a topic online, writes a source-backed knowledge note under .thunderkit/knowledge/, and can draft a new validated tk-* skill from what was learned — so knowledge becomes reusable, not one-shot.

tk-map

Use before planning work in a large or unfamiliar repo: builds or refreshes a code map (structure, entry points, ownership, hotspots) so plan and execute work from facts, not guesses.

tk-memory

Use to give a project durable intent: scaffolds and maintains .thunderkit/ (north-star goals + a decision log) so the project's opinion and choices persist across sessions, agents, and model changes.

tk-plan

Use to turn a big-repo change into a parallel execution plan: decomposes work into disjoint, dependency-layered lanes, each file-scoped with acceptance criteria and a verification command, ready for tk-execute.

tk-research

Use to investigate unknowns before planning a big change: fans parallel research lanes (library options, prior art, pitfalls, API behavior) across cheap wide models, each writing a focused finding, consolidated into RESEARCH.md.

tk-review

Use to review and verify completed big-repo work: fans a diff to two-plus model families for cross-family review, consolidates findings by severity, and runs each lane's verification command so done means evidence, not intent.

tk-router

Use when starting big-repo multi-model work: sizes the change, asks you to pick three model classes (one planner, a set of executors, everyone as reviewers), and routes through the thunderkit lifecycle — grill, map, plan, execute, review, ship. Entry point for the thunderkit pack.

tk-ship

Use to close a completed big change: gates on passing cross-family review and UAT, assembles a rich PR body from the .thunderkit artifacts, and prepares a branch for merge — never pushing or merging without your go-ahead.

tk-spec

Use to clarify WHAT a big change delivers before planning: runs an ambiguity-scored Socratic loop until scope, non-goals, and rejection criteria are unambiguous, producing SPEC.md that tk-plan builds on.

tk-test

Use to prove the fleet configured by tk-router is actually reachable: pings every model in .thunderkit/config.json through its real harness CLI with a one-word probe and reports reachable/unreachable per model and per class before any real work starts.

tk-verify-work

Use to validate built features through conversational walk-through: turns each acceptance criterion into a real user-surface test, tracks pass/fail/gap in UAT.md that survives a context reset, and feeds gaps back to tk-plan.