Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →ccplugins/dev-report
Write up a coding session for a non-technical stakeholder — the context, what was built, and the engineering reasoning behind it — the way a senior engineer briefs a product manager who does not read code. Use ONLY when explicitly invoked, either through the /dev-report slash command or one of its localized aliases (/개발보고 and similar), or when the user directly asks for a stakeholder-facing write-up of the session ("write today up for my PM", "explain this session for a non-developer", "개발 보고서 써
Passed 8 of 15 test cases with the skill, and 7 of 15 without it.
and 6 more in the full report
6 fixed7 passed either way7 still failing3 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 6 test cases the skill fixed. Same model, same prompt, with and without the skill.
Hey, what did you just do in src/auth.ts?
| Checked | Without skill | With skill |
|---|---|---|
| Answers the casual inquiry directly without producing a structured report. | Missed | Passed |
| Focuses directly on the requested file edit. | Missed | Passed |
The instructions your model reads when the skill loads.
Turn a work session into a report a non-technical stakeholder can actually act on.
This skill is explicit-only. It runs when the user calls /dev-report, a localized alias of it, or asks in plain words for a stakeholder-facing write-up. A casual "what did you just do?" is not an invocation — answer that normally.
Anything the user types after the command is a scope or focus hint: /dev-report this week, /dev-report just the auth work, /dev-report 짧게. With no hint, report on the current conversation session. Honor a length or emphasis hint over this skill's defaults — they know their reader.
A product owner, founder, or PM who decides priorities and budget but does not read code. Increasingly they did prompt this code into existence themselves ("vibe coding"), so they know the product vocabulary and about half the technical vocabulary — with gaps they can't see and won't announce.
The failure mode to avoid is not "too technical." It is technical words with no referent. A non-developer can follow arbitrarily deep reasoning as long as every noun in it has been given a meaning first. So: go deep on the logic, and pay for each new term the moment you introduce it.
Two things they need that a peer-to-peer standup would skip:
Write the report in the language of the message that invoked the skill. /dev-report 이번 주 작업 정리해줘 → Korean. /dev-report with no text → the language the conversation has been in.
Keep these verbatim in their original form regardless of output language: file paths, function and variable names, commands, log lines, error messages, branch and commit names, product and vendor names. The reader needs to paste them into a search box or say them to someone else — a translated identifier is a broken one.
When a technical term has no natural equivalent in the output language, use the English term and gloss it once in the reader's language, then keep using the English term.
The conversation is the primary source. It holds what git cannot: why this work was chosen, what was tried and abandoned, what the user corrected you on, what a number actually meant. Reconstruct from it first.
Then corroborate the facts a report will be judged on:
git log --oneline -15
git diff --stat HEAD~1 # or the session's base commit
git status --short
test cases passed, vs 7 / 15 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.