create-plan-v5

---
description: Create a comprehensive task plan from an exported conversation between a user and an LLM
argument-hint: CONVERSATION=<exported-conversation-text>
---
 
<conversation>
$CONVERSATION
</conversation>

# Create Plan From Conversation (slash command) create-plan_v5

Goal: infer the user’s underlying needs and the assistant’s recommendations from an exported conversation, then draft a confident, implementation-ready task plan in `docs/tasks/todo/<XX>-<name>.md`.

Always do this first:

* Repository vs. conversation source of truth:

  * The exported conversation comes from an LLM that did not have direct access to this repository. Treat it as a high-level description of user intent and prior reasoning, not as an authoritative spec of the current codebase, architecture, or constraints.
  * As the CLI agent with full access to the codebase and tooling, always inspect the actual repository (code, configuration, docs, tests) relevant to the conversation before finalizing the plan.
  * Do not assume that any file paths, module names, interfaces, or behaviors described in the conversation exist or are accurate. Verify them directly in the repository.
  * When the conversation’s claims about the system conflict with the repository, treat the repository as canonical. Adjust and strengthen the plan based on the real code, and briefly capture key discrepancies in the Context, Approach, or Risks / unknowns sections.
  * Prefer plans that extend, refactor, or integrate with existing code over plans that introduce parallel or redundant implementations implied by the prior LLM’s responses. Avoid adding new abstractions or layers solely to mirror assumptions in the exported conversation.
  * Use the conversation to decide what the user is trying to achieve and which directions have already been explored; use the repository to decide how to achieve it with minimal, coherent changes and without unnecessary bloat.

* Read `AGENTS.md` and follow all rules and constraints.
* Read `skill-usage.md` and obey its rules for selecting and applying Codex skills based on the type of work implied by the conversation.
* Read the entire conversation from start to finish.
* Infer the stable problems, goals, and constraints that persist across turns.
* Infer the main recommendations, patterns, and decisions suggested by the assistant.
* Decide whether the dominant work is:

  * UI/frontend (layouts, components, visual design, UX), or
  * Logic/backend (features, workflows, integrations, infra, docs), or
  * Mixed.
* For UI/frontend-heavy work, interpret the task under `AGENTS.md` and apply the `codex-skills/frontend-design/SKILL.md` guidance when shaping the plan’s approach, deliverables, and quality bar.
* For logic/backend-heavy work, scan `codex-skills/` and align the plan with the most relevant skill’s doctrine and structure (tests, refactors, planning, problem analysis, PRD generation, etc.), resolving any conflict in favor of `AGENTS.md` and solid, well-supported practices.
* Use all available tools (documentation search, code search, prior notes, web search, or other integrations in this environment) to fill gaps, resolve ambiguities, and align with current best practices.

Your job:

* Synthesize what the user is actually trying to achieve across the entire conversation, not just the last turn.
* Synthesize what the assistant was trying to recommend, including partial plans and implied decisions.
* Cross-check both against applicable Codex skills, project documentation, standards, and best practices, updating and strengthening the plan where needed.
* When user intuition conflicts with clear best practices or governing rules, favor the best-practice path and state the rationale briefly.
* Produce a single, coherent plan that stands on its own and can be executed with minimal additional user input.

Plan requirements (concise and qualitative, but complete):

* Context: concise recap of the core problem, goals, and any critical background inferred from the conversation and supporting materials.
* Success criteria / acceptance: conditions that, if met, mean the plan has succeeded; tie these to the user’s goals and the validated best practices you applied.
* Deliverables: tangible outcomes to produce (code, UX/behavior changes, documents, refactors, processes, tests, or other artifacts).
* Approach: ordered outline of how to move from current state to the desired end state, using clean, maintainable solutions rather than temporary workarounds.
* Risks / unknowns: important uncertainties, dependencies, tradeoffs, and any places where you had to choose a direction among plausible options.
* Testing & validation: how to check that the work meets the success criteria (flows, behaviors, checks, or reviews appropriate to the context).
* Rollback / escape hatches: how the system, process, or plan can be reverted, paused, or safely adjusted if outcomes are not acceptable.
* Owner / date: responsible role or team label, and today’s date.

Constraints:

* Work primarily from the conversation plus the additional information you can obtain via tools, skills, and documentation; do not rely on the user to fill in details you can reasonably look up or infer.
* Combine overlapping or fragmented points into a single coherent picture; avoid repeating the same issue in different words.
* Do not quote the conversation at length unless it is necessary; focus on intent, decisions, and implications.
* Assume a position of expert guidance: be decisive, specific, and opinionated, grounded in skills and references rather than user guesswork.

After writing the plan:

* Save at path `docs/tasks/todo/<XX>-<name>.md`.
* Use the same tools, Codex skills, and references to resolve any remaining uncertainties as far as possible.
* Only when a critical detail is genuinely unknowable from the conversation and accessible resources, add a short “Assumptions / open points” list at the end of the plan, written as declarative statements that you are proceeding with.
* Do not append long lists of clarifying questions for the user; rely on investigation, inference, and best practices instead.

Suggested prompt body:

```md
Context
- ...

Success criteria / acceptance
- ...

Deliverables
- ...

Approach
1) ...
2) ...
3) ...

Risks / unknowns
- ...

Testing & validation
- ...

Rollback / escape hatch
- ...

Owner / date
- <role or team> / <YYYY-MM-DD>

Assumptions / open points
- ...
```

Reminder:

* No workarounds or half measures; design for long-term maintainability.
* Default to authoritative, evidence-backed recommendations rooted in `AGENTS.md`, `skill-usage.md`, and the most relevant Codex skills.
* Prefer resolving ambiguity through tools, documentation, and best practices rather than asking the user for more input.
* Make the plan self-contained so it can be executed without further clarification whenever reasonably possible.
- Do NOT ask additional follow-up questions unless a missing detail blocks safe implementation.
- If details are still unknown, choose conservative defaults, list them as Assumptions, and proceed.
- Begin implementing the plan immediately in the repo (apply code changes + tests).
- Recognize `CODEX_QA_HANDOFF: READY` as the signal that answers are complete and implementation must start.