analyze-plan

name	analyze-plan
description	Analyze a plan or design request until scope, decisions, dependencies, and risks are clear.

Codex invocation: use $analyze-plan or select this skill through /skills. References below to /analyze-plan describe the source repository command.

Use this command when the user needs a plan, design breakdown, or implementation approach clarified before coding.

The expected result is an actionable plan with explicit scope, decisions, dependencies, risks, open questions, and repository evidence, without implementing code or changing files.

Input

This command expects /analyze-plan <request>.

<request> can be a product idea, design question, implementation approach, technical proposal, refactor plan, or ambiguous task that needs analysis before execution.

If no request is provided, ask the user what they want to plan and stop.

Preconditions

Before producing the plan, verify that the planning scope is clear enough to distinguish analysis from implementation.

If the user asks to implement code, create issues, update docs, or open pull requests as part of this command, stop and ask whether to switch to the appropriate command or continue with planning only.

If a question can be answered from repository evidence, inspect the relevant files before asking the user.

Workflow

1. Treat $ARGUMENTS as the raw planning request.
2. Identify the main objective, intended outcome, likely boundaries, and anything explicitly out of scope.
3. Break the request into decisions, dependencies, assumptions, constraints, and risks.
4. Inspect relevant repository files and docs when they can answer an open question, validate an assumption, or reveal existing patterns.
5. Ask only the remaining clarification questions that cannot be resolved safely from repository evidence.
6. Resolve the decision tree branch-by-branch until the path forward, blockers, and unknowns are explicit.
7. Produce an actionable plan that another command or engineer can execute.
8. Stop at planning scope. Do not edit files, run mutating commands, create issues, open pull requests, or implement follow-up work unless the user explicitly changes scope after the plan is delivered.

Required output

Report:

• command result status: ready, needs_clarification, or blocked;
• shared-understanding summary;
• objective and scope boundaries;
• decisions made or inferred from repository evidence;
• dependencies, risks, blockers, and open questions;
• repository evidence consulted;
• actionable plan;
• residual risks or follow-up decisions needed before implementation.