feat: Add predefined suggestions after finishing the planning session

[alex-alecu]

Context

Following the example from Claude Code after a planning session:

The context management is the most important job of tools using AI models. By starting a fresh session with just the plan as the first message, we maximize the efficiency of the implementation.

It's also cheaper to start with a fresh context - the CLI will not send on every request all the context it took build the plan.

Implementation

Now I have a thorough understanding of both the branch changes and the existing context limiter system. Here's the answer:

---

What this branch does with the context limiter and why

This branch sidesteps the context limiter entirely by creating a fresh session when transitioning from planning to implementation — rather than relying on compaction to reclaim space in an increasingly bloated conversation.

The mechanism

When the plan agent finishes its turn (packages/opencode/src/session/prompt.ts:339-347), the new PlanFollowup.ask() hook intercepts before the loop exits and presents the user with three choices:

1. "Start new session" — Creates a brand-new session with a clean context window. Instead of carrying the entire planning conversation forward (which would eventually trigger compaction/pruning), it runs a one-shot LLM call (generateHandover() in packages/opencode/src/kilocode/plan-followup.ts:62-98) using the compaction agent to distill the planning conversation into a concise handover summary. The new session receives only:

   • The plan text itself
   • The handover summary (discoveries, relevant files, implementation notes)
   • The todo list from the planning session

   This message is injected as a non-synthetic user message addressed to the code agent, and the prompt loop starts immediately.

2. "Continue here" — Injects a synthetic "Implement the plan above." message in the current session (keeping the existing context, which will eventually hit compaction normally).

3. Custom text — Sends the user's text back to the plan agent for further iteration.

Why this approach is better than relying on compaction

The existing compaction system has fundamental limitations for the plan-to-implementation transition:

1. Information loss is uncontrolled — Compaction produces a generic summary of the entire conversation. When the context overflows mid-implementation, the summary may lose critical planning details (architecture decisions, gotchas, file locations) because the compaction prompt isn't aware that this was a planning-then-implementing workflow.

2. Delayed context recovery — With the old approach, the plan conversation consumes a large portion of the context window before implementation even begins. The agent would explore code, produce a plan, and then start coding — but by the time it starts coding, much of the context is already consumed by planning exploration. Compaction only triggers after overflow, meaning the agent may hit the wall mid-implementation.

3. Targeted handover vs. generic compaction — The HANDOVER_PROMPT in this branch (plan-followup.ts:20-40) is specifically designed to extract implementation-relevant information that supplements the plan — discoveries, relevant files, pitfalls — while explicitly avoiding repeating the plan itself. This is a much more efficient use of context than a generic compaction summary.

4. Clean context budget — By starting a fresh session, the implementation agent gets the full context window for actual coding work. The injected message (plan + handover + todos) is compact and purpose-built, rather than a lossy compression of an entire exploration conversation.

5. Todo continuity — The todo list is copied to the new session (Todo.update at plan-followup.ts:196-198), preserving task tracking across the session boundary.

In short: instead of letting the context limiter reactively compress a mixed planning+implementation conversation (losing fidelity), this branch proactively creates a clean boundary between planning and implementation, carrying forward only the high-value information in a structured format.

Screenshots

How to Test

Start a planning session and look for the suggestions at the end.

Get in Touch

We'd love to have a way to chat with you about your changes if necessary. If you're in the Kilo Code Discord, please share your handle here.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
kilo-ui-storybook	Ready	Preview, Comment	Feb 19, 2026 0:10am

[kilo-code-bot]

Code Review Summary

Status: No Issues Found | Recommendation: Merge

The PR introduces a well-structured plan follow-up feature that prompts users after a plan agent completes, offering three options: start a new session with handover context, continue in the current session, or provide custom follow-up text.

Key observations (no blocking issues):

• Error handling in generateHandover is solid — failures gracefully return "" so the flow continues without handover context.
• Abort signal handling in prompt() is well-implemented with proper cleanup via removeEventListener in finally.
• The startNew function correctly fires off SessionPrompt.loop as fire-and-forget with error logging, which is appropriate since the new session should run independently.
• The formatTodos helper correctly handles all todo statuses with a fallback for unknown statuses.
• Test coverage is comprehensive — 13 tests covering all branches including abort scenarios, empty inputs, and LLM failures.
• The kilocode_change markers are properly placed in the shared prompt.ts file.

Files Reviewed (3 files)

• packages/opencode/src/kilocode/plan-followup.ts - New file, 274 lines. Core plan follow-up logic.
• packages/opencode/src/session/prompt.ts - 10 lines added. Integration point in the session loop.
• packages/opencode/test/kilocode/plan-followup.test.ts - New file, 547 lines. Comprehensive test suite.