Ask Qoder to prepare a reviewable plan before implementation.
Use Plan when the task needs scope alignment, a reviewable approach, or explicit acceptance criteria before files are changed.
Qoder keeps the plan and execution in the same task. Review tool activity, changed files, tests, and other evidence as work progresses. Add a requirement in the conversation when it stays within the same objective; create a new task when the objective changes.
Open the code-review area to inspect the resulting changes. Verify tests or builds before committing or pushing.
When to use Plan
- A feature spans several files or modules and the implementation boundary must be agreed first.
- Several designs are possible and you want to compare tradeoffs before editing code.
- The team wants to review task decomposition, risks, and verification steps.
- The task has a design, API contract, or compatibility requirement that must guide implementation.
Start a planned task
- Open Add context in the task composer and select Plan. You can also type
/planand select Plan from the suggestions. The composer shows Turn off plan mode while it is active. - Describe the outcome, allowed scope, constraints, and verification requirements.
- Review Qoder's planning response. When the task boundary is unclear, Qoder may ask follow-up questions; provide the information that affects scope, implementation choices, and validation.
- For an engineering task that requires implementation, review the goals, affected files, steps, risks, and validation method before asking Qoder to proceed or revise the approach. A simple analysis or checklist may be returned directly in the conversation instead of opening a separate Plan work surface.
During implementation
Qoder keeps the plan and execution in the same task. Review tool activity, changed files, tests, and other evidence as work progresses. Add a requirement in the conversation when it stays within the same objective; create a new task when the objective changes.
Finish the task
Open the code-review area to inspect the resulting changes. Verify tests or builds before committing or pushing.
Plan versus Goal
| Mode | What you provide | How Qoder proceeds | Best for |
|---|---|---|---|
| Plan | Reviewable requirements, constraints, and design evidence | Produces a plan, waits for approval, then implements it | Features and engineering changes whose path must be aligned first |
| Goal | A verifiable end state | Plans and iterates until the result is met | Optimization, migration, and cleanup where every step cannot be known in advance |