git:20260808.2008cd8 to git:20260906.9af3950

1 added, 1 removed. Audit A to A.

---

name: deep-planning

- description: Use when Codex is in Plan Mode for architectural or high-risk work; when reviewing a plan before coding; or when the user asks to think deeply, challenge assumptions, or do adversarial planning. Do not use merely because work has multiple steps, or for tiny edits, simple command-output checks, pure execution, or post-code verification.

+ description: "Use for architectural or high-risk Plan Mode work, explicit plan critique, or adversarial planning. Skip ordinary multi-step work and execution-only requests."

---

# Deep Planning

Use this skill to raise Plan Mode quality before a plan is accepted. It is an

adversarial critique gate, not an execution workflow.

## Boundaries

- Do not edit or write files, create issues, dispatch workers, refresh

schedulers, mutate external systems, or run implementation steps from this

skill.

- Keep the critique in the response; do not create persistent planning or

design artifacts.

- For ordinary multi-step work, tiny edits, simple command-output checks, pure

execution, or post-code verification, skip the full protocol and use normal

Codex behavior.

## Protocol

1. **Ground the plan.** Gather observed facts before asking questions. Read the

minimal files, docs, memory, or tool output needed to avoid guessing.

2. **Name assumptions and unknowns.** Separate observed facts from assumptions.

Ask only material questions whose answers would change architecture, scope,

risk, or routing.

3. **Draft the strongest plan.** Prefer a simple, surgical plan with explicit

goals, non-goals, constraints, affected surfaces, and verification.

4. **Run adversarial review.** Challenge the draft across the review axes

below. Assume the plan is wrong somewhere and find where.

5. **Revise or block.** Fix the plan inline when the answer is inferable. Ask

the user only when a material unknown remains.

6. **Route execution.** End by choosing the next lane: Codex-only, native Codex

subagents, or OpenSpec.

## Adversarial Review Axes

- **Product value:** Does the plan solve the real user goal, or only the stated

implementation idea? What would be wasteful?

- **Architecture:** Are boundaries, dependencies, data flow, and ownership

coherent with the existing system?

- **Implementation risk:** What is likely to fail first? Which assumptions are

brittle, expensive, or hard to reverse?

- **Edge cases:** What missing states, permissions, concurrency, migration, or

platform cases could break the plan?

- **Tests:** What failing test or deterministic check proves the plan is right?

What evidence would be weak or misleading?

- **Rollout:** How will the change be introduced, verified, reverted, or

handed off without surprising the user?

- **Scope:** What should be cut, deferred, or split so the plan stays small and

reviewable?

## Routing

- **Codex-only:** Use for tiny edits, one bugfix, one review, fast debugging,

or single-session exploration.

- **Native Codex subagents:** Use when the revised plan has independent,

testable subtasks that can run in parallel within the current task.

- **OpenSpec:** Use when the work benefits from durable requirements,

acceptance criteria, or multi-agent/spec governance before implementation.

## Output Contract

For non-trivial Plan Mode work, use this exact section sequence unless the

current conversation format requires something stricter. Do not skip

**Strongest Plan** even when the revised plan is similar; the critique needs a

clear target.

- **Observed Facts:** Brief source-backed facts gathered before planning.

- **Assumptions / Unknowns:** Assumptions you are making and any material

question that remains.

- **Strongest Plan:** The best current plan before critique.

- **Adversarial Review:** The most important objections and failure modes.

- **Revised Plan / Routing:** The final plan and the chosen execution lane.

For tiny Plan Mode prompts, keep the answer short and skip formal sections.