Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add Nimrobo/superdense --skill outcome-updategit clone --depth 1 https://github.com/Nimrobo/superdenseWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/nimrobo/superdense/outcome-update)<a href="https://agentmods.dev/skills/nimrobo/superdense/outcome-update"><img src="https://agentmods.dev/badge/skills/nimrobo/superdense/outcome-update.svg" alt="Measured on agentmods" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00052 | $0.00945 |
| Opus 5 | $0.00026 | $0.00473 |
| Sonnet 5 | $0.00010 | $0.00189 |
| Haiku 4.5 | $0.00005 | $0.00094 |
Grade A, and why
outcome-update scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 7d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 61 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Outcome Update
Update only the reusable playbook and completion gate for an outcome loop. This is observer mode: inspect prior runs and Superdense reward evidence, then improve run.md and, when repeated misses show a reusable completion gap, gate.md for future runs.
Read references/outcome-loop.md before editing.
Workflow
- Locate the outcome folder and read
goal.md,run.md,gate.md, andruns/. - Identify runs since
## Update Markerinrun.md. If no marker exists, review all completed run folders and add## Update Markerafter updating. - Inspect Superdense evidence related to those runs:
- session IDs listed in
work.md, - artifact IDs,
- externalization target IDs,
- relevant cohorts or version chains,
- reward snapshots already stored in Superdense.
- hypotheses and experiments referenced in
work.md, - open/refuted/supported hypotheses from
superdense hypothesis list --project <project-id>, - open or due experiments from
superdense experiment list --project <project-id>.
- session IDs listed in
- Look for macro improvements:
- levers that seem weak, strong, or under-instrumented,
- lever statuses to promote, exhaust, retire, or keep because they are Pareto-best on a non-headline reward dimension or guardrail,
- realized explore/exploit mix versus the target ratio,
- hypotheses that should be pruned from future selection because they were refuted,
- experiments that need more reps, are due for verdict, or are inconclusive because instrumentation is missing,
- novelty gaps in untested lever regions,
- actions that repeatedly create friction,
- missing preflight checks,
- repeated required-gate failures or warning misses,
- diagnostic measurements that explain the north star poorly,
- target repo/account workflow gaps,
- Superdense reward-layer bottlenecks.
- Render due verdicts with
superdense experiment verdict <id>when an experiment has enough reps and a mature reward window. Use verdicts to update lever status and the Selection Policy, but do not duplicate reward snapshots into markdown. - Retune the target explore ratio in
run.mdas evidence accumulates: higher when uncertainty and novelty gaps dominate, lower when a proven lever has headroom and supported hypotheses. - Edit
run.mdfor playbook improvements andgate.mdfor reusable completion checks or failure-policy refinements. Do not editgoal.md, old run folders, or target repos. Do not create a new run. - Keep
goal.mdprotected. If evidence suggests the north star or guardrails are wrong, add a clearly marked "Recommended goal review" section torun.mdinstead of changinggoal.md. - Preserve useful existing playbook content. Make focused improvements that the next
outcome-runcan execute without guessing. - Update
## Update Markerinrun.mdto the latest reviewed run id or timestamp. - Commit the playbook and gate changes, for example
git add run.md gate.md && git commit -m "outcome: update playbook (runs through <marker>)". If any reviewedruns/<run-id>/files are still uncommitted, include them in the same commit.
What ships with it
1 file beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 7d ago First seen · 61 lines · 52 tokens per session scan A 17b0797060a4
outcome-update is a skill published in the GitHub repository Nimrobo/superdense (85 stars, last pushed 1mo ago), licensed Apache-2.0. It adds 52 tokens to every session and 945 once invoked, about $0.0003 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
opensrc
Fetch dependency source code to give AI agents deeper implementation context. Use when the agent needs to understand how a library works internally, read source code for a package, fetch implementation details for a dependency, or explore how an npm/PyPI/crates.io package is built. Triggers include "fetch source for"…
brain-bootstrap
Seed a freshly-scaffolded brain with real project knowledge — on an existing (brownfield) project read the code, docs, and git log to draft the six root pages and capture key historical decisions; on a near-empty (greenfield) project interview the user. Every write goes through the brain CLI. Run it after brain-setup.
brain-page
Operating manual for reading and writing a project's brain — every read and write goes through the bundled zero-dependency brain CLI; never hand-edit brain files. Read it before creating or modifying any page or root page.
brain-ingest
The process for digesting a conversation, document, or research result, classifying it, and writing it down as brain content (a root-page update or a new/updated page) through the brain CLI.
brain-setup
Bootstrap the Open Project Brain Standard into the current project — prefer brain init (ensure BRAIN.md, scaffold empty brain brainRoot-aware, default-wire CLAUDE.md + AGENTS.md). Optionally install a pre-commit hook and a Claude Code SessionStart hook.
agentplane-task-closure-recovery
Use when Agentplane task completion, direct finish, branchpr integration, hosted-close, close-tail PRs, PR metadata, dirty task artifacts, or remote branch divergence need diagnosis or recovery.