explain-fix
Skill0 starsChanged 34 days agoMITView on GitHub
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.
In this repository4 other files it gives its agents.
- explain-implementationSkill
- explainSkill
- gcpSkill
- use-subagentsSkill
The file
We split this skill into the rules it gives an agent
6 rules. About 0 are common, 4 are distinctive, and 2 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈4
Distinctive · estimate
This author's own choices. Worth a look.
2
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 14
Read ../explain/SKILL.md (relative to this skill's directory) and follow it end to end — same scope resolution, same parallel subagent …
- Distinctive: line 25
Write a test in the repo's existing test framework and style that captures the correct behavior.
- Distinctive: line 28
Run the full test suite for the affected area and confirm nothing broke.
- Distinctive: line 30
Never write the fix before the failing test.
- Distinctive: line 33
Do NOT auto-fix findings that require design decisions, public API changes, schema migrations, or new dependencies.
- Very specific: line 39
Update explain-report.md so each finding is marked fixed (with the test that now guards it) or recommended, not applied (with why).
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
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
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.