bvandeusen
88106309f4
Superpowers was uninstalled but its replacements were never built (only using-scribe shipped) — a live functional hole. Author the 4 the operator wants back, each integrated with Scribe's toolset rather than generic copies: - writing-plans -> start_planning / kind=plan task, not local .md - systematic-debugging -> capture issue (symptom->cause->fix, tag issue) on resolve - verification -> log results to the task work-log; honest done - brainstorming -> recall prior thinking first; capture the decision note Skipped TDD + receiving-code-review per operator (well-covered by Claude/them). Manifest + using-scribe list now advertise only the 4 that ship. Remove the stale docs/superpowers/*.md reference in _INSTRUCTIONS (superpowers is gone). Plugin 0.1.6 -> 0.1.7. Refs plan 821 (Phase 3 of 755). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
47 lines
2.2 KiB
Markdown
47 lines
2.2 KiB
Markdown
---
|
|
name: writing-plans
|
|
description: Use before starting any non-trivial or multi-step piece of work — produce a clear plan BEFORE diving in. Triggers when the user asks you to plan, design an approach, scope an effort, or tackle work big enough to need ordered steps. The plan lives in a Scribe kind=plan task (via start_planning), not a local file.
|
|
---
|
|
|
|
# Writing plans
|
|
|
|
A plan is **how** you'll execute a chunk of work — the design plus an ordered,
|
|
checkable list of steps — written *before* you start, so the approach is
|
|
reviewable and the work stays trackable.
|
|
|
|
## Start the plan in Scribe, not a file
|
|
|
|
For non-trivial work, call **`start_planning(project_id, title)` FIRST** —
|
|
before any design or implementation. It creates a `kind=plan` task seeded with a
|
|
template and returns the task id plus the project's applicable rules. The plan
|
|
lives in that task: edit the body with `update_task`, record progress with
|
|
`add_task_log`. **Do not** write plans or specs to local `.md` files — the task
|
|
is the record, not a file on disk.
|
|
|
|
Before designing from scratch, **recall**: `search` Scribe for a related prior
|
|
plan or decision. Often the thinking (or half of it) already exists.
|
|
|
|
## What a good plan contains
|
|
|
|
- **Goal** — what "done" looks like, and why, in a sentence or two.
|
|
- **Approach** — the key design decisions and the trade-offs you chose, briefly.
|
|
- **Steps** — an ordered checklist, each step small enough to verify on its own;
|
|
note which files/areas each touches.
|
|
- **Verification** — how you'll know it actually works (a test, CI, an
|
|
observable behavior), not just "it's written."
|
|
|
|
## While executing
|
|
|
|
- Keep the plan **honest**: tick steps as they land; record decisions, findings,
|
|
and pivots with `add_task_log` rather than silently rewriting the body.
|
|
- If reality diverges from the plan, **update the plan** — one that no longer
|
|
matches what you're doing is worse than none.
|
|
- Set the plan task `in_progress` when you start and `done` when it's complete.
|
|
|
|
## Match depth to the work
|
|
|
|
A two-step change deserves a two-line plan; a multi-day effort deserves
|
|
milestones and sub-tasks. Don't over-plan the trivial, and don't under-plan
|
|
something that will sprawl. The point is a shared, reviewable intent — not
|
|
ceremony.
|