validate-change-plan
Skill7 starsChanged 3 months agoMITView on GitHub
Check whether a proposed implementation plan matches the current code graph. Use before coding or approving a plan that names files, symbols, dependencies, boundaries, or expected blast radius; this is structural plan validation, not full PRD or semantic correctness verification.
In this repository4 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- impact-analysisSkill
- understand-codebaseSkill
The file
We split this skill into the rules it gives an agent
7 rules. About 0 are common, 0 are distinctive, and 7 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈0
Distinctive · estimate
This author's own choices. Worth a look.
7
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 8
Use only the eight tools in the core profile.
- Very specific: line 17
If a full-profile workflow supplies a check_security_gates receipt, inspect both gates_passed and report.assessment_complete.
- Very specific: line 25
Call health_check, then build or refresh the graph with analyze_codebase.
- Very specific: line 27
Call get_impact for every symbol the plan changes.
- Very specific: line 28
If a real diff exists, call detect_changes and compare its affected symbols and risk scores with the plan.
- Very specific: line 29
Call query_graph with graph="missed".
- Very specific: line 30
Use read-only query_graph queries for remaining structural assertions, adding ORDER BY when paging.
≈ “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
Validate Change Plan
Use only the eight tools in the core profile. Do not present this workflow as equivalent to the full profile's PRD validator, security gates, or semantic-diff verifier.
For Rust caller or impact questions, request lsp: true in analyze_codebase
and make rust-analyzer available. Inspect lsp_status.state: disabled means
static-only analysis; failed means analysis continued and may retain partial
LSP results. Record the error and treat affected conclusions as unverified until
source checks or a successful rerun support them. completed means the pass
returned, not that every call resolved. Record unresolved sites and coverage gaps.
If a full-profile workflow supplies a check_security_gates receipt, inspect
both gates_passed and report.assessment_complete. A true pass with an incomplete
assessment is not security clearance: report skipped checks, unresolved symbols
and warnings. This core-profile workflow does not invoke that additional tool.
Workflow
- Break the plan into falsifiable claims: files exist, symbols exist, dependency directions are correct, named boundaries match communities or processes, and the stated blast radius is plausible.
- Call
health_check, then build or refresh the graph withanalyze_codebase. Reuse the returnedgraph_path. - Resolve each named symbol with
search_codebase, then verify it withget_symbolorget_context. Mark ambiguous or missing names as unverified instead of choosing a convenient match. - Call
get_impactfor every symbol the plan changes. Compare callers, importers, users, implementors, communities, and processes with the plan's scope claims. - If a real diff exists, call
detect_changesand compare its affected symbols and risk scores with the plan. Skip this step for a plan-only review. - Call
query_graphwithgraph="missed". Inspect flagged ranges and search the relevant source, including unflagged files, before accepting any absence-based claim. A clean coverage report does not prove all relationships were recovered. - Use read-only
query_graphqueries for remaining structural assertions, addingORDER BYwhen paging.
Verdict
Return one row per plan claim with the evidence, a verdict of supported, contradicted, or unverified, and the smallest correction needed. End with coverage gaps, unresolved questions, likely tests, and the plan steps that require deeper semantic or runtime validation.
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.

