plan-change
Skill1 starsChanged 44 days agoMITView on GitHub
Turns .workflow/<KEY>/triage.json and the code into an audited implementation spec at .workflow/<KEY>/sdd.json. Use before writing code for a ticket, bug fix or feature.
11 other projects use a version of this.
Adopted by
Most recently taken up by
- Apicurio/apicurio-registrytheir own version, first seen Nov 9, 2026
- 0xdeafcafe/skillstheir own version, first seen Nov 6, 2026
- CsHeng/agent-skillstheir own version, first seen Nov 4, 2026
- aantoniadis/skillstheir own version, first seen Oct 20, 2026
- Ionate-Technologies/indium-agentkittheir own version, first seen Oct 20, 2026
- otaviobarros/agent-engineeringtheir own version, first seen Oct 17, 2026
Used with
Projects with it also use review-change and security-review.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
thlaureSkillreview-change
Use this skill when the user asks for a code review, a correctness pass, a check before PR, or asks whether a Signalist change follows project conventions.
Also in 7 projects that use this
SentrySkillsecurity-review
Finds exploitable application security vulnerabilities in code changes. Use for Warden security scans, appsec review, OWASP-style checks, authentication or authorization bugs, injection, XSS, SSRF, path traversal, secrets, unsafe crypto, webhook verification, open redirects, or sensitive data exposure.
Also in 3 projects that use this
Other versions11 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 11
- Apicurio/apicurio-registry★ 951same name
- Indium-AI-Labs/indium-agentkit★ 18same name
- Ionate-Technologies/indium-agentkit★ 17same name
- CsHeng/agent-skills★ 3same name
- otaviobarros/agent-engineering★ 3same name
- contextosai/skills★ 1same name
- hamburger-os/PraxFlow★ 1same name
- 0xdeafcafe/skills★ 0same name
- aantoniadis/skills★ 0same name
- BanKnight/claude-template★ 0same name
1 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository9 other files it gives its agents.
- address-reviewSkill
- draft-prSkill
- frame-productSkill
- implement-changeSkill
- review-diffSkill
- trace-incidentSkill
- triage-taskSkill
- write-commitSkill
- write-handoverSkill
The file
We split this skill into the rules it gives an agent
1 rule. 0 are common, 0 are distinctive, and 1 is very specific to this project.
0
Common
Most of the 10 edited versions we read keep these.
0
Distinctive
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 15
No triage yet? Run triage-task first, or work from what the user stated and record that in questions.
“Common” is measured: kept by at least 6 in 10 of the 10 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
plan-change
wb <args> # wb not on PATH: python <this skill's directory>/../../lib/wb.py <args>Steps
- Load the ticket.
sdd getis not it — read.workflow/<KEY>/triage.json. No triage yet? Runtriage-taskfirst, or work from what the user stated and record that inquestions. - Get the bar.
repo profile. It prints the preset, the repo's own conventions, and the gates that apply. Follow the conventions it reports; do not introduce a second test runner or package manager.LOW confidencemeans the preset is a guess nobody reviewed: say so, let the user settle it. Once the file list is known,repo gates <paths>resolves the bar those paths land in — in a monorepo that is not the repo's, and the audit fails a plan that declares a preset below it. Pick a persona from
references/personas.md. It shapes what counts as done, not the format.A change already on disk (a light-path ticket
finishmoved here) stays: plan around it, never revert it to plan from scratch.- Confirm everything in the code. Assume nothing. Every claim about this
codebase needs a
file:lineand the text of that line, because the audit in step 7 reopens each one. A claim you cannot cite is a question, not a fact — put it inquestions. Search with the strongest tool available and quote only lines you actually read:../../shared/code-search.md. - Find the raised bar.
repo zones <path>...with every file you plan to touch. Billing, auth, user data, migrations and secrets are held to a higher standard whatever the preset says. - Write
.workflow/<KEY>/sdd.json. Shape and required fields:references/sdd.md. Audit.
sdd audit <KEY>. It must pass. On failure, fix the plan — never the citation to match a wrong claim, and never proceed to implementation. Thensdd render <KEY>for the human-readable copy.The audit reports a tier. Give every
files[]entry alinesestimate (added plus removed); an entry without one makes the planstandard. An estimated total within the repo's bound (100 by default), no critical zone and no bug/support ticket qualifies aslight, which waivesstepsandproduct— nothing else.impl checkmeasures the real diff against the bound, so an estimate written low only moves the failure later. Do not aim for a tier: write the plan the change needs and let the audit compute it. Citations, the file list,verifyandrollbackare required at every tier.The first audit is strict and reads the working tree, so get the line numbers right while the plan is still cheap to change. It records the commit it ran against; every later audit is anchored there, so a plan can be corrected while it is being implemented. Drifted citations are reported, not failed. A quote that was never in the code fails at every stage.
Rules
- Smallest change that achieves the objective. Fixes and improvements to existing behaviour touch as little as possible. No refactor riding along, no abstraction for a second case that does not exist yet, no dependency that replaces code already in the repo.
- List every file before touching any.
implement-changestops on a file that is not in the list, so an incomplete list is a plan that fails to run. - Verification is commands, not intentions.
verifyholds the exact lines that will be executed, using this repo's runner. Shell is refused, so a command needing a variable declares it inverify_env({"PYTHONPATH": "lib"}) rather than inliningVAR=x. Variables that change how a process loads code are refused there. - An open question is output. A plan that guesses reads the same as a plan that knows; say which one it is.
Next: implement-change reads sdd get <KEY> --section files|steps.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

