Practical decision guide
5 min read
Updated
Ask an agent for a small change without a rewrite
Bound the desired behavior, preserve existing work and review the smallest useful patch.
Direct answer
Describe one observable change, the behavior that must stay and the evidence that will show success. Have the agent inspect existing components before proposing new ones. Keep authorization tied to that change: a local correction is not permission to replace the stack, publish secrets or clean unrelated work.
01
Name the behavioral difference
Instead of “make the form better”, request “after an invalid email, show a persistent correction message while retaining the other fields”. Include one before/after example and identify the screen.
List what must not change: validation rules, submitted payload, translations and visual tokens. These constraints guide implementation; they are not a request for a new architecture document.
- ask my agent for a small fix without rewriting
- limit the scope of an agent change
Instead of “make the form better”, request “after an invalid email, show a persistent correction message while retaining the other fields”. Include one before/after example and identify the screen. List what must not change: validation rules, submitted payload, translations and visual tokens. These constraints guide implementation; they are not a request for a new architecture document.
02
Inspect before writing
Ask for the relevant component, its callers and existing tests. Identify uncommitted work and ownership boundaries. A clean patch should not absorb unrelated formatting or dependency upgrades.
Prefer an existing error component if it satisfies the contract. If it cannot, state the missing behavior and change that seam locally rather than copying the entire page.
Ask for the relevant component, its callers and existing tests. Identify uncommitted work and ownership boundaries. A clean patch should not absorb unrelated formatting or dependency upgrades. Prefer an existing error component if it satisfies the contract. If it cannot, state the missing behavior and change that seam locally rather than copying the entire page.
03
Example: preserve form input
Provide a fictional invalid email and expected message. Ask the agent to demonstrate that correcting it retains the name field, resubmits correctly and does not send the form twice.
The deliverable is the changed component, relevant check and a short explanation of the behavior. A screenshot alone cannot prove preserved values or a server-side outcome.
Provide a fictional invalid email and expected message. Ask the agent to demonstrate that correcting it retains the name field, resubmits correctly and does not send the form twice. The deliverable is the changed component, relevant check and a short explanation of the behavior. A screenshot alone cannot prove preserved values or a server-side outcome.
04
Control scope drift
If the agent discovers a separate defect, record it with its impact. Fix it in the same patch only when needed for the requested behavior or explicitly authorized. Avoid turning every small task into a cleanup project.
Before destructive or external actions, verify the actual authorization. A prompt is not an enforcement boundary: tool permissions and the environment determine what the agent can do.
If the agent discovers a separate defect, record it with its impact. Fix it in the same patch only when needed for the requested behavior or explicitly authorized. Avoid turning every small task into a cleanup project. Before destructive or external actions, verify the actual authorization. A prompt is not an enforcement boundary: tool permissions and the environment determine what the agent can do.
05
Review the actual patch
Read the diff for unintended files and behavior, then exercise the original case and one nearby failure. Choose tests according to risk, retaining required checks for security, persistence and shared runtime changes.
Report implementation, tests and publication separately. This guide provides a reusable brief, not a promise that every agent will obey it or that fewer changed lines always mean less risk.
Read the diff for unintended files and behavior, then exercise the original case and one nearby failure. Choose tests according to risk, retaining required checks for security, persistence and shared runtime changes. Report implementation, tests and publication separately. This guide provides a reusable brief, not a promise that every agent will obey it or that fewer changed lines always mean less risk.
Keep this
Verify in your product
- 01One behavior is explicit.
- 02Preserved behavior is listed.
- 03Existing components were inspected.
- 04Unrelated work stays outside the patch.
- 05Important failure paths are checked.
- 06Delivery claims match evidence.
Primary sources
Technical claims in this guide connect to first-party specifications and documentation.
- git diff (opens in a new tab)Git · Primary reference for the documented mechanism. The worked scenario and decision checklist are original SkillCodex editorial guidance, not a certified implementation.
- Pull request reviews (opens in a new tab)GitHub · Primary reference for the documented mechanism. The worked scenario and decision checklist are original SkillCodex editorial guidance, not a certified implementation.
Continue
Related guides and tools
Understand → Recognize → Choose → Compare
Pack for your agent
Pre-written instruction by SkillCodex — your request is neither sent nor used to adapt this text; no content is generated, and copying executes nothing.
Implement correctly
Apply “Ask an agent for a small change without a rewrite” step by step
# Apply the “Ask an agent for a small change without a rewrite” guide in your agent ## Objective Describe one observable change, the behavior that must stay and the evidence that will show success. Have the agent inspect existing components before proposing new ones. Keep authorization tied to that change: a local correction is not permission to replace the stack, publish secrets or clean unrelated work. ## Prerequisites - Inspect the repository, documentation, and existing conventions. - Confirm the need matches the guide scope: Bound the desired behavior, preserve existing work and review the smallest useful patch. - Preserve the correct decisions already in place. ## Guide steps - 1. Name the behavioral difference — Instead of “make the form better”, request “after an invalid email, show a persistent correction message while retaining the other fields”. Include one before/after example and identify the screen. List what must not change: validation rules, submitted payload, translations and visual tokens. These constraints guide implementation; they are not a request for a new architecture document. - 2. Inspect before writing — Ask for the relevant component, its callers and existing tests. Identify uncommitted work and ownership boundaries. A clean patch should not absorb unrelated formatting or dependency upgrades. Prefer an existing error component if it satisfies the contract. If it cannot, state the missing behavior and change that seam locally rather than copying the entire page. - 3. Example: preserve form input — Provide a fictional invalid email and expected message. Ask the agent to demonstrate that correcting it retains the name field, resubmits correctly and does not send the form twice. The deliverable is the changed component, relevant check and a short explanation of the behavior. A screenshot alone cannot prove preserved values or a server-side outcome. - 4. Control scope drift — If the agent discovers a separate defect, record it with its impact. Fix it in the same patch only when needed for the requested behavior or explicitly authorized. Avoid turning every small task into a cleanup project. Before destructive or external actions, verify the actual authorization. A prompt is not an enforcement boundary: tool permissions and the environment determine what the agent can do. - 5. Review the actual patch — Read the diff for unintended files and behavior, then exercise the original case and one nearby failure. Choose tests according to risk, retaining required checks for security, persistence and shared runtime changes. Report implementation, tests and publication separately. This guide provides a reusable brief, not a promise that every agent will obey it or that fewer changed lines always mean less risk. ## Acceptance criteria — Verify in your product - One behavior is explicit. - Preserved behavior is listed. - Existing components were inspected. - Unrelated work stays outside the patch. - Important failure paths are checked. - Delivery claims match evidence. ## Guardrails - Show the proposed changes before any external action. - Do not publish, send, delete, pay for, or change remote state without explicit authorization. - Preserve unrelated changes and stop if the scope becomes ambiguous. ## Output format - Outcome or verdict. - Files or actions involved. - Checks run and observable evidence. - Remaining blockers or limitations.
- Requires · The real project context: repository, documentation, and existing constraints
Why it works
- The steps come from a published, sourced guide, not improvisation.
- The checklist turns advice into verifiable criteria.
- The declared scope keeps the guide within its evidence.
Try next
Anchor the guide in the project
# Anchor the guide in the project ## Objective Turn the applied steps into durable repository conventions. ## Checks - Link each decision made to the guide step that justifies it. - Add the checklist to the relevant reviews. - Record out-of-scope cases for the neighboring guides. ## Guardrails - Show the proposed changes before any external action. - Do not publish, send, delete, pay for, or change remote state without explicit authorization. - Preserve unrelated changes and stop if the scope becomes ambiguous. ## Output format - Outcome or verdict. - Files or actions involved. - Checks run and observable evidence. - Remaining blockers or limitations.
sha256:df177065493c13e17bd8b2c05068761245028fed95127b085e95dcd002d70ed4
Diagnose a problem
Diagnose a “Ask an agent for a small change without a rewrite” guide gap
# Diagnose a failed application of the “Ask an agent for a small change without a rewrite” guide ## Observed symptom [DESCRIBE THE SYMPTOM HERE] ## Observable checks - Replay the steps in order and note the first one that diverges: - 1. Name the behavioral difference — Instead of “make the form better”, request “after an invalid email, show a persistent correction message while retaining the other fields”. Include one before/after example and identify the screen. List what must not change: validation rules, submitted payload, translations and visual tokens. These constraints guide implementation; they are not a request for a new architecture document. - 2. Inspect before writing — Ask for the relevant component, its callers and existing tests. Identify uncommitted work and ownership boundaries. A clean patch should not absorb unrelated formatting or dependency upgrades. Prefer an existing error component if it satisfies the contract. If it cannot, state the missing behavior and change that seam locally rather than copying the entire page. - 3. Example: preserve form input — Provide a fictional invalid email and expected message. Ask the agent to demonstrate that correcting it retains the name field, resubmits correctly and does not send the form twice. The deliverable is the changed component, relevant check and a short explanation of the behavior. A screenshot alone cannot prove preserved values or a server-side outcome. - 4. Control scope drift — If the agent discovers a separate defect, record it with its impact. Fix it in the same patch only when needed for the requested behavior or explicitly authorized. Avoid turning every small task into a cleanup project. Before destructive or external actions, verify the actual authorization. A prompt is not an enforcement boundary: tool permissions and the environment determine what the agent can do. - 5. Review the actual patch — Read the diff for unintended files and behavior, then exercise the original case and one nearby failure. Choose tests according to risk, retaining required checks for security, persistence and shared runtime changes. Report implementation, tests and publication separately. This guide provides a reusable brief, not a promise that every agent will obey it or that fewer changed lines always mean less risk. ## Possible causes - A step was skipped or executed out of order. - The actual need falls outside the guide scope. - A checklist criterion was never verified. ## Bounded fixes - Redo only the diverging step and what depends on it. - Document the gap if the guide scope does not cover the need. ## Final verification — Verify in your product - One behavior is explicit. - Preserved behavior is listed. - Existing components were inspected. - Unrelated work stays outside the patch. - Important failure paths are checked. - Delivery claims match evidence. ## Guardrails - Show the proposed changes before any external action. - Do not publish, send, delete, pay for, or change remote state without explicit authorization. - Preserve unrelated changes and stop if the scope becomes ambiguous. ## Output format - Outcome or verdict. - Files or actions involved. - Checks run and observable evidence. - Remaining blockers or limitations.
- Requires · The real project context: repository, documentation, and existing constraints
Why it works
- The diagnosis replays ordered steps instead of searching at random.
- Fixes stay bounded to the first real divergence.
- The checklist serves as a reproducible final verification.
Try next
Prevent the next drift
# Prevent the next drift ## Objective Turn the first diverging step into an explicit project check. ## Checks - Add a focused check on the step that diverged. - Verify the checklist on a second real case. - Document the scope limit you hit. ## Guardrails - Show the proposed changes before any external action. - Do not publish, send, delete, pay for, or change remote state without explicit authorization. - Preserve unrelated changes and stop if the scope becomes ambiguous. ## Output format - Outcome or verdict. - Files or actions involved. - Checks run and observable evidence. - Remaining blockers or limitations.
sha256:f95eb77141f405a37b35c8573af7477c54a89a68d90cb0960d7065cda5964ead
Pack digest: sha256:ba578e826b2948bc0f215680ec7eb787d4267403daba9b75d416a9b1ee1e28cf