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 wot-ui/wot-starter --skill openspec-update-changegit clone --depth 1 https://github.com/wot-ui/wot-starterWrote 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/wot-ui/wot-starter/openspec-update-change)<a href="https://agentmods.dev/skills/wot-ui/wot-starter/openspec-update-change"><img src="https://agentmods.dev/badge/skills/wot-ui/wot-starter/openspec-update-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/wot-ui/wot-starter/openspec-update-change"><img src="https://agentmods.dev/badge/skills/wot-ui/wot-starter/openspec-update-change.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.00055 | $0.01562 |
| Opus 5 | $0.00028 | $0.00781 |
| Sonnet 5 | $0.00011 | $0.00312 |
| Haiku 4.5 | $0.00006 | $0.00156 |
Grade A, and why
openspec-update-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 8d 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.
This is a copy
98% identical to openspec-update-change — 1 line differ, which has more behind it and is treated as the original. This page carries a canonical link to it rather than competing with it.
How it starts
The opening of the file, as written. The whole thing — 92 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Revise a change's existing planning artifacts and keep them coherent. Never edit code.
Store selection: If the user names a store (a store is a standalone OpenSpec repo registered on this machine) or the work lives in one, run openspec store list --json to discover registered store ids, then pass --store <id> on the commands that read or write specs and changes (new change, status, instructions, list, show, validate, archive, doctor, context, schemas, view). Once selected, treat --store <id> as sticky for the rest of the workflow. Every unscoped example of those commands below is shorthand: before running it, append the flag. For example, run openspec status --change "<name>" --json --store "<id>", not the unscoped form shown below. Other commands do not take the flag. Hints printed by commands already carry the flag; keep it on follow-ups. Without a store, commands act on the nearest local openspec/ root.
Input: Optionally specify a change name. If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
/openspec-continue-change is an optional workflow and may not be installed. Before suggesting it anywhere below, verify that it is available. If it is unavailable, openspec status --change "<name>" --json shows the next artifact and openspec instructions "<artifact-id>" --change "<name>" --json explains how to create it.
Steps
-
Select the change
If a name is provided, use it. Otherwise:
- Infer from conversation context if the user mentioned a change
- Auto-select if only one active change exists
- If ambiguous, run
openspec list --jsonto get available changes sorted by most recently modified, and ask the user to select one
When prompting, present the top 3-4 most recently modified changes as options, showing:
- Change name
- Schema (from
schemafield if present, otherwise "spec-driven") - Status (e.g., "0/5 tasks", "complete", "no tasks")
- How recently it was modified (from
lastModifiedfield)
Mark the most recently modified change as "(Recommended)" since it's likely what the user wants to update.
Always announce: "Using change: " and how to override (e.g.,
/openspec-update-change <other>). -
Get the change's artifacts
openspec status --change "<name>" --jsonParse the JSON to understand current state. The response includes:
schemaName: The workflow schema being used (e.g., "spec-driven")artifacts: Array of artifacts with their status ("done", "skipped", "ready", "blocked")isPlanningComplete: Boolean indicating if all planning artifacts are complete. Older CLI versions expose the same value asisComplete.planningHome,changeRoot,artifactPaths, andactionContext: path and scope context. Use these instead of assuming repo-local paths.
The artifact ids and paths come from the active schema - do NOT assume them, and do NOT branch on hardcoded artifact names. Custom schemas must work unchanged.
The files to edit are
artifactPaths.<id>.existingOutputPaths- the concrete files that exist on disk, already glob-expanded for glob artifacts (e.g.specs/**/*.md). Do NOT write toresolvedOutputPath: for a glob artifact it is still the glob pattern, not a real file. -
Understand the request
- If the user asked for a specific revision ("the design now uses X"), that is the starting edit.
- If they only said "update" / "make this coherent", treat it as a coherence review: read the existing artifacts and check them against each other for contradictions, gaps, and duplication.
-
Read and reconcile
- Read the artifact(s) the request touches and the change's other existing artifacts.
- Apply the requested edit. Then check every other existing artifact against it - in ANY direction: an edit to a later artifact may require revising an earlier one, not only the other way around. Build order is a useful reading order, not a constraint on which artifacts may be revised.
- Note everything that is now inconsistent, missing, or contradictory.
- Revise only files that already exist (
existingOutputPaths). Do NOT create artifacts that don't exist yet, and do NOT invent new files under a glob artifact - note them and point the user to/openspec-continue-changeto create them. - If the change is already coherent, say so and make no edits.
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.
- 8d ago First seen · 92 lines · 55 tokens per session scan A f19faf94e7a9
openspec-update-change is a skill published in the GitHub repository wot-ui/wot-starter (386 stars, last pushed 10d ago), licensed MIT. It adds 55 tokens to every session and 1,562 once invoked, about $0.0003 per session on Opus 5. A static security scan graded it A with 0 findings. It is 98% identical to openspec-update-change, differing in 1 line, and is treated as a copy.
Other skills, from other repositories
merge-seed
Merge upstream React Starter Kit updates (the seed remote) into main, preserving this project's identity, scope, and behavior. Use when asked to sync, pull, or merge the seed / starter kit / upstream template.
handoff
A session handoff workflow for recording unfinished work and transferring it to another coding-agent session. It can also divide several independent tasks among worker sessions.
wt
A workflow tool for creating isolated Git worktrees, which are separate working directories connected to the same repository. It coordinates parallel tasks without mixing their changes.
gh-ci-watch
A watcher for GitHub Actions, the service that runs automated checks and deployments for a repository. It waits for a selected workflow run or commit to reach a final state and collects its logs.
blog-scout
A read-only skill that scans internal knowledge and published blog posts to suggest new article topics, while flagging duplicates and sensitive material.
better-auth-best-practices
Configure Better Auth server and client, set up database adapters, manage sessions, add plugins, and handle environment variables. Use when users mention Better Auth, betterauth, auth.ts, or need to set up TypeScript authentication with email/password, OAuth, or plugin configuration.