القائمة
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.