Safe code change
Portable, reusable instruction packages for AI coding assistants.
npx -y skills add RobinGru/AgentSkillForge --skill safe-code-changeAssembled 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
Make a bounded code change with an explicit behavior specification and proportionate verification. Use for localized fixes or behavior-preserving refactors, not for broad design, review, or investigation work.
The file declares its own license as Apache-2.0. 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.7 KB, as published. Nobody here has run it
Safe code change
Use this workflow for a small, understood change where safety comes from a clear specification and direct proof, not from expanding the task into a broad refactor.
Use this skill when
- A localized defect has a reproducible symptom or clear expected behavior.
- A small refactor must preserve observable behavior.
- The likely files and affected boundary can be identified without a broad redesign or investigation.
Do not use this skill when
- The request is only to review an existing change.
- A performance question needs measurement or bottleneck analysis.
- A component needs structural decomposition before a safe local patch exists.
- The outcome, scope, or ownership decision remains unclear.
Workflow
1. Inspect
Read the affected code, its nearest tests, and the closest existing pattern. Identify the narrowest change boundary and expand the inspection only when a real dependency requires it.
2. Specification
Before editing, record:
- behavior that must remain unchanged;
- behavior that must change;
- public interfaces, data formats, or callers at risk;
- the smallest signal that will demonstrate success.
If the specification cannot be stated, stop and obtain the missing decision.
3. Patch
Make the smallest sufficient change. Preserve error paths and existing type, language, and style conventions. Do not fold unrelated cleanup, speculative abstractions, or an API redesign into the patch.
4. Prove
Choose only the checks justified by the change, in this order where relevant:
- reproduce the original symptom or run the affected test;
- run the nearest targeted test;
- run type or lint checks;
- build the affected artifact;
- run a broader suite when the boundary or risk warrants it.
Record checks that were not run and why. A passing broad check does not replace the direct behavior signal when one is available.
5. Report
Report the completed change, the proof obtained, unrun checks, remaining risks, and deliberately untouched areas. Do not claim checks that did not run.
Output specification
Use this format after the change:
## Change
## Specification preserved
## Facts
## Checks not run
## Remaining risks
## Intentionally untouched
Each section must contain a concrete statement. If no risk, skipped check, or untouched area applies, state that explicitly rather than omitting the section.