Outcome readout
The open source operating system for design teams running on AI — three gates, gate-enforcing Claude skills, a work ledger, and a conductor. Installable as a Claude Code plugin.
npx -y skills add royvergara/design-team-os --skill outcome-readoutAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
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.
SKILL.md
4.9 KB, as published. Nobody here has run it
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/<slug>.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). 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, which reads from these verdicts. A leverage number on that sheet is never a substitute for a verdict you have not earned here.