Augment Plan Mode rule

plan-mode-rule.md

type	description
agent_requested	/run plan mode

Plan Mode Rules

Quick Start: Ask Questions First

When entering Plan Mode, IMMEDIATELY ask focused questions to gather critical information:

Standard Opening Questions (ask 2-4 relevant ones):

1. What's the primary goal or problem you're solving?
2. Are there specific files, components, or modules involved?
3. Any constraints? (performance, compatibility, security, timeline)
4. Should this work integrate with existing patterns in the codebase?
5. What's your rollout preference? (all-at-once, phased, feature-flagged)
6. Any specific testing requirements?

Then: Research the codebase, produce the plan, and invite review.

Core Behavior

Plan, Do Not Execute

• NEVER edit files or run commands with side effects in Plan Mode
• Use ONLY read-only tools: view, codebase-retrieval, web-search, web-fetch, github-api (GET), notion (read), glean (search)
• FORBIDDEN: str-replace-editor, save-file, remove-files, launch-process (with side effects), any write operations

Safety & Clarity

• Label risky operations: [HIGH RISK], [BREAKING CHANGE], [DATA MIGRATION], [REQUIRES DOWNTIME]
• Prefer straightforward designs over clever ones
• Use simple, consistent terminology
• Optimize for human reviewability

Workflow

1. Ask Questions - Clarify ambiguities upfront (2-4 focused questions)
2. Research - Use read-only tools to understand the codebase
3. Plan - Produce structured plan using required format below
4. Create a Task List - Using the add_tasks tool create a comprehensive, hierarchical task list organized into phases based on the Plan.
5. Review - Invite user to approve, modify, or expand sections
6. Update the Task List - Using the add_tasks update the task list as needed based on the user Plan review and invite the user to use the Task List to run the tasks individualy or at once.
7. Wait - NEVER auto-execute; require explicit approval to switch to execution mode

Required Plan Structure

## Summary

2–4 bullets: goal and high-level approach

## Clarifications & Assumptions

• Open Questions: Specific questions for the user (or "None")
• Assumptions: What you're assuming; mark [CRITICAL] where needed

## Constraints & Risks

• Constraints: Performance, compatibility, security, timeline
• Risks: Label as [HIGH], [MEDIUM], [LOW] with mitigation strategies

## Step-by-Step Plan

Numbered phases with 2–6 concrete actions each. Include file/module specificity. Mark: [BREAKING CHANGE], [DATA MIGRATION], [REQUIRES DOWNTIME], [SECURITY SENSITIVE]

## Implementation Notes

• Recommended patterns, APIs, libraries
• Testing strategy (unit, integration, e2e)
• Performance, security, and error handling considerations

## Validation & Rollout

• Local verification steps
• Test requirements
• Rollout strategy (staging, canary, monitoring)
• Rollback plan

## Next Actions

Bullet list of what should happen next (use imperative voice: "Implement Phase 1", not "I will implement")

Language & Formatting

Use proposed language:

• "Add", "Update", "Refactor", "Create", "Modify" (NOT "I have implemented")
• Label code examples: "Example:", "Pseudocode:", "Proposed:"

Keep it scannable:

• Markdown headings (##, ###), numbered lists for steps, bullets for items
• Code blocks with language tags: python, typescript
• Bold for risks and critical items

Approval & Execution

When user says "looks good" or "go ahead":

1. Acknowledge approval
2. Ask: "I'm in Plan Mode. Switch to execution mode, or implement yourself?"
3. If they confirm execution: "Switching to execution mode. Implementing now."
4. Only then use write tools

Stay in Plan Mode until explicit approval to execute.