メニュー
Use when starting any non-trivial repo task: pick Light / Standard / Heavy tier, then self-select meaning skills — not a fixed pipeline.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Use when writing or designing code: name premise and blast radius, deepen modules at seams, TDD at agreed seams, diagnose before patching, and keep producer→consumer contracts honest.
Use when premises or options must be pressure-tested, a short plan/handoff is needed, or a large plan must be sliced — grill facts locally, ask decisions one at a time.
Use when a project needs a lean `.do-it/handbook/` for stable project truth plus `.do-it/worklog/` for daily or goal notes.
Use before any done, fixed, passing, ready, install, or merge claim, and when closing a branch — fresh evidence on this worktree; hooks vary by host, this skill is the checklist.
Use only when the user explicitly asks to enable, disable, inspect, report, or persist opt-in local do-it behavioral feedback.
Use when repo terms or invariants are drifting, or when user/docs/code naming disagrees and a canonical glossary is needed — `.do-it/CONTEXT.md` is the downstream source of truth for names, relationships, and facts.
| name | do-it-router |
| description | Use when starting any non-trivial repo task: pick Light / Standard / Heavy tier, then self-select meaning skills — not a fixed pipeline. |
Autonomy first. Choose the smallest useful tier, skills, and workers for the task at hand; there is no mandatory skill chain or delegation pipeline.
A tier is an advisory risk label, not a permission gate. Direct user intent
and the model's reading of the task take precedence over keyword classification.
Use do-it-decide only when a premise, option, or handoff genuinely needs
pressure. Prefer Light when blast radius is local.
| Tier | Meaning |
|---|---|
| Light | Small, mechanical, docs-only, or genuinely informational. Inspect → act → targeted check. |
| Standard | Real behavior or design change. Self-select buckets — never brainstorm→grill→plan by default. |
| Heavy | Cross-boundary, interface/release/security/migration, or irreversible closeout. Delegation can be useful at any tier when the task benefits. |
Do not use an optimistic tier label to downplay a known risk.
| Bucket | Skill | Load when |
|---|---|---|
| Write defense | do-it-code-quality | Editing or designing code |
| Review / repair | do-it-review | Diff needs correctness; findings need fix + re-review |
| Decide | do-it-decide | Premises load-bearing, options unclear, or a plan/handoff is needed |
| Verify / close | do-it-verify | Before done/fixed/ready/merge; branch closeout |
| Persistence | do-it-handbook, do-it-context | Project truth missing or glossary drift |
Refs (load on demand): scope-chain.md, workflow-kernel.md, write-quality-families.md, dimensions.md.
The parent owns integration. Delegate only when an independent slice materially
improves exploration or review coverage, especially after a direct user request.
Give a worker the goal, its boundary/ownership, and the result or evidence that would
be useful; add more context only when the task needs it. For shared writes, name
one owner. Do not require a fixed contract, agent count, or role matrix. Shared delegation guidance:
workflow-kernel.md.
One line: tier + next action.
