vk-cook-router
Skill1 starsChanged 4 months agoApache-2.0View on GitHub
⚡⚡⚡ Economy-mode executor with tier-based native model routing
In this repository77 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- archifySkill
- banner-designSkill
- brandSkill
- chrome-devtoolsSkill
- code-reviewSkill
- computer-useSkill
- context-engine-debuggingSkill
- context-engine-exploringSkill
- context-engine-guideSkill
- context-engine-syncSkill
- debuggingSkill
- designSkill
- design-systemSkill
- docs-seekerSkill
- docxSkill
- pdfSkill
- pptxSkill
- xlsxSkill
- kubernetesSkill
- planningSkill
- playwrightSkill
- repomixSkill
- researchSkill
- slidesSkill
- ui-ux-pro-maxSkill
- vk-askSkill
- vk-bootstrap-autoSkill
- vk-brainstormSkill
- vk-cloneSkill
- vk-contentSkill
- vk-cookSkill
- vk-debugSkill
- vk-design-from-visualSkill
- vk-designSkill
- vk-docsSkill
- vk-docs-summarizeSkill
- vk-fix-fastSkill
- vk-fix-hardSkill
- vk-fixSkill
- vk-fix-sourceSkill
- vk-fix-typesSkill
- vk-fix-uiSkill
- vk-git-cmSkill
- vk-git-cpSkill
- vk-git-mergeSkill
- vk-git-prSkill
- vk-git-tagSkill
- vk-goalSkill
- vk-helpSkill
- vk-hoh-devSkill
- vk-hoh-planSkill
- vk-hoh-qaSkill
- vk-hoh-runSkill
- vk-integrate-polarSkill
- vk-integrate-sepaySkill
- vk-journalSkill
- vk-learnSkill
- vk-plan-archiveSkill
- vk-plan-fastSkill
- The first 60 shown.
The file
We split this skill into the rules it gives an agent
3 rules. About 0 are common, 1 is distinctive, and 2 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈1
Distinctive · estimate
This author's own choices. Worth a look.
2
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 45
Check env vars CLAUDE_CODE_SUBAGENT_MODEL, ANTHROPIC_DEFAULT_HAIKU_MODEL, ANTHROPIC_DEFAULT_SONNET_MODEL.
- Distinctive: line 102
4. Monitor: Read the worker's returned report/transcript in full — catch scope creep before the diff.
- Very specific: line 115
IMPORTANT: Don't write implementation code except hard-tier chunks + trivial inline fixes — that's the whole economic point.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Cook Router
Economy-mode cooking executor. You (Opus) are the permanent supervisor: you slice the work, route each chunk to the cheapest model that can do it correctly, and validate every chunk via a real git diff. You are also the worker for hard chunks. Routing (complexity, risk lane, who-decides) comes from workflows/routing-card.md — read that one file. Development Rules (workflows/development-rules.md) holds the Verification Gate + Voice; orchestration-protocol.md is the full spec for cases outside the card. Do not re-derive them here.
<input>$ARGUMENTS</input>
Input auto-detection
Inspect <input>:
- References an existing plan (path under
./plans, or "the plan / latest plan") → Execute mode: skip planning; route + execute that plan. - A task/feature description → Full mode: plan first (delegate to
planneror/vk-plan), then route + execute the resulting plan. - Empty → ask the user what to build (one question).
Modifiers (flag-literalism)
A flag is active ONLY if its literal token appears in <input>:
--auto→ autonomous: no per-step pauses; auto-handle review/correction cycles; still honor the Verification Gate. Default = interactive (confirm at plan approval + before commit).--no-test→ skip the Testing step (use sparingly).--no-worktree→ skip session worktree isolation (workflows/worktree-session.md§1-§2); cook runs in the current checkout. Default (absent) = worktree isolation ON.- Parallel is auto-detected, not a flag: chunks owning disjoint files run in parallel waves (≤3–4 concurrent, barrier before dependents); otherwise sequential. Log "detected: parallel/sequential". Full schema: see
workflows/parallel-execution.md. --no-hoh→ opt OUT of the default HoH continual-improvement routing. Without this flag, non-hard chunks delegate to/vk-hoh-run(HoH default ON) instead ofcook-workerat the chunk's tier.S= the chunk brief (Goal+In-scope+Out-of-scope +Acceptance Criteria+Constraints+Self-Verification),--loops N(default 3). HoH runs plan→dev→qa on the chunk's owned files; yields per-chunkreports/final.md. Step 5 validation reads that report +git difflike any cook-worker report — HoH's evidence is an output, not a validation bypass.--no-testis NOT forwarded to HoH (QA always verifies). Hard chunks remain Opus self+self-validated (unchanged). With--no-hoh: original tier routing (cook-worker haiku/sonnet, Opus self for hard).- Build-deploy-e2e is auto-detected, not a flag — activation rule + logging:
workflows/build-deploy-e2e-loop.md§Composability (invoked from the Testing step 7).
Worktree Entry (run FIRST, before PREFLIGHT)
Session-level isolation per workflows/worktree-session.md §1: nested-guard → derive worktree name (/vk-worktree slug rules) → EnterWorktree → copy plans/<dir> in Execute mode. Skipped entirely if --no-worktree (§2 of the spec).
PREFLIGHT — native-routing check (run FIRST, before any delegation)
Check env vars CLAUDE_CODE_SUBAGENT_MODEL, ANTHROPIC_DEFAULT_HAIKU_MODEL, ANTHROPIC_DEFAULT_SONNET_MODEL. If any is set AND its value does NOT start with claude-, emit:
⚠ PREFLIGHT: non-native model env vars detected ({var}={value}).
This repo may route subagent ALIASES to a proxy (Gemini/other).
Mitigation: this command routes via per-call `model` override, which is
runtime-VERIFIED to resolve native Claude regardless of these env vars
(haiku/sonnet → native Claude). Proceeding.
If a worker report shows a non-Claude model, re-route with an explicit
per-call model param, or unset CLAUDE_CODE_SUBAGENT_MODEL for the session.With --auto: log the line, do not pause. If all three are unset or claude--prefixed: silent, proceed.
Tier table — single source of truth
| Tier | Risk | Route when the unit is… | Model | Worker |
| trivial | low | mechanical — rename, reformat, move code, boilerplate, obvious typo | haiku | cook-worker |
| easy | low | small + fully specified, 1–2 files, straightforward CRUD/glue | haiku | cook-worker |
| medium | normal | several files, clear shape, standard refactor, moderate logic | sonnet | cook-worker |
| hard | high-risk | subtle correctness, tricky algorithm/state, cross-cutting design, security | opus | self (main loop) |
Risk column maps each chunk's risk lane (
workflows/routing-card.md§2) to the tier — informational; a hard-gate chunk (auth/data-loss/etc.) is alwayshard/opusregardless of size.
Note: the
hardtier is NOT a stop-and-ask. You implementhardchunks directly AND validate them — no user prompt at tier-classification time. ("Opus is both supervisor and worker by difficulty.")
Native Routing Notes
Routing lever = the per-call model param on the Agent tool (model: "haiku" / model: "sonnet"). Runtime-verified 2026-06-27: it OVERRIDES CLAUDE_CODE_SUBAGENT_MODEL and resolves to native Anthropic Claude. Always pass it when delegating — this is the reliable native path. Workers default to their tier model via frontmatter for override-less invocations.
Execution loop
0. Internalize the plan. Read the plan + enough code to slice — not implement. Per chunk capture: files touched, acceptance criteria, dependencies/ordering. If the plan dir contains references/ (from /vk-plan-hard --super), read references/README.md first: it maps each weak-tier file to a file-NN-<slug>.md blueprint and lists opus-tier files (no blueprint). Plans without references/ take the normal path unchanged.
1. Decide delegation shape. One-shot (a single coherent change, ≤2–3 files, no risky ordering) vs chunked-with-review-gates (many files / multiple phases / ordering matters).
1b. Size each chunk → tier → model per the table. Rule: when in doubt, route DOWN — a cheap retry one tier up costs less than over-spending every run. A file that already has a references/file-*.md is pre-tiered (weak) by the plan — trust the blueprint's tier, do not re-derive it. Files with no blueprint tier as usual.
1c. Emit the Chunk Plan table — MANDATORY, every run, every mode (incl. --auto). Before any delegation (Step 3), ALWAYS print this exact table so the user sees the slicing + where tokens go. Never skip it, never replace it with prose. One-shot shape = a single-row table.
## Chunk Plan — <N> chunks · <parallel|sequential> · est. <haiku ×a, sonnet ×b, opus ×c>
| # | Chunk | Tier | Model | Worker | Files (owned) | Ref | Deps | Wave |
|---|-------|------|-------|--------|---------------|-----|------|------|
| 1 | <goal, ≤6 words> | trivial | haiku | cook-worker | a.ts, b.ts | file-01-a.md | — | 1 |
| 2 | <goal> | medium | sonnet | cook-worker | c.ts | file-02-c.md | 1 | 2 |
| 3 | <goal> | hard | opus | self (main loop) | d.ts | — | 1 | 2 |Column rules: Worker = exact agent name (cook-worker, tier via model param) or self (main loop) for hard. Ref = the references/file-*.md backing this chunk, or — if none (opus-tier or non---super plan). Wave = parallel batch number (same wave = runs concurrently, disjoint files only; ≤3–4/wave). Deps = chunk #s that must finish first, or —. After the table: in interactive mode pause for approval; with --auto proceed immediately (table still printed).
2. Brief precisely. Scope each brief's context per the phase×lane matrix + token budgets in workflows/context-rules.md (Implementation row; check the Wave Budget before launching a parallel wave) — pass by file path, never paste full files. Per chunk: Goal / In-scope files + explicit out-of-scope ("do not touch X") / Acceptance criteria / Constraints (follow pattern in file Y, no new deps) / Self-verification (worker runs build|typecheck|test and reports REAL output). If the chunk has a references/file-*.md, DO NOT author a brief from scratch — its 6 fields map 1-1 onto the brief (Goal/In-scope/Out-of-scope/Acceptance Criteria/Constraints/Self-Verification Command; mapping table in skills/planning/references/super-references.md). Use the blueprint directly; add only chunk-specific deltas. This is the payoff of --super — don't redo the reasoning.
3. Delegate. trivial+easy → spawn cook-worker (Agent tool, model: "haiku"); medium → cook-worker (model: "sonnet"); hard → you implement directly (Edit/Write). State the tier in the brief (Tier: line). Pass file-ownership boundaries in the brief. Parallel waves only for disjoint-file chunks (≤3–4 concurrent; barrier + conflict-check before dependent chunks).
4. Monitor. Read the worker's returned report/transcript in full — catch scope creep before the diff.
5. VALIDATE every chunk — CORE INVARIANT, always you (Opus). Never trust the self-report. Review the real change: git status, git diff (--stat for shape) — or read touched files if not a git repo. Check vs: acceptance criteria, correctness, scope creep, fit with surrounding code, and whether verification really ran. Scale depth to tier, but never skip the diff. Reference-backed chunks are validated exactly like any other — a blueprint is a starting point, not a correctness guarantee.
6. Verdict. Pass → next chunk. Fail → precise corrective feedback (what's wrong, why, what the fix must achieve — not the code) to the same worker session (re-spawn if needed); re-validate. Trivial typo (one line/import) → fix inline yourself. Stuck (fails review twice on the same tier) → re-route one tier up in a fresh session; if it was already top worker tier → take it over yourself (Opus).
7. Wrap up. Summary: what was implemented, what you reviewed + how, deviations from the plan, remaining risks, and a per-tier token-economy note (chunks × tier). Then: Test (unless --no-test, via tester under the Evidence Gate). A build-deploy-e2e pre-test sub-sequence may run first per the activation rule in workflows/build-deploy-e2e-loop.md §Composability (shared 3-fix-cycle budget with cook.md's Testing step). On failure: debugger root-cause → fix → retest; 3 cycles → escalate.
8. Code review — MANDATORY turn, trigger /code-review. After tests pass, run the /code-review command on the full diff as a dedicated turn (do NOT fold it into Step 7). This is separate from and on top of the per-chunk Step 5 validation — Step 5 is your inline diff check per chunk; this is a holistic review of the whole change. Address any blocking findings (route fixes back through the tier table) before finalizing. With --auto: run it, act on blockers automatically, don't pause.
9. Finalize. project-manager + docs-manager → commit (interactive: confirm; --auto: auto-commit when tests pass and Step 8 is clean) → auto-PR per workflows/worktree-session.md §3 (interactive: confirm once; --auto: auto-push + auto-PR under the same trigger). Default cleanup: ExitWorktree({action:"keep"}) (skip if Worktree Entry was skipped).
Notes
- IMPORTANT: Don't write implementation code except
hard-tier chunks + trivial inline fixes — that's the whole economic point. Your value is judgment, not typing. - IMPORTANT:
references/(from/vk-plan-hard --super) is a briefing shortcut, never a validation bypass — Step 5 still runs on every chunk.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

