Explain fix
My AI agent skills collection.
npx -y skills add TheEdoRan/skills --skill explain-fixAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- 21 days oldThe repository was created 21 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.
- 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
Analyzes the implementation of a feature (or the work just completed in the conversation) across security, performance, maintainability, and edge cases, then hardens it test-first — same analysis as the `explain` skill, but the fixes are applied instead of left to the user. Invoke only when the user explicitly requests `/explain-fix` or `$explain-fix`, optionally naming the feature, paths, or diff to analyze.
SKILL.md
2.2 KB, as published. Nobody here has run it
Explain and Fix Implementation
Two phases: analyze, then fix.
Phase 1: Explain
Read ../explain/SKILL.md (relative to this skill's directory) and follow it
end to end — same scope resolution, same parallel subagent exploration, same
four dimensions with security first, same explain-report.md written to the
repo root. Its read-only rule applies to this phase only: once the report is
written, continue below instead of stopping.
Phase 2: TDD hardening
For every confirmed defect and every unhandled edge case with local, clearly correct behavior:
- Write a test in the repo's existing test framework and style that captures the correct behavior. Run it and confirm it FAILS against the current code.
- Apply the minimal fix. Confirm the test passes.
- Run the full test suite for the affected area and confirm nothing broke.
Never write the fix before the failing test. A finding without a failing test is a hypothesis, not a defect — verify it before fixing it.
Do NOT auto-fix findings that require design decisions, public API changes, schema migrations, or new dependencies. Report those as recommendations with a suggested approach and leave the code untouched.
Report
Update explain-report.md so each finding is marked fixed (with the test
that now guards it) or recommended, not applied (with why). Then end with
a short summary in the conversation:
- Fixed — each finding fixed, with severity,
file:line, and the test that now guards it. - Recommended, not applied — findings needing a user decision, with the suggested approach.
- Path to the updated
explain-report.md.
$ARGUMENTS