mirror of
https://github.com/cline/cline.git
synced 2026-09-09 06:45:53 +08:00
Compare commits
3
Commits
| Author | SHA1 | Date | |
|---|---|---|---|
 candieduniverse
|
50f1153cfe | ||
|
candieduniverse
|
5797f993a1 | ||
|
candieduniverse
|
8749bd720f |
@@ -39,12 +39,12 @@ Abstract descriptions don't help anyone. Show actual code, real file paths, and
|
||||
|
||||
```markdown
|
||||
# Good
|
||||
I use `/deep-planning` whenever I'm building features that touch multiple
|
||||
I start in Plan mode whenever I'm building features that touch multiple
|
||||
parts of the codebase. For example, when adding authentication, Cline
|
||||
mapped every endpoint and created a migration plan that avoided breaking changes.
|
||||
mapped every endpoint and helped me write a migration plan that avoided breaking changes.
|
||||
|
||||
# Bad
|
||||
The deep planning feature can be utilized for various complex tasks
|
||||
The planning workflow can be utilized for various complex tasks
|
||||
that may require careful consideration and planning.
|
||||
```
|
||||
|
||||
|
||||
@@ -80,16 +80,16 @@ When enabled, switching between Plan and Act mode automatically switches to the
|
||||
| Maximum quality | Claude Opus | Claude Sonnet |
|
||||
| Speed-focused | Gemini 3 Flash | Cerebras |
|
||||
|
||||
## Using `/deep-planning`
|
||||
## Planning Large Tasks
|
||||
|
||||
For complex tasks that need thorough analysis, use the `/deep-planning` slash command. This triggers an extended planning session where Cline:
|
||||
For complex tasks that need thorough analysis, stay in Plan mode long enough to:
|
||||
|
||||
1. Explores the codebase systematically
|
||||
2. Identifies all affected files and dependencies
|
||||
3. Creates a detailed implementation plan
|
||||
4. Asks clarifying questions before proceeding
|
||||
1. Explore the codebase systematically
|
||||
2. Identify affected files, dependencies, and edge cases
|
||||
3. Discuss tradeoffs and clarify requirements
|
||||
4. Write down an implementation plan before switching to Act mode
|
||||
|
||||
The deep planning prompt is optimized for each model family, so it adapts to the strengths of whatever model you're using. See the [Deep Planning docs](/features/deep-planning) for more details.
|
||||
If you want a durable artifact, ask Cline to create a markdown planning document you can review with your team before implementation begins. If your team does this often, turn the process into a reusable [workflow](/customization/workflows).
|
||||
|
||||
## Choosing the Right Approach by Task Size
|
||||
|
||||
@@ -105,9 +105,9 @@ For most development work, start in Plan mode to understand the scope and approa
|
||||
|
||||
**Examples:** Add a new API endpoint, implement a UI component, fix a bug that requires investigation, refactor a single module.
|
||||
|
||||
### Large tasks: Use `/deep-planning`
|
||||
### Large tasks: Plan mode + written plan
|
||||
|
||||
For complex features that span multiple files, require architectural decisions, or will take multiple sessions to complete, use the `/deep-planning` slash command. This creates a detailed implementation plan that Cline can reference throughout the work.
|
||||
For complex features that span multiple files, require architectural decisions, or will take multiple sessions to complete, spend more time in Plan mode and have Cline produce a written implementation plan before switching to Act mode.
|
||||
|
||||
**Examples:** Add a new feature across frontend and backend, major refactoring across the codebase, implementing a new system or integration, multi-step migrations.
|
||||
|
||||
|
||||
@@ -1,10 +1,10 @@
|
||||
---
|
||||
title: "Using Commands"
|
||||
sidebarTitle: "Using Commands"
|
||||
description: "Built-in slash commands to manage context, plan implementations, and create reusable workflows."
|
||||
description: "Built-in slash commands to manage context and create reusable workflows."
|
||||
---
|
||||
|
||||
Cline provides slash commands in chat that help you manage your conversation and plan complex implementations.
|
||||
Cline provides slash commands in chat that help you manage your conversation and kick off reusable workflows.
|
||||
|
||||
<Tip>
|
||||
**New to slash commands?** Watch our [quick video walkthrough](https://youtu.be/MxS5Jerpf-o) to see these commands in action.
|
||||
@@ -19,7 +19,6 @@ Type `/` in the chat input to see available slash commands:
|
||||
| `/newtask` | Start fresh task with distilled context from current conversation |
|
||||
| `/smol` | Compress conversation history while preserving essential context |
|
||||
| `/newrule` | Create a rule file to teach Cline your preferences |
|
||||
| `/deep-planning` | Investigate codebase, plan thoroughly, then create implementation task |
|
||||
| `/explain-changes` | Generate AI explanations for any git diff (VS Code only) |
|
||||
| `/reportbug` | Report a bug with diagnostic info |
|
||||
|
||||
@@ -41,17 +40,6 @@ Use `/smol` when you're deep into a debugging session or brainstorming and need
|
||||
|
||||
Use `/newrule` when you find yourself repeating the same instructions across tasks. For more about rules, see [Cline Rules](/customization/cline-rules).
|
||||
|
||||
### /deep-planning
|
||||
|
||||
Transform Cline into a meticulous architect who investigates your codebase, asks clarifying questions, and creates a comprehensive implementation plan before writing any code. Deep planning follows a four-step process:
|
||||
|
||||
1. **Silent Investigation** - Cline explores your codebase structure and patterns
|
||||
2. **Discussion** - Targeted questions about requirements and approach
|
||||
3. **Plan Creation** - Generates `implementation_plan.md` with detailed specifications
|
||||
4. **Task Creation** - Creates a new task with trackable implementation steps
|
||||
|
||||
Use `/deep-planning` for features touching multiple parts of your codebase, architectural changes, or complex integrations. For detailed documentation, see [Deep Planning](/features/deep-planning).
|
||||
|
||||
### /explain-changes
|
||||
|
||||
<Note>
|
||||
@@ -72,4 +60,6 @@ Use `/reportbug` when you encounter unexpected behavior, crashes, or bugs you wa
|
||||
|
||||
Beyond the built-in slash commands, you can create your own workflow files that work the same way. Store Markdown files in `.clinerules/workflows/` and invoke them with `/your-workflow.md`.
|
||||
|
||||
For larger implementations, start in [Plan & Act Mode](/core-workflows/plan-and-act) to investigate the codebase, discuss tradeoffs, and decide on an implementation strategy before switching to Act mode.
|
||||
|
||||
For a complete guide on creating and managing custom workflows, see [Workflows](/customization/workflows).
|
||||
|
||||
+5
-2
@@ -131,7 +131,6 @@
|
||||
"features/subagents",
|
||||
"features/background-edit",
|
||||
"features/jupyter-notebooks",
|
||||
"features/deep-planning",
|
||||
"features/web-tools",
|
||||
"features/worktrees"
|
||||
]
|
||||
@@ -647,9 +646,13 @@
|
||||
"source": "/troubleshooting/terminal-integration-guide",
|
||||
"destination": "/troubleshooting/terminal-quick-fixes"
|
||||
},
|
||||
{
|
||||
"source": "/features/deep-planning",
|
||||
"destination": "/core-workflows/plan-and-act"
|
||||
},
|
||||
{
|
||||
"source": "/features/slash-commands/deep-planning",
|
||||
"destination": "/features/deep-planning"
|
||||
"destination": "/core-workflows/plan-and-act"
|
||||
},
|
||||
{
|
||||
"source": "/features/slash-commands/smol",
|
||||
|
||||
@@ -107,6 +107,8 @@ Select your provider below to begin the configuration process:
|
||||
</Card>
|
||||
|
||||
<Card title="Anthropic" icon="robot" href="/enterprise-solutions/configuration/remote-configuration/anthropic/admin-configuration">
|
||||
Direct Anthropic API access with centralized model and endpoint configuration.
|
||||
</Card>
|
||||
|
||||
<Card title="LiteLLM" icon="layer-group" href="/enterprise-solutions/configuration/remote-configuration/litellm/admin-configuration">
|
||||
Unified proxy for accessing 100+ AI models through a single interface.
|
||||
|
||||
@@ -297,7 +297,7 @@ Now that you understand member management, proceed with configuring your organiz
|
||||
<Card
|
||||
title="Configure Providers"
|
||||
icon="plug"
|
||||
href="/enterprise-solutions/configuration/choosing-your-deployment"
|
||||
href="/enterprise-solutions/configuration/remote-configuration/overview"
|
||||
>
|
||||
Set up API providers for your team to use
|
||||
</Card>
|
||||
|
||||
@@ -1,129 +0,0 @@
|
||||
---
|
||||
title: "Deep Planning"
|
||||
sidebarTitle: "Deep Planning"
|
||||
description: "Transform Cline into a meticulous architect who investigates your codebase and creates comprehensive implementation plans."
|
||||
---
|
||||
|
||||
Deep Planning (`/deep-planning`) turns Cline into an architect before it becomes a builder. Instead of jumping straight into code, Cline systematically explores your codebase, asks targeted questions, and produces a detailed implementation plan — all before writing a single line.
|
||||
|
||||
<Tip>
|
||||
**When should you use this?** Use `/deep-planning` for features that touch multiple files, architectural changes, complex integrations, or any task where "just start coding" would lead to rework.
|
||||
</Tip>
|
||||
|
||||
## How It Works
|
||||
|
||||
Deep Planning follows a four-step process:
|
||||
|
||||
<Steps>
|
||||
<Step title="Silent Investigation">
|
||||
Cline explores your codebase without asking you anything. It reads relevant files, traces dependencies, examines patterns, and builds a mental model of how your project is structured. You'll see Cline reading files and running searches during this phase.
|
||||
|
||||
This step is intentionally silent — Cline gathers context first so it can ask better questions next.
|
||||
</Step>
|
||||
|
||||
<Step title="Discussion">
|
||||
Based on what it learned, Cline asks you targeted, specific questions about your requirements and preferences. These aren't generic questions — they're informed by what Cline found in your code.
|
||||
|
||||
For example, instead of asking "how should authentication work?", Cline might ask "I see you're using JWT tokens in `auth/middleware.ts` with refresh token rotation. Should the new endpoint follow the same pattern, or do you want session-based auth for this feature?"
|
||||
|
||||
Answer these questions to shape the plan. The more specific you are, the better the implementation plan will be.
|
||||
</Step>
|
||||
|
||||
<Step title="Plan Creation">
|
||||
Cline generates a comprehensive `implementation_plan.md` file in your project. This plan typically includes:
|
||||
|
||||
- **Overview** of the feature and its scope
|
||||
- **File-by-file changes** with specific descriptions of what to add, modify, or remove
|
||||
- **Dependencies** between changes (what needs to happen first)
|
||||
- **Edge cases** and error handling considerations
|
||||
- **Testing strategy** for the implementation
|
||||
|
||||
The plan is saved as a markdown file you can review, edit, and share with your team before any code is written.
|
||||
</Step>
|
||||
|
||||
<Step title="Task Creation">
|
||||
After you approve the plan, Cline creates a new task with the implementation steps loaded as trackable items. This gives you a clean context window focused entirely on execution, with the plan serving as the roadmap.
|
||||
</Step>
|
||||
</Steps>
|
||||
|
||||
## Using Deep Planning
|
||||
|
||||
### Invoking It
|
||||
|
||||
Type `/deep-planning` in the Cline chat input, followed by a description of what you want to build:
|
||||
|
||||
```
|
||||
/deep-planning Add a notification system that sends email and in-app
|
||||
notifications when users receive comments on their posts
|
||||
```
|
||||
|
||||
The more context you provide upfront, the more focused the investigation phase will be. Include:
|
||||
|
||||
- What you want to build
|
||||
- Any constraints or preferences
|
||||
- Which parts of the codebase are relevant (if you know)
|
||||
|
||||
### Reviewing the Plan
|
||||
|
||||
Once Cline generates `implementation_plan.md`, review it carefully:
|
||||
|
||||
1. **Check the scope** — Does it cover everything you need? Is anything missing?
|
||||
2. **Verify the approach** — Does the technical approach match your preferences?
|
||||
3. **Review the order** — Are dependencies handled correctly?
|
||||
4. **Edit if needed** — It's a markdown file. Change anything that doesn't look right.
|
||||
|
||||
Tell Cline about any adjustments before proceeding to implementation.
|
||||
|
||||
## Model-Specific Optimization
|
||||
|
||||
The deep planning prompt is optimized for each model family. Cline adapts its investigation and planning approach based on the strengths of whatever model you're using — whether that's Claude, GPT, Gemini, DeepSeek, or others.
|
||||
|
||||
This means you get effective deep planning regardless of your model choice, though stronger reasoning models will generally produce more thorough plans.
|
||||
|
||||
<Tip>
|
||||
Consider using a stronger reasoning model for the planning phase and a faster model for implementation. You can configure separate models for Plan and Act modes in Cline Settings. See [Plan & Act Mode](/core-workflows/plan-and-act#using-different-models-for-each-mode) for details.
|
||||
</Tip>
|
||||
|
||||
## Pairing with Other Features
|
||||
|
||||
Deep Planning works well with several other Cline features:
|
||||
|
||||
| Feature | How It Helps |
|
||||
|---------|-------------|
|
||||
| [Focus Chain](/features/focus-chain) | Tracks implementation progress against the plan with a visible todo list |
|
||||
| [Memory Bank](/features/memory-bank) | Preserves project context across sessions so deep planning has richer input |
|
||||
| [Plan & Act Mode](/core-workflows/plan-and-act) | Use Plan mode for quick exploration, deep planning for thorough architecture |
|
||||
| [Checkpoints](/core-workflows/checkpoints) | Roll back implementation steps if something goes wrong during execution |
|
||||
|
||||
<Tip>
|
||||
A powerful workflow: run `/deep-planning` to create the plan, enable [Focus Chain](/features/focus-chain) to track progress, then let Cline implement step by step. You get architecture-level thinking with granular progress visibility.
|
||||
</Tip>
|
||||
|
||||
## Deep Planning vs Plan Mode
|
||||
|
||||
Both involve thinking before doing, but they serve different purposes:
|
||||
|
||||
| | Plan Mode | Deep Planning |
|
||||
|---|-----------|---------------|
|
||||
| **Scope** | Quick exploration and discussion | Thorough codebase investigation |
|
||||
| **Output** | Conversation context | `implementation_plan.md` file |
|
||||
| **Best for** | Medium tasks, understanding code | Large tasks, multi-file features |
|
||||
| **Duration** | Minutes | Longer — depends on codebase size |
|
||||
| **Persistence** | Lives in conversation history | Saved as a file you can reference later |
|
||||
|
||||
For most development work, starting in Plan mode is sufficient. Reserve `/deep-planning` for tasks where you'd normally spend significant time planning on a whiteboard before coding.
|
||||
|
||||
## Tips
|
||||
|
||||
- **Be specific in your initial prompt.** "Add authentication" gives a vague plan. "Add OAuth2 authentication with Google and GitHub providers, using our existing user model in `models/user.ts`" gives a focused one.
|
||||
- **Point Cline at relevant files.** Use `@` mentions to highlight key files in your prompt so the investigation phase starts in the right place.
|
||||
- **Edit the plan before implementing.** The generated plan is a starting point. Adjust priorities, remove unnecessary steps, or add details before Cline starts coding.
|
||||
- **Save plans for reference.** The `implementation_plan.md` file is useful documentation even after the feature is built. Consider committing it or moving it to a docs folder.
|
||||
- **Use for onboarding.** Run `/deep-planning` on a feature you're unfamiliar with to get Cline to map out the codebase and explain how things connect.
|
||||
|
||||
## Related
|
||||
|
||||
- [Plan & Act Mode](/core-workflows/plan-and-act) — Cline's dual-mode system for structured development
|
||||
- [Focus Chain](/features/focus-chain) — Automatic todo list tracking for long-running tasks
|
||||
- [Memory Bank](/features/memory-bank) — Structured documentation for cross-session context
|
||||
- [Using Commands](/core-workflows/using-commands) — All available slash commands
|
||||
@@ -23,7 +23,7 @@ Focus Chain works best for:
|
||||
For quick, single-step requests, Focus Chain adds overhead without much benefit.
|
||||
|
||||
<Tip>
|
||||
Focus Chain pairs well with [Deep Planning](/features/deep-planning). Use `/deep-planning` to create a detailed implementation plan, then let Focus Chain track progress as you execute it.
|
||||
Focus Chain pairs well with [Plan Mode](/core-workflows/plan-and-act). Explore the task first, decide on the implementation steps, then let Focus Chain track progress as you execute them.
|
||||
</Tip>
|
||||
|
||||
## Enabling Focus Chain
|
||||
|
||||
@@ -56,7 +56,7 @@ Memory Bank pairs naturally with [Plan & Act mode](/core-workflows/plan-and-act)
|
||||
- **Plan mode**: Start here when resuming a project. Ask Cline to read the Memory Bank, review the current state, and discuss strategy before making changes.
|
||||
- **Act mode**: Switch to Act mode once you have a plan. Cline retains everything from the planning session and can implement changes.
|
||||
|
||||
For complex features, use [`/deep-planning`](/core-workflows/using-commands#deep-planning) to have Cline investigate your codebase and create a detailed implementation plan. The Memory Bank gives Cline the project context it needs to plan effectively.
|
||||
For complex features, ask Cline to use Plan mode to investigate your codebase and write down an implementation plan before moving into Act mode. The Memory Bank gives Cline the project context it needs to plan effectively.
|
||||
|
||||
## Managing Context Windows
|
||||
|
||||
|
||||
@@ -1,6 +1,3 @@
|
||||
import type { ApiProviderInfo } from "@/core/api"
|
||||
import { getDeepPlanningPrompt } from "./commands/deep-planning"
|
||||
|
||||
export const newTaskToolResponse = (willUseNativeTools: boolean) => {
|
||||
const xmlExample = `
|
||||
Example:
|
||||
@@ -303,18 +300,3 @@ Use the generate_explanation tool with:
|
||||
Below is the user's input describing what changes they want explained. If no input is provided, default to analyzing uncommitted changes in the working directory (may or may not be staged).
|
||||
</explicit_instructions>\n
|
||||
`
|
||||
|
||||
/**
|
||||
* Generates the deep-planning slash command response with model-family-aware variant selection
|
||||
* @param focusChainSettings Optional focus chain settings to include in the prompt
|
||||
* @param providerInfo Optional API provider info for model family detection
|
||||
* @param enableNativeToolCalls Optional flag to determine if native tool calling is enabled
|
||||
* @returns The deep-planning prompt string with appropriate variant and focus chain settings applied
|
||||
*/
|
||||
export const deepPlanningToolResponse = (
|
||||
focusChainSettings?: { enabled: boolean },
|
||||
providerInfo?: ApiProviderInfo,
|
||||
enableNativeToolCalls?: boolean,
|
||||
) => {
|
||||
return getDeepPlanningPrompt(focusChainSettings, providerInfo, enableNativeToolCalls)
|
||||
}
|
||||
|
||||
@@ -1,88 +0,0 @@
|
||||
import type { ApiProviderInfo } from "@/core/api"
|
||||
import type { SystemPromptContext } from "@/core/prompts/system-prompt/types"
|
||||
import { getDeepPlanningRegistry } from "./registry"
|
||||
import { generateGemini3Template } from "./variants/gemini3"
|
||||
import { generateGPT51Template } from "./variants/gpt51"
|
||||
|
||||
const focusChainIntro: string = `**Task Progress Parameter:**
|
||||
When creating the new task, you must include a task_progress parameter that breaks down the implementation into trackable steps. This parameter should be included inside the tool call, but not located inside of other content/argument blocks. This should follow the standard Markdown checklist format with "- [ ]" for incomplete items.`
|
||||
|
||||
/**
|
||||
* Generates the deep-planning slash command response with model-family-aware variant selection
|
||||
* @param focusChainSettings Optional focus chain settings to include in the prompt
|
||||
* @param providerInfo Optional API provider info for model family detection
|
||||
* @param enableNativeToolCalls Optional flag to determine if native tool calling is enabled
|
||||
* @returns The deep-planning prompt string with appropriate variant and focus chain settings applied
|
||||
*/
|
||||
export function getDeepPlanningPrompt(
|
||||
focusChainSettings?: { enabled: boolean },
|
||||
providerInfo?: ApiProviderInfo,
|
||||
enableNativeToolCalls?: boolean,
|
||||
): string {
|
||||
// Create context for variant selection
|
||||
const context: SystemPromptContext = {
|
||||
providerInfo: providerInfo || ({} as ApiProviderInfo),
|
||||
ide: "vscode",
|
||||
}
|
||||
|
||||
// Get the appropriate variant from registry
|
||||
const registry = getDeepPlanningRegistry()
|
||||
const variant = registry.get(context)
|
||||
const newTaskInstructions = generateNewTaskInstructions(enableNativeToolCalls ?? false)
|
||||
const focusChainParam = focusChainSettings?.enabled ? focusChainIntro : ""
|
||||
|
||||
// For variants with extensive focus chain prompting, generate template with focus chain flag
|
||||
let template: string
|
||||
if (variant.id === "gpt-51") {
|
||||
template = generateGPT51Template(focusChainSettings?.enabled ?? false, enableNativeToolCalls ?? false)
|
||||
} else if (variant.id === "gemini-3") {
|
||||
template = generateGemini3Template(focusChainSettings?.enabled ?? false, enableNativeToolCalls ?? false)
|
||||
} else {
|
||||
template = variant.template
|
||||
template = template.replace("{{FOCUS_CHAIN_PARAM}}", focusChainParam)
|
||||
template = template.replace("{{NEW_TASK_INSTRUCTIONS}}", newTaskInstructions)
|
||||
}
|
||||
|
||||
return template
|
||||
}
|
||||
|
||||
/**
|
||||
* Generates the new_task tool instructions based on whether native tool calling is enabled
|
||||
* @param enableNativeToolCalls Whether native tool calling is enabled
|
||||
* @returns The new_task tool instructions string
|
||||
*/
|
||||
function generateNewTaskInstructions(enableNativeToolCalls: boolean): string {
|
||||
if (enableNativeToolCalls) {
|
||||
return `
|
||||
**new_task Tool Definition:**
|
||||
|
||||
When you are ready to create the implementation task, you must call the new_task tool with the following structure:
|
||||
|
||||
\`\`\`json
|
||||
{
|
||||
"name": "new_task",
|
||||
"arguments": {
|
||||
"context": "Your detailed context here following the 5-point structure..."
|
||||
}
|
||||
}
|
||||
\`\`\`
|
||||
|
||||
The context parameter should include all five sections as described above.`
|
||||
} else {
|
||||
return `
|
||||
**new_task Tool Definition:**
|
||||
|
||||
When you are ready to create the implementation task, you must call the new_task tool with the following structure:
|
||||
|
||||
\`\`\`xml
|
||||
<new_task>
|
||||
<context>Your detailed context here following the 5-point structure...</context>
|
||||
</new_task>
|
||||
\`\`\`
|
||||
|
||||
The context parameter should include all five sections as described above.`
|
||||
}
|
||||
}
|
||||
|
||||
// Export types for external use
|
||||
export type { DeepPlanningRegistry, DeepPlanningVariant } from "./types"
|
||||
@@ -1,100 +0,0 @@
|
||||
import type { SystemPromptContext } from "@/core/prompts/system-prompt/types"
|
||||
import { Logger } from "@/shared/services/Logger"
|
||||
import type { DeepPlanningVariant, DeepPlanningRegistry as IDeepPlanningRegistry } from "./types"
|
||||
import {
|
||||
createAnthropicVariant,
|
||||
createGemini3Variant,
|
||||
createGeminiVariant,
|
||||
createGenericVariant,
|
||||
createGPT51Variant,
|
||||
} from "./variants"
|
||||
|
||||
/**
|
||||
* Singleton registry for managing deep-planning prompt variants
|
||||
* Selects appropriate variant based on model family detection
|
||||
*/
|
||||
class DeepPlanningRegistry implements IDeepPlanningRegistry {
|
||||
private static instance: DeepPlanningRegistry | null = null
|
||||
private variants: Map<string, DeepPlanningVariant> = new Map()
|
||||
private genericVariant: DeepPlanningVariant
|
||||
|
||||
private constructor() {
|
||||
// Initialize all variants
|
||||
this.registerVariant(createAnthropicVariant())
|
||||
this.registerVariant(createGeminiVariant())
|
||||
this.registerVariant(createGemini3Variant())
|
||||
this.registerVariant(createGPT51Variant())
|
||||
|
||||
// Generic variant must be registered last as fallback
|
||||
const genericVariant = createGenericVariant()
|
||||
this.registerVariant(genericVariant)
|
||||
this.genericVariant = genericVariant
|
||||
}
|
||||
|
||||
/**
|
||||
* Get the singleton instance of the registry
|
||||
*/
|
||||
public static getInstance(): DeepPlanningRegistry {
|
||||
if (!DeepPlanningRegistry.instance) {
|
||||
DeepPlanningRegistry.instance = new DeepPlanningRegistry()
|
||||
}
|
||||
return DeepPlanningRegistry.instance
|
||||
}
|
||||
|
||||
/**
|
||||
* Register a new variant in the registry
|
||||
*/
|
||||
public register(variant: DeepPlanningVariant): void {
|
||||
this.registerVariant(variant)
|
||||
}
|
||||
|
||||
/**
|
||||
* Internal method to register a variant
|
||||
*/
|
||||
private registerVariant(variant: DeepPlanningVariant): void {
|
||||
this.variants.set(variant.id, variant)
|
||||
}
|
||||
|
||||
/**
|
||||
* Get the appropriate variant based on the system prompt context
|
||||
* Uses matcher functions to determine which variant to use
|
||||
* Falls back to generic variant if no match or on error
|
||||
*/
|
||||
public get(context: SystemPromptContext): DeepPlanningVariant {
|
||||
try {
|
||||
// Try each variant's matcher function (except generic which is last)
|
||||
for (const variant of this.variants.values()) {
|
||||
// Skip generic variant in iteration (it's the fallback)
|
||||
if (variant.id === "generic") {
|
||||
continue
|
||||
}
|
||||
|
||||
// Test if this variant matches the context
|
||||
if (variant.matcher(context)) {
|
||||
return variant
|
||||
}
|
||||
}
|
||||
|
||||
// No match found, return generic variant
|
||||
return this.genericVariant
|
||||
} catch (error) {
|
||||
// On any error, safely fall back to generic variant
|
||||
Logger.warn("Error selecting deep-planning variant, falling back to generic:", error)
|
||||
return this.genericVariant
|
||||
}
|
||||
}
|
||||
|
||||
/**
|
||||
* Get all registered variants
|
||||
*/
|
||||
public getAll(): DeepPlanningVariant[] {
|
||||
return Array.from(this.variants.values())
|
||||
}
|
||||
}
|
||||
|
||||
/**
|
||||
* Export singleton instance getter
|
||||
*/
|
||||
export function getDeepPlanningRegistry(): DeepPlanningRegistry {
|
||||
return DeepPlanningRegistry.getInstance()
|
||||
}
|
||||
@@ -1,38 +0,0 @@
|
||||
import type { SystemPromptContext } from "@/core/prompts/system-prompt/types"
|
||||
|
||||
/**
|
||||
* Configuration for a deep-planning prompt variant
|
||||
*/
|
||||
export interface DeepPlanningVariant {
|
||||
/** Unique identifier for this variant (e.g., "anthropic", "gemini", "gpt-5", "generic") */
|
||||
id: string
|
||||
|
||||
/** Human-readable description of this variant */
|
||||
description: string
|
||||
|
||||
/** The model family this variant is designed for */
|
||||
family: string
|
||||
|
||||
/** Version number for this variant */
|
||||
version: number
|
||||
|
||||
/** Matcher function to determine if this variant should be used */
|
||||
matcher: (context: SystemPromptContext) => boolean
|
||||
|
||||
/** The complete prompt template string */
|
||||
template: string
|
||||
}
|
||||
|
||||
/**
|
||||
* Registry for deep-planning prompt variants
|
||||
*/
|
||||
export interface DeepPlanningRegistry {
|
||||
/** Get the appropriate variant based on context */
|
||||
get(context: SystemPromptContext): DeepPlanningVariant
|
||||
|
||||
/** Register a new variant */
|
||||
register(variant: DeepPlanningVariant): void
|
||||
|
||||
/** Get all registered variants */
|
||||
getAll(): DeepPlanningVariant[]
|
||||
}
|
||||
@@ -1,277 +0,0 @@
|
||||
import { isAnthropicModelId } from "@utils/model-utils"
|
||||
import { getShell } from "@utils/shell"
|
||||
import type { SystemPromptContext } from "@/core/prompts/system-prompt/types"
|
||||
import type { DeepPlanningVariant } from "../types"
|
||||
|
||||
/**
|
||||
* Creates the Anthropic Claude variant for deep-planning prompt
|
||||
* This variant is optimized for Claude models
|
||||
*/
|
||||
export function createAnthropicVariant(): DeepPlanningVariant {
|
||||
return {
|
||||
id: "anthropic",
|
||||
description: "Deep-planning variant optimized for Anthropic Claude models",
|
||||
family: "anthropic",
|
||||
version: 1,
|
||||
matcher: (context: SystemPromptContext) => {
|
||||
const modelId = context.providerInfo?.model?.id
|
||||
if (!modelId) {
|
||||
return false
|
||||
}
|
||||
return isAnthropicModelId(modelId)
|
||||
},
|
||||
template: generateTemplate(),
|
||||
}
|
||||
}
|
||||
|
||||
/**
|
||||
* Generates the deep-planning template with shell-specific commands
|
||||
*/
|
||||
function generateTemplate(): string {
|
||||
const detectedShell = getShell()
|
||||
|
||||
// FIXME: detectedShell returns a non-string value on some Windows machines
|
||||
let isPowerShell = false
|
||||
try {
|
||||
isPowerShell =
|
||||
detectedShell != null &&
|
||||
typeof detectedShell === "string" &&
|
||||
(detectedShell.toLowerCase().includes("powershell") || detectedShell.toLowerCase().includes("pwsh"))
|
||||
} catch {}
|
||||
|
||||
return `<explicit_instructions type="deep-planning">
|
||||
Your task is to create a comprehensive implementation plan before writing any code. This process has four distinct steps that must be completed in order.
|
||||
|
||||
Your behavior should be methodical and thorough - take time to understand the codebase completely before making any recommendations. The quality of your investigation directly impacts the success of the implementation.
|
||||
|
||||
## STEP 1: Silent Investigation
|
||||
|
||||
<important>
|
||||
until explicitly instructed by the user to proceed with coding.
|
||||
You must thoroughly understand the existing codebase before proposing any changes.
|
||||
Perform your research without commentary or narration. Execute commands and read files without explaining what you're about to do. Only speak up if you have specific questions for the user.
|
||||
</important>
|
||||
|
||||
### Required Research Activities
|
||||
You must use the read_file tool to examine relevant source files, configuration files, and documentation. You must use terminal commands to gather information about the codebase structure and patterns. All terminal output must be piped to cat for visibility.
|
||||
|
||||
### Essential Terminal Commands
|
||||
First, determine the language(s) used in the codebase, then execute these commands to build your understanding. You must tailor them to the codebase and ensure the output is not overly verbose. For example, you should exclude dependency folders such as node_modules, venv or php vendor, etc. These are only examples, the exact commands will differ depending on the codebase.
|
||||
|
||||
${
|
||||
isPowerShell
|
||||
? // PowerShell-specific commands
|
||||
|
||||
`# Discover project structure and file types
|
||||
Get-ChildItem -Recurse -Include "*.py","*.js","*.ts","*.java","*.cpp","*.go" | Select-Object -First 30 | Select-Object FullName
|
||||
|
||||
# Find all class and function definitions
|
||||
Get-ChildItem -Recurse -Include "*.py","*.js","*.ts","*.java","*.cpp","*.go" | Select-String -Pattern "class|function|def|interface|struct"
|
||||
|
||||
# Analyze import patterns and dependencies
|
||||
Get-ChildItem -Recurse -Include "*.py","*.js","*.ts","*.java","*.cpp" | Select-String -Pattern "import|from|require|#include" | Sort-Object | Get-Unique
|
||||
|
||||
# Find dependency manifests
|
||||
Get-ChildItem -Recurse -Include "requirements*.txt","package.json","Cargo.toml","pom.xml","Gemfile","go.mod" | Get-Content
|
||||
|
||||
# Identify technical debt and TODOs
|
||||
Get-ChildItem -Recurse -Include "*.py","*.js","*.ts","*.java","*.cpp","*.go" | Select-String -Pattern "TODO|FIXME|XXX|HACK|NOTE"
|
||||
`
|
||||
: // bash/zsh-specific commands
|
||||
`# Discover project structure and file types
|
||||
find . -type f -name "*.py" -o -name "*.js" -o -name "*.ts" -o -name "*.java" -o -name "*.cpp" -o -name "*.go" | head -30 | cat
|
||||
|
||||
# Find all class and function definitions
|
||||
grep -r "class\\|function\\|def\\|interface\\|struct\\|func\\|type.*struct\\|type.*interface" --include="*.py" --include="*.js" --include="*.ts" --include="*.java" --include="*.cpp" --include="*.go" . | cat
|
||||
|
||||
# Analyze import patterns and dependencies
|
||||
grep -r "import\\|from\\|require\\|#include" --include="*.py" --include="*.js" --include="*.ts" --include="*.java" --include="*.cpp" . | sort | uniq | cat
|
||||
|
||||
# Find dependency manifests
|
||||
find . -name "requirements*.txt" -o -name "package.json" -o -name "Cargo.toml" -o -name "pom.xml" -o -name "Gemfile" -o -name "go.mod" | xargs cat
|
||||
|
||||
# Identify technical debt and TODOs
|
||||
grep -r "TODO\\|FIXME\\|XXX\\|HACK\\|NOTE" --include="*.py" --include="*.js" --include="*.ts" --include="*.java" --include="*.cpp" --include="*.go" . | cat
|
||||
`
|
||||
}
|
||||
|
||||
|
||||
## STEP 2: Discussion and Questions
|
||||
|
||||
Ask the user brief, targeted questions that will influence your implementation plan. Keep your questions concise and conversational. Ask only essential questions needed to create an accurate plan.
|
||||
|
||||
**Ask questions only when necessary for:**
|
||||
- Clarifying ambiguous requirements or specifications
|
||||
- Choosing between multiple equally valid implementation approaches
|
||||
- Confirming assumptions about existing system behavior or constraints
|
||||
- Understanding preferences for specific technical decisions that will affect the implementation
|
||||
|
||||
Your questions should be direct and specific. Avoid long explanations or multiple questions in one response.
|
||||
|
||||
## STEP 3: Create Implementation Plan Document
|
||||
|
||||
Create a structured markdown document containing your complete implementation plan. The document must follow this exact format with clearly marked sections:
|
||||
|
||||
### Document Structure Requirements
|
||||
|
||||
Your implementation plan must be saved as implementation_plan.md, and *must* be structured as follows:
|
||||
|
||||
|
||||
# Implementation Plan
|
||||
|
||||
[Overview]
|
||||
Single sentence describing the overall goal.
|
||||
|
||||
Multiple paragraphs outlining the scope, context, and high-level approach. Explain why this implementation is needed and how it fits into the existing system.
|
||||
|
||||
[Types]
|
||||
Single sentence describing the type system changes.
|
||||
|
||||
Detailed type definitions, interfaces, enums, or data structures with complete specifications. Include field names, types, validation rules, and relationships.
|
||||
|
||||
[Files]
|
||||
Single sentence describing file modifications.
|
||||
|
||||
Detailed breakdown:
|
||||
- New files to be created (with full paths and purpose)
|
||||
- Existing files to be modified (with specific changes)
|
||||
- Files to be deleted or moved
|
||||
- Configuration file updates
|
||||
|
||||
[Functions]
|
||||
Single sentence describing function modifications.
|
||||
|
||||
Detailed breakdown:
|
||||
- New functions (name, signature, file path, purpose)
|
||||
- Modified functions (exact name, current file path, required changes)
|
||||
- Removed functions (name, file path, reason, migration strategy)
|
||||
|
||||
[Classes]
|
||||
Single sentence describing class modifications.
|
||||
|
||||
Detailed breakdown:
|
||||
- New classes (name, file path, key methods, inheritance)
|
||||
- Modified classes (exact name, file path, specific modifications)
|
||||
- Removed classes (name, file path, replacement strategy)
|
||||
|
||||
[Dependencies]
|
||||
Single sentence describing dependency modifications.
|
||||
|
||||
Details of new packages, version changes, and integration requirements.
|
||||
|
||||
[Testing]
|
||||
Single sentence describing testing approach.
|
||||
|
||||
Test file requirements, existing test modifications, and validation strategies.
|
||||
|
||||
[Implementation Order]
|
||||
Single sentence describing the implementation sequence.
|
||||
|
||||
Numbered steps showing the logical order of changes to minimize conflicts and ensure successful integration.
|
||||
|
||||
|
||||
## STEP 4: Create Implementation Task
|
||||
|
||||
Use the new_task command to create a task for implementing the plan. The task must include a <task_progress> list that breaks down the implementation into trackable steps.
|
||||
|
||||
### Task Creation Requirements
|
||||
|
||||
Your new task should be self-contained and reference the plan document rather than requiring additional codebase investigation. Include these specific instructions in the task description:
|
||||
|
||||
**Plan Document Navigation Commands:**
|
||||
The implementation agent should use these commands to read specific sections of the implementation plan. You should adapt these examples to conform to the structure of the .md file you created, and explicitly provide them when creating the new task:
|
||||
|
||||
${
|
||||
isPowerShell
|
||||
? `
|
||||
# Read Overview section
|
||||
$content = Get-Content implementation_plan.md; $start = ($content | Select-String -Pattern '\\[Overview\\]').LineNumber; $end = ($content | Select-String -Pattern '\\[Types\\]').LineNumber; $content[($start-1)..($end-2)]
|
||||
|
||||
# Read Types section
|
||||
$content = Get-Content implementation_plan.md; $start = ($content | Select-String -Pattern '\\[Types\\]').LineNumber; $end = ($content | Select-String -Pattern '\\[Files\\]').LineNumber; $content[($start-1)..($end-2)]
|
||||
|
||||
# Read Files section
|
||||
$content = Get-Content implementation_plan.md; $start = ($content | Select-String -Pattern '\\[Files\\]').LineNumber; $end = ($content | Select-String -Pattern '\\[Functions\\]').LineNumber; $content[($start-1)..($end-2)]
|
||||
|
||||
# Read Functions section
|
||||
$content = Get-Content implementation_plan.md; $start = ($content | Select-String -Pattern '\\[Functions\\]').LineNumber; $end = ($content | Select-String -Pattern '\\[Classes\\]').LineNumber; $content[($start-1)..($end-2)]
|
||||
|
||||
# Read Classes section
|
||||
$content = Get-Content implementation_plan.md; $start = ($content | Select-String -Pattern '\\[Classes\\]').LineNumber; $end = ($content | Select-String -Pattern '\\[Dependencies\\]').LineNumber; $content[($start-1)..($end-2)]
|
||||
|
||||
# Read Dependencies section
|
||||
$content = Get-Content implementation_plan.md; $start = ($content | Select-String -Pattern '\\[Dependencies\\]').LineNumber; $end = ($content | Select-String -Pattern '\\[Testing\\]').LineNumber; $content[($start-1)..($end-2)]
|
||||
|
||||
# Read Testing section
|
||||
$content = Get-Content implementation_plan.md; $start = ($content | Select-String -Pattern '\\[Testing\\]').LineNumber; $end = ($content | Select-String -Pattern '\\[Implementation Order\\]').LineNumber; $content[($start-1)..($end-2)]
|
||||
|
||||
# Read Implementation Order section
|
||||
$content = Get-Content implementation_plan.md; $start = ($content | Select-String -Pattern '\\[Implementation Order\\]').LineNumber; $content[($start-1)..($content.Length-1)]
|
||||
`
|
||||
: `
|
||||
# Read Overview section
|
||||
sed -n '/\\[Overview\\]/,/\\[Types\\]/p' implementation_plan.md | head -n 1 | cat
|
||||
|
||||
# Read Types section
|
||||
sed -n '/\\[Types\\]/,/\\[Files\\]/p' implementation_plan.md | head -n 1 | cat
|
||||
|
||||
# Read Files section
|
||||
sed -n '/\\[Files\\]/,/\\[Functions\\]/p' implementation_plan.md | head -n 1 | cat
|
||||
|
||||
# Read Functions section
|
||||
sed -n '/\\[Functions\\]/,/\\[Classes\\]/p' implementation_plan.md | head -n 1 | cat
|
||||
|
||||
# Read Classes section
|
||||
sed -n '/\\[Classes\\]/,/\\[Dependencies\\]/p' implementation_plan.md | head -n 1 | cat
|
||||
|
||||
# Read Dependencies section
|
||||
sed -n '/\\[Dependencies\\]/,/\\[Testing\\]/p' implementation_plan.md | head -n 1 | cat
|
||||
|
||||
# Read Testing section
|
||||
sed -n '/\\[Testing\\]/,/\\[Implementation Order\\]/p' implementation_plan.md | head -n 1 | cat
|
||||
|
||||
# Read Implementation Order section
|
||||
sed -n '/\\[Implementation Order\\]/,$p' implementation_plan.md | cat
|
||||
`
|
||||
}
|
||||
|
||||
|
||||
**Task Progress Format:**
|
||||
<IMPORTANT>
|
||||
You absolutely must include the task_progress contents in context when creating the new task. When providing it, do not wrap it in XML tags- instead provide it like this:
|
||||
|
||||
|
||||
task_progress Items:
|
||||
- [ ] Step 1: Brief description of first implementation step
|
||||
- [ ] Step 2: Brief description of second implementation step
|
||||
- [ ] Step 3: Brief description of third implementation step
|
||||
- [ ] Step N: Brief description of final implementation step
|
||||
|
||||
|
||||
You also MUST include the path to the markdown file you have created in your new task prompt. You should do this as follows:
|
||||
|
||||
Refer to @path/to/file/markdown.md for a complete breakdown of the task requirements and steps. You should periodically read this file again.
|
||||
|
||||
{{FOCUS_CHAIN_PARAM}}
|
||||
|
||||
{{NEW_TASK_INSTRUCTIONS}}
|
||||
|
||||
### Mode Switching
|
||||
|
||||
When creating the new task, request a switch to "act mode" if you are currently in "plan mode". This ensures the implementation agent operates in execution mode rather than planning mode.
|
||||
</IMPORTANT>
|
||||
|
||||
## Quality Standards
|
||||
|
||||
You must be specific with exact file paths, function names, and class names. You must be comprehensive and avoid assuming implicit understanding. You must be practical and consider real-world constraints and edge cases. You must use precise technical language and avoid ambiguity.
|
||||
|
||||
Your implementation plan should be detailed enough that another developer could execute it without additional investigation.
|
||||
|
||||
---
|
||||
|
||||
**Execute all four steps in sequence. Your role is to plan thoroughly, not to implement. Code creation begins only after the new task is created and you receive explicit instruction to proceed.**
|
||||
|
||||
Below is the user's input when they indicated that they wanted to create a comprehensive implementation plan.
|
||||
</explicit_instructions>
|
||||
`
|
||||
}
|
||||
@@ -1,285 +0,0 @@
|
||||
import { isGemini2dot5ModelFamily } from "@utils/model-utils"
|
||||
import { getShell } from "@utils/shell"
|
||||
import type { SystemPromptContext } from "@/core/prompts/system-prompt/types"
|
||||
import type { DeepPlanningVariant } from "../types"
|
||||
|
||||
/**
|
||||
* Creates the Google Gemini 2.5 variant for deep-planning prompt
|
||||
* This variant is optimized for Gemini 2.5 models
|
||||
*/
|
||||
export function createGeminiVariant(): DeepPlanningVariant {
|
||||
return {
|
||||
id: "gemini",
|
||||
description: "Deep-planning variant optimized for Google Gemini 2.5 models",
|
||||
family: "gemini",
|
||||
version: 1,
|
||||
matcher: (context: SystemPromptContext) => {
|
||||
const modelId = context.providerInfo?.model?.id
|
||||
if (!modelId) {
|
||||
return false
|
||||
}
|
||||
return isGemini2dot5ModelFamily(modelId)
|
||||
},
|
||||
template: generateTemplate(),
|
||||
}
|
||||
}
|
||||
|
||||
/**
|
||||
* Generates the deep-planning template with shell-specific commands
|
||||
*/
|
||||
function generateTemplate(): string {
|
||||
const detectedShell = getShell()
|
||||
|
||||
// FIXME: detectedShell returns a non-string value on some Windows machines
|
||||
let isPowerShell = false
|
||||
try {
|
||||
isPowerShell =
|
||||
detectedShell != null &&
|
||||
typeof detectedShell === "string" &&
|
||||
(detectedShell.toLowerCase().includes("powershell") || detectedShell.toLowerCase().includes("pwsh"))
|
||||
} catch {}
|
||||
|
||||
return `<explicit_instructions type="deep-planning">
|
||||
Your task is to create a comprehensive implementation plan before writing any code. This process has four distinct steps that must be completed in order.
|
||||
|
||||
Your behavior should be methodical and thorough - take time to understand the codebase completely before making any recommendations. The quality of your investigation directly impacts the success of the implementation.
|
||||
|
||||
## STEP 1: Silent Investigation
|
||||
|
||||
<important>
|
||||
until explicitly instructed by the user to proceed with coding.
|
||||
You must thoroughly understand the existing codebase before proposing any changes.
|
||||
Perform your research without commentary or narration. Execute commands and read files without explaining what you're about to do. Only speak up if you have specific questions for the user.
|
||||
</important>
|
||||
|
||||
### Required Research Activities
|
||||
You must first use the read_file tool to examine several source files, configuration files, and documentation to better inform subsequent research steps. You should only use read_file to prepare for more granular searching. Use this tool to determine the language(s) used in the codebase, and to identify the domain(s) relevant to the user's request.
|
||||
|
||||
You must then use terminal commands to gather information about the codebase structure and patterns relevant to the user's request. All terminal output must be piped to cat for visibility.
|
||||
You will tailor these commands to explore and identify key functions, classes, methods, types, and variables that are directly, or indirectly related to the task.
|
||||
These commands must be crafted to not produce exceptionally long or verbose search results. For example, you should exclude dependency folders such as node_modules, venv or php vendor, etc. Carefully consider the scope of search patterns. Use the results of your read_file tool calls to tailor the commands for balanced search result lengths. If a command returns no results, you may loosen the search patterns or scope slightly. If a command returns hundreds or thousands of results, you should adjust subsequent commands to be more targeted.
|
||||
|
||||
Execute these commands to build your understanding. Adjust subsequent commands based on the output you have received from each previous command, informing the scope and direction of your search.
|
||||
|
||||
Here are some example commands, remember to adjust them as instructed previously:
|
||||
|
||||
${
|
||||
isPowerShell
|
||||
? // PowerShell-specific commands
|
||||
`
|
||||
# Discover project structure and file types
|
||||
Get-ChildItem -Recurse -Include "*.py","*.js","*.ts","*.java","*.cpp","*.go" | Select-Object -First 30 | Select-Object FullName
|
||||
|
||||
# Find all class and function definitions
|
||||
Get-ChildItem -Recurse -Include "*.py","*.js","*.ts","*.java","*.cpp","*.go" | Select-String -Pattern "class|function|def|interface|struct"
|
||||
|
||||
# Analyze import patterns and dependencies
|
||||
Get-ChildItem -Recurse -Include "*.py","*.js","*.ts","*.java","*.cpp" | Select-String -Pattern "import|from|require|#include" | Sort-Object | Get-Unique
|
||||
|
||||
# Find dependency manifests
|
||||
Get-ChildItem -Recurse -Include "requirements*.txt","package.json","Cargo.toml","pom.xml","Gemfile","go.mod" | Get-Content
|
||||
|
||||
# Identify technical debt and TODOs
|
||||
Get-ChildItem -Recurse -Include "*.py","*.js","*.ts","*.java","*.cpp","*.go" | Select-String -Pattern "TODO|FIXME|XXX|HACK|NOTE"
|
||||
`
|
||||
: // bash/zsh-specific commands
|
||||
`
|
||||
# Discover project structure and file types
|
||||
find . -type f -name "*.py" -o -name "*.js" -o -name "*.ts" -o -name "*.java" -o -name "*.cpp" -o -name "*.go" | head -30 | cat
|
||||
|
||||
# Find all class and function definitions
|
||||
grep -r "class\\|function\\|def\\|interface\\|struct\\|func\\|type.*struct\\|type.*interface" --include="*.py" --include="*.js" --include="*.ts" --include="*.java" --include="*.cpp" --include="*.go" . | cat
|
||||
|
||||
# Analyze import patterns and dependencies
|
||||
grep -r "import\\|from\\|require\\|#include" --include="*.py" --include="*.js" --include="*.ts" --include="*.java" --include="*.cpp" . | sort | uniq | cat
|
||||
|
||||
# Find dependency manifests
|
||||
find . -name "requirements*.txt" -o -name "package.json" -o -name "Cargo.toml" -o -name "pom.xml" -o -name "Gemfile" -o -name "go.mod" | xargs cat
|
||||
|
||||
# Identify technical debt and TODOs
|
||||
grep -r "TODO\\|FIXME\\|XXX\\|HACK\\|NOTE" --include="*.py" --include="*.js" --include="*.ts" --include="*.java" --include="*.cpp" --include="*.go" . | cat
|
||||
`
|
||||
}
|
||||
|
||||
|
||||
## STEP 2: Discussion and Questions
|
||||
|
||||
Ask the user brief, targeted questions that will influence your implementation plan. Keep your questions concise and conversational. Ask only essential questions needed to create an accurate plan.
|
||||
|
||||
**Ask questions only when necessary for:**
|
||||
- Clarifying ambiguous requirements or specifications
|
||||
- Choosing between multiple equally valid implementation approaches
|
||||
- Confirming assumptions about existing system behavior or constraints
|
||||
- Understanding preferences for specific technical decisions that will affect the implementation
|
||||
|
||||
Your questions should be direct and specific. Avoid long explanations or multiple questions in one response.
|
||||
|
||||
## STEP 3: Create Implementation Plan Document
|
||||
|
||||
Create a structured markdown document containing your complete implementation plan. The document must follow this exact format with clearly marked sections:
|
||||
|
||||
### Document Structure Requirements
|
||||
|
||||
Your implementation plan must be saved as implementation_plan.md, and *must* be structured as follows:
|
||||
|
||||
|
||||
# Implementation Plan
|
||||
|
||||
[Overview]
|
||||
Single sentence describing the overall goal.
|
||||
|
||||
Multiple paragraphs outlining the scope, context, and high-level approach. Explain why this implementation is needed and how it fits into the existing system.
|
||||
|
||||
[Types]
|
||||
Single sentence describing the type system changes.
|
||||
|
||||
Detailed type definitions, interfaces, enums, or data structures with complete specifications. Include field names, types, validation rules, and relationships.
|
||||
|
||||
[Files]
|
||||
Single sentence describing file modifications.
|
||||
|
||||
Detailed breakdown:
|
||||
- New files to be created (with full paths and purpose)
|
||||
- Existing files to be modified (with specific changes)
|
||||
- Files to be deleted or moved
|
||||
- Configuration file updates
|
||||
|
||||
[Functions]
|
||||
Single sentence describing function modifications.
|
||||
|
||||
Detailed breakdown:
|
||||
- New functions (name, signature, file path, purpose)
|
||||
- Modified functions (exact name, current file path, required changes)
|
||||
- Removed functions (name, file path, reason, migration strategy)
|
||||
|
||||
[Classes]
|
||||
Single sentence describing class modifications.
|
||||
|
||||
Detailed breakdown:
|
||||
- New classes (name, file path, key methods, inheritance)
|
||||
- Modified classes (exact name, file path, specific modifications)
|
||||
- Removed classes (name, file path, replacement strategy)
|
||||
|
||||
[Dependencies]
|
||||
Single sentence describing dependency modifications.
|
||||
|
||||
Details of new packages, version changes, and integration requirements.
|
||||
|
||||
[Testing]
|
||||
Single sentence describing testing approach.
|
||||
|
||||
Test file requirements, existing test modifications, and validation strategies.
|
||||
|
||||
[Implementation Order]
|
||||
Single sentence describing the implementation sequence.
|
||||
|
||||
Numbered steps showing the logical order of changes to minimize conflicts and ensure successful integration.
|
||||
|
||||
|
||||
## STEP 4: Create Implementation Task
|
||||
|
||||
Use the new_task command to create a task for implementing the plan. The task must include a <task_progress> list that breaks down the implementation into trackable steps.
|
||||
|
||||
### Task Creation Requirements
|
||||
|
||||
Your new task should be self-contained and reference the plan document rather than requiring additional codebase investigation. Include these specific instructions in the task description:
|
||||
|
||||
**Plan Document Navigation Commands:**
|
||||
The implementation agent should use these commands to read specific sections of the implementation plan. You should adapt these examples to conform to the structure of the .md file you created, and explicitly provide them when creating the new task:
|
||||
|
||||
${
|
||||
isPowerShell
|
||||
? // PowerShell-specific commands
|
||||
`
|
||||
# Read Overview section
|
||||
$content = Get-Content implementation_plan.md; $start = ($content | Select-String -Pattern '\\[Overview\\]').LineNumber; $end = ($content | Select-String -Pattern '\\[Types\\]').LineNumber; $content[($start-1)..($end-2)]
|
||||
|
||||
# Read Types section
|
||||
$content = Get-Content implementation_plan.md; $start = ($content | Select-String -Pattern '\\[Types\\]').LineNumber; $end = ($content | Select-String -Pattern '\\[Files\\]').LineNumber; $content[($start-1)..($end-2)]
|
||||
|
||||
# Read Files section
|
||||
$content = Get-Content implementation_plan.md; $start = ($content | Select-String -Pattern '\\[Files\\]').LineNumber; $end = ($content | Select-String -Pattern '\\[Functions\\]').LineNumber; $content[($start-1)..($end-2)]
|
||||
|
||||
# Read Functions section
|
||||
$content = Get-Content implementation_plan.md; $start = ($content | Select-String -Pattern '\\[Functions\\]').LineNumber; $end = ($content | Select-String -Pattern '\\[Classes\\]').LineNumber; $content[($start-1)..($end-2)]
|
||||
|
||||
# Read Classes section
|
||||
$content = Get-Content implementation_plan.md; $start = ($content | Select-String -Pattern '\\[Classes\\]').LineNumber; $end = ($content | Select-String -Pattern '\\[Dependencies\\]').LineNumber; $content[($start-1)..($end-2)]
|
||||
|
||||
# Read Dependencies section
|
||||
$content = Get-Content implementation_plan.md; $start = ($content | Select-String -Pattern '\\[Dependencies\\]').LineNumber; $end = ($content | Select-String -Pattern '\\[Testing\\]').LineNumber; $content[($start-1)..($end-2)]
|
||||
|
||||
# Read Testing section
|
||||
$content = Get-Content implementation_plan.md; $start = ($content | Select-String -Pattern '\\[Testing\\]').LineNumber; $end = ($content | Select-String -Pattern '\\[Implementation Order\\]').LineNumber; $content[($start-1)..($end-2)]
|
||||
|
||||
# Read Implementation Order section
|
||||
$content = Get-Content implementation_plan.md; $start = ($content | Select-String -Pattern '\\[Implementation Order\\]').LineNumber; $content[($start-1)..($content.Length-1)]
|
||||
`
|
||||
: // bash/zsh-specific commands
|
||||
`
|
||||
# Read Overview section
|
||||
sed -n '/\\[Overview\\]/,/\\[Types\\]/p' implementation_plan.md | head -n 1 | cat
|
||||
|
||||
# Read Types section
|
||||
sed -n '/\\[Types\\]/,/\\[Files\\]/p' implementation_plan.md | head -n 1 | cat
|
||||
|
||||
# Read Files section
|
||||
sed -n '/\\[Files\\]/,/\\[Functions\\]/p' implementation_plan.md | head -n 1 | cat
|
||||
|
||||
# Read Functions section
|
||||
sed -n '/\\[Functions\\]/,/\\[Classes\\]/p' implementation_plan.md | head -n 1 | cat
|
||||
|
||||
# Read Classes section
|
||||
sed -n '/\\[Classes\\]/,/\\[Dependencies\\]/p' implementation_plan.md | head -n 1 | cat
|
||||
|
||||
# Read Dependencies section
|
||||
sed -n '/\\[Dependencies\\]/,/\\[Testing\\]/p' implementation_plan.md | head -n 1 | cat
|
||||
|
||||
# Read Testing section
|
||||
sed -n '/\\[Testing\\]/,/\\[Implementation Order\\]/p' implementation_plan.md | head -n 1 | cat
|
||||
|
||||
# Read Implementation Order section
|
||||
sed -n '/\\[Implementation Order\\]/,$p' implementation_plan.md | cat
|
||||
`
|
||||
}
|
||||
|
||||
|
||||
**Task Progress Format:**
|
||||
<IMPORTANT>
|
||||
You absolutely must include the task_progress contents in context when creating the new task. When providing it, do not wrap it in XML tags- instead provide it like this:
|
||||
|
||||
|
||||
task_progress Items:
|
||||
- [ ] Step 1: Brief description of first implementation step
|
||||
- [ ] Step 2: Brief description of second implementation step
|
||||
- [ ] Step 3: Brief description of third implementation step
|
||||
- [ ] Step N: Brief description of final implementation step
|
||||
|
||||
|
||||
You also MUST include the path to the markdown file you have created in your new task prompt. You should do this as follows:
|
||||
|
||||
Refer to @path/to/file/markdown.md for a complete breakdown of the task requirements and steps. You should periodically read this file again.
|
||||
|
||||
{{FOCUS_CHAIN_PARAM}}
|
||||
|
||||
{{NEW_TASK_INSTRUCTIONS}}
|
||||
|
||||
### Mode Switching
|
||||
|
||||
When creating the new task, request a switch to "act mode" if you are currently in "plan mode". This ensures the implementation agent operates in execution mode rather than planning mode.
|
||||
</IMPORTANT>
|
||||
|
||||
## Quality Standards
|
||||
|
||||
You must be specific with exact file paths, function names, and class names. You must be comprehensive and avoid assuming implicit understanding. You must be practical and consider real-world constraints and edge cases. You must use precise technical language and avoid ambiguity.
|
||||
|
||||
Your implementation plan should be detailed enough that another developer could execute it without additional investigation.
|
||||
|
||||
---
|
||||
|
||||
**Execute all four steps in sequence. Your role is to plan thoroughly, not to implement. Code creation begins only after the new task is created and you receive explicit instruction to proceed.**
|
||||
|
||||
Below is the user's input when they indicated that they wanted to create a comprehensive implementation plan.
|
||||
</explicit_instructions>
|
||||
`
|
||||
}
|
||||
@@ -1,260 +0,0 @@
|
||||
import { isGemini3ModelFamily } from "@utils/model-utils"
|
||||
import { getShell } from "@utils/shell"
|
||||
import type { SystemPromptContext } from "@/core/prompts/system-prompt/types"
|
||||
import type { DeepPlanningVariant } from "../types"
|
||||
|
||||
/**
|
||||
* Creates the Gemini 3 variant for deep-planning prompt
|
||||
*/
|
||||
export function createGemini3Variant(): DeepPlanningVariant {
|
||||
return {
|
||||
id: "gemini-3",
|
||||
description: "Deep-planning variant optimized for Gemini 3 models",
|
||||
family: "gemini-3",
|
||||
version: 1,
|
||||
matcher: (context: SystemPromptContext) => {
|
||||
const modelId = context.providerInfo?.model?.id
|
||||
if (!modelId) {
|
||||
return false
|
||||
}
|
||||
return isGemini3ModelFamily(modelId)
|
||||
},
|
||||
template: "", // Template is dynamically generated in getDeepPlanningPrompt() based on focus chain settings
|
||||
}
|
||||
}
|
||||
|
||||
/**
|
||||
* Generates the deep-planning template with shell-specific commands
|
||||
* @param focusChainEnabled Whether focus chain (task_progress) is enabled for this task
|
||||
* @param enableNativeToolCalls Whether native tool calling is enabled
|
||||
*/
|
||||
export function generateGemini3Template(focusChainEnabled: boolean, enableNativeToolCalls: boolean): string {
|
||||
const detectedShell = getShell()
|
||||
|
||||
let isPowerShell = false
|
||||
try {
|
||||
isPowerShell =
|
||||
detectedShell != null &&
|
||||
typeof detectedShell === "string" &&
|
||||
(detectedShell.toLowerCase().includes("powershell") || detectedShell.toLowerCase().includes("pwsh"))
|
||||
} catch {}
|
||||
|
||||
return `<explicit_instructions type="deep-planning">
|
||||
Your task is to create a comprehensive implementation plan before writing any code. This process has five distinct steps that must be completed in order:
|
||||
1. Silent Read Investigation
|
||||
2. Silent Terminal Investigation
|
||||
3. Discussion and Questions
|
||||
4. Create Implementation Plan Document
|
||||
5. Create new_task for Implementation Phase
|
||||
|
||||
${focusChainEnabled ? `You should track these five steps in your task_progress parameter, and update it only when steps are completed.` : ""}
|
||||
Your behavior should be methodical and thorough - take time to understand the codebase completely before making any recommendations. The quality of your investigation and use of targeted reads/searches directly impacts the success of the implementation.
|
||||
|
||||
<IMPORTANT>
|
||||
Execute only exploration and plan generation steps until explicitly instructed by the user to proceed with coding.
|
||||
You must thoroughly understand the existing codebase before proposing any changes.
|
||||
Perform your research without commentary or narration. Execute commands and read files without explaining what you're about to do. Only speak up if you have specific questions for the user.
|
||||
</IMPORTANT>
|
||||
|
||||
## STEP 1: Silent Read Investigation
|
||||
|
||||
### Required Research Activities
|
||||
You MUST first use the read_file tool to examine several source files, configuration files, and documentation to better inform subsequent research steps. You should only use read_file to prepare for more granular searching. Use this step to get the big picture, then you will use the next step for granular details by searching using terminal commands. Use this tool to determine the language(s) used in the codebase, and to identify the domain(s) relevant to the user's request.
|
||||
|
||||
|
||||
## STEP 2: Silent Terminal Investigation
|
||||
|
||||
### Required Research Activities
|
||||
You MUST use terminal commands to gather information about the codebase structure and patterns relevant to the user's request.
|
||||
You will tailor these commands to explore and identify key functions, classes, methods, types, and variables that are directly, or indirectly related to the task.
|
||||
These commands must be crafted to not produce exceptionally long or verbose search results. For example, you should exclude dependency folders such as node_modules, venv or php vendor, etc. Carefully consider the scope of search patterns. Use the results of your read_file tool calls to tailor the commands for balanced search result lengths. If a command returns no results, you may loosen the search patterns or scope slightly. If a command returns hundreds or thousands of results, you should adjust subsequent commands to be more targeted.
|
||||
Execute these commands to build your understanding. Adjust subsequent commands based on the output you have received from each previous command, informing the scope and direction of your search.
|
||||
You should only execute one command at a time for the first 1-3 commands. Do not chain search commands until you have executed and interpreted the results of several search commands, then use the context you have gathered to inform more complex chained commands.
|
||||
|
||||
Here are some example commands, remember to adjust them as instructed previously:
|
||||
${
|
||||
isPowerShell
|
||||
? // PowerShell-specific commands
|
||||
`
|
||||
# Discover project structure and file types
|
||||
Get-ChildItem -Recurse -Include "*.py","*.js","*.ts","*.java","*.cpp","*.go" | Select-Object -First 30 | Select-Object FullName
|
||||
|
||||
# Find all class and function definitions
|
||||
Get-ChildItem -Recurse -Include "*.py","*.js","*.ts","*.java","*.cpp","*.go" | Select-String -Pattern "class|function|def|interface|struct"
|
||||
|
||||
# Analyze import patterns and dependencies
|
||||
Get-ChildItem -Recurse -Include "*.py","*.js","*.ts","*.java","*.cpp" | Select-String -Pattern "import|from|require|#include" | Sort-Object | Get-Unique
|
||||
|
||||
# Find dependency manifests
|
||||
Get-ChildItem -Recurse -Include "requirements*.txt","package.json","Cargo.toml","pom.xml","Gemfile","go.mod" | Get-Content
|
||||
|
||||
# Identify technical debt and TODOs
|
||||
Get-ChildItem -Recurse -Include "*.py","*.js","*.ts","*.java","*.cpp","*.go" | Select-String -Pattern "TODO|FIXME|XXX|HACK|NOTE"
|
||||
`
|
||||
: // bash/zsh-specific commands
|
||||
`
|
||||
# Discover project structure and file types
|
||||
find . -type f -name "*.py" -o -name "*.js" -o -name "*.ts" -o -name "*.java" -o -name "*.cpp" -o -name "*.go" | head -30 | cat
|
||||
|
||||
# Find all class and function definitions
|
||||
grep -r "class\\|function\\|def\\|interface\\|struct\\|func\\|type.*struct\\|type.*interface" --include="*.py" --include="*.js" --include="*.ts" --include="*.java" --include="*.cpp" --include="*.go" . | cat
|
||||
|
||||
# Analyze import patterns and dependencies
|
||||
grep -r "import\\|from\\|require\\|#include" --include="*.py" --include="*.js" --include="*.ts" --include="*.java" --include="*.cpp" . | sort | uniq | cat
|
||||
|
||||
# Find dependency manifests
|
||||
find . -name "requirements*.txt" -o -name "package.json" -o -name "Cargo.toml" -o -name "pom.xml" -o -name "Gemfile" -o -name "go.mod" | xargs cat
|
||||
|
||||
# Identify technical debt and TODOs
|
||||
grep -r "TODO\\|FIXME\\|XXX\\|HACK\\|NOTE" --include="*.py" --include="*.js" --include="*.ts" --include="*.java" --include="*.cpp" --include="*.go" . | cat
|
||||
`
|
||||
}
|
||||
|
||||
|
||||
## STEP 3: Discussion and Questions
|
||||
|
||||
Ask the user brief, targeted questions that will influence your implementation plan. Keep your questions concise and conversational. Ask only essential questions needed to create an accurate plan.
|
||||
|
||||
**Ask questions only when necessary for:**
|
||||
- Clarifying ambiguous requirements or unclear specifications
|
||||
- Choosing between multiple equally valid implementation approaches that have significant trade-offs
|
||||
- Confirming non-trivial assumptions about existing system behavior or constraints
|
||||
- Understanding preferences for specific technical decisions that will affect the final implementation's behavior or code maintainability
|
||||
|
||||
Your questions should be direct and specific. Avoid long explanations or multiple questions in one response. Only ask one question at a time. You may ask several questions if required and within scope of the task.
|
||||
|
||||
## STEP 4: Create Implementation Plan Document
|
||||
|
||||
Once you have obtained sufficient context to understand all code modifications that will be required, create a structured markdown document containing your complete implementation plan. The document must follow this exact format with clearly marked sections:
|
||||
|
||||
### Document Structure Requirements
|
||||
|
||||
Your implementation plan must be saved as implementation_plan.md, and *must* be structured as follows:
|
||||
|
||||
<example_implementation_plan>
|
||||
# Implementation Plan
|
||||
|
||||
[Overview]
|
||||
Single sentence describing the overall goal.
|
||||
|
||||
Multiple paragraphs outlining the scope, context, and high-level approach. Explain why this implementation is needed and how it fits into the existing system.
|
||||
|
||||
[Types]
|
||||
Single sentence describing the type system changes.
|
||||
|
||||
Detailed type definitions, interfaces, enums, or data structures with complete specifications. Include field names, types, validation rules, and relationships.
|
||||
|
||||
[Files]
|
||||
Single sentence describing file modifications.
|
||||
|
||||
Detailed breakdown:
|
||||
- New files to be created (with full paths and purpose)
|
||||
- Existing files to be modified (with specific changes)
|
||||
- Files to be deleted or moved
|
||||
- Configuration file updates
|
||||
|
||||
[Functions]
|
||||
Single sentence describing function modifications.
|
||||
|
||||
Detailed breakdown:
|
||||
- New functions (name, signature, file path, purpose)
|
||||
- Modified functions (exact name, current file path, required changes)
|
||||
- Removed functions (name, file path, reason, migration strategy)
|
||||
|
||||
[Classes]
|
||||
Single sentence describing class modifications.
|
||||
|
||||
Detailed breakdown:
|
||||
- New classes (name, file path, key methods, inheritance)
|
||||
- Modified classes (exact name, file path, specific modifications)
|
||||
- Removed classes (name, file path, replacement strategy)
|
||||
|
||||
[Dependencies]
|
||||
Single sentence describing dependency modifications.
|
||||
|
||||
Details of new packages, version changes, and integration requirements.
|
||||
|
||||
[Implementation Order]
|
||||
Single sentence describing the implementation sequence.
|
||||
|
||||
Numbered steps showing the logical order of changes to minimize conflicts and ensure successful integration.
|
||||
${focusChainEnabled ? "A task_progress list of steps that will need to be completed during the implementation" : ""}
|
||||
|
||||
</example_implementation_plan>
|
||||
|
||||
## STEP 5: Create Implementation new_task
|
||||
|
||||
Use the new_task command to create a task for implementing the plan. ${focusChainEnabled ? "The task must include a <task_progress> list that breaks down the implementation into trackable steps." : ""}
|
||||
|
||||
### Task Creation Requirements
|
||||
|
||||
<IMPORTANT>
|
||||
**Standalone Product:**
|
||||
Your new task should be self-contained and reference the plan document rather than requiring additional codebase investigation. Include these specific instructions in the task description:
|
||||
|
||||
${
|
||||
focusChainEnabled
|
||||
? `**Task Progress Format:**
|
||||
You absolutely MUST include the task_progress contents in context when creating the new task. When providing it, do not wrap it in XML tags- instead provide it like this:
|
||||
|
||||
task_progress Items:
|
||||
- [ ] Step 1: Brief description of first implementation step
|
||||
- [ ] Step 2: Brief description of second implementation step
|
||||
- [ ] Step 3: Brief description of third implementation step
|
||||
- [ ] Step N: Brief description of subsequent/final implementation step(s)
|
||||
|
||||
**Markdown Implementation Plan Path:**
|
||||
You also MUST include the path to the markdown file you have created in your new task prompt. You should do this as follows:
|
||||
Refer to @path/to/file/markdown.md for a complete breakdown of the task requirements and steps. You should periodically read this file again.`
|
||||
: ""
|
||||
}
|
||||
</IMPORTANT>
|
||||
|
||||
${
|
||||
enableNativeToolCalls
|
||||
? `**new_task Tool Definition:**
|
||||
|
||||
When you are ready to create the implementation task, you must call the new_task tool with the following structure:
|
||||
|
||||
{
|
||||
"name": "new_task",
|
||||
"arguments": {
|
||||
"context": "Your detailed context here following the 5-point structure..."
|
||||
}
|
||||
}
|
||||
|
||||
The context parameter should include all five sections as described above.
|
||||
|
||||
`
|
||||
: `**new_task Tool Definition:**
|
||||
|
||||
When you are ready to create the implementation task, you must call the new_task tool with the following structure:
|
||||
|
||||
<new_task>
|
||||
<context>Your detailed context here following the 5-point structure...</context>
|
||||
</new_task>
|
||||
|
||||
The context parameter should include all five sections as described above.
|
||||
|
||||
`
|
||||
}
|
||||
### Mode Switching
|
||||
|
||||
<IMPORTANT>
|
||||
When creating the new task, request a switch to "act mode" if you are currently in "plan mode". This ensures the implementation agent operates in execution mode rather than planning mode.
|
||||
</IMPORTANT>
|
||||
|
||||
## Quality Standards
|
||||
|
||||
You must be specific with exact file paths, function names, and class names. You must be comprehensive and avoid assuming implicit understanding. You must be practical and consider real-world constraints and edge cases. You must use precise technical language and avoid ambiguity.
|
||||
|
||||
Your implementation plan should be detailed enough that another developer could execute it without additional investigation.
|
||||
|
||||
---
|
||||
|
||||
**Execute all five steps in sequence. Your role is to plan thoroughly, not to implement. Code creation begins only after the new task is created and you receive explicit instruction to proceed.**
|
||||
|
||||
Below is the user's input from when they indicated that they wanted to create this comprehensive implementation plan.
|
||||
</explicit_instructions>
|
||||
`
|
||||
}
|
||||
@@ -1,268 +0,0 @@
|
||||
import { getShell } from "@utils/shell"
|
||||
import type { DeepPlanningVariant } from "../types"
|
||||
|
||||
/**
|
||||
* Creates the generic fallback variant for deep-planning prompt
|
||||
* This variant is used when no specific model family matcher applies
|
||||
*/
|
||||
export function createGenericVariant(): DeepPlanningVariant {
|
||||
return {
|
||||
id: "generic",
|
||||
description: "Generic fallback variant for deep-planning prompt, used for all models",
|
||||
family: "generic",
|
||||
version: 1,
|
||||
matcher: () => true, // Always matches as fallback
|
||||
template: generateTemplate(),
|
||||
}
|
||||
}
|
||||
|
||||
/**
|
||||
* Generates the deep-planning template with shell-specific commands
|
||||
*/
|
||||
function generateTemplate(): string {
|
||||
const detectedShell = getShell()
|
||||
|
||||
// FIXME: detectedShell returns a non-string value on some Windows machines
|
||||
let isPowerShell = false
|
||||
try {
|
||||
isPowerShell =
|
||||
detectedShell != null &&
|
||||
typeof detectedShell === "string" &&
|
||||
(detectedShell.toLowerCase().includes("powershell") || detectedShell.toLowerCase().includes("pwsh"))
|
||||
} catch {}
|
||||
|
||||
return `<explicit_instructions type="deep-planning">
|
||||
Your task is to create a comprehensive implementation plan before writing any code. This process has four distinct steps that must be completed in order.
|
||||
|
||||
Your behavior should be methodical and thorough - take time to understand the codebase completely before making any recommendations. The quality of your investigation directly impacts the success of the implementation.
|
||||
|
||||
## STEP 1: Silent Investigation
|
||||
|
||||
<important>
|
||||
until explicitly instructed by the user to proceed with coding.
|
||||
You must thoroughly understand the existing codebase before proposing any changes.
|
||||
Perform your research without commentary or narration. Execute commands and read files without explaining what you're about to do. Only speak up if you have specific questions for the user.
|
||||
</important>
|
||||
|
||||
### Required Research Activities
|
||||
You must use the read_file tool to examine relevant source files, configuration files, and documentation. You must use terminal commands to gather information about the codebase structure and patterns. All terminal output must be piped to cat for visibility.
|
||||
|
||||
### Essential Terminal Commands
|
||||
First, determine the language(s) used in the codebase, then execute these commands to build your understanding. You must tailor them to the codebase and ensure the output is not overly verbose. For example, you should exclude dependency folders such as node_modules, venv or php vendor, etc. These are only examples, the exact commands will differ depending on the codebase.
|
||||
|
||||
${
|
||||
isPowerShell
|
||||
? `
|
||||
# Discover project structure and file types
|
||||
Get-ChildItem -Recurse -Include "*.py","*.js","*.ts","*.java","*.cpp","*.go" | Select-Object -First 30 | Select-Object FullName
|
||||
|
||||
# Find all class and function definitions
|
||||
Get-ChildItem -Recurse -Include "*.py","*.js","*.ts","*.java","*.cpp","*.go" | Select-String -Pattern "class|function|def|interface|struct"
|
||||
|
||||
# Analyze import patterns and dependencies
|
||||
Get-ChildItem -Recurse -Include "*.py","*.js","*.ts","*.java","*.cpp" | Select-String -Pattern "import|from|require|#include" | Sort-Object | Get-Unique
|
||||
|
||||
# Find dependency manifests
|
||||
Get-ChildItem -Recurse -Include "requirements*.txt","package.json","Cargo.toml","pom.xml","Gemfile","go.mod" | Get-Content
|
||||
|
||||
# Identify technical debt and TODOs
|
||||
Get-ChildItem -Recurse -Include "*.py","*.js","*.ts","*.java","*.cpp","*.go" | Select-String -Pattern "TODO|FIXME|XXX|HACK|NOTE"
|
||||
`
|
||||
: `
|
||||
# Discover project structure and file types
|
||||
find . -type f -name "*.py" -o -name "*.js" -o -name "*.ts" -o -name "*.java" -o -name "*.cpp" -o -name "*.go" | head -30 | cat
|
||||
|
||||
# Find all class and function definitions
|
||||
grep -r "class\\|function\\|def\\|interface\\|struct\\|func\\|type.*struct\\|type.*interface" --include="*.py" --include="*.js" --include="*.ts" --include="*.java" --include="*.cpp" --include="*.go" . | cat
|
||||
|
||||
# Analyze import patterns and dependencies
|
||||
grep -r "import\\|from\\|require\\|#include" --include="*.py" --include="*.js" --include="*.ts" --include="*.java" --include="*.cpp" . | sort | uniq | cat
|
||||
|
||||
# Find dependency manifests
|
||||
find . -name "requirements*.txt" -o -name "package.json" -o -name "Cargo.toml" -o -name "pom.xml" -o -name "Gemfile" -o -name "go.mod" | xargs cat
|
||||
|
||||
# Identify technical debt and TODOs
|
||||
grep -r "TODO\\|FIXME\\|XXX\\|HACK\\|NOTE" --include="*.py" --include="*.js" --include="*.ts" --include="*.java" --include="*.cpp" --include="*.go" . | cat
|
||||
`
|
||||
}
|
||||
|
||||
|
||||
## STEP 2: Discussion and Questions
|
||||
|
||||
Ask the user brief, targeted questions that will influence your implementation plan. Keep your questions concise and conversational. Ask only essential questions needed to create an accurate plan.
|
||||
|
||||
**Ask questions only when necessary for:**
|
||||
- Clarifying ambiguous requirements or specifications
|
||||
- Choosing between multiple equally valid implementation approaches
|
||||
- Confirming assumptions about existing system behavior or constraints
|
||||
- Understanding preferences for specific technical decisions that will affect the implementation
|
||||
|
||||
Your questions should be direct and specific. Avoid long explanations or multiple questions in one response.
|
||||
|
||||
## STEP 3: Create Implementation Plan Document
|
||||
|
||||
Create a structured markdown document containing your complete implementation plan. The document must follow this exact format with clearly marked sections:
|
||||
|
||||
### Document Structure Requirements
|
||||
|
||||
Your implementation plan must be saved as implementation_plan.md, and *must* be structured as follows:
|
||||
|
||||
|
||||
# Implementation Plan
|
||||
|
||||
[Overview]
|
||||
Single sentence describing the overall goal.
|
||||
|
||||
Multiple paragraphs outlining the scope, context, and high-level approach. Explain why this implementation is needed and how it fits into the existing system.
|
||||
|
||||
[Types]
|
||||
Single sentence describing the type system changes.
|
||||
|
||||
Detailed type definitions, interfaces, enums, or data structures with complete specifications. Include field names, types, validation rules, and relationships.
|
||||
|
||||
[Files]
|
||||
Single sentence describing file modifications.
|
||||
|
||||
Detailed breakdown:
|
||||
- New files to be created (with full paths and purpose)
|
||||
- Existing files to be modified (with specific changes)
|
||||
- Files to be deleted or moved
|
||||
- Configuration file updates
|
||||
|
||||
[Functions]
|
||||
Single sentence describing function modifications.
|
||||
|
||||
Detailed breakdown:
|
||||
- New functions (name, signature, file path, purpose)
|
||||
- Modified functions (exact name, current file path, required changes)
|
||||
- Removed functions (name, file path, reason, migration strategy)
|
||||
|
||||
[Classes]
|
||||
Single sentence describing class modifications.
|
||||
|
||||
Detailed breakdown:
|
||||
- New classes (name, file path, key methods, inheritance)
|
||||
- Modified classes (exact name, file path, specific modifications)
|
||||
- Removed classes (name, file path, replacement strategy)
|
||||
|
||||
[Dependencies]
|
||||
Single sentence describing dependency modifications.
|
||||
|
||||
Details of new packages, version changes, and integration requirements.
|
||||
|
||||
[Testing]
|
||||
Single sentence describing testing approach.
|
||||
|
||||
Test file requirements, existing test modifications, and validation strategies.
|
||||
|
||||
[Implementation Order]
|
||||
Single sentence describing the implementation sequence.
|
||||
|
||||
Numbered steps showing the logical order of changes to minimize conflicts and ensure successful integration.
|
||||
|
||||
|
||||
## STEP 4: Create Implementation Task
|
||||
|
||||
Use the new_task command to create a task for implementing the plan. The task must include a <task_progress> list that breaks down the implementation into trackable steps.
|
||||
|
||||
### Task Creation Requirements
|
||||
|
||||
Your new task should be self-contained and reference the plan document rather than requiring additional codebase investigation. Include these specific instructions in the task description:
|
||||
|
||||
**Plan Document Navigation Commands:**
|
||||
The implementation agent should use these commands to read specific sections of the implementation plan. You should adapt these examples to conform to the structure of the .md file you created, and explicitly provide them when creating the new task:
|
||||
|
||||
${
|
||||
isPowerShell
|
||||
? `
|
||||
# Read Overview section
|
||||
$content = Get-Content implementation_plan.md; $start = ($content | Select-String -Pattern '\\[Overview\\]').LineNumber; $end = ($content | Select-String -Pattern '\\[Types\\]').LineNumber; $content[($start-1)..($end-2)]
|
||||
|
||||
# Read Types section
|
||||
$content = Get-Content implementation_plan.md; $start = ($content | Select-String -Pattern '\\[Types\\]').LineNumber; $end = ($content | Select-String -Pattern '\\[Files\\]').LineNumber; $content[($start-1)..($end-2)]
|
||||
|
||||
# Read Files section
|
||||
$content = Get-Content implementation_plan.md; $start = ($content | Select-String -Pattern '\\[Files\\]').LineNumber; $end = ($content | Select-String -Pattern '\\[Functions\\]').LineNumber; $content[($start-1)..($end-2)]
|
||||
|
||||
# Read Functions section
|
||||
$content = Get-Content implementation_plan.md; $start = ($content | Select-String -Pattern '\\[Functions\\]').LineNumber; $end = ($content | Select-String -Pattern '\\[Classes\\]').LineNumber; $content[($start-1)..($end-2)]
|
||||
|
||||
# Read Classes section
|
||||
$content = Get-Content implementation_plan.md; $start = ($content | Select-String -Pattern '\\[Classes\\]').LineNumber; $end = ($content | Select-String -Pattern '\\[Dependencies\\]').LineNumber; $content[($start-1)..($end-2)]
|
||||
|
||||
# Read Dependencies section
|
||||
$content = Get-Content implementation_plan.md; $start = ($content | Select-String -Pattern '\\[Dependencies\\]').LineNumber; $end = ($content | Select-String -Pattern '\\[Testing\\]').LineNumber; $content[($start-1)..($end-2)]
|
||||
|
||||
# Read Testing section
|
||||
$content = Get-Content implementation_plan.md; $start = ($content | Select-String -Pattern '\\[Testing\\]').LineNumber; $end = ($content | Select-String -Pattern '\\[Implementation Order\\]').LineNumber; $content[($start-1)..($end-2)]
|
||||
|
||||
# Read Implementation Order section
|
||||
$content = Get-Content implementation_plan.md; $start = ($content | Select-String -Pattern '\\[Implementation Order\\]').LineNumber; $content[($start-1)..($content.Length-1)]
|
||||
`
|
||||
: `
|
||||
# Read Overview section
|
||||
sed -n '/\\[Overview\\]/,/\\[Types\\]/p' implementation_plan.md | head -n 1 | cat
|
||||
|
||||
# Read Types section
|
||||
sed -n '/\\[Types\\]/,/\\[Files\\]/p' implementation_plan.md | head -n 1 | cat
|
||||
|
||||
# Read Files section
|
||||
sed -n '/\\[Files\\]/,/\\[Functions\\]/p' implementation_plan.md | head -n 1 | cat
|
||||
|
||||
# Read Functions section
|
||||
sed -n '/\\[Functions\\]/,/\\[Classes\\]/p' implementation_plan.md | head -n 1 | cat
|
||||
|
||||
# Read Classes section
|
||||
sed -n '/\\[Classes\\]/,/\\[Dependencies\\]/p' implementation_plan.md | head -n 1 | cat
|
||||
|
||||
# Read Dependencies section
|
||||
sed -n '/\\[Dependencies\\]/,/\\[Testing\\]/p' implementation_plan.md | head -n 1 | cat
|
||||
|
||||
# Read Testing section
|
||||
sed -n '/\\[Testing\\]/,/\\[Implementation Order\\]/p' implementation_plan.md | head -n 1 | cat
|
||||
|
||||
# Read Implementation Order section
|
||||
sed -n '/\\[Implementation Order\\]/,$p' implementation_plan.md | cat
|
||||
`
|
||||
}
|
||||
|
||||
|
||||
**Task Progress Format:**
|
||||
<IMPORTANT>
|
||||
You absolutely must include the task_progress contents in context when creating the new task. When providing it, do not wrap it in XML tags- instead provide it like this:
|
||||
|
||||
|
||||
task_progress Items:
|
||||
- [ ] Step 1: Brief description of first implementation step
|
||||
- [ ] Step 2: Brief description of second implementation step
|
||||
- [ ] Step 3: Brief description of third implementation step
|
||||
- [ ] Step N: Brief description of final implementation step
|
||||
|
||||
|
||||
You also MUST include the path to the markdown file you have created in your new task prompt. You should do this as follows:
|
||||
|
||||
Refer to @path/to/file/markdown.md for a complete breakdown of the task requirements and steps. You should periodically read this file again.
|
||||
|
||||
{{FOCUS_CHAIN_PARAM}}
|
||||
|
||||
{{NEW_TASK_INSTRUCTIONS}}
|
||||
|
||||
### Mode Switching
|
||||
|
||||
When creating the new task, request a switch to "act mode" if you are currently in "plan mode". This ensures the implementation agent operates in execution mode rather than planning mode.
|
||||
</IMPORTANT>
|
||||
|
||||
## Quality Standards
|
||||
|
||||
You must be specific with exact file paths, function names, and class names. You must be comprehensive and avoid assuming implicit understanding. You must be practical and consider real-world constraints and edge cases. You must use precise technical language and avoid ambiguity.
|
||||
|
||||
Your implementation plan should be detailed enough that another developer could execute it without additional investigation.
|
||||
|
||||
---
|
||||
|
||||
**Execute all four steps in sequence. Your role is to plan thoroughly, not to implement. Code creation begins only after the new task is created and you receive explicit instruction to proceed.**
|
||||
|
||||
Below is the user's input when they indicated that they wanted to create a comprehensive implementation plan.
|
||||
</explicit_instructions>
|
||||
`
|
||||
}
|
||||
@@ -1,261 +0,0 @@
|
||||
import { isGPT51Model } from "@utils/model-utils"
|
||||
import { getShell } from "@utils/shell"
|
||||
import type { SystemPromptContext } from "@/core/prompts/system-prompt/types"
|
||||
import type { DeepPlanningVariant } from "../types"
|
||||
|
||||
/**
|
||||
* Creates the OpenAI GPT-5.1 variant for deep-planning prompt
|
||||
*/
|
||||
export function createGPT51Variant(): DeepPlanningVariant {
|
||||
return {
|
||||
id: "gpt-5",
|
||||
description: "Deep-planning variant optimized for OpenAI GPT-5 models",
|
||||
family: "gpt-5",
|
||||
version: 1,
|
||||
matcher: (context: SystemPromptContext) => {
|
||||
const modelId = context.providerInfo?.model?.id
|
||||
if (!modelId) {
|
||||
return false
|
||||
}
|
||||
return isGPT51Model(modelId)
|
||||
},
|
||||
template: "", // Template is dynamically generated in getDeepPlanningPrompt() based on focus chain settings
|
||||
}
|
||||
}
|
||||
|
||||
/**
|
||||
* Generates the deep-planning template with shell-specific commands
|
||||
* @param focusChainEnabled Whether focus chain (task_progress) is enabled for this task
|
||||
* @param enableNativeToolCalls Whether native tool calling is enabled
|
||||
*/
|
||||
export function generateGPT51Template(focusChainEnabled: boolean, enableNativeToolCalls: boolean): string {
|
||||
const detectedShell = getShell()
|
||||
|
||||
let isPowerShell = false
|
||||
try {
|
||||
isPowerShell =
|
||||
detectedShell != null &&
|
||||
typeof detectedShell === "string" &&
|
||||
(detectedShell.toLowerCase().includes("powershell") || detectedShell.toLowerCase().includes("pwsh"))
|
||||
} catch {}
|
||||
|
||||
return `<explicit_instructions type="deep-planning">
|
||||
Your task is to create a comprehensive implementation plan before writing any code. This process has five distinct steps that must be completed in order:
|
||||
1. Silent Read Investigation
|
||||
2. Silent Terminal Investigation
|
||||
3. Discussion and Questions
|
||||
4. Create Implementation Plan Document
|
||||
5. Create new_task for Implementation Phase
|
||||
|
||||
${focusChainEnabled ? `You should track these five steps in your task_progress parameter, and update it only when steps are completed.` : ""}
|
||||
Your behavior should be methodical and thorough - take time to understand the codebase completely before making any recommendations. The quality of your investigation and use of targeted reads/searches directly impacts the success of the implementation.
|
||||
|
||||
<IMPORTANT>
|
||||
Execute only exploration and plan generation steps until explicitly instructed by the user to proceed with coding.
|
||||
You must thoroughly understand the existing codebase before proposing any changes.
|
||||
Perform your research without commentary or narration. Execute commands and read files without explaining what you're about to do. Only speak up if you have specific questions for the user.
|
||||
</IMPORTANT>
|
||||
|
||||
## STEP 1: Silent Read Investigation
|
||||
|
||||
### Required Research Activities
|
||||
You MUST first use the read_file tool to examine several source files, configuration files, and documentation to better inform subsequent research steps. You should only use read_file to prepare for more granular searching. Use this step to get the big picture, you will use the next step for granular details. Use this tool to determine the language(s) used in the codebase, and to identify the domain(s) relevant to the user's request.
|
||||
|
||||
|
||||
## STEP 2: Silent Terminal Investigation
|
||||
|
||||
### Required Research Activities
|
||||
You MUST use terminal commands to gather information about the codebase structure and patterns relevant to the user's request.
|
||||
You will tailor these commands to explore and identify key functions, classes, methods, types, and variables that are directly, or indirectly related to the task.
|
||||
These commands must be crafted to not produce exceptionally long or verbose search results. For example, you should exclude dependency folders such as node_modules, venv or php vendor, etc. Carefully consider the scope of search patterns. Use the results of your read_file tool calls to tailor the commands for balanced search result lengths. If a command returns no results, you may loosen the search patterns or scope slightly. If a command returns hundreds or thousands of results, you should adjust subsequent commands to be more targeted.
|
||||
Execute these commands to build your understanding. Adjust subsequent commands based on the output you have received from each previous command, informing the scope and direction of your search.
|
||||
You should only execute one command at a time for the first 1-3 commands. Do not chain search commands until you have executed and interpreted the results of several search commands, then use the context you have gathered to inform more complex chained commands.
|
||||
|
||||
Here are some example commands, remember to adjust them as instructed previously:
|
||||
${
|
||||
isPowerShell
|
||||
? // PowerShell-specific commands
|
||||
`
|
||||
# Discover project structure and file types
|
||||
Get-ChildItem -Recurse -Include "*.py","*.js","*.ts","*.java","*.cpp","*.go" | Select-Object -First 30 | Select-Object FullName
|
||||
|
||||
# Find all class and function definitions
|
||||
Get-ChildItem -Recurse -Include "*.py","*.js","*.ts","*.java","*.cpp","*.go" | Select-String -Pattern "class|function|def|interface|struct"
|
||||
|
||||
# Analyze import patterns and dependencies
|
||||
Get-ChildItem -Recurse -Include "*.py","*.js","*.ts","*.java","*.cpp" | Select-String -Pattern "import|from|require|#include" | Sort-Object | Get-Unique
|
||||
|
||||
# Find dependency manifests
|
||||
Get-ChildItem -Recurse -Include "requirements*.txt","package.json","Cargo.toml","pom.xml","Gemfile","go.mod" | Get-Content
|
||||
|
||||
# Identify technical debt and TODOs
|
||||
Get-ChildItem -Recurse -Include "*.py","*.js","*.ts","*.java","*.cpp","*.go" | Select-String -Pattern "TODO|FIXME|XXX|HACK|NOTE"
|
||||
`
|
||||
: // bash/zsh-specific commands
|
||||
`
|
||||
# Discover project structure and file types
|
||||
find . -type f -name "*.py" -o -name "*.js" -o -name "*.ts" -o -name "*.java" -o -name "*.cpp" -o -name "*.go" | head -30 | cat
|
||||
|
||||
# Find all class and function definitions
|
||||
grep -r "class\\|function\\|def\\|interface\\|struct\\|func\\|type.*struct\\|type.*interface" --include="*.py" --include="*.js" --include="*.ts" --include="*.java" --include="*.cpp" --include="*.go" . | cat
|
||||
|
||||
# Analyze import patterns and dependencies
|
||||
grep -r "import\\|from\\|require\\|#include" --include="*.py" --include="*.js" --include="*.ts" --include="*.java" --include="*.cpp" . | sort | uniq | cat
|
||||
|
||||
# Find dependency manifests
|
||||
find . -name "requirements*.txt" -o -name "package.json" -o -name "Cargo.toml" -o -name "pom.xml" -o -name "Gemfile" -o -name "go.mod" | xargs cat
|
||||
|
||||
# Identify technical debt and TODOs
|
||||
grep -r "TODO\\|FIXME\\|XXX\\|HACK\\|NOTE" --include="*.py" --include="*.js" --include="*.ts" --include="*.java" --include="*.cpp" --include="*.go" . | cat
|
||||
`
|
||||
}
|
||||
|
||||
|
||||
## STEP 3: Discussion and Questions
|
||||
|
||||
Ask the user brief, targeted questions that will influence your implementation plan. Keep your questions concise and conversational. Ask only essential questions needed to create an accurate plan.
|
||||
|
||||
**Ask questions only when necessary for:**
|
||||
- Clarifying ambiguous requirements or unclear specifications
|
||||
- Choosing between multiple equally valid implementation approaches that have significant trade-offs
|
||||
- Confirming non-trivial assumptions about existing system behavior or constraints
|
||||
- Understanding preferences for specific technical decisions that will affect the final implementation's behavior or code maintainability
|
||||
|
||||
Your questions should be direct and specific. Avoid long explanations or multiple questions in one response. Only ask one question at a time. You may ask several questions if required and within scope of the task.
|
||||
|
||||
## STEP 4: Create Implementation Plan Document
|
||||
|
||||
Once you have obtained sufficient context to understand all code modifications that will be required, create a structured markdown document containing your complete implementation plan. The document must follow this exact format with clearly marked sections:
|
||||
|
||||
### Document Structure Requirements
|
||||
|
||||
Your implementation plan must be saved as implementation_plan.md, and *must* be structured as follows:
|
||||
|
||||
<example_implementation_plan>
|
||||
# Implementation Plan
|
||||
|
||||
[Overview]
|
||||
Single sentence describing the overall goal.
|
||||
|
||||
Multiple paragraphs outlining the scope, context, and high-level approach. Explain why this implementation is needed and how it fits into the existing system.
|
||||
|
||||
[Types]
|
||||
Single sentence describing the type system changes.
|
||||
|
||||
Detailed type definitions, interfaces, enums, or data structures with complete specifications. Include field names, types, validation rules, and relationships.
|
||||
|
||||
[Files]
|
||||
Single sentence describing file modifications.
|
||||
|
||||
Detailed breakdown:
|
||||
- New files to be created (with full paths and purpose)
|
||||
- Existing files to be modified (with specific changes)
|
||||
- Files to be deleted or moved
|
||||
- Configuration file updates
|
||||
|
||||
[Functions]
|
||||
Single sentence describing function modifications.
|
||||
|
||||
Detailed breakdown:
|
||||
- New functions (name, signature, file path, purpose)
|
||||
- Modified functions (exact name, current file path, required changes)
|
||||
- Removed functions (name, file path, reason, migration strategy)
|
||||
|
||||
[Classes]
|
||||
Single sentence describing class modifications.
|
||||
|
||||
Detailed breakdown:
|
||||
- New classes (name, file path, key methods, inheritance)
|
||||
- Modified classes (exact name, file path, specific modifications)
|
||||
- Removed classes (name, file path, replacement strategy)
|
||||
|
||||
[Dependencies]
|
||||
Single sentence describing dependency modifications.
|
||||
|
||||
Details of new packages, version changes, and integration requirements.
|
||||
|
||||
[Implementation Order]
|
||||
Single sentence describing the implementation sequence.
|
||||
|
||||
Numbered steps showing the logical order of changes to minimize conflicts and ensure successful integration.
|
||||
${focusChainEnabled ? "A task_progress list of steps that will need to be completed during the implementation" : ""}
|
||||
|
||||
</example_implementation_plan>
|
||||
|
||||
## STEP 5: Create Implementation new_task
|
||||
|
||||
Use the new_task command to create a task for implementing the plan. ${focusChainEnabled ? "The task must include a <task_progress> list that breaks down the implementation into trackable steps." : ""}
|
||||
|
||||
### Task Creation Requirements
|
||||
|
||||
<IMPORTANT>
|
||||
**Standalone Product:**
|
||||
Your new task should be self-contained and reference the plan document rather than requiring additional codebase investigation. Include these specific instructions in the task description:
|
||||
|
||||
${
|
||||
focusChainEnabled
|
||||
? `**Task Progress Format:**
|
||||
You absolutely MUST include the task_progress contents in context when creating the new task. When providing it, do not wrap it in XML tags- instead provide it like this:
|
||||
|
||||
task_progress Items:
|
||||
- [ ] Step 1: Brief description of first implementation step
|
||||
- [ ] Step 2: Brief description of second implementation step
|
||||
- [ ] Step 3: Brief description of third implementation step
|
||||
- [ ] Step N: Brief description of subsequent/final implementation step(s)
|
||||
|
||||
**Markdown Implementation Plan Path:**
|
||||
You also MUST include the path to the markdown file you have created in your new task prompt. You should do this as follows:
|
||||
Refer to @path/to/file/markdown.md for a complete breakdown of the task requirements and steps. You should periodically read this file again.`
|
||||
: ""
|
||||
}
|
||||
</IMPORTANT>
|
||||
|
||||
${
|
||||
enableNativeToolCalls
|
||||
? `**new_task Tool Definition:**
|
||||
|
||||
When you are ready to create the implementation task, you must call the new_task tool with the following structure:
|
||||
|
||||
{
|
||||
"name": "new_task",
|
||||
"arguments": {
|
||||
"context": "Your detailed context here following the 5-point structure..."
|
||||
}
|
||||
}
|
||||
|
||||
The context parameter should include all five sections as described above.
|
||||
|
||||
`
|
||||
: `**new_task Tool Definition:**
|
||||
|
||||
When you are ready to create the implementation task, you must call the new_task tool with the following structure:
|
||||
|
||||
<new_task>
|
||||
<context>Your detailed context here following the 5-point structure...</context>
|
||||
</new_task>
|
||||
|
||||
The context parameter should include all five sections as described above.
|
||||
|
||||
`
|
||||
}
|
||||
|
||||
### Mode Switching
|
||||
|
||||
<IMPORTANT>
|
||||
When creating the new task, request a switch to "act mode" if you are currently in "plan mode". This ensures the implementation agent operates in execution mode rather than planning mode.
|
||||
</IMPORTANT>
|
||||
|
||||
## Quality Standards
|
||||
|
||||
You must be specific with exact file paths, function names, and class names. You must be comprehensive and avoid assuming implicit understanding. You must be practical and consider real-world constraints and edge cases. You must use precise technical language and avoid ambiguity.
|
||||
|
||||
Your implementation plan should be detailed enough that another developer could execute it without additional investigation.
|
||||
|
||||
---
|
||||
|
||||
**Execute all five steps in sequence. Your role is to plan thoroughly, not to implement. Code creation begins only after the new task is created and you receive explicit instruction to proceed.**
|
||||
|
||||
Below is the user's input from when they indicated that they wanted to create this comprehensive implementation plan.
|
||||
</explicit_instructions>
|
||||
`
|
||||
}
|
||||
@@ -1,9 +0,0 @@
|
||||
/**
|
||||
* Export for all deep-planning prompt variants
|
||||
*/
|
||||
|
||||
export { createAnthropicVariant } from "./anthropic"
|
||||
export { createGeminiVariant } from "./gemini"
|
||||
export { createGemini3Variant } from "./gemini3"
|
||||
export { createGenericVariant } from "./generic"
|
||||
export { createGPT51Variant } from "./gpt51"
|
||||
@@ -1,5 +1,7 @@
|
||||
import type { McpPromptResponse } from "@shared/mcp"
|
||||
import { expect } from "chai"
|
||||
import * as sinon from "sinon"
|
||||
import { StateManager } from "@/core/storage/StateManager"
|
||||
import { formatMcpPromptResponse, McpPromptFetcher, parseSlashCommands } from "../index"
|
||||
|
||||
describe("slash-commands", () => {
|
||||
@@ -141,4 +143,24 @@ describe("slash-commands", () => {
|
||||
// are skipped because they require StateManager initialization when falling
|
||||
// through to workflow checking. The core MCP functionality is covered above.
|
||||
})
|
||||
|
||||
describe("parseSlashCommands built-in handling", () => {
|
||||
afterEach(() => {
|
||||
sinon.restore()
|
||||
})
|
||||
|
||||
it("should not treat the removed planning command as a built-in command anymore", async () => {
|
||||
sinon.stub(StateManager, "get").returns({
|
||||
getRemoteConfigSettings: () => ({ remoteGlobalWorkflows: [] }),
|
||||
getGlobalStateKey: () => ({}),
|
||||
} as any)
|
||||
|
||||
const removedCommand = "deep-planning" // previously a built-in command, removed in this PR
|
||||
const text = `<task>/${removedCommand} Build the feature carefully</task>`
|
||||
const result = await parseSlashCommands(text, {}, {}, "test-ulid", undefined, false)
|
||||
|
||||
expect(result.processedText).to.equal(text)
|
||||
expect(result.needsClinerulesFileCheck).to.equal(false)
|
||||
})
|
||||
})
|
||||
})
|
||||
|
||||
@@ -7,7 +7,6 @@ import { Logger } from "@/shared/services/Logger"
|
||||
import { isNativeToolCallingConfig } from "@/utils/model-utils"
|
||||
import {
|
||||
condenseToolResponse,
|
||||
deepPlanningToolResponse,
|
||||
explainChangesToolResponse,
|
||||
newRuleToolResponse,
|
||||
newTaskToolResponse,
|
||||
@@ -49,7 +48,7 @@ export async function parseSlashCommands(
|
||||
providerInfo?: ApiProviderInfo,
|
||||
mcpPromptFetcher?: McpPromptFetcher,
|
||||
): Promise<{ processedText: string; needsClinerulesFileCheck: boolean }> {
|
||||
const SUPPORTED_DEFAULT_COMMANDS = ["newtask", "smol", "compact", "newrule", "reportbug", "deep-planning", "explain-changes"]
|
||||
const SUPPORTED_DEFAULT_COMMANDS = ["newtask", "smol", "compact", "newrule", "reportbug", "explain-changes"]
|
||||
|
||||
// Determine if the current provider/model/setting actually uses native tool calling
|
||||
const willUseNativeTools = isNativeToolCallingConfig(providerInfo!, enableNativeToolCalls || false)
|
||||
@@ -60,7 +59,6 @@ export async function parseSlashCommands(
|
||||
compact: condenseToolResponse(focusChainSettings),
|
||||
newrule: newRuleToolResponse(),
|
||||
reportbug: reportBugToolResponse(),
|
||||
"deep-planning": deepPlanningToolResponse(focusChainSettings, providerInfo, willUseNativeTools),
|
||||
"explain-changes": explainChangesToolResponse(),
|
||||
}
|
||||
|
||||
|
||||
@@ -12,12 +12,6 @@ export const BASE_SLASH_COMMANDS: SlashCommand[] = [
|
||||
section: "default",
|
||||
cliCompatible: true,
|
||||
},
|
||||
{
|
||||
name: "deep-planning",
|
||||
description: "Create a comprehensive implementation plan before coding",
|
||||
section: "default",
|
||||
cliCompatible: true,
|
||||
},
|
||||
{
|
||||
name: "smol",
|
||||
description: "Condenses your current context window",
|
||||
|
||||
@@ -65,6 +65,13 @@ describe("getAvailableSlashCommands", () => {
|
||||
;(deprecatedCommand === undefined).should.be.true()
|
||||
})
|
||||
|
||||
it("should not include the removed planning slash command", async () => {
|
||||
const response = await getAvailableSlashCommands(mockController as Controller, EmptyRequest.create())
|
||||
const removedCommandName = "deep-planning" // previously a built-in command, removed in this PR
|
||||
const removedCommand = response.commands.find((cmd) => cmd.name === removedCommandName)
|
||||
;(removedCommand === undefined).should.be.true()
|
||||
})
|
||||
|
||||
it("should mark base commands with section 'default'", async () => {
|
||||
const response = await getAvailableSlashCommands(mockController as Controller, EmptyRequest.create())
|
||||
|
||||
|
||||
Reference in New Issue
Block a user