Standardize how the agent reports completed work — task understood, actions taken, files touched, architecture rules followed, validation attempted/result, assumptions, risks/unresolved issues, unrelated failures, and recommended next steps. This is the central reporting skill referenced by every other skill's "Output rule." Use it at the end of any task to structure the final response to the user. Always use this format instead of inventing a custom report structure.
SkillScore100Maintained
Automatic
◆Project Management pack
Last verified 8/3/2026
What it changes
Passed 22 of 22 test cases with the skill, and 19 of 22 without it.
Without skill86%
With skill100%
Checks it passed that the model alone missed
Uses standard unnumbered section headings for the report structure.
Documents the dependency injection convention in the architecture rules followed section.
Includes an explicit recommendation to update the client SDK in packages/sdk/index.ts as a next step.
3 fixed19 passed either way0 still failing0 broke
Pass-rate lift
+14 pp
Tokens
+58%
Agent turns
0%
Response time
-29%
Model gemini-3.6-flashMeasured 8/3/2026v122 of 22 cases passed with skill
Tokens, turns and time describe resource use, not a dollar price.
See it in action
One of 3 test cases the skill fixed. Same model, same prompt, with and without the skill.
1 of 3
Prompt
We created a new service layer file src/services/notificationService.ts adhering to the project's dependency injection pattern. Present the final completion report.
What was checked, without and with the skill
Checked
Without skill
With skill
Documents the dependency injection convention in the architecture rules followed section.
Missed
Passed
case-17 · gemini-3.6-flash · 8/3/2026 · answers are capped and redacted
What's inside
The instructions your model reads when the skill loads.
SKILL.md93 linessingle file
Global Agent Output and Reporting Skill
Purpose
Provide one consistent, honest, scannable reporting format for completed work, so the user always knows what was done, how it was verified, what's assumed, and what (if anything) still needs attention — regardless of which other skill(s) were used.
When to Use
At the end of any task that produced changes, a plan, an analysis, or any other deliverable.
After Review Before Final Skill has confirmed the work against the original request.
When Not to Use
For trivial conversational replies with no work performed (e.g. answering a quick question with no changes, no files, nothing to validate). In that case, just answer directly — don't force this structure onto a one-line answer.
Required Inputs
The original request and clarified scope.
The findings from Review Before Final Skill.
A record of: files created/modified/moved/deleted, architecture decisions followed, validation run and its results, assumptions made, risks/issues found, and any unrelated failures encountered.
Assumptions
The user wants an accurate picture of what happened, not just a "done" signal.
Sections with nothing to report can be omitted or marked "None" — don't pad the report with empty sections written out at length.
Step-by-Step Workflow
Gather inputs from the work performed and from Review Before Final Skill's findings.
Fill in each section of the reporting structure (below) based on what actually happened — only include details that help the user understand the completed work.
Be concise: use short statements/lists; avoid restating the entire conversation or over-explaining simple changes.
Be honest: if something wasn't done, wasn't validated, or is uncertain, say so plainly — don't imply completeness that wasn't achieved.
Surface anything actionable: risks, unresolved issues, and next steps should be specific enough that the user (or the next agent) can act on them directly.
Skip empty sections or mark them "None" rather than leaving placeholders or over-explaining the absence.
Rules and Best Practices
Use this format for the final response instead of a skill-specific format, even when multiple skills were used in the task.
Only include skill-specific reporting details (e.g. specific QA steps performed, specific architecture decisions) when they help the user understand the completed work — don't mechanically list every skill used.
Be specific about file paths, not vague references ("a few components were updated").
Be specific about what changed, not just that something changed.
Don't over-explain simple, low-risk changes — a one-line summary plus the structure below (with empty sections omitted) is fine for small tasks.
For larger tasks, the structure below should still be scannable — use short bullets, not long paragraphs.
Safety Checks
Never state that validation passed if it wasn't run, or that a risky action was taken if it wasn't approved.
Never omit a known risk or unresolved issue to make the report look cleaner.