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 agentmods add skills/ribeirogab/specwright/proposenpx skills add ribeirogab/specwright --skill proposegit clone --depth 1 https://github.com/ribeirogab/specwrightWhat 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 | $0.00073 | $0.01316 |
| Opus 5 | $0.00036 | $0.00658 |
| Sonnet 5 | $0.00015 | $0.00263 |
| Haiku 4.5 | $0.00007 | $0.00132 |
Grade A, and why
propose 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 yesterday.
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 — 121 lines — stays where its author put it; the contents beside it link to each section on GitHub.
propose — intent into an approved ticket
Produce the ticket: what is being built, why, and the acceptance criteria that
decide when it is done. The technical how is not written here — that is
sw:plan's job, and mixing them makes both worse.
Announce at start: "Writing the change ticket."
Resolve bundled resources
Resolve SW_PLUGIN_ROOT before reading a template:
- use
PLUGIN_ROOTwhen it contains.codex-plugin/plugin.json; - otherwise use
CLAUDE_PLUGIN_ROOTwhen it contains.claude-plugin/plugin.json; - otherwise derive the root from this loaded
skills/propose/SKILL.mdreal path (two parents above theskills/propose/directory).
Require templates/proposal.md and templates/delivery.md beneath that root. Stop
before writing if resolution fails. Never look for bundled resources inside the
target repository.
Two ways in
After a conversation — the common case. The design discussion already happened in this session; you are here to capture it. Read the conversation back, build the ticket from what was actually settled, and ask only about what is still open. Do not re-litigate a decision the maintainer already made, and do not re-ask something the conversation answered.
From a cold start — $ARGUMENTS names a topic and there is no prior
discussion. Then the exploration happens now: understand the intent, surface the
alternatives, and talk it through.
Either way, the rule is the same: converse first, decide at the end. Explore in prose — questions, trade-offs, a recommendation with its reason. Do not open with a multiple-choice gate, and do not stack option menus mid-exploration; they force a decision before the maintainer has the picture. When the shape is clear, then confirm the choices that remain.
Find the loose ends
Before writing anything, list what a ticket needs and the conversation has not settled. A loose end is real when a different answer would change what gets built: an unnamed boundary, an unstated failure behavior, an unpinned data shape, a scope edge that could reasonably fall either way.
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.
- yesterday First seen · 121 lines · 73 tokens per session scan A 81d72441913c
propose is a skill published in the GitHub repository ribeirogab/specwright (3 stars, last pushed 24d ago), licensed MIT. It adds 73 tokens to every session and 1,316 once invoked, about $0.0004 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-31.
Other skills, from other repositories
review-depth
Decide how much review a change has earned, before reviewing it. Selects quick, standard, or deep from stated signals (reviewable changed lines, directory spread, trust-boundary risk flags, blast radius, documentation-only scope), reports the signal table and the rule that fired, then runs house-review at the selected…
doc-sync
Use when code has moved and the documentation may not have, or when a documentation set needs auditing for stale claims. Detects documentation drift by checking prose claims against repository facts, classifies every document as current-state (correctable), contract (report-only, human-owned) or ledger (skipped), and…
init-worktracking
Scaffold a portable, agent-optimized spec-driven work-tracking system into the current repository: AGENTS.md (global rules + agent reading protocol), a .tasks/ directory of atomic task files, and (by tier) ROADMAP.md, CHANGELOG.md, a validate.py checker, and thin CLAUDE.md/Cursor/Copilot pointers. Choose a footprint…
reconcile-worktrees
Safely consolidate one or more isolated git worktrees (for example left behind by parallel background agents, or from the fix-batch skill) into the main working tree, without committing or merging blindly. Use whenever asked to "reconcile the worktrees", "merge these agent branches", "bring the worktree changes back…
verifier-agent
Use before reconciling or landing an implementation to independently verify it against its approved spec and its task's acceptance criteria. Runs the declared verification commands and records each exact outcome, composes the spec-conformance lens so a contract divergence fails the run even when every command passes…
spec-author
Use when turning a raw idea, feature request, or bug into a persistent behavioral spec before any tasks or code. Drafts a scenario-based spec (problem, goals, non-goals, constraints, Given/When/Then scenarios with stable S-NNN ids, proposed surface, open questions), composes the spec-quality lens to self-check and…