菜单
Use before modifying a file or symbol, or when asked "what breaks if I change X?". Depth 0 — fast, no follow-up queries, returns immediately. Two modes: inline (no artifacts, default for agent-initiated use) and artifact (writes to docs/act/, triggered for human-initiated requests or Critical risk verdicts).
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
Audit whether an AI agent edit to a file is safe — composes secret-surface, taint-flow, change-impact, and API-surface analysis into an agent-edit safety report. Use before letting an agent modify a sensitive or high-blast-radius file.
Execute structural decompositions based on an architectural analysis report. Use when breaking circular dependencies, splitting god classes, reducing coupling between modules, extracting interfaces at seam boundaries, or executing any large-scale structural change identified in an architectural analysis. Requires a prior architecture audit (the architecture-audit skill) that produced project-map.md and a run report.
Use when asked to audit architecture, produce a comprehensive architectural overview, get the full structural picture of a codebase, assess overall health and porting readiness, find module boundaries, circular dependencies, coupling hotspots, dead code, or code patterns. Depth 3 — full audit with hypothesis-driven investigation. Optionally enriches the structural audit with runtime and git evidence (coverage, churn, co-change coupling, ownership) when those overlays are available. Replaces the architectural-analysis and architecture-audit-plus skills.
Use when looking for extraction candidates, planning a module split, analyzing module boundaries, or before decomposing a large component. Also use when asked "where should I split this?" or "find natural module boundaries". Depth 2 — investigate. Produces extraction candidates with cut costs, layer violations, interface width assessment, orphan types, and a recommended decomposition sequence.
Traverse large repositories efficiently using act's query tools. Use when exploring unfamiliar code, mapping dependencies, understanding API surfaces, analyzing side effects before modifying functions, or following call chains across files. Avoids reading entire files by querying only the structure needed.
Review code for bugs, complexity, unused symbols, and structural issues using AST-aware analysis. Use when reviewing PRs, checking code quality, finding dead code, analyzing function complexity, auditing a codebase, or checking for type errors. Each call reports the kinds it modeled in `modeled_kinds` — that is the honest coverage signal; the supported-language list is whatever act ships.
| name | change-impact |
| description | Use before modifying a file or symbol, or when asked "what breaks if I change X?". Depth 0 — fast, no follow-up queries, returns immediately. Two modes: inline (no artifacts, default for agent-initiated use) and artifact (writes to docs/act/, triggered for human-initiated requests or Critical risk verdicts). |
Depth: Level 0 (Collect).
See ../analysis-protocol/references/protocol.md for: artifact directory structure,
the investigation loop, depth levels, summary format, token budget rules, and project
map structure.
| Tool | Purpose | MCP call | Tier |
|---|---|---|---|
analyze_impact (file mode) | Blast radius — files that depend on target (R1) | analyze_impact with target: <file> | Free |
analyze_impact (symbol mode) | Transitive callers of a function symbol | analyze_impact with target: <file> and symbol: <name> | Architecture |
analyze_test_gaps | Is the target tested? (R5) | analyze_test_gaps | — |
analyze_cycle_risk | Is the target in a risky cycle? (R6) | analyze_cycle_risk | — |
Symbol mode workflow (Architecture): For PR review or before renaming/changing a function signature,
run skeleton to confirm the function exists in the file, then use symbol mode to get the full
transitive caller chain. Append ::<line> to symbol to disambiguate overloads
(e.g. symbol: "process::42"). Symbol mode uses syntactic-floor analysis; LSP is not required.
The confidence, modeled_kinds, and unresolved fields in the result are honesty signals —
review them to understand gaps in the analysis.
If analyze_test_gaps or analyze_cycle_risk are unavailable: run analyze_impact
only. Note which tools were skipped in the verdict and caveat accordingly.
If analyze_impact is unavailable: report that and stop — no useful verdict possible.
Inline mode (default for agent-initiated use):
Artifact mode (for human-initiated requests, or when verdict is Critical):
docs/act/<timestamp>/, write
manifest.json, save raw/*.json, write report.mdCompute from tool outputs:
| Verdict | Criteria |
|---|---|
| Low | Blast radius < 5 files, target is tested, not in a risky cycle |
| Medium | Blast radius 5-15 files, OR target is untested |
| High | Blast radius > 15 files, OR target is untested AND in a cycle |
| Critical | Blast radius > 30 files, OR target is in a high-risk cycle (>50% of codebase risk surface) |
When multiple criteria apply, use the highest verdict. When tools are missing, caveat the verdict: "Medium (test coverage unknown — analyze_test_gaps not available)".
Return this to the calling agent:
## Change Impact: <target>
**Risk: <Low / Medium / High / Critical>**
- Blast radius: N direct, M transitive dependents
- Test coverage: tested / untested / unknown (tool unavailable)
- Cycle risk: none / low / high (N% of codebase affected) / unknown (tool unavailable)
**Caution areas:** <list of highest-risk direct dependents, or "none identified">
**Suggested:** <e.g., "run tests in X before merging", "review Y for breakage", "run architecture-audit to understand full impact">
None. Change Impact reads project-map.md (workspace root) for context (chokepoints, known
risky files) but does not modify it.