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 synaptiai/synapti-marketplace --skill scoring-and-release-gategit clone --depth 1 https://github.com/synaptiai/synapti-marketplaceWrote 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/synaptiai/synapti-marketplace/scoring-and-release-gate)<a href="https://agentmods.dev/skills/synaptiai/synapti-marketplace/scoring-and-release-gate"><img src="https://agentmods.dev/badge/skills/synaptiai/synapti-marketplace/scoring-and-release-gate/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/synaptiai/synapti-marketplace/scoring-and-release-gate"><img src="https://agentmods.dev/badge/skills/synaptiai/synapti-marketplace/scoring-and-release-gate.svg" alt="Reviewed on agentmods" width="80" 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.00149 | $0.01906 |
| Opus 5 | $0.00075 | $0.00953 |
| Sonnet 5 | $0.00030 | $0.00381 |
| Haiku 4.5 | $0.00015 | $0.00191 |
Grade A, and why
scoring-and-release-gate 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 8d 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 — 122 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Scoring and Release Gate
Two separate judgments that must never be collapsed: how good the package is, and whether it may be released.
Iron Law
THE GATE IS BINARY AND CONJUNCTIVE — 19 of 19 or NOT-RELEASABLE. A high score never substitutes for a failed condition.
The score is a quality signal for the people improving the package. The gate is a release decision. A 98 with one unapproved public claim is not ready, and the 98 is irrelevant to that fact.
Scoring
Ten weighted dimensions summing to 100. Full tests and 0/3/5/8/10 anchors: references/scorecard-rubric.md.
| # | Dimension | Weight |
|---|---|---|
| 1 | Evidence grounding and freshness | 18 |
| 2 | Coverage and completeness | 12 |
| 3 | Technical correctness | 15 |
| 4 | Cross-document consistency | 10 |
| 5 | Due-diligence decision value | 10 |
| 6 | Onboarding and operability | 10 |
| 7 | Security, privacy, and disclosure safety | 10 |
| 8 | Reliability and verification depth | 5 |
| 9 | Public usefulness and claim integrity | 5 |
| 10 | Clarity and maintainability | 5 |
Two rules:
- Every deduction cites at least one finding ID. A deduction with no finding is a mood. If the deduction is real, write the finding.
- Every dimension must reach
gate.minDimensionPercentof its available points (default 80%). This is a gate condition, not a scoring rule — it exists so a package cannot average well while failing one dimension outright.
Who scores what
Each verification pass scores independently, seeing only its own findings. Do not calibrate toward the other passes or toward an expected number — variance across passes is the signal three passes exist to produce, and averaging it away in advance destroys it.
dossier-scorer issues the final score and is the only issuer of the gate verdict. It sees the final package, the adjudicated findings ledger, and the resolved scope — never the drafting rationale, never the repair rationale, never the author's self-score.
The mechanical / judgment split
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.
- 8d ago First seen · 122 lines · 149 tokens per session scan A 8a8c020c597e
scoring-and-release-gate is a skill published in the GitHub repository synaptiai/synapti-marketplace (6 stars, last pushed today), licensed Apache-2.0. It adds 149 tokens to every session and 1,906 once invoked, about $0.0007 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-09-03.
Other skills, from other repositories
step4-archive-spec
Archive a completed spec — moves it to specs-archived and blocks agent access.
plan-roadmap
Create or update a prioritized product roadmap with phased milestones.
harvest-findings
Composable operation that harvests inline manual-test findings from an epic's test plan, captures them to the backlog, and turns in-scope ones into a remediation story. Called at the manual-test-pass boundary by /epic-flywheel and /retrospective. Directly invocable as /harvest-findings {N}.
check
Confirm a change before merge. /check verify drives the real app to prove behavior against the spec (every acceptance criterion met, every surface built). /check review runs a senior code review on a fresh model, one that did not write the code. Verify after /develop, review before a PR. Writes to docs/reviews/, never…
pipeline-efficiency-benchmark
A repeatable benchmark for comparing different versions of a development pipeline. It runs the same public tasks in isolated workspaces and records scores, tokens, time, tool calls, and cost.
x-qdev
A compact development workflow for a small, clearly defined code change. It keeps the requirement, initially failing tests, implementation, and real verification results in one task document, following TDD, or test-driven development.