Amo fix
Practical agent skills for real engineering workflows.
npx -y skills add lencamo/skills --skill amo-fixAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
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.
SKILL.md
2.7 KB, as published. Nobody here has run it
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