# Outcome Readout > Use after a shipped feature has run long enough to read its analytics, to judge whether it solved the pain and name the next thing worth building. Triggers on a launched feature plus its spec's Validation Record and live numbers. No pre-registered metric and measured value, no verdict. - **Type:** Skill - **Install:** `agentstack add skill-royvergara-design-team-os-outcome-readout` - **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior - **Seller:** [royvergara](https://agentstack.voostack.com/s/royvergara) - **Installs:** 0 - **Category:** [Data & Analytics](https://agentstack.voostack.com/c/data-and-analytics) - **Latest version:** 0.1.0 - **License:** MIT - **Upstream author:** [royvergara](https://github.com/royvergara) - **Source:** https://github.com/royvergara/design-team-os/tree/main/skills/outcome-readout ## Install ```sh agentstack add skill-royvergara-design-team-os-outcome-readout ``` Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent. ## About # Outcome Readout You are the only skill that closes the loop. `prototype-to-spec` built the proof into the launch; this reads it back. Without it the spine ships forever and never learns whether any of it mattered. ## The gate, before any verdict Require two things: the metric and target pre-registered before launch (from the spec's Validation Record), and that metric's actual measured value now. If the bar carries pre-registered guardrails, their current values are part of the read — a guardrail nobody fetched reports as **unread**, never assumed held. If the bar was never set in advance, you cannot score the launch — say so; the fix is upstream at `brief-from-pain` (with `validation-plan` designing the read so it's cleanly readable), not a number invented now. If the number is not in hand, the output is "not yet measurable, here is exactly what to pull and from where," not a verdict. If a `design-os.profile.yaml` is present, read the metric's meaning from its `metrics:` dictionary (the definition settles what was measured) and locate the number via `analytics.source` — the pre-registered bar and the measured value are still required; the profile says where and what, never whether. Never score the launch against a criterion invented after it. "Engagement looks up," "the team loves it," a flattering metric nobody pre-registered — that is how a miss gets laundered into a win. Judge only against the bar set before the build. ## When the gate passes, render the readout State the pre-registered bar, the measured value and where it came from, then the verdict — one word from a fixed set, tied to the number, not the impression: - **solved** — the bar cleared. - **partial** — real movement toward the bar that falls short. 34→47 against a 50 bar is partial. - **didn't** — no meaningful movement, or the wrong direction. The mapping is mechanical: cleared the bar → **solved**; short of the bar but meaningfully above baseline → **partial**; at or near baseline, or moved the wrong way → **didn't**. Once the numbers are placed, no judgment call remains. Never a softer or harsher synonym — and never at anyone's request. A stakeholder asking you to round a partial down to didn't ("rip the band-aid," "just call it a miss") gets the same refusal as one asking to round it up to solved: the numbers pick the word, people don't. Beside the verdict, show arithmetic a reader can check — the movement from baseline (e.g. +13 from 34%) and the distance to the bar (e.g. −3 against 50%) — and never swap the two. If guardrails were pre-registered, read each one beside the bar — **held**, **broken**, or **unread**, with its numbers — and the verdict carries both reads: "solved, guardrail broken" is legal and required. A cleared bar never silences a broken guardrail. Then diagnose briefly: did it address the pain, or move a different thing — and did the number move because the thing it stands for moved, or was the metric gamed hollow (invites prompted that nobody accepts move the number, not the pain). ## Always end with the next Intent input The next problem worth starting, framed as a Gate-1 prompt for `prd-to-ia` or `user-journey-mapping`, or an explicit "stop investing here, because." The loop-back is never empty — that is what makes this a loop and not a dead end. If a `design-os.work/.yaml` ledger is present, record the measured value and its source, the verdict against the pre-registered bar, each guardrail's read (held/broken/unread), and this next-Intent line to `value.outcome` — the number and where it came from, never a bare `solved` — closing this work's ledger and seeding the next (see [templates/work-ledger.schema.md](../../templates/work-ledger.schema.md)). No ledger changes nothing about the readout above. ## Orientation — one line in, one line out Open with the spine position: this is the **exit of Gate 3 (Value)** — the last gate, behind it a shipped feature and its pre-registered bar, ahead of it only the next loop. The look-ahead is the next-Intent line the readout already requires: name it as Gate-1 input explicitly, so the verdict lands as the start of the next piece of work and never as a report that files itself. ## Quality bar The verdict cites a pre-registered bar and a measured number, never one without the other. If you claimed success without the number, you faked the gate. This skill scores one feature. The rollup across a whole effort lives in [templates/ai-outcomes-scorecard.md](../../templates/ai-outcomes-scorecard.md), which reads from these verdicts. A leverage number on that sheet is never a substitute for a verdict you have not earned here. ## Source & license This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code. - **Author:** [royvergara](https://github.com/royvergara) - **Source:** [royvergara/design-team-os](https://github.com/royvergara/design-team-os) - **License:** MIT Install and usage instructions live in the source repository linked above. ## Pricing - **Free** — Free ## Security capabilities Automated source analysis of v0.1.0 — what this tool can access: - **Network access:** no - **Filesystem access:** no - **Shell / process execution:** no - **Environment & secrets:** no - **Dynamic code execution:** no *"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.* ## Versions - **0.1.0** — security scan: passed — Imported from the upstream source. ## Links - Listing page: https://agentstack.voostack.com/l/skill-royvergara-design-team-os-outcome-readout - Seller: https://agentstack.voostack.com/s/royvergara - Browse the marketplace: https://agentstack.voostack.com/browse --- Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.