Chat Modes

What are Chat Modes?

Chat Modes tell the AI how to approach your request. Each mode optimizes the AI's behavior for specific tasks—from writing production code to creating implementation plans to debugging issues.

Why modes matter:

• Get better results tailored to your task

• Save credits by using Plan mode for discussions

• Streamline your workflow with specialized AI behavior

• Improve code quality with targeted feedback

How to switch modes: Select the mode from the dropdown in your chat input before sending a message. The mode applies only to that specific message.

Build mode

Write and modify code to implement features and functionality.

What it does:

• Writes production-ready code

• Creates new files and components

• Modifies existing code

• Implements features end-to-end

• Adds UI elements and logic

Best for:

• Adding new features

• Creating pages or components

• Implementing functionality

• Modifying existing code

• Building user interfaces

Example requests:

• "Add a login form with email and password fields"

• "Create a user profile page with avatar upload"

• "Implement a shopping cart with add/remove functionality"

• "Add dark mode toggle to the settings page"

Note: Build mode is the default. Use it when you want the AI to write code.

Plan mode

Create detailed implementation plans without writing any code.

What it does:

• Outlines implementation approach

• Lists files to create or modify

• Describes architecture decisions

• Identifies potential challenges

• Suggests testing strategies

• Provides step-by-step tasks

Best for:

• Planning complex features before implementation

• Exploring different architectural approaches

• Understanding project structure

• Breaking down large features into tasks

• Discussing options without committing to code

Example requests:

• "Plan how to add real-time chat to my app"

• "What's the best way to structure a multi-tenant application?"

• "Outline the steps to add payment processing with Stripe"

• "How should I organize my API routes and database schema?"

Output format:

1. High-level approach

2. Step-by-step implementation tasks

3. Files to create/modify

4. Key functions and components

5. Challenges and solutions

6. Testing considerations

7. Performance and security notes

Tip: Use Plan mode first for complex features, then switch to Build mode to implement the plan.

Debug mode

Troubleshoot and fix issues in your code.

What it does:

• Analyzes error messages systematically

• Identifies root causes

• Provides debugging steps

• Suggests specific fixes

• Tests solutions

• Includes preventive measures

Best for:

• Fixing bugs and errors

• Investigating unexpected behavior

• Resolving runtime issues

• Troubleshooting integration problems

• Understanding error messages

Example requests:

• "Fix the 'undefined' error in the user dashboard"

• "The login button isn't working, help me debug it"

• "Why is my API call returning 404?"

• "Investigate why the profile page loads slowly"

Debugging approach:

1. Analyzes the problem

2. Checks logs and error messages

3. Identifies potential root causes

4. Provides step-by-step fixes

5. Explains why the issue occurred

6. Suggests preventive measures

Tip: Include error messages, stack traces, or describe the unexpected behavior for best results.

Review mode

Get code quality feedback and improvement suggestions.

What it does:

• Reviews code for best practices

• Identifies potential bugs

• Suggests optimizations

• Checks for security issues

• Evaluates maintainability

• Recommends improvements

Best for:

• Code quality checks

• Pre-deployment reviews

• Learning best practices

• Security audits

• Performance optimization

• Refactoring guidance

Example requests:

• "Review the authentication logic in auth.ts"

• "Check my API routes for security issues"

• "Suggest improvements for the UserCard component"

• "Review my database schema design"

Review focus areas:

1. Code quality and best practices

2. Potential bugs and edge cases

3. Performance bottlenecks

4. Security vulnerabilities

5. Code readability

6. Testing coverage

7. Specific improvement suggestions

Tip: Use @file/path to reference specific files you want reviewed.

Docs mode

Create or improve project documentation.

What it does:

• Writes markdown documentation

• Creates README files

• Documents APIs and functions

• Generates usage guides

• Adds code examples

• Saves files in /docs folder

Best for:

• Writing README files

• Creating API documentation

• Documenting components

• Adding setup guides

• Writing troubleshooting guides

• Creating architecture docs

Example requests:

• "Create a README for this project"

• "Document the API endpoints in my app"

• "Write usage guide for the UserService class"

• "Add setup instructions for new developers"

Documentation output:

1. Clear, concise explanations

2. Code examples with comments

3. Step-by-step instructions

4. API references with parameters

5. Common use cases

6. Troubleshooting section

7. Proper markdown formatting

File location: All docs are saved in the /docs directory with appropriate subdirectories.

Tip: Be specific about what to document. Mention audience (end-users, developers, etc.)

Mode comparison

When to use which mode

Start a new feature

1. Plan mode: Outline the implementation approach

2. Build mode: Write the code based on the plan

3. Review mode: Check code quality before deployment

Fix a bug

1. Debug mode: Identify and fix the issue

2. Review mode: Ensure the fix follows best practices

Improve existing code

1. Review mode: Get improvement suggestions

2. Build mode: Implement the improvements

Document your project

1. Docs mode: Create or update documentation

2. Review mode: Check docs for clarity and completeness

Explore options

