docs(plugin): find the existing plan before making one, and file related work into it (#4080)
CI & Build / Python lint (push) Successful in 2s
CI & Build / Plugin hooks (push) Successful in 11s
CI & Build / integration (push) Successful in 57s
CI & Build / TypeScript typecheck (push) Successful in 1m15s
CI & Build / Python tests (push) Successful in 1m46s
CI & Build / Build & push image (push) Successful in 35s
CI & Build / Python lint (push) Successful in 2s
CI & Build / Plugin hooks (push) Successful in 11s
CI & Build / integration (push) Successful in 57s
CI & Build / TypeScript typecheck (push) Successful in 1m15s
CI & Build / Python tests (push) Successful in 1m46s
CI & Build / Build & push image (push) Successful in 35s
Step 5 of milestone 415 "An existing plan is found before a new one is made". Sessions opened a second milestone beside the roadmap milestone that already covered the work, and filed related tasks loose, because no surface told them to look first. - writing-plans: a section on finding the plan that exists (enter_project's unplanned_milestones, search(content_type="milestone"), list_milestones); when an active milestone covers the work, add steps to it; a second milestone only for a separate arc; the gate's existing_milestone reply. - using-scribe: "when you plan" gains the same check and milestone_id on related tasks. - _INSTRUCTIONS PLAN line points at the milestone search (1,689 of 2,000). - test_guidance_ownership pins the topic on writing-plans. - Plugin version minted: 2026.09.15.1744. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01821k5B3Ysecp9fNYs92Kuy
This commit is contained in:
@@ -111,6 +111,12 @@ Two constraints on *how* that's achieved:
|
||||
is just a task — don't wrap it in a milestone. Either way, do not write
|
||||
plans/specs to local `.md` files. See the **writing-plans** skill.
|
||||
|
||||
**Find the plan before you make one.** A project's existing milestones are
|
||||
often its roadmap, and a milestone with no steps yet is still open work.
|
||||
`search(content_type="milestone", project_id=...)` finds one by purpose. When
|
||||
an active milestone covers the work, add steps to it rather than opening
|
||||
another, and give any task you record for that work its `milestone_id`.
|
||||
|
||||
5. **Keep state honest.** Set a task `in_progress` when you start it, `done` the
|
||||
moment it's complete; log progress as you go. Always log when you
|
||||
**complete** a task and when you **hit or discover a problem**, so a change
|
||||
|
||||
Reference in New Issue
Block a user