explain-implementation
Skill2 starsChanged 4 days agoMITView on GitHub
Use when a completed implementation needs an ownership transfer, a visual PR explanation, or a source-backed walkthrough of its lifecycle and decisions.
1 other project uses a version of this.
Adopted by
Most recently taken up by
- TheEdoRan/skillstheir own version, first seen Oct 15, 2026
Other versions1 project uses a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 1
- TheEdoRan/skills★ 0same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository4 other files it gives its agents.
- adversarial-reviewSkill
- dispatch-ticketsSkill
- frontend-designSkill
- grill-plan-buildSkill
The file
We split this skill into the rules it gives an agent
8 rules. About 0 are common, 7 are distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈7
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 16
Read the approved intent, final diff including new files, entry points and adjacent callers, relevant tests, execution output, and review …
- Distinctive: line 18
Prefer final source over planned source.
- Very specific: line 29
Read $pr for its Summary, Evidence, and Merge Danger structure.
- Distinctive: line 45
Use committed GitHub source links in published PRs.
- Distinctive: line 47
Do not add quizzes, HTML artifacts, annotation servers, or a separate briefing workflow.
- Distinctive: line 52
Check the explanation against the final source, validation, and review evidence.
- Distinctive: line 53
If reconstruction finds a material contradiction, return it to the implementation owner for a bounded fix and relevant validation.
- Distinctive: line 57
Create or update the PR only when already authorized.
≈ “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 Implementation
Explain the final implementation visually in the PR body. Start with the concrete trigger and resulting behavior, then show the lifecycle from its main entry point. Scale the explanation to the change; a small fix needs little prose.
Reconstruct From Evidence
Read the approved intent, final diff including new files, entry points and adjacent callers, relevant tests, execution output, and review dispositions. Prefer final source over planned source. Explain deviations only when they help a reviewer understand the resulting design. Use the repository's glossary and architectural decisions when present.
A fresh explanation context can help for a substantial implementation. Give it source and evidence pointers, not the author's conclusions. It drafts the PR body; the main agent verifies it and owns publication. This is explanation, not another mandatory review event.
Draft The PR Body
Read $pr for its Summary, Evidence, and Merge Danger structure. If unavailable,
use those three sections directly. Respect the repository's PR template.
- Summary: choose the smallest visual that explains the change: a call tree, before/after diff sketch, component/file tree, pseudocode, or Mermaid. Put brief prose next to it. Show ownership and side-effect ordering; include an important failure or recovery path when it changes the behavior. For a larger ownership transfer, explain consequential decisions and where a maintainer would change the feature next. Link verified source paths or symbols.
- Evidence: map the claimed behavior to observed before/after output, relevant tests, or UI screenshots. Distinguish execution from source inspection and simulated checks. Never invent a failing baseline, screenshot, or test run. Say when a baseline or requested validation is unavailable.
- Merge Danger: explain reversibility (one-way or two-way door), affected surfaces, and any rollout, recovery, or remaining limitation that affects review.
Use committed GitHub source links in published PRs; local absolute file links are for chat. Avoid copying large code blocks that obscure the lifecycle. Do not add quizzes, HTML artifacts, annotation servers, or a separate briefing workflow. The PR itself is the durable visual explanation.
Verify And Publish Within Scope
Check the explanation against the final source, validation, and review evidence. If reconstruction finds a material contradiction, return it to the implementation owner for a bounded fix and relevant validation; update the explanation afterward. Reopen review only when changed evidence introduces material risk.
Create or update the PR only when already authorized. Otherwise return the draft body in chat; missing publication permission does not block explaining the work. Report the PR link, meaningful checks, and material limitations. Do not treat writing an explanation as proof that the implementation is correct.
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.