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 lukas-grigis/ralphctl --skill ralphctl-spec-driven-developmentgit clone --depth 1 https://github.com/lukas-grigis/ralphctlWrote 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/lukas-grigis/ralphctl/ralphctl-spec-driven-development)<a href="https://agentmods.dev/skills/lukas-grigis/ralphctl/ralphctl-spec-driven-development"><img src="https://agentmods.dev/badge/skills/lukas-grigis/ralphctl/ralphctl-spec-driven-development/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/lukas-grigis/ralphctl/ralphctl-spec-driven-development"><img src="https://agentmods.dev/badge/skills/lukas-grigis/ralphctl/ralphctl-spec-driven-development.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.00101 | $0.01932 |
| Opus 5.5 | $0.00040 | $0.00773 |
| Sonnet 5.5 | $0.00020 | $0.00386 |
| Haiku 4.5 | $0.00010 | $0.00193 |
Grade A, and why
ralphctl-spec-driven-development 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 4d 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 — 149 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Spec-Driven Development
Adapted from addyosmani/agent-skills — "Spec-Driven Development" (MIT). Adapted for ralphctl's harness contract.
Code without a spec is guessing. In ralphctl the spec already has a home: the requirements body the refine or ideate session produces is what the planner and every implementing session build against. This skill is the discipline for making that body a real spec — specific enough that two engineers reading it would build the same thing — not a second artifact beside it.
What this skill does not add. No separate spec, plan, or to-do files, and no extra review stops. The
session's prompt owns the output (a single signal in signals.json), the section layout, and the
operator approval gate; follow those exactly. The prompt's approval gate is the human review of the
spec — run it as the prompt describes, and do not end the session early to wait for a review the gate
already provides.
When this applies
- Refine — the primary home: turn one ticket into requirements whose scope, criteria, and open questions are explicit. Stay implementation-agnostic, as the refine prompt requires.
- Ideate — Phase 1 (the WHAT): the same discipline before any planning. Phase 2 then inherits the approved success criteria as the raw material for each task's verification criteria.
When not to reach for the full discipline: a ticket that is already unambiguous and self-contained. It still needs acceptance criteria — a two-line spec is fine — but not a ceremony.
Scope check first
Most tickets describe one capability. Before specifying, check whether this one bundles several that could be built and verified independently:
- It names distinct capabilities with their own users or data.
- Its acceptance criteria fall into groups that could ship and be checked separately.
- One part could be cut or replaced without rewriting the others' requirements.
When it does, say so before writing criteria. Propose the split to the operator — one ticket per capability, or one numbered topic block per capability when the session's output format supports multi-topic requirements — and name the dependency direction between them (which one has to exist first). Dependencies point one way; if two parts each need the other, they are one capability. Keep the names you give each part stable once chosen, so later tasks can refer to them without guessing.
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.
- 4d ago First seen · 149 lines · 101 tokens per session scan A 1c92c5031022
ralphctl-spec-driven-development is a skill published in the GitHub repository lukas-grigis/ralphctl (24 stars, last pushed today), licensed MIT. It adds 101 tokens to every session and 1,932 once invoked, about $0.0004 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-10-13.
Other skills, from other repositories
save-learning
Saves user instructions as persistent learnings for future sessions. Use when the user says 'remember this', 'always do X', 'from now on', 'never do Y', or gives any instruction they want persisted across sessions. Proactively suggest when the user states a preference, convention, or rule they clearly want followed in…
review
Review local code changes for bugs, regressions, missing tests, and pragmatic improvements. Use when the user asks to review the current changes from git status, or to review a specific backlog task by id such as task-65 or TASK-65. Also trigger when the user says things like "review", "review current changes", "check…
web-access
A method for handling difficult web tasks across search, page fetching, and a real browser. It covers sites that need login sessions, dynamic pages, anti-bot handling, or exploration before their structure is understood.
skill-creator
A skill for creating or improving reusable instructions for an agent. It covers capturing the intended workflow, writing a draft, testing it, and refining its trigger description.
repo
Repository operating rules for verified Mythos edits.
ce-work
Execute a plan or concrete work prompt end-to-end. Use when implementing from docs/plans, a spec path, or a clear build request; use ce-debug for open-ended bugs.