Add dev-report skill - #1531
Open
delpicorp wants to merge 2 commits into
Open
Conversation
Describes the plugin by its output — a plain-language explanation of a Claude Code session — instead of by its intended audience.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Adds dev-report to Communication & Writing, in alphabetical order. README entry only — the skill lives in its own repository, like
article-extractor,brainstorming, andfamily-history-researchin the same section.What problem it solves
You finish a long Claude Code session. A dozen files changed, a bug got fixed, and several implementation calls were made along the way. Ask "what did we do today?" and the summary is accurate but written for someone reading the diff alongside it — file names, function names, a change list. Ask for it "simply" instead and the reasoning goes out with the jargon, leaving something short you still can't act on.
dev-report explains the session in plain language and reports four things: what was built or changed, why that approach was chosen, what is still unfinished or unverified, and what to do next. Technical terms aren't removed — they're explained the first time they appear, so the reasoning survives intact.
Two rules do most of the work. Every finding leads with the raw artifact — the actual log line, the actual count — before it gets explained. And the section on how a problem was solved is required to name the option that was rejected and what would have gone wrong, which is the only way to check a technical decision you can't read yourself.
Who uses this workflow
People building their own products with Claude Code — vibe coders, indie hackers, solo founders — who need to understand what happened in a session before deciding what's next. Also developers who owe an end-of-session explanation to a founder, client, or PM who doesn't read code.
Attribution
Our own working practice — the end-of-session write-up we were doing by hand, turned into a skill. Not adapted from anyone else's workflow.
Example
Opening of a worked example that ships in the repo (illustrative, not a real customer session):
Notes
/plugin marketplace add delpicorp/dev-report) or as a plain skill via git clone. Tested on Claude Code. MIT licensed.Updated 2026-08-04: reworded the entry and this description to lead with what the skill does rather than who it's for.