Surgical implementation
Skill 26zl/universal-agent-skills/skills/surgical-implementation
Canonical Agent Skills with idempotent cross-agent installers for Claude Code, Codex, OpenCode, and GitHub Copilot
npx -y skills add 26zl/universal-agent-skills --skill surgical-implementationAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- 14 days oldThe repository was created 14 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
- 1 stars1 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
Make the smallest justified code or configuration change, surface material assumptions, avoid unrelated cleanup, fix rather than silently skip defects found along the way, and define verifiable success criteria. Use when implementing features, fixes, refactors, or configuration changes in an existing repository; do not use for read-only analysis or broad rewrites the user explicitly requested.
The file declares its own license as MIT. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.
SKILL.md
2.8 KB, as published. Nobody here has run it
Surgical Implementation
Keep every changed line traceable to the requested outcome. Match the repository before introducing a new convention.
Workflow
- Read the relevant code, local instructions, and nearby tests before choosing an approach.
- State only assumptions that could materially change the implementation. Ask when guessing would create meaningful risk.
- Define a short success condition that can be checked after the change.
- Choose the smallest design that satisfies the request and existing contracts.
- Modify only the required files. Match local naming, structure, error handling, and style.
- Remove imports or helpers made obsolete by this change. Leave pre-existing cleanup alone unless requested.
- Run focused checks against the success condition, then inspect the final diff for unrelated edits.
Guardrails
- Do not add speculative features, abstraction layers, configuration, or fallback behavior.
- Do not silently choose among materially different interpretations.
- Do not refactor adjacent code merely because it could be cleaner.
- Do not rewrite comments or formatting outside the changed behavior.
- Do not fold an unrelated defect into the requested patch, and do not leave it unfixed either.
- Expand scope only when the requested behavior cannot be implemented safely without it; explain the dependency first.
Defects found outside the request
A defect stays in scope even when it predates the task, came from another session, or sits in code nobody asked about. Silently skipping it is not allowed.
- Name the defect, the evidence for it, and the risk of leaving it in place.
- Fix it as its own change, kept out of the requested patch so both stay reviewable.
- Ask first when the fix is destructive, outward-facing, or needs a materially different design.
- Verify the fix on its own terms and report it separately from the requested work.
Style differences, unfamiliar patterns, and code that is merely improvable are not defects. A defect is behavior that is wrong, unsafe, or contradicts a documented contract.
Completion evidence
- the success condition and focused checks performed;
- any necessary scope expansion and why it was unavoidable;
- any defect found outside the request, and whether it was fixed or is waiting for approval;
- remaining uncertainty or checks that could not run.