mirror of
https://github.com/backnotprop/plannotator.git
synced 2026-09-14 14:17:26 +08:00
Sergiy Dybskiy
050dfcda9a
* feat(opencode): add OpenCode 2 plan review adapter * fix(opencode): harden V2 review lifecycle * fix(opencode): address V2 review feedback * fix(opencode): update V2 target and isolate tests * test(opencode): assert prompt composition invariants
45 lines
1.9 KiB
TypeScript
45 lines
1.9 KiB
TypeScript
/** Planning instructions shared by the OpenCode 1 and OpenCode 2 adapters. */
|
|
export function getPlanningPrompt(): string {
|
|
return `## Plannotator — Plan Review
|
|
|
|
You have a plan submission tool called \`submit_plan\`. It opens an interactive review UI where the user can annotate, approve, or request changes.
|
|
|
|
**How to use it:**
|
|
|
|
\`submit_plan\` accepts an array of line-range edits. On first submission, pass the full plan as a single edit starting at line 1:
|
|
|
|
\`\`\`json
|
|
{ "edits": [{ "start": 1, "content": "# My Plan\\n\\n## Goals\\n..." }] }
|
|
\`\`\`
|
|
|
|
If the user denies and requests changes, apply surgical edits using line ranges. The tool response includes your plan with line numbers so you can target specific ranges:
|
|
|
|
\`\`\`json
|
|
{ "edits": [
|
|
{ "start": 12, "end": 14, "content": "revised section content" },
|
|
{ "start": 30, "end": 30, "content": "" }
|
|
] }
|
|
\`\`\`
|
|
|
|
Edit semantics:
|
|
- \`start\` and \`end\` are 1-indexed, inclusive line numbers
|
|
- Omit \`end\` to replace from \`start\` through end of file (use this for the initial full write)
|
|
- Empty \`content\` with \`start\`/\`end\` deletes those lines
|
|
- Multiple edits in one call are applied in order; line numbers refer to the state before edits
|
|
|
|
### Before you write a plan
|
|
|
|
Do not jump straight to writing a plan. First:
|
|
|
|
1. **Explore** — Read the relevant code, trace dependencies, and look at existing patterns. The depth should match the task.
|
|
2. **Ask questions** — If you need information only the user can provide (requirements, preferences, tradeoffs), ask using the \`question\` tool. Don't guess at ambiguous requirements.
|
|
|
|
Only write and submit a plan once you have sufficient context.
|
|
|
|
### What NOT to do
|
|
|
|
- Don't proceed with implementation until the plan is approved.
|
|
- Don't use \`plan_exit\` — use \`submit_plan\` instead.
|
|
- Don't end your turn without either submitting a plan or asking the user a question.`;
|
|
}
|