菜单
Coordination: Use when a task genuinely needs a compact workflow-plan.md across sessions or independent lanes. Own only the routing, handoffs, and reopen conditions needed for that coordination; Skip when one lane is sufficient or process would exist only for documentation.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Root cause: Use when a Go bug, flaky test, build failure, hang, deadlock, timeout incident, or production regression needs causal diagnosis. Own the first broken invariant and, only when authorized, the smallest causal fix and replayed proof; Skip when feature implementation, unresolved policy design, broad review, or claim-only verification is primary.
Pressure-test: Use when existing research or framing needs a few independent, discriminating questions before specification or planning. Own hidden assumptions, ownership, failure semantics, irreversible consequences, and rollout risk, plus the next owner; Skip when framing is blank, ordinary spec review is needed, or one isolated high-impact approval question is primary.
Approval question: Use when one candidate-spec decision is high-impact, hard to reverse, or explicitly challenged. Own a read-only pressure test with evidence, options, a recommended option, and decision owner; Skip when framing is blank, whole-spec review is needed, or the clarification is low-impact.
Problem frame: Use when a chosen or mostly chosen feature/refactor direction still needs an engineering-ready behavior delta, scope, constraints, assumptions, and readiness decision. Own that frame, its decided defaults, surviving user-owned questions, challenge routing, and next owner; Skip when raw ideation, final design decisions, or task breakdown is primary.
Delivery platform: Use when CI/CD gates, release trust, drift controls, containers, migrations, or rollout policy needs a decision, or when changed delivery controls need conformance review. Own delivery acceptance and review; Skip when API, data, security, reliability, or pipeline implementation is primary.
Test strategy: Use when accepted behavior needs risk scenarios, proof levels, deterministic oracles, or executable gates, or when changed tests and validation evidence need review. Own proof design and test conformance; Skip when behavior is unresolved, tests must be implemented, or completion claims need validation.
| name | workflow-planning-session |
| description | Coordination: Use when a task genuinely needs a compact workflow-plan.md across sessions or independent lanes. Own only the routing, handoffs, and reopen conditions needed for that coordination; Skip when one lane is sufficient or process would exist only for documentation. |
Must read the Artifact Model; it owns the persistence trigger, workflow-plan shape, status, and resume order. Build a control plane only when work spans sessions or independent lanes: reconstruct only the coordination state needed from canonical artifacts, current status, lane dependencies, and reopen conditions, never a second source of task decisions. Give every transition an actionable chain of custody—owner, consumed artifact/evidence, next action, produced checkpoint, next owner, and reopen condition—and disposition missing inputs as open decision, external input, or blocker. Stop when every transition is actionable or blocked by its named owner without chat archaeology.
