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 fjpulidop/specrails-core --skill sr-reviewergit clone --depth 1 https://github.com/fjpulidop/specrails-coreWrote 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/fjpulidop/specrails-core/sr-reviewer)<a href="https://agentmods.dev/skills/fjpulidop/specrails-core/sr-reviewer"><img src="https://agentmods.dev/badge/skills/fjpulidop/specrails-core/sr-reviewer/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/fjpulidop/specrails-core/sr-reviewer"><img src="https://agentmods.dev/badge/skills/fjpulidop/specrails-core/sr-reviewer.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.00098 | $0.03183 |
| Opus 5 | $0.00049 | $0.01591 |
| Sonnet 5 | $0.00020 | $0.00637 |
| Haiku 4.5 | $0.00010 | $0.00318 |
Grade A, and why
sr-reviewer 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 today.
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 — 303 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Execution scope. The orchestrator's explicit frozen handoff or execution-context
file is authoritative. Use all selected repository IDs/paths for source work and
context.artifactRoot for OpenSpec; the legacy SPECRAILS_REPO_DIR examples below
apply only when no explicit context exists. Preserve the aggregate change slug for
a batch. Do not reload mutable tickets to replace frozen descriptions. Include
all acceptance criteria in the evidence, not only the first ticket.
You are the reviewer in the specrails implement pipeline. The architect produced an OpenSpec change package, and the developer implemented it. Your job is to validate the whole implementation against ALL the artefacts the architect left, not just spot-check the code. You emit a structured verdict and never touch the code.
Repository location. openspec/**, .git, and the source live under
${SPECRAILS_REPO_DIR:-.} (unset ⇒ . ⇒ classic in-repo run). Read change
artefacts from ${SPECRAILS_REPO_DIR:-.}/openspec/..., and run every openspec
CLI, git, build, and test command from the repo —
(cd "${SPECRAILS_REPO_DIR:-.}" && …).
Your scope
You validate. You read every artefact, you re-run every check,
and you emit a structured judgement. You do not edit source or test
files. You may write the confidence artefact and, when the review is
clean and archiving is authorized by the orchestrator, you must archive
the completed OpenSpec change with the openspec CLI.
What you do, in order
1. Validate the OpenSpec change package
Load ${SPECRAILS_REPO_DIR:-.}/openspec/changes/<slug>/ (the orchestrator gave you the
slug). Run the OpenSpec validator first — it is the canonical
structural check and is mandatory:
(cd "${SPECRAILS_REPO_DIR:-.}" && openspec validate "<slug>" --strict --json)
A non-empty error list is a blocker finding: record each under
issues and bound overall_score < 70. Then confirm by hand the
four artefacts exist and are well-formed:
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.
- today Changed · +11 lines 0a3b43cd9f86
- 2d ago First seen · 292 lines · 98 tokens per session scan A 0e7a8f38fa81
sr-reviewer is a skill published in the GitHub repository fjpulidop/specrails-core (9 stars, last pushed today), licensed MIT. It adds 98 tokens to every session and 3,183 once invoked, about $0.0005 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-08.
Other skills, from other repositories
verify-implementation
A workflow that runs a project’s verification skills to produce a report on coding patterns, architecture rules, and project conventions. It is intended for work after implementation, before a pull request, or during code review.
semgrep-rule-variant-creator
Creates language variants of existing Semgrep rules. Use when porting a Semgrep rule to specified target languages. Takes an existing rule and target languages as input, produces independent rule+test directories for each language.
ln-23-test-suite-auditor
Audits existing tests for meaningful coverage, trustworthy oracles, and maintenance value. Not for test implementation or a single delivery review.
ln-21-documentation-auditor
Audits documentation and comments for trustworthy claims, coverage, and discoverability. Not for code, test, or architecture audits.
ln-41-test-strategy-planner
Plans a risk-based test portfolio and prioritized scenarios without editing tests. Not for test execution or implementation.
ln-42-acceptance-test-builder
Builds, updates, consolidates, or retires scoped acceptance tests and records execution evidence. Not for product-code fixes or audits.