메뉴
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.
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 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 starting any non-trivial repo task: pick Light / Standard / Heavy tier, then self-select meaning skills — not a fixed pipeline.
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-decide |
| description | 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. |
Align before you build. Standard stays short; Heavy earns pressure-test. No mandatory brainstorm→grill→plan chain.
Leading words: grill, tracer bullet, path map.
| Mode | When |
|---|---|
| Grill | Heavy default; Standard only if a load-bearing premise or user preference gates the route |
| Diverge | Requirement or architecture shape is genuinely unclear |
| Plan card | Handoff, multi-step Standard, or Heavy needs durable acceptance/verify notes |
| Slice | More than one independently deliverable unit |
Skip for Light mechanical work and pure questions.
Interview relentlessly on decisions; never on readable facts.
path:line) before asking.Fresh-context challenge applies in-flight too: doubt the route while deciding, not only the finished diff.
Surface real alternatives (skip → stdlib/native → existing → minimal custom). Do not invent fog. Hand route-changing choices to grill.
For a new dependency, datastore, framework/runtime, protocol, or other permanent external surface: inspect repository constraints, compare at least two viable candidates, and record compatibility, maintenance/activity, license, operational fit, and a recommendation. Ask the user only when a preference changes the selected route; never memory-pick a permanent dependency. Cite primary sources (official docs, the source repo) over summaries; when findings are durable, capture them in the worklog or handbook instead of re-researching next session.
Only fields that change execution:
../references/workflow-kernel.mdDurable file only when another session or worker must read it.
Thin vertical tracer bullets. Each slice: ownership, deps, acceptance, AFK/HITL. Parallel only with disjoint writes. Parent owns shared files and integration.
Pause when preference gates the route. Do not expand scope silently.