Implementation Plan

Implementation Plan

A plan's job is to surface the things the user might actually need to alter, before changing them becomes expensive. Order it by likelihood of change, not by execution order.

Workflow

1. Gather the inputs. Collect what this plan is based on: the brainstorm,

spec, prototype, or interview decisions from earlier in the conversation, plus a read of the code that will be touched.

1. Sort by likelihood of change, not chronology. Lead with the decisions

the user is most likely to tweak:

• data model and schema changes
• new type interfaces and API shapes
• anything user-facing (UX flows, copy, layout)

Bury the mechanical refactoring at the bottom — the user trusts the agent on that part.

1. Make the top decisions reviewable. For each high-change-risk decision:

the chosen option, 1-2 alternatives considered, and what changing it later would cost. This is what lets the user veto cheaply.

1. Mark the improvisation zones. Flag the areas where unknowns are likely

to surface mid-implementation, and state the fallback posture for each (e.g. "pick the conservative option and log it").

1. End with an explicit go/no-go. Ask the user to approve, adjust, or

reject. On approval, suggest starting implementation in a fresh session with this plan (and any prototypes) passed in as artifacts.

Rules

• The plan is for review, not a contract — it should tell the reader where

it is likely to be wrong.

• Do not start implementing in the same breath as presenting the plan.
• If a plan section would just restate the obvious ("write the code, run the

tests"), cut it; length is not thoroughness.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: GreatMark
• Source: GreatMark/fable-field-guide-skills
• License: MIT

Install and usage instructions live in the source repository linked above.