feat: add plan mode by vadiminshakov · Pull Request #2822 · charmbracelet/crush

vadiminshakov · 2026-05-06T22:10:47Z

[+] I have read CONTRIBUTING.md.
[+/-] I have created a discussion that was approved by a maintainer (for new features).

Resolve feature request #1734

Let's plan!

charmcli · 2026-05-06T22:11:05Z

All contributors have signed the CLA ✍️ ✅
_{Posted by the CLA Assistant Lite bot.}

vadiminshakov · 2026-05-06T22:17:41Z

I have read the Contributor License Agreement (CLA) and hereby sign the CLA.

vadiminshakov · 2026-05-06T22:17:57Z

recheck

oiwn · 2026-05-13T05:07:27Z

What's up? What's prevent this from merging?

dcu · 2026-05-19T23:45:39Z

+6. once all required questions are answered and no further investigation is needed, ask the user to switch to code mode and confirm the plan.
+</critical_rules>
+
+<workflow>


can you add a rule to present trade offs and risks?

present trade-offs, risks, and alternatives for non-trivial decisions.

make sense, added

dcu · 2026-05-20T04:40:27Z

+	t := m.com.Styles
+	if info.LineNumber == 0 {
+		if info.Focused {
+			return "[plan] > "


I don't like much how this looks, any other alternatives?

we can move it to the status bar

hey my friend, recently yolo mode was introduced in master and it includes its own badge at the prompt, I think we should adopt it, maybe keep both

I’m not sure the plan needs a badge as well

dcu · 2026-05-20T12:33:35Z

+</critical_rules>
+
+<workflow>
+1. explore the codebase and gather relevant context.


I was thinking about these guard rails:

Deeply analyze the repository to understand existing norms, structures and baseline conditions.

Pinpoint analogous functionalities and structural designs within the project.

Evaluate various potential solutions, weighing the pros and cons of each.

Assess potential risks, edge cases, and failure modes.

I'm testing them...

dcu · 2026-05-22T09:24:22Z

hey Vadim, great work!

have you thought about having a tool to start the plan and, one to finish, present and ask for approval or feedback?

vadiminshakov · 2026-05-22T09:51:16Z

@dcu yes, I mentioned this in the discussion: #2947

We do need a question tool so that the model can ask questions during planning when needed. But I saw that this tool had already been discussed earlier in the project, so I didn’t want to bundle two features into a single request.

If you think adding question is acceptable, I can hide plan behind an experimental flag in the current request and add question in a separate request. What do you think?

dcu · 2026-05-22T10:55:35Z

+</critical_rules>
+
+<workflow>
+1. deeply analyze the repository to understand existing norms, structures and baseline conditions.


I'm getting much better results with these rules although it spends more tokens:

1. thoroughly explore the codebase using read-only tools 2. understand existing patterns and architecture 3. pinpoint analogous functionalities and structural designs within the project. ...

dcu · 2026-05-22T11:04:35Z

+</workflow>
+
+<style>
+- be concise and precise.


consider these rules:

<style> - Deliver exact, accurate technical details while ruthlessly eliminating filler words and unnecessary jargon. - Ensure all technical mechanisms, dependencies, and edge cases are factual and thoroughly accounted for, without sacrificing readability. - Avoid asking open-ended questions for information that can be verified directly from the code. - If the code is ambiguous or lacks context, do not guess; state your technical inference as an explicit assumption for the user to validate. - Explain the technical plan by deconstructing it into three distinct layers: the Purpose (Why), the Change (What), and the Impact (So What). </style>

Ideally we need a tool to ask to the user...

Replaced style guidelines

Ideally we need a tool to ask to the user...

I suggest adding the question tool separately, since it will involve a lot of UI work that will need to be discussed separately. I can contribute this tool very soon.

vadiminshakov · 2026-05-22T13:21:53Z

@dcu question PR is here now #2980

After the merge, we’ll be able to integrate this into plan mode easily (in this pr or another, I’ll pick it up)

dcu · 2026-05-22T16:14:46Z

there's a bug I just noticed when you are writing something in the prompt and press shift + tab the cursor acts up

vadiminshakov · 2026-05-22T17:38:01Z

there's a bug I just noticed when you are writing something in the prompt and press shift + tab the cursor acts up

fixed

dcu · 2026-05-23T23:05:20Z

I ran a test with both claude code and crush using the same model (kimi k2.6) and the results are pretty different, this is the verdict:

   ## Verdict

   Claude Code is stronger on user-facing API ergonomics, naming, documentation consistency, and example quality.
   It identified concrete bugs (MCP ordering, SetupAgents destructive behavior) and design friction points
   (pointer return, free functions vs methods).

   Crush is stronger on API boundary hygiene and internal dependency leaks. It correctly identified that several
   App  methods expose bubbletea/internal types, making them unusable from external code.

   They are complementary. Merge both lists: ~18 distinct issues total, with only the goroutine leak overlapping.

Claude identified more unique issues (13 vs 8). it also took more time exploring

dcu · 2026-05-24T01:14:50Z

I ran a test with both claude code and crush using the same model (kimi k2.6) and the results are pretty different, this is the verdict:

   ## Verdict

   Claude Code is stronger on user-facing API ergonomics, naming, documentation consistency, and example quality.
   It identified concrete bugs (MCP ordering, SetupAgents destructive behavior) and design friction points
   (pointer return, free functions vs methods).

   Crush is stronger on API boundary hygiene and internal dependency leaks. It correctly identified that several
   App  methods expose bubbletea/internal types, making them unusable from external code.

   They are complementary. Merge both lists: ~18 distinct issues total, with only the goroutine leak overlapping.

Claude identified more unique issues (13 vs 8). it also took more time exploring

#2989 improves significantly the plan in my case if you want to test

dcu · 2026-05-24T04:47:24Z

@vadiminshakov test this tpl when you can

You are Crush in plan mode — an expert architect, senior UX designer, and planning specialist with meticulous attention to detail.

Your job is to analyze the codebase and user intent, then produce a concrete, actionable implementation plan without modifying files or running state-changing commands.

<critical_rules>
These rules override everything else. Follow them strictly:

1. do not modify files, create files, delete files, or run write operations.
2. do not execute commands that can change system state.
3. delegation to sub-agents is allowed for deeper codebase exploration only.
4. provide the most complete analysis possible for the user's request before proposing implementation steps.
5. ask clarifying questions only when they are strictly necessary to produce a correct implementation plan.
6. once all required questions are answered and no further investigation is needed, ask the user to switch to code mode and confirm the plan.
</critical_rules>

<workflow>
1. decompose the request into independent exploration threads (e.g., architecture, analogous features, tests, config, documentation, user-facing touchpoints)
2. launch multiple `agent` tool calls in parallel for independent searches; use direct `glob`, `grep`, `ls`, and `view` only for simple, targeted lookups you can resolve in one or two calls
3. synthesize findings: existing patterns, analogous functionality, structural designs, and dependencies relevant to the request
4. critically review the synthesis — identify gaps, contradictions, unverified assumptions, and areas not yet explored; run additional targeted `agent` calls or direct reads to close gaps; repeat until confident nothing material is missing
5. assess potential risks, edge cases, failure modes, and pre-existing issues in touched areas; do not expand scope beyond what informs the plan
6. produce a concrete, actionable implementation plan
7. if needed, ask only clarifying questions required to unblock the plan
8. when the plan is ready and complete, explicitly request:
   - switch to code mode
   - confirmation to execute the plan
</workflow>

<style>
- Deliver exact, accurate technical details while ruthlessly eliminating filler words and unnecessary jargon.
- Ensure all technical mechanisms, dependencies, and edge cases are factual and thoroughly accounted for, without sacrificing readability.
- Avoid asking open-ended questions for information that can be verified directly from the code.
- If the code is ambiguous or lacks context, do not guess; ask the user.
- Explain the technical plan by deconstructing it into three distinct layers: the Purpose (Why), the Change (What), and the Impact (So What).
- Never ask the user what you could discover by reading the code, running tests, or checking documentation.
- When evaluating a public API, ask: "Could an external caller use this correctly without reading the source?"
- When you find a design choice (unclear ownership semantics, standalone function, exposed internal type), evaluate whether it was intentional or accidental.
- When the change touches user-facing behavior, describe the intended user flow, interaction states, and failure/empty states before listing implementation steps.
- When the change touches APIs or data models, evaluate ergonomics for callers and consumers: naming, defaults, error surfaces, and whether the design matches existing project patterns.
- After synthesizing exploration results, explicitly list what remains unknown or unverified before proceeding; do not draft the plan until those gaps are closed or stated as assumptions.
</style>

### Critical Files for Implementation
List 3-5 files most critical for implementing this plan:
- path/to/file1
- path/to/file2
- path/to/file3

vadiminshakov · 2026-05-24T06:47:10Z

@dcu added your prompt. I think manual model benchmarks rely on subjectivity one way or another and are not deterministic. But I think this makes sense as part of unifying it with the changes you’re proposing in the other pull request

…sion

…ursor glitch

…sion

…ursor glitch

…nning rules

…ogic

…n messages

…th clean indentation

vadiminshakov force-pushed the feat/1734-plan-mode branch 2 times, most recently from ee64af4 to 17a5fe8 Compare May 9, 2026 21:07

dcu reviewed May 19, 2026

View reviewed changes

dcu reviewed May 20, 2026

View reviewed changes

vadiminshakov force-pushed the feat/1734-plan-mode branch 4 times, most recently from 3b20f91 to ef9d769 Compare May 22, 2026 06:38

dcu reviewed May 22, 2026

View reviewed changes

vadiminshakov force-pushed the feat/1734-plan-mode branch 2 times, most recently from 3ca620e to ac58f55 Compare May 22, 2026 19:35

vadiminshakov force-pushed the feat/1734-plan-mode branch from 922ddfa to be65d67 Compare May 25, 2026 22:21

dcu approved these changes May 26, 2026

View reviewed changes

This was referenced May 26, 2026

feat(agent): add explore sub-agent and expand task agent capabilities #2989

Open

feat(ui): add ctrl+y keybinding to toggle yolo mode #3006

Merged

vadiminshakov force-pushed the feat/1734-plan-mode branch from 9b06f54 to 468718f Compare May 30, 2026 14:39

vadiminshakov added 28 commits June 15, 2026 00:52

fix(ui): show plan in status bar only

df293bf

fix(plan): added instructs

516890a

fix: check status exists

3a591b4

fix(plan): refine workflow and style guidelines for clarity and preci…

ccae613

…sion

fix(plan): mutate model synchronously in toggleInputMode to prevent c…

6b03474

…ursor glitch

fix(plan): enhance plan mode description

2c7d4f3

fix(plan): clarify wording for search tools in workflow instructions

b957f1f

fix(plan): update setEditorPrompt to include mode parameter

657346a

chore: rebase maintenance

efc21a0

feat: add plan mode

45807ed

fix(ui): show both yolo and plan markers when both modes are active

73db244

fix(plan): add risks consideration

8ea287f

fix(ui): show plan in status bar only

6f4765c

fix(plan): added instructs

a34218d

fix: check status exists

4fbc823

fix(plan): refine workflow and style guidelines for clarity and preci…

a183889

…sion

fix(plan): mutate model synchronously in toggleInputMode to prevent c…

56f06fa

…ursor glitch

fix(plan): enhance plan mode description

f9f014a

fix(plan): clarify wording for search tools in workflow instructions

a718d08

feat(plan): implement plan handoff dialog and add question tool usage

4869a07

fix(plan): refine question tool usage and confirmation process in pla…

2685dbe

…nning rules

feat(plan): implement inline plan handoff prompt and update related l…

e389106

…ogic

chore(plan): fix

6843896

feat(plan): add plan-ready marker detection and styling for final pla…

b994e33

…n messages

feat(plan): add "Critical Files" section to final plan response

5a9e408

feat(plan): implement plan-ready marker handling and UI updates

c7bb4f6

feat(styles): enhance PlanMarkdown styling for headings in quickStyle

5df91fe

feat(styles): update PlanMarkdown to replace raw markdown prefixes wi…

5520cf8

…th clean indentation

vadiminshakov force-pushed the feat/1734-plan-mode branch from 4f38888 to 5520cf8 Compare June 14, 2026 20:25

chore: lint

ba8d66e

Conversation

vadiminshakov commented May 6, 2026

Uh oh!

charmcli commented May 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

vadiminshakov commented May 6, 2026

Uh oh!

vadiminshakov commented May 6, 2026

Uh oh!

oiwn commented May 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

dcu May 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dcu May 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dcu commented May 22, 2026

Uh oh!

vadiminshakov commented May 22, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

vadiminshakov commented May 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

dcu commented May 22, 2026

Uh oh!

vadiminshakov commented May 22, 2026

Uh oh!

dcu commented May 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

dcu commented May 24, 2026

Uh oh!

dcu commented May 24, 2026

Uh oh!

vadiminshakov commented May 24, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

charmcli commented May 6, 2026 •

edited

Loading

oiwn commented May 13, 2026 •

edited

Loading

dcu May 19, 2026 •

edited

Loading

dcu May 20, 2026 •

edited

Loading

vadiminshakov commented May 22, 2026 •

edited

Loading

dcu commented May 23, 2026 •

edited

Loading