scip-plan

SCIP Plan

Load $scip-query for mechanics and use $scip-explore to establish the existing behavior the change will touch. Reuse facts already established by current evidence. A plan is an ordered set of concrete changes and checks another agent can execute without rediscovering the system.

The planning and change-review commands distinguish a pre-change briefing, proposed symbol impact, actual diff metrics and downstream consumers. Choose the one that settles the current planning question; do not run them all for the same fact.

Plan changes spanning owners, consumers, dependencies, migrations, or several implementation steps. Skip a document for one obvious edit. Persist substantial plans in the project's normal location, usually docs/plans/YYYY-MM-DD-<change>.md, when they must survive a context reset.

Map the existing system before designing the change

State the requested observable outcome. Then establish how the affected operation works today, from its actual initiating surface to the result its consumer observes. Cover the relevant authorization and validation, dispatch or registration, transformations, shared services, durable state changes, runtime handoffs, notifications, returned values, and failure/recovery paths. Follow queued work through its consumer when completion depends on that consumer. Bound this investigation to facts that can change the plan; an end-to-end map does not require reading the entire repository.

Locate the entry surface with ordinary repository search; use entrypoints when external roots are unclear. Use context for reuse candidates and evidence for the execution, runtime or dependency relationships needed to connect the existing path and consumers. Read implementation details with ordinary file tools; symbol-aware reads are optional. Choose commands to settle facts, not to complete a fixed query checklist. A module inventory, a matching type, a helper's implementation or the first search result does not establish the operation's live path.