How to Use Claude Ultraplan for a Reviewable Plan

Claude Ultraplan is an extended planning capability in Claude Code that generates a detailed, step-by-step plan for a coding task before executing any changes. It gives you a document to review and approve, so you can catch misunderstandings before they become code changes. Tools like fenbs retain the approved plan and the decisions behind it, so the next session starts from what you agreed rather than from another blank prompt.

The value is the review step. A plan you can read is a plan you can correct. Without it, Claude moves directly from your description to code, and a misread constraint or an assumed approach is only visible after the change is already made.

How to verify that Ultraplan is available

Ultraplan availability depends on your Claude Code subscription and version. Check the Claude Code documentation↗ (opens in a new tab) for the current list of features available at each tier. If Ultraplan does not appear in your session options, the feature may require an upgrade or a specific version of Claude Code.

To confirm it is working, run it on a small, well-understood task first. If the output is a plan rather than a direct code change, Ultraplan is active. If you see code changes immediately, the feature is either unavailable or not activated in that session.

How to prepare constraints before invoking Ultraplan

Ultraplan generates a better plan when it has clear constraints upfront. Before invoking it, prepare the following.

• The goal: what the finished feature or fix should do, in one or two sentences.
• Scope boundaries: which files, directories or systems may be changed.
• Technical constraints: language version, framework, existing patterns to follow.
• Standing rules: anything that must not change, or behaviors that must be preserved.
• Acceptance criteria: how you will know the plan was executed correctly.

The more specific your constraints, the smaller the gap between the plan and what you actually want. A vague request produces a plan that looks comprehensive but assumes answers to the questions you left open.

How to review the plan Ultraplan produces

Read the plan as a proposal, not as instructions. For each step, ask whether it is scoped to the right files, whether it preserves the behaviors you specified as off limits, and whether the approach matches the patterns your codebase already uses.

Pay attention to assumptions the plan makes that you did not state explicitly. If a step says "refactor the existing service," ask yourself whether you intended a refactor or only an addition. Correct those before approving.

Record the approved plan in fenbs as the task's plan field, and note the constraints and decisions behind it in Decisions and rules. The next assistant reads both when it picks up the task, so the reasoning is available even if you are not.

Running the plan and handling deviations

Once you approve the plan, allow Ultraplan to execute it step by step. If it asks for confirmation at a step, read the proposed action before approving. If it produces something that differs from the plan, stop and diagnose before continuing.

A deviation is usually a signal that the plan contained an ambiguity. Correct the plan rather than the code, so the remaining steps stay aligned with the revised intent. If the deviation was minor and acceptable, note it in the task so the next session knows.

Iterating on the plan if the first version misses

The first Ultraplan result is rarely the final plan. If the plan misses an important constraint or proposes an approach you did not intend, do not accept it and correct later. Reject it, update the constraints, and generate again. Each iteration should narrow the gap between the plan and what you actually need.

When the same misunderstanding appears in multiple iterations, the problem is usually in how you stated the constraints rather than in the planner. Rephrase the ambiguous constraint as an explicit rule: "do not modify files outside the src/payments directory" is more actionable than "keep the scope narrow." The more specific the input, the more reliably the plan reflects your intent.

When Ultraplan is not the right approach

Ultraplan is most useful for tasks that are large enough that an unreviewed approach could lead to significant rework. For a small, well-understood change in a familiar codebase, the planning step adds overhead without proportionate benefit.

It is also not a replacement for tests or human review of the result. Use Ultraplan to agree on the approach; use your normal verification process to confirm the implementation.

How to do this with fenbs

1. Create a free account and add the project. Write standing constraints and approved patterns as Decisions and rules so every connected session reads them first.
2. Add a task for the feature or fix. Leave the plan field empty until Ultraplan produces a plan you have reviewed and approved.
3. Connect Claude Code over MCP from Integrations. Ask it to read the project context, then invoke Ultraplan with your prepared constraints.
4. Review the generated plan. Update the task's plan field with the approved version and record any decisions made during the review in Decisions and rules.
5. After execution, update the task with what was completed and what was verified. If the execution deviated from the plan in a way worth remembering, add a Lessons learned entry.