agentleFS
cdeustcdeust/ai-architect-mcp-codebase/skills/validate-change-plan/SKILL.md

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.

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
  1. Very specific:

    Use only the eight tools in the core profile.

    line 8
  2. Very specific:

    If a full-profile workflow supplies a check_security_gates receipt, inspect both gates_passed and report.assessment_complete.

    line 17
  3. Very specific:

    Call health_check, then build or refresh the graph with analyze_codebase.

    line 25
  4. Very specific:

    Call get_impact for every symbol the plan changes.

    line 27
  5. Very specific:

    If a real diff exists, call detect_changes and compare its affected symbols and risk scores with the plan.

    line 28
  6. Very specific:

    Call query_graph with graph="missed".

    line 29
  7. Very specific:

    Use read-only query_graph queries for remaining structural assertions, adding ORDER BY when paging.

    line 30

≈ “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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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

  1. 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.
  2. Call health_check, then build or refresh the graph with analyze_codebase. Reuse the returned graph_path.
  3. Resolve each named symbol with search_codebase, then verify it with get_symbol or get_context. Mark ambiguous or missing names as unverified instead of choosing a convenient match.
  4. Call get_impact for every symbol the plan changes. Compare callers, importers, users, implementors, communities, and processes with the plan's scope claims.
  5. If a real diff exists, call detect_changes and compare its affected symbols and risk scores with the plan. Skip this step for a plan-only review.
  6. Call query_graph with graph="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.
  7. Use read-only query_graph queries for remaining structural assertions, adding ORDER BY when 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.

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.