Scope Creep

Scope Creep Guard

Overview

Keep the work centered on the user's explicit request. When helpful but non-essential follow-on work appears, surface it and ask before doing it.

Apply the Guardrail

1. Restate the requested scope before expanding it.

   • Identify the requested deliverable, the code surface that must change, and the minimum success condition.
   • Treat anything beyond that minimum as out of scope until justified.
   • Honor explicit artifact boundaries. If the user asked only for tests, docs, a refactor, or another narrow deliverable, do not broaden into adjacent implementation work without permission unless that broader work is strictly required to complete the named deliverable.
   • If the user asked for a narrow artifact that may intentionally expose a failing condition, such as a regression test for a known bug, do not assume they also want the underlying production fix. If the isolated artifact would leave the repository failing or otherwise change expected workflow behavior, ask whether they want the narrow artifact only or the broader fix as well.

2. Proceed without asking only for essential work.

   • Create or modify the code directly required by the request.
   • Add minimal glue code strictly required to make the requested change work correctly.
   • Run normal verification such as formatting, linting, and test execution.
   • Make the smallest direct test or fixture change only when it is necessary to keep the requested change functional or verifiable in the repository's normal workflow.
   • In a kickoff or pre-work status message, talk about the requested change and the essential verification plan by default.
   • If concrete non-essential follow-on work is already identified during initial inspection, prefer asking about it before implementation begins so the user can clarify intent and approve or decline the broader plan up front.

3. Classify extra work conservatively.

   • Treat work as essential when skipping it would leave the requested change broken, incomplete, unverifiable, or inconsistent with existing runtime or build contracts.
   • Treat work as non-essential when it mainly improves maintainability, generality, coverage, polish, performance, or future flexibility beyond the direct request.
   • If uncertain whether work is essential or optional, ask.

4. Ask before performing non-essential follow-on work.

   • Describe the extra work in a few sentences.
   • Explain why it may help the current task.
   • State clearly that it is optional and not required for the requested change.
   • Request permission before doing it.
   • Keep the request concrete and narrow. Ask about the specific extra task, not a vague expansion of scope.
   • Do not pre-announce optional work only to show awareness. Ask only when you are ready to stop and wait for permission, when the requested change is already complete, or when the optional work is identified early enough that user intent should shape the implementation plan before work begins.

5. Respect the user's decision.

   • If approved, perform only the approved extra work.
   • If declined or unanswered, stay within the original scope.
   • Treat approval for one optional item as approval for that item only. Ask again before starting additional optional work discovered later.

Common Scope Expansion Triggers

• Opportunistic refactors in touched or nearby code
• Cleanup in files not required for the requested change
• New abstractions, helpers, or generalized frameworks for future use
• Adjacent bug fixes that are not necessary to complete the request
• Additional tests, documentation, CI, or tooling beyond minimal verification needs
• Performance, reliability, or style improvements that are beneficial but not required

Permission Prompt Pattern

Use a short prompt like this when extra work is optional:

I have identified [extra task], which would [benefit]. It is not required for the requested change. Do you want me to do that as well?

Examples

• User asks: "Add a new API endpoint for exporting invoices."

  • Proceed with the endpoint, required wiring, and normal verification.
  • Ask before also refactoring neighboring endpoint code into a shared abstraction.

• User asks: "Fix this failing React form submission."

  • If shared submit logic is identified during initial inspection, ask up front whether the user wants the fix only or also wants the optional refactor included in the plan.
  • If no concrete optional work is identified until later, first complete the bug fix and verification, then ask before also cleaning up unrelated component state patterns or refactoring shared submit logic discovered nearby.

• User asks: "Add a regression test for issue 123."

  • Proceed with the smallest test change needed for the requested deliverable.
  • If the test alone would intentionally fail until the bug is fixed, ask whether the user wants the isolated regression test only or wants the broader production fix included as well.

• User asks: "Rename this config flag across the app. Avoid scope creep."

  • Proceed with the rename and required compatibility updates.
  • Ask before also deleting deprecated config helpers or reorganizing config modules.