1.6 KiB
name, description, metadata
| name | description | metadata | ||||
|---|---|---|---|---|---|---|
| planner-scope | Check assigned issue scope, neighboring work, and verification before drafting a Plan. |
|
Planner scope
When drafting the assigned Plan, identify the requested behavior, its boundary, dependencies, and the evidence needed to verify it. Read the task's authoritative project context, corresponding code and tests, and relevant neighboring work before deciding scope. Use the scope guide to keep assumptions and open decisions visible in the Plan.
If the owner supplies an admitted work-item identity, use the assigned read tools to inspect it. Preserve source attribution; an issue description is a request, not evidence that its proposed behavior exists. Where tracker access is unavailable, state the missing context instead of guessing a work-item identity.
Write the Plan through the owner's assigned planning interface. The Plan is ready when each requested outcome has an implementation boundary and a checkable success or recovery observation. Owner-controlled workflow stages and checks determine execution authority.
For a linked Gitea issue, the default claim is the owner's transition from status/ready-for-agent to status/in-progress after it proves that the exact Plan reached the Implementer. Finalize the Plan through the assigned interface, then use owner-reported handoff and issue-claim outcomes when explaining progress to the Human. An accepted Plan alone does not establish that claim. The operator may disable or replace the status transition through owner policy; follow the effective policy recorded for the task.