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 clawplays/ospec --skill ospec-changegit clone --depth 1 https://github.com/clawplays/ospecWrote 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/clawplays/ospec/ospec-change)<a href="https://agentmods.dev/skills/clawplays/ospec/ospec-change"><img src="https://agentmods.dev/badge/skills/clawplays/ospec/ospec-change/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/clawplays/ospec/ospec-change"><img src="https://agentmods.dev/badge/skills/clawplays/ospec/ospec-change.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector warn
SkillSpector: 1 finding, up to medium
These are SkillSpector’s own severities. On a checked sample its high-severity flags on skills were ~96% false positives — a documented command, a public API, a “never do X” rule — so we show them as a caution to read, not a verdict. Why →
- medium Excessive Agency · line 52 Skill enables autonomous high-impact decisions without human-in-the-loop verification. Critical operations (destructive commands, financial transactions, data deletion) should require explicit user confirmation.Fix: Add human-in-the-loop confirmation for destructive, irreversible, or high-impact operations. Never auto-execute commands that modify files, send data, or alter system state.
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.00018 | $0.02323 |
| Opus 5.5 | $0.00007 | $0.00929 |
| Sonnet 5.5 | $0.00004 | $0.00465 |
| Haiku 4.5 | $0.00002 | $0.00232 |
Grade A, and why
ospec-change 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 — 79 lines — stays where its author put it; the contents beside it link to each section on GitHub.
OSpec Change
Use this skill for small or routine requirements where the classic OSpec 1.0 change flow is enough.
Scope
This skill is the fast change lifecycle inside an initialized OSpec project: requirement intake, change naming or matching, proposal and task refinement, implementation guidance, verification, archive readiness check, and finalize closeout.
The user owns profile selection. Once the user chooses a change, keep it on the classic flow regardless of complexity, flags, file count, or batch size. Never auto-promote, reject, or replace it with a Goal. Use ospec-goal only when the user explicitly selects a Goal.
Read Order
.skillrcospec index query <keyword...>for the relevant.ospec/SKILL.index.jsonentries (rootSKILL.index.jsonin legacy classic projects) — never read the whole index file, which grows without bound as changes archive.ospec/for-ai/change-protocol.mdfor nested projects, or legacyfor-ai/change-protocol.md.ospec/changes/active/<change>/proposal.md,tasks.md, andstate.jsonfor nested projects, or their legacy classic paths- Read
verification.mdonly when entering verification - Read
review.mdonly when entering closeout
change-protocol.md is the whole classic contract — the decision-gate ladder, force archive, and every other rule this profile needs are stated there in full. for-ai/execution-protocol.md is the goal controller layer and tells this profile not to open it, so never go there for a change rule. If change-protocol.md itself is missing, use for-ai/ai-guide.md to route back to the protocol for the active profile.
Language
Write every change document and brainstorm you author in the project document language (.skillrc documentLanguage / managed for-ai/ guidance / existing change docs). Never infer that language from product copy, site locale, or an "English-first" requirement, and never mix languages within one change.
Visibility & Decisions
Announce-Before-Act: never run the change flow silently. Announce in one line which skill you are using (ospec-change) and the current stage, whichospeccommand you are about to run and the artifact it writes, and which gate is blocking when progress stops.Brainstorm-First(forked decisions only): raise a gate only for a genuine fork — mutually exclusive API shapes, competing UI approaches, data-model or storage choices, destructive or hard-to-reverse operations, or a scope conflict with what the user asked for. For routine unambiguous changes — an evident-cause bug fix, a mechanical refactor, a docs update, a small addition with one reasonable implementation — do not open a gate or runospec brainstorm: proceed with the reasonable default and record your assumptions inproposal.md.- On a genuine fork, ask one question at a time and never auto-select a
recommendedoption or resolve a gate yourself —recommendedis a hint you show the user, never a choice you may take. Present every gate through the capability ladder, in this order: a harness-native question UI when the harness has one (Claude CodeAskUserQuestion, Geminiask_user), otherwise its plan/approval UI (for example Codex plan mode), otherwise the decision reportChat Promptas plain chat text. You always ask the user and wait for their actual answer; only the presentation differs, and a required pending decision blocks implementation and closeout identically on every harness. Record the gate withospec execute decision [changes/active/<change>] --id <id> --question "..." --option id:label:impact [--recommended id] [--required]and the answer with--select <option-id> --answered-by user; that shared decision command is the one controller command a change may use. If you did runospec brainstorm, do not leave it an unanswered template — record each answer withospec brainstorm resolve [path] --brainstorm <id> --gate <gate-id> --select <option-id> --answered-by user. In Claude Code the managed session hook re-injects this contract at runtime, but it is a convenience for one harness, not the source of the rule: the contract above binds on Codex, Gemini, Grok, OpenCode, Cursor and Copilot too. Full text:for-ai/change-protocol.md. Zero-Setup: the user only describes the change; you run everyospeccommand yourself and never ask them to type setup or execution commands. In a Claude Code harness, if.claude/settings.jsondoes not yet reference.ospec/hooks/claude/ospec-claude-hook.cjs, runospec session hook --target claude --applyonce (idempotent).
What ships with it
2 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 First seen · 79 lines · 18 tokens per session scan A d297d7570108
ospec-change is a skill published in the GitHub repository clawplays/ospec (396 stars, last pushed 1mo ago), licensed MIT. It adds 18 tokens to every session and 2,323 once invoked, about $0.0001 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-30.
Other skills, from other repositories
implement
Use when an approved plan and task list exist and it is time to turn them into working, tested code — the SDD phase after analyze and before verify. Enforces TDD: a failing test comes before the code that makes it pass, one task at a time, appended to a progress ledger that survives compaction. Delegates test tooling…
review
Use when a green diff needs adversarial judgment in the rsc SDD chain, between verify and ship — give a review keyed to the spec/plan/constitution in 02-DOCS/wiki/sdd/, or receive one and verify each comment before agreeing. NOT running lint/type/tests (that is verify), NOT the spec-less standalone pass (that is…
clarify
Use when a spec exists and must be de-risked before planning — hunt its ambiguities, unstated assumptions and edge cases, ask the few build-changing questions, bake the answers back into the spec. The rsc SDD gate between specify (writes the spec) and plan (designs the build). NOT the cross-artifact consistency check…
analyze
Use when constitution, spec, plan and tasks all exist and you want them cross-read against each other before any code is written — the rsc-sdd pre-implementation gate. Reports coverage gaps, contradictions, duplication, ambiguity and scope drift; edits nothing. NOT the task breakdown (that is tasks), NOT the coding…
constitution
Use when setting or amending a project's non-negotiables — stack canon, quality bars, conventions, security/a11y floors — as numbered, testable rules later phases obey. First rsc-sdd phase; writes 02-DOCS/wiki/sdd/constitution.md. NOT a feature spec (that is specify), NOT the technical plan (that is plan), NOT the…
plan
Use when an approved, clarified spec must become a technical blueprint before any code — the SDD phase between clarify and tasks: architecture, contracts, data flow, testing strategy, sequencing and risks, at structure altitude, never framework syntax. NOT the what/why spec (that is specify), NOT the ambiguity sweep…