Amo Fix
Diagnose a bug from symptom to root cause before choosing the fix.
Shared Output Marker
Prefix the first output line inline with 🛠️ [amo-fix]. Do not put the marker in a separate paragraph.
Use When
- Existing behavior is wrong, broken, flaky, regressed, inconsistent, or unexpected.
- Runtime, build, framework, state, data flow, or rendered behavior does not match expectation.
- A quick patch may hide a deeper ownership, state, or flow problem.
Do Not Use
- The requested change is intentional product behavior; use
amo-improve.
- The task is a new capability; use
amo-feature.
- Structure is the primary problem with no bug symptom; use
amo-refactor.
- A proposed fix needs challenge; use
amo-best.
Best Standard
Select and state one before recommending a fix:
- Target-state best: default for development-stage work when no explicit constraint is stated; prioritize correct boundaries, long-term maintainability, refactoring when needed, and not bending the design around legacy implementation.
- Constraint best: use when the user requires fast delivery, compatibility, minimal change, short-term delivery, or limited scope.
- Evolutionary best: use when the root fix needs target design work, but should be delivered in safe, staged steps.
- Lowest-risk best: use when production, data, security, auth/permission, payment, migration, or rollback risk dominates.
Workflow
- State symptom and expected behavior.
- Select the best standard and explain why.
- Inspect the real code path, state/data flow, runtime behavior, or rendered output.
- Separate root cause from symptoms and secondary effects.
- Recommend one fix with tradeoffs, regression risk, and verification.
Key Rules
- Root cause before fix.
- Do not present a workaround as the best fix.
- Do not add speculative compatibility paths, fallback branches, or legacy handling without evidence from the codebase or explicit user requirements.
- If the real fix requires refactoring, say so explicitly.
- If implementation reveals a better approach, pause and explain before switching.
Output
Use the user's language for output labels and content.
🛠️ [amo-fix] Scenario: bug fix
Best standard:
Symptom:
Root-cause judgment:
Recommended fix:
Tradeoffs:
Impact scope:
Verification:
Next: use amo-best for second-pass pressure testing if needed
1---2name: amo-fix3description: Use when the user asks why existing behavior is broken, incorrect, flaky, regressed, unexpected, or runtime/build behavior is failing and wants a bug-fix approach before coding. Do not use for planned feature changes, pure refactors, or second-pass solution challenges.4---56# Amo Fix78Diagnose a bug from symptom to root cause before choosing the fix.910## Shared Output Marker1112Prefix the first output line inline with `🛠️ [amo-fix]`. Do not put the marker in a separate paragraph.1314## Use When1516- Existing behavior is wrong, broken, flaky, regressed, inconsistent, or unexpected.17- Runtime, build, framework, state, data flow, or rendered behavior does not match expectation.18- A quick patch may hide a deeper ownership, state, or flow problem.1920## Do Not Use2122- The requested change is intentional product behavior; use `amo-improve`.23- The task is a new capability; use `amo-feature`.24- Structure is the primary problem with no bug symptom; use `amo-refactor`.25- A proposed fix needs challenge; use `amo-best`.2627## Best Standard2829Select and state one before recommending a fix:3031- **Target-state best**: default for development-stage work when no explicit constraint is stated; prioritize correct boundaries, long-term maintainability, refactoring when needed, and not bending the design around legacy implementation.32- **Constraint best**: use when the user requires fast delivery, compatibility, minimal change, short-term delivery, or limited scope.33- **Evolutionary best**: use when the root fix needs target design work, but should be delivered in safe, staged steps.34- **Lowest-risk best**: use when production, data, security, auth/permission, payment, migration, or rollback risk dominates.3536## Workflow37381. State symptom and expected behavior.392. Select the best standard and explain why.403. Inspect the real code path, state/data flow, runtime behavior, or rendered output.414. Separate root cause from symptoms and secondary effects.425. Recommend one fix with tradeoffs, regression risk, and verification.4344## Key Rules4546- Root cause before fix.47- Do not present a workaround as the best fix.48- Do not add speculative compatibility paths, fallback branches, or legacy handling without evidence from the codebase or explicit user requirements.49- If the real fix requires refactoring, say so explicitly.50- If implementation reveals a better approach, pause and explain before switching.5152## Output5354Use the user's language for output labels and content.5556```text57🛠️ [amo-fix] Scenario: bug fix58Best standard:59Symptom:60Root-cause judgment:61Recommended fix:62Tradeoffs:63Impact scope:64Verification:65Next: use amo-best for second-pass pressure testing if needed66```
lencamo