1. Plan mode: Discuss different approaches without committing to code

2. Build mode: Implement the chosen approach

Best practices

Build mode tips

Do:

• Be specific about UI details and functionality

• Mention error handling and edge cases

• Request loading states and user feedback

• Specify file locations when relevant

Don't:

• Ask for multiple unrelated features at once

• Use vague descriptions

• Forget to mention styling preferences

Example: "Add a user profile edit form with fields for name (required), bio (optional, max 500 chars), and avatar upload. Include validation, loading state while saving, and success/error messages."

Plan mode tips

Do:

• Ask about architecture and structure

• Request pros/cons of different approaches

• Break down complex features

• Explore integration options

Don't:

• Expect code to be written

• Ask to implement (switch to Build mode for that)

Credit saver: Use Plan mode for all discussions and exploratory questions.

Debug mode tips

Do:

• Include error messages and stack traces

• Describe the expected vs. actual behavior

• Mention recent changes that might have caused the issue

• Reference relevant files with @file/path

Don't:

• Be vague ("it doesn't work")

• Skip error messages

• Forget to mention what you've already tried

Example: "Getting 'Cannot read property user of undefined' in Dashboard.tsx line 45. This started after I added the profile fetch. Error appears when navigating to /dashboard after login."

Review mode tips

Do:

• Specify what to focus on (security, performance, etc.)

• Reference specific files or functions

• Ask for specific types of feedback

• Request explanation of suggestions

Don't:

• Ask to implement changes (use Build mode after review)

• Submit entire codebase (focus on specific areas)

Example: "Review @src/api/auth.ts for security issues. Focus on token handling and session management."

Docs mode tips

Do:

• Specify the documentation type (README, API, guide)

• Mention the target audience

• Request specific sections or topics

• Include examples in docs

Don't:

• Ask for code documentation in code files (use comments in Build mode)

• Forget to specify what needs documenting

Example: "Create API documentation for the user endpoints. Include request/response examples, authentication requirements, and error codes. Target audience: frontend developers."

Examples by scenario

Building a new feature

1. Plan first:

• Mode: Plan

• Prompt: "Plan how to add a favorites feature where users can save items"

2. Implement:

• Mode: Build

• Prompt: "Implement the favorites feature based on the plan"

3. Review:

• Mode: Review

• Prompt: "Review the favorites implementation for potential issues"

Fixing a bug

1. Debug:

• Mode: Debug

• Prompt: "The save button throws 'undefined is not a function' error when clicked"

2. Verify fix:

• Mode: Build

• Prompt: "Add error handling to prevent this issue in the future"

Documenting your app

1. Create docs:

• Mode: Docs

• Prompt: "Write a README explaining what this app does and how to run it locally"

2. Add API docs:

• Mode: Docs

• Prompt: "Document all API endpoints in /src/api with request/response examples"

Switching between modes

You can change modes freely during a conversation.

Example workflow:

1. Start in Plan mode: "Plan a search feature with filters"

2. Switch to Build mode: "Implement the search UI from the plan"

3. Switch to Debug mode: "Fix the filter dropdown not showing options"

4. Switch to Review mode: "Review the search component for performance issues"

5. Switch to Docs mode: "Document how to use the search feature"

Each message operates independently in the selected mode.

Credit optimization

Credit-saving strategy:

• Use Plan mode for all discussions and exploratory questions

• Use Review mode before building to catch issues early

• Be specific in Build mode to avoid rework

• Batch related changes in one Build mode request

Common questions

Can I change modes mid-conversation?

Yes. Each message can use a different mode. The mode applies only to that specific message, not the entire session.

Which mode should I use most?

Build mode is the default and most commonly used. Use Plan mode for discussions to save credits, and switch to specialized modes (Debug, Review, Docs) as needed.

Do all modes consume credits?

Yes, but costs vary. Plan mode uses the least credits since it doesn't generate code. Build and Debug modes use the most since they generate or modify code.

What if I choose the wrong mode?

No problem. If you select Plan mode but ask for code, the AI will create a plan instead. Just send a new message in Build mode to get the actual implementation.

Can I use multiple modes for one task?

Yes. It's often beneficial to:

1. Plan mode to outline the approach

2. Build mode to implement

3. Review mode to check quality

4. Debug mode to fix any issues

5. Docs mode to document the feature

Troubleshooting

Mode not behaving as expected

Issue: Plan mode is writing code instead of creating a plan.

Solution: The AI interprets your request based on mode instructions. If code appears, rephrase your request to focus on planning (e.g., "Create an implementation plan for..." instead of "Add a feature...").

Issue: Build mode isn't generating code.

Solution: Check your prompt. Be specific about what code to write. If you asked a question instead of requesting implementation, the AI may provide explanation instead of code.

Issue: Review mode is modifying code.

Solution: Review mode only provides feedback. If you want changes implemented, copy the suggestions and submit in Build mode.

Related links

• Getting Started

• Plans and Credits - Credit costs explained

• FAQ

• Prompt Writing Guide (coming soon)

• Chat Sessions Guide