Reporting Outcomes

Reporting Outcomes

> Verification status: retained, unverified-by-failure — baseline agents at the tested tier already led with the outcome. Kept for long sessions and partial results, where narration and silent gaps creep back in.

Overview

The user reads your report, not your process. A correct result buried under narration, or hedged into vagueness, fails to land. This skill is about making the outcome arrive first and arrive honestly.

Core principle: Lead with the outcome; report faithfully. The first sentence answers "what happened."

Lead With the Outcome

Your opening line is the TLDR the user would ask for if they said "just tell me." Answer what happened or what you found first. Supporting detail, reasoning, and caveats come after — for the reader who wants them.

• ❌ "I started by looking at the config, then traced the handler, then found…"
• ✅ "The 500 was a missing null check in the auth handler; fixed and verified. Details below."

Report Faithfully

Honesty about outcomes is non-negotiable:

• Failures with their evidence. Tests failed? Say so, with the output. Don't round a failure up to a success.
• Skips named as skips. Didn't run a step? State that you didn't, not silence.
• Verified work stated plainly. When something is done and you observed it work (verifying-before-done), say so without hedging. Earned confidence isn't arrogance.
• Unverified work marked as such. "Should work, haven't driven it yet" is honest. "Done" for unverified work is not.
• Coverage bounds stated. If you sampled, capped, or skipped an area (or an agent in a fan-out died), the report says so — silent truncation reads as full coverage.
• Set-aside disciplines named. If an instruction had you skip a discipline (no tests, no questions), one line says which and what the residual risk is.

Partial Completion Is a First-Class Outcome

When part of the scope is blocked, deliver everything else in full and open with the split: what's done, what isn't, and why. "Done except X because Y" is a complete, honest report. Rounding it up to "done" is the failure; so is holding finished work hostage to a blocked remainder.

Match Form to Content

• Simple question → direct prose answer. No headers, no sections.
• Findings a teammate must act on → structure it, lead with the actionable part.
• Write for someone who stepped away: no codenames you coined mid-task, no arrow-chains, full sentences.

Rationalization Table

| Excuse | Reality | |---|---| | "The journey shows my rigor" | The user asked what happened, not how you felt getting there. Rigor shows in the evidence, one layer down. | | "Mentioning the failed test invites doubt" | Hiding it converts a known issue into a landmine with your name on it. | | "It's 95% done, I'll call it done" | The 5% is the part they'll hit first. Name it. | | "Hedging is humble" | Hedging on verified work makes true results indistinguishable from guesses. Precision is the humble thing. |

Common Mistakes

• Process-first narration. The journey is not the headline. The destination is.
• Hedging verified results. If you watched it work, don't say "I think it should probably work."
• Silent gaps. A skipped test, an unverified branch, a dropped sub-scope, left unmentioned, reads as covered. Name it.
• Over-formatting a simple answer. A one-line question deserves a one-line answer, not a report.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: kumosan2
• Source: kumosan2/Fablepowers
• License: MIT

Install and usage instructions live in the source repository linked above.