kyaulabs/prism/writing-plans

Writing Plans

Make the next steps clear enough to execute without prescribing every line of code.

1. Read the requested outcome and relevant implementation. Reuse settled decisions;

ask only about missing requirements that materially affect the approach.

1. List coherent vertical slices in dependency order. For each, identify behavior,

likely files/interfaces, a failing-test seam, and verification commands found in the project or applicable module.

1. Include integration, migration and deletion work where required. State risks

and unresolved assumptions plainly. Do not create speculative abstractions.

1. Use a conversation checklist for ordinary tasks or one durable plan for work

that benefits from resumption. Link an existing spec rather than duplicating it.

1. If implementation is authorized, continue with executing-plans. A request

for a plan alone stops at the plan. No extra approval just to move between skills.

Rules

Use TDD for development. Do not prewrite complete production code in the plan, require exact future test names, or bind execution to receipts and commit hashes. Keep useful plans after completion. Track an originating issue when there is one; close it only when its requested outcome is actually delivered.

Gotchas

• A plan is a working guide, not a frozen program. Adjust implementation details

as evidence improves; discuss changes to the user's goal or material trade-offs.

• Oversized work needs smaller slices, not necessarily more documents or tickets.