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 tercel/spec-forge --skill srs-generationgit clone --depth 1 https://github.com/tercel/spec-forgeWrote 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/tercel/spec-forge/srs-generation)<a href="https://agentmods.dev/skills/tercel/spec-forge/srs-generation"><img src="https://agentmods.dev/badge/skills/tercel/spec-forge/srs-generation/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/tercel/spec-forge/srs-generation"><img src="https://agentmods.dev/badge/skills/tercel/spec-forge/srs-generation.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.00113 | $0.04880 |
| Opus 5.5 | $0.00045 | $0.01952 |
| Sonnet 5.5 | $0.00023 | $0.00976 |
| Haiku 4.5 | $0.00011 | $0.00488 |
Grade A, and why
srs-generation 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 1mo 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 — 186 lines — stays where its author put it; the contents beside it link to each section on GitHub.
SRS Generation Skill
What Is a Software Requirements Specification?
A Software Requirements Specification (SRS) is a formal document that describes exactly what a software system must do and the constraints under which it must operate. It serves as the contractual bridge between stakeholders who define the product vision (captured in a PRD) and the engineering team that designs, builds, and tests the system. A well-written SRS eliminates ambiguity, reduces rework, and provides a single source of truth for every requirement the system must satisfy.
The two foundational standards for SRS documents are IEEE 830 (IEEE Recommended Practice for Software Requirements Specifications) and ISO/IEC/IEEE 29148 (Systems and Software Engineering -- Life Cycle Processes -- Requirements Engineering). IEEE 830 established the canonical section structure -- introduction, overall description, specific requirements -- and defined the quality attributes every requirement must exhibit: correctness, unambiguity, completeness, consistency, ranking for importance, verifiability, modifiability, and traceability. ISO/IEC/IEEE 29148 modernized this foundation by integrating requirements engineering into the full systems and software lifecycle, emphasizing stakeholder needs analysis, requirements analysis, and requirements validation as continuous activities rather than one-time documentation events. This skill combines the structural rigor of both standards with the pragmatic, metric-driven approach found in Amazon technical specifications, where every requirement must be tied to a measurable outcome.
Generation Workflow
The SRS generation process follows a six-step workflow designed to produce a complete, high-quality document:
Step 1: Scan Context
Before writing a single requirement, scan the project to build context:
@../shared/project-context.md
Execute the Project Context Protocol. Prefer its PC.0 fast path — resolve <sf_scripts> (see @../shared/scripts.md) and run python3 "<sf_scripts>/sf-scan.py" --root "<project_root>", which returns the languages, frameworks, DB/auth signals, test command, and the existing-doc inventory (including any upstream prd.md with its declared IDs) in one pass. Fall back to the manual PC.1–PC.3 scan only if the script is unavailable. Then apply judgement the script does not: label the project profile (PC.3) and pick which non-functional requirement categories are most relevant (e.g., database-backed projects need data integrity NFRs; CLI tools need usability NFRs).
What ships with it
3 files 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.
- 1mo ago Changed · +22 lines 738f2ce781a9
- 1mo ago First seen · 164 lines · 113 tokens per session scan A f3d84046445d
srs-generation is a skill published in the GitHub repository tercel/spec-forge (10 stars, last pushed 1mo ago), licensed MIT. It adds 113 tokens to every session and 4,880 once invoked, about $0.0005 per session on Opus 5.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-31.
Other skills, from other repositories
architecture-diagram
Build interactive, click-through architecture diagrams for software systems — a self-contained single HTML file with animated step-by-step flows, mode toggles (dev/prod, offline/online, v1/v2), dark/light theme, and a side panel with payload details, plus a companion markdown description. Use when the user wants to…
rigorous-review
Rigorous, evidence-backed code review for high-stakes changes. Trigger on: rigorous review, thorough review, deep review, review this PR properly, review before merge, high-stakes review, "is this actually safe to merge", regulated or compliance code review, batch-review these PRs. Every finding carries quoted…
alloy-structural-analysis
Formal model-checking layer over Allium specs using Alloy 6 + Electrod + nuXmv. Trigger on: "rigorous structural analysis", "model-check this spec", "verify this Allium spec formally", "check for structural divergence with Alloy", "run the Alloy loop", "does the code actually satisfy this spec", temporal/CTL/LTL…
daily-briefing
Daily orientation and chief-of-staff briefing. Pulls from Slack (saved items), Gmail (important/starred), Google Calendar (today's events), Jira CLI (configured projects), and Todoist CLI, validates every action item, synthesizes a prioritized briefing using three consequence-based tiers, then produces a decisive…
jira
Manage Jira issues, sprints, and epics via CLI — jira-cli (ankitpokhrel/jira-cli) for bearer/basic-auth instances, acli (Atlassian's official CLI) for OAuth-only Jira Cloud tenants. Trigger on: jira, jira-cli, acli, ticket, issue key (e.g. PROJ-123), work item, epic, sprint, transition/move ticket, comment on ticket…
scala
Use whenever reading, writing, reviewing, or navigating Scala or Java code, or working anywhere in a Scala/Java project (build.sbt, .scala, .java files, sbt/Bloop/BSP setup). Enforces preferred tool order for code search and compile/test, plus house style for collections, sbt workflow, and returns.