Opinionated multi-model delegation for very large repos.
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.
npx skills add thunderock/thunderkit -s '*' -gOr one skill: npx skills add thunderock/thunderkit -s tk-router -g
Use when you need a harness, a dispatched lane, or a person to answer one question in a checkable closed shape: enforces yes/no, one-word, number, path, or enum answers with a hard word cap, so an answer is either a listed value or the literal `unknown` and cannot hide uncertainty in prose.
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.
Use when a lane fails, behavior is wrong or a crash has no obvious cause: preserve symptoms, falsifiable hypotheses, executed probes, a demonstrated root cause and a minimal fix with failing-before/passing-after regression evidence. Separates native investigation advice from executed debugging.
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.
Use to generate or refresh project documentation when behavior, setup, commands, examples or public APIs change: assign disjoint files to selected executors and independently verify every factual claim against live sources with selected reviewers of a different family.
Use to run a reviewed and separately approved thunderkit plan under one qualified native execution owner or an explicitly bound portable owner. Preserves selected models, native artifact identity and project-contained worktrees; stops on stale approvals, uncertain ownership or failed verification without automatic delivery.
Use when a change is trivial and local (a typo, a rename, a one-line fix, a config value): edit inline in the current session with no model selection, plan, subagents or review, run the targeted test and make one atomic commit; escalate to tk-quick when it stops being trivial.
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. Reuses a compatible native interview component for unresolved intake questions only; Thunderkit keeps the checklist, the decisions and the brief. Never a paragraph.
Use when pausing work, nearing the context limit, or restoring a saved checkpoint: preserve portable stage, artifact, model and session identities; validate them before resume. Locate a specific missing session only when the user explicitly requests and consents to lookup.
Use to investigate factual project unknowns and preserve source-backed findings in .thunderkit/knowledge/. Optionally search existing skill metadata before proposing a reusable capability; ordinary learning does not create or install skills.
Use before planning work in a large or unfamiliar repo, or when its map is stale: build or refresh a source-backed, read-only code map with boundaries, ownership, hotspots, per-area verification commands, and explicit unmapped areas.
Use when viewing project intent, saving an approved choice, or migrating old model selections: maintain committed .thunderkit/ north-star goals, an append-only decision log, and portable configuration across sessions, agents, and model changes.
Use to turn an agreed big-repo change into dependency-layered lanes with file ownership, acceptance criteria and verification commands. Hands planning to one qualified native planner or a bound owned planner, preserves native artifacts and approvals, and prepares a lane summary for separate cross-family plan review before execution approval.
Use when a task is small but not trivial: run it on one model (the planner class from .thunderkit/config.json, or model=<key> from models.json) with no plan document or parallel lanes, atomic commits and tests, and exactly one reviewer from a different model family before each commit.
Use to investigate unknowns before planning a large change: give bounded library, API, prior-art and pitfalls questions to one source-qualified research owner, then consolidate evidence, contradictions and unknowns into RESEARCH.md.
Use when recovering context or exporting verified backups.
Use for independent cross-family review of a plan before execution or a completed diff: preserve selected reviewers, consolidate evidence-backed findings and disagreements, and block approval on insufficient actual families, stale targets, unresolved blocker or major findings, or missing verification.
Use when starting big-repo multi-model work: sizes the change, has you pick three model classes (one planner, a set of executors, reviewers) from the local catalog, checks which workflow backend and sibling tk-* stages are actually available, and routes through the thunderkit lifecycle with plan review gated before execution. Entry point for the thunderkit pack.
Use when a completed change needs a readiness check and PR-body draft: require fresh cross-family review, per-lane verification, applicable UAT and unchanged frozen paths; prepare an engineering summary and branch handoff only, without push, PR creation, merge, deploy or publication.
Use to clarify WHAT a big change delivers before planning: runs a bounded Socratic loop over scope, interfaces, data, done-criteria and edge cases until the ambiguity gate passes, then writes a requirements-only SPEC.md that tk-plan builds on. Reuses a compatible native interview component for open questions only; never plans, executes or approves anything.
Use after tk-router selects model classes, on a fresh machine, or when a fleet stalls: run the bounded CLI preflight to distinguish verified model reachability, completed but unverified replies, missing harnesses and reviewer-family failure before starting 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.