plan
Strategic planning with optional interview workflow
>_
Quick Installnpxskills add yeachan-heo/oh-my-claudecode--skill planInstructions
Loading…
Tags & Topics
agentic-codingai-agentsclaudeclaude-codeoh-my-opencodeopencode
Strategic planning with optional interview workflow
npxskills add yeachan-heo/oh-my-claudecode--skill planLoading…
<Use_When>
--review--consensus, "ralplan"<Do_Not_Use_When>
autopilot insteadralph or delegate to executor<Why_This_Exists> Jumping into code without understanding requirements leads to rework, scope creep, and missed edge cases. Plan provides structured requirements gathering, expert analysis, and quality-gated plans so that execution starts from a solid foundation. The consensus mode adds multi-perspective validation for high-stakes projects. </Why_This_Exists>
<Steps> <Examples> <Good> Adaptive interview (gathering facts before asking): ``` Planner: [spawns explore agent: "find authentication implementation"] Planner: [receives: "Auth is in src/auth/ using JWT with passport.js"] Planner: "I see you're using JWT authentication with passport.js in src/auth/. For this new feature, should we extend the existing auth or add a separate auth flow?" ``` Why good: Answers its own codebase question first, then asks an informed preference question. </Good> <Good> Single question at a time: ``` Q1: "What's the main goal?" A1: "Improve performance" Q2: "For performance, what matters more -- latency or throughput?" A2: "Latency" Q3: "For latency, are we optimizing for p50 or p99?" ``` Why good: Each question builds on the previous answer. Focused and progressive. </Good> <Bad> Asking about things you could look up: ``` Planner: "Where is authentication implemented in your codebase?" User: "Uh, somewhere in src/auth I think?" ``` Why bad: The planner should spawn an explore agent to find this, not ask the user. </Bad> <Bad> Batching multiple questions: ``` "What's the scope? And the timeline? And who's the audience?" ``` Why bad: Three questions at once causes shallow answers. Ask one at a time. </Bad> <Bad> Presenting all design options at once: ``` "Here are 4 approaches: Option A... Option B... Option C... Option D... Which do you prefer?" ``` Why bad: Decision fatigue. Present one option with trade-offs, get reaction, then present the next. </Bad> </Examples> <Advanced> ## Design Option Presentation<Execution_Policy>
explore agent before asking the user about them--interactive to enable user prompts at draft review and final approval steps--deliberate or when the request explicitly signals high risk (auth/security, data migration, destructive/irreversible changes, production incident, compliance/PII, public API breakage)pending approval unless the user has explicitly opted into execution in the current turn or via the structured approval UI. Before explicit execution approval, planning modes MUST NOT run mutation-oriented shell commands, edit source files, commit, push, open PRs, invoke execution skills, or delegate implementation tasks./goal, Ralph, Team, UltraQA, or artifact-only Ultragoal, identify exactly one primary loop authority and use the deterministic conflict policies refuse, adopt_existing, and artifact_only rather than non-deterministic warning handling. /goal facts must cite Claude Code/Anthropic sources only (Claude Code /goal docs: https://code.claude.com/docs/en/goal; Anthropic Claude Code changelog: https://raw.githubusercontent.com/anthropics/claude-code/main/CHANGELOG.md), and plans MUST NOT claim the /goal evaluator independently runs commands or reads files; require surfaced proof evidence before any completion claim.docs/shared/mode-selection-guide.md#goal-oriented-workflow-selection and docs/REFERENCE.md#goal-workflow-ux-goal-ralph-team-ultraqa-ultragoal.
</Execution_Policy>| Mode | Trigger | Behavior |
|---|---|---|
| Interview | Default for broad requests | Interactive requirements gathering |
| Direct | --direct, or detailed request | Skip interview, generate plan directly |
| Consensus | --consensus, "ralplan" | Planner -> Architect -> Critic loop until agreement with RALPLAN-DR structured deliberation (short by default, --deliberate for high-risk); add --interactive for user prompts at draft and approval steps |
| Review | --review, "review this plan" | Critic evaluation of existing plan |
AskUserQuestion for preferences, scope, and constraintsexplore agent to find out, then ask informed follow-up questions--consensus / "ralplan")RALPLAN-DR modes: Short (default, bounded structure) and Deliberate (for --deliberate or explicit high-risk requests). Both modes keep the same Planner -> Architect -> Critic sequence and the same AskUserQuestion gates.
Provider overrides (supported when the provider CLI is installed):
--architect codex — replace the Claude Architect pass with omc ask codex --agent-prompt architect "..." for implementation-heavy architecture review--critic codex — replace the Claude Critic pass with omc ask codex --agent-prompt critic "..." for an external review pass before executionState lifecycle: The persistent-mode stop hook uses ralplan-state.json to enforce continuation during the consensus loop. The skill MUST manage this state:
state_write(mode="ralplan", active=true, session_id=<current_session_id>) before step 1state_write(mode="ralplan", active=false, session_id=<current_session_id>). Do NOT use state_clear here — state_clear writes a 30-second cancel signal that disables stop-hook enforcement for ALL modes, leaving the newly launched execution mode unprotected.state_clear(mode="ralplan", session_id=<current_session_id>) — no execution mode follows, so the cancel signal window is harmless.Without cleanup, the stop hook blocks all subsequent stops with [RALPLAN - CONSENSUS PLANNING] reinforcement messages even after the consensus workflow has finished. Always pass session_id to avoid clearing other concurrent sessions' state.
--interactive, MUST use AskUserQuestion to present the draft plan plus the RALPLAN-DR Principles / Decision Drivers / Options summary for early direction alignment with these options:
--interactive, automatically proceed to review (step 3).Task(subagent_type="oh-my-claudecode:architect", ...). Architect review MUST include: strongest steelman counterargument (antithesis) against the favored option, at least one meaningful tradeoff tension, and (when possible) a synthesis path. In deliberate mode, Architect should explicitly flag principle violations. Wait for this step to complete before proceeding to step 4. Do NOT run steps 3 and 4 in parallel.Task(subagent_type="oh-my-claudecode:critic", ...). Critic MUST verify principle-option consistency, fair alternative exploration, risk mitigation clarity, testable acceptance criteria, and concrete verification steps. Critic MUST explicitly reject shallow alternatives, driver contradictions, vague risks, or weak verification. In deliberate mode, Critic MUST reject missing/weak pre-mortem or missing/weak expanded test plan. Run only after step 3 is complete.AskUserQuestion with note that expert consensus was not reached.omc/plans/ with the accepted improvements (add missing details, refine steps, strengthen acceptance criteria, ADR updates, etc.)
d. Note which improvements were applied in a brief changelog section at the end of the planpending approval unless explicit execution approval has already been captured. (--interactive only) If running with --interactive, use AskUserQuestion to present the plan with these options:
/team). Team is the canonical orchestration surface since v4.1.7.--interactive, output the final plan marked pending approval, call state_clear(mode="ralplan", session_id=<current_session_id>), and stop. Do NOT auto-execute.AskUserQuestion UI (never ask for approval in plain text). If user selects Reject, call state_clear(mode="ralplan", session_id=<current_session_id>) and stop.state_write(mode="ralplan", active=false, session_id=<current_session_id>) before invoking the execution skill (ralph/team), so the stop hook does not interfere with the execution mode's own enforcement. Do NOT use state_clear here — it writes a cancel signal that disables enforcement for the newly launched mode.
Skill("oh-my-claudecode:team") with the approved plan path from .omc/plans/ as context. Do NOT implement directly. The team skill coordinates parallel agents across the staged pipeline for faster execution on large tasks. This is the recommended default execution path.Skill("oh-my-claudecode:ralph") with the approved plan path from .omc/plans/ as context. Do NOT implement directly. Do NOT edit source code files in the planning agent. The ralph skill handles execution via ultrawork parallel agents.Skill("compact") to compress the context window (reduces token usage accumulated during planning), then return with the saved pending-approval plan path and require a fresh explicit execution approval before any ralph/team launch. This path is recommended when the context window is 50%+ full after the planning session.--review).omc/plans/Task(subagent_type="oh-my-claudecode:critic", ...)Every plan includes:
Plans are saved to .omc/plans/. Drafts go to .omc/drafts/.
</Steps>
<Tool_Usage>
AskUserQuestion for preference questions (scope, priority, timeline, risk tolerance) -- provides clickable UIexplore agent (Haiku, 30s timeout) to gather codebase facts before asking the userTask(subagent_type="oh-my-claudecode:planner", ...) for planning validation on large-scope plansTask(subagent_type="oh-my-claudecode:analyst", ...) for requirements analysisTask(subagent_type="oh-my-claudecode:critic", ...) for plan review in consensus and review modes--deliberate or explicit high-risk signals (auth/security, migrations, destructive changes, production incidents, compliance/PII, public API breakage)--interactive: use AskUserQuestion for the user feedback step (step 2) and the final approval step (step 7) -- never ask for approval in plain text. Without --interactive, skip both prompts, mark the plan pending approval, output the final plan, and stop.--interactive, on explicit user approval MUST invoke Skill("oh-my-claudecode:ralph") or Skill("oh-my-claudecode:team") for execution (step 9) -- never implement directly in the planning agentpending approval, call state_write(mode="ralplan", active=false, current_phase="pending_approval", session_id=<current_session_id>), then invoke Skill("compact") to compress the accumulated planning context. After compact, require a fresh explicit execution approval before any ralph/team launch; never auto-start implementation from compact continuationstate_write(active=false) for handoff paths (approval → ralph/team) and state_clear for true terminal exits (rejection, error). Never use state_clear before launching an execution mode — its cancel signal disables stop-hook enforcement for 30 seconds.
</Tool_Usage><Escalation_And_Stop_Conditions>
--interactive outputs the final plan marked pending approval and stops; with --interactive, requires explicit user approval before any implementation begins. Always call state_clear(mode="ralplan", session_id=<current_session_id>) before stopping.pending approval and ask for explicit execution approval via the structured approval UI. Do NOT invoke Skill("oh-my-claudecode:ralph"), mutate files, delegate implementation, commit, push, or open a PR from the planning module until that approval exists.<Final_Checklist>
.omc/plans/--interactive: user explicitly approved before any execution; without --interactive: plan output marked pending approval only, no auto-executionstate_write(active=false) for handoff to execution, state_clear for terminal exits (rejection, error, non-interactive stop)
</Final_Checklist>When presenting design choices during interviews, chunk them:
Format for each option:
### Option A: [Name]
**Approach:** [1 sentence]
**Pros:** [bullets]
**Cons:** [bullets]
What's your reaction to this approach?
Before asking any interview question, classify it:
| Type | Examples | Action |
|---|---|---|
| Codebase Fact | "What patterns exist?", "Where is X?" | Explore first, do not ask user |
| User Preference | "Priority?", "Timeline?" | Ask user via AskUserQuestion |
| Scope Decision | "Include feature Y?" | Ask user |
| Requirement | "Performance constraints?" | Ask user |
| Criterion | Standard |
|---|---|
| Clarity | 80%+ claims cite file/line |
| Testability | 90%+ criteria are concrete |
| Verification | All file refs exist |
| Specificity | No vague terms |
The separate /planner, /ralplan, and /review skills have been merged into /plan. All workflows (interview, direct, consensus, review) are available through /plan.
</Advanced>
Create or update AgentSkills. Use when designing, structuring, or packaging skills with scripts, references, and assets.
Create or update AgentSkills. Use when designing, structuring, or packaging skills with scripts, references, and assets.
Set up and use 1Password CLI (op). Use when installing the CLI, enabling desktop app integration, signing in (single or multi-account), or reading/injecting/running secrets via op.
CLI to manage emails via IMAP/SMTP. Use `himalaya` to list, read, write, reply, forward, search, and organize emails from the terminal. Supports multiple accounts and message composition with MML (MIME Meta Language).
Create or update AgentSkills. Use when designing, structuring, or packaging skills with scripts, references, and assets.
Create or update AgentSkills. Use when designing, structuring, or packaging skills with scripts, references, and assets.
Set up and use 1Password CLI (op). Use when installing the CLI, enabling desktop app integration, signing in (single or multi-account), or reading/injecting/running secrets via op.
CLI to manage emails via IMAP/SMTP. Use `himalaya` to list, read, write, reply, forward, search, and organize emails from the terminal. Supports multiple accounts and message composition with MML (MIME Meta Language).