plan-change

To create an ADR and Gherkin specification, you can use a structured planning workflow that drives interactive discussion to produce architecture decision records and behavioural feature files. This ensures technical rationale and acceptance scenarios are documented before code is written.

The best way to plan a software refactor is to clarify scope, edge cases, and alternatives through interactive discovery, resulting in right-sized planning artifacts. This approach produces an ADR for architectural changes or a Gherkin spec for behavioural shifts to prevent under-specified work.

You need an architecture decision record for architectural choices and a Gherkin feature file for behavioural expectations. A dual-document approach writes both when warranted, but produces only one if the change is purely architectural or purely behavioural.

Yes, you can match existing repository conventions by inspecting the codebase for current ADR and spec patterns. The planning process follows local naming, formatting, and commit conventions to ensure new documents align with your established repository workflows.

To document scope boundaries for a feature kickoff, engage in an interactive change discovery process that clarifies user flows and explicitly defines out-of-scope boundaries. This yields reviewable planning artifacts that cross-link decision rationale with behavioural specifications.

Yes, this planning approach works for significant bug fixes that alter system behaviour by generating Gherkin specifications to capture the expected new behaviour. It also creates an ADR if the fix changes underlying design assumptions or architecture.