Menú
Closure-mode discipline at workflow boundaries. Use when a sprint, phase, or vertical slice locks clean, or when a multi-candidate "what next" decision arises. Owns the closure→build transition.
Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.
| name | closure-mode-at-boundaries |
| description | Closure-mode discipline at workflow boundaries. Use when a sprint, phase, or vertical slice locks clean, or when a multi-candidate "what next" decision arises. Owns the closure→build transition. |
| disable-model-invocation | true |
The moment a phase of work finishes is exactly when you (or your agent) are most tempted to charge into the next thing without review. Nothing can be called "done" until someone has deliberately tried to break it — and you can't move to the next phase until this one is certified. That deliberate try-to-break-it pass is closure mode.
Three cognitive modes:
Closure mode is NOT continuous. It is a deliberate phase shift, invoked at completion edges, that produces an action list which the workflow MUST execute before re-entering build mode with the next vector.
Closure mode applies when ANY of these hold:
Closure mode does NOT apply mid-implementation, mid-debugging, when working a single bounded scope, or when explicitly skipped.
Two halves: a parallel SME swarm (the closure run), then a transition step that executes the swarm's output. Both required. Running only the swarm and forwarding its output as a menu IS the failure mode — see gotchas.md.
Before the first invocation, confirm your runtime and project surfaces — see prerequisites.md.
For a worked example showing both the failure case and the correct execution, see case-study.md.
For wiring closure mode into a phase-lock-style terminal step so it runs automatically at boundaries, see formalization.md.
The discipline is the stable contract:
The implementation surface is illustrative and adapts to your project:
phase-lock, post-merge CI hook, retro template, /done slash command) — see formalization.md.When adopting this skill, hold the discipline as the contract; substitute your project's implementation surface.
[ ] Prerequisites confirmed (parallel dispatch, ≥2 role-suitable agents, next-step authority identified)
[ ] Swarm dispatched in parallel (single message, multiple agent calls)
[ ] Critic specifically assigned frame-rejection ("what is MISSING?")
[ ] Verifications run (any phantom-claim, grep-checkable assertion)
[ ] Scope corrections run (audit blast radius where cost was estimated from one site)
[ ] Pre-flight requirements scheduled or executed
[ ] Dead candidates removed (do not leave for "completeness")
[ ] Missing candidates added
[ ] Revised frame presented — single pick named OR values axis named
The skill is "ready to use" in YOUR project when:
Basado en la clasificación ocupacional SOC
Decide whether a capability should become a skill. Use when asking "should this be a skill?", pruning a library, choosing skill vs CLAUDE.md vs MCP vs hook, or before building an eval instrument.
Use when dispatching parallel agents to verify/adjudicate findings — adversarial verify, security disposition, design triage, council fires. Shared disposition schema so seat outputs join cleanly.
Use before `git pull` where `pull.rebase` may be `true`. `--no-ff` does NOT stop a rebase under `pull.rebase=true` (silently ignored); it rewrites every local commit SHA. Check config first.
Framing discipline for any artifact instructing a downstream reader — handoffs, plans, ADRs, subagent prompts. Bans blanket do-not-re-litigate framing; requires per-decision Revisit-if clauses.
Reliability checks for web-research subagents. Pre-dispatch, verify the agent's tool grant actually includes web tools (else it no-ops or fabricates). Post-return, verify every citation before acting.
Verify a GitHub Pages (or any CDN-fronted) deploy actually serves new content. Poll on a marker that did not exist pre-deploy; avoid sleep-and-curl chains the agent harness blocks.
