verify-software-change
Skill1 starsChanged 4 months agoMITView on GitHub
Design and run risk-based verification after software or infrastructure changes, or when asked whether work is fixed or ready. Respect repository-specific remote, hardware, staging, and production constraints.
In this repository15 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- apply-project-updatesSkill
- audit-project-updatesSkill
- design-agent-capabilitySkill
- engineer-cli-toolsSkill
- maintain-agent-instructionsSkill
- maintain-project-docsSkill
- maintain-project-memorySkill
- maintain-web-design-systemSkill
- prepare-web-assetsSkill
- red-team-technical-planSkill
- release-web-applicationSkill
- research-software-versionsSkill
- web-discovery-artifactsSkill
The file
We split this skill into the rules it gives an agent
12 rules. About 0 are common, 11 are distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈11
Distinctive · estimate
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
- Distinctive: line 12
Before running checks, state what must be true.
- Very specific: line 19
Read references/risk-matrix.md for selecting depth.
- Distinctive: line 24
Read repository instructions and use approved commands.
- Distinctive: line 32
run focused formatter, lint, type, schema, or unit checks
- Distinctive: line 33
test the changed behavior and important failure paths
- Distinctive: line 36
use preview, staging, device, or production evidence only when authorized
- Distinctive: line 40
After refactors, check imports, signatures, generated bindings, configuration, entry points, tests, examples, and documented commands.
- Distinctive: line 45
Never fabricate output or convert inspection into an execution claim.
- Distinctive: line 46
Do not hide failed attempts or warnings.
- Distinctive: line 47
Do not weaken tests to make them pass unless the changed expectation is explicitly correct and reviewed.
- Distinctive: line 49
Do not discard unrelated work to obtain a clean state.
- Distinctive: line 52
If a check cannot run, explain why and choose the best non-equivalent evidence without calling it equivalent.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Verify Software Change
Build the smallest sufficient evidence chain for the actual risk.
Define the claim
Before running checks, state what must be true. Map each material change to:
- expected behavior
- likely regression surface
- appropriate evidence
- environment required
Read references/risk-matrix.md for selecting depth. Do not substitute broad
but irrelevant test volume for targeted evidence.
Follow project constraints
Read repository instructions and use approved commands. Preserve remote-only, hardware-bound, sandboxed, staging, production, or resource constraints. Do not install tools, deploy, access production, or broaden permissions merely to make verification convenient.
Execute progressively
- inspect static consistency and affected references
- run focused formatter, lint, type, schema, or unit checks
- test the changed behavior and important failure paths
- broaden to subsystem, build, packaging, or integration checks when risk warrants it
- use preview, staging, device, or production evidence only when authorized
- inspect exit status and relevant output
- classify existing versus introduced warnings and failures
After refactors, check imports, signatures, generated bindings, configuration, entry points, tests, examples, and documented commands.
Preserve evidence integrity
- Never fabricate output or convert inspection into an execution claim.
- Do not hide failed attempts or warnings.
- Do not weaken tests to make them pass unless the changed expectation is explicitly correct and reviewed.
- Do not discard unrelated work to obtain a clean state.
- Label local, remote, simulated, preview, staging, device, and production evidence.
- If a check cannot run, explain why and choose the best non-equivalent evidence without calling it equivalent.
Report
Provide:
- claim evaluated
- commands and environments
- passed behavior
- warnings and failures
- existing versus introduced issues
- areas inspected but not executed
- remaining uncertainty
- readiness conclusion bounded by the evidence
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.