Boundary Analysis — act101 Agent Skill
Use when looking for extraction candidates, planning a module split, analyzing module boundaries, or asked "where should I split this?". Produces ranked extraction candidates with cut costs, layer violations, interface width, orphan types, and a decomposition sequence.
Boundary Analysis
Depth: Level 2 (Investigate). Read ../analysis-protocol/references/protocol.md
first: it defines the run artifacts, the investigation loop, the Shared
Interpretation Rules, the summary format, and the project-map structure.
Phase 0: Refuted ledger
If project-map.md exists at the workspace root, read its ## Refuted &
Re-characterized Findings ledger before any tool call. A refuted hypothesis is
re-investigated only when this run surfaces new contradicting evidence; otherwise
carry it as "previously refuted (date), no new evidence". During synthesis, add each
newly refuted or re-characterized hypothesis to the ledger with its disproving
evidence.
Phase 1: Parallel tool dispatch
Dispatch every available tool in one parallel batch, one subagent per tool. Each
saves raw JSON to raw/<tool-name>.json and returns a structured summary.
Must-have:
| Tool | Purpose |
|---|---|
analyze_clusters |
Current module groupings |
analyze_seams |
Natural boundaries |
If both are unavailable, report that and stop. Interpret analyze_seams through
analyze_clusters per the protocol's seam / hub-collapse rule: empty seams are
actionable only when clustering produced at least two non-hub clusters.
Extended (use if available; note skips in the manifest):
| Tool | Purpose |
|---|---|
analyze_layers |
Layer detection and violations (S1+S2) |
analyze_extraction |
Extraction candidates (M2) |
analyze_interfaces |
Cross-module contracts (M4) |
analyze_cohesion |
Are current modules coherent? (H2) |
analyze_interface_bloat |
Are APIs too wide? (H3) |
analyze_orphan_types |
Misplaced type definitions (H4) |
Phase 2: Investigation
Form a hypothesis for each significant finding before dispatching a subagent, and
save the notes to investigation/hypothesis-N.md.
Extraction candidate:
Hypothesis N:
<candidate>can be extracted as a clean module. Evidence:analyze_seamsfound a seam at this boundary;analyze_extractionscored it high. Confirming query:analyze_surfaceon the candidate files, to measure cut cost (edges to sever vs. edges retained). Confirms if: internal edges far outnumber external edges. Refutes if: external edges equal or exceed internal edges.
Layer violation:
Hypothesis N: the violation from
<source>to<target>is structural, not accidental. Evidence:analyze_layersflagged an inversion from layer X to layer Y. Confirming query:graphon<source>to trace the full import path. Confirms if: several files in layer X import from layer Y. Refutes if: one file, one import: a quick fix, not erosion.
Low-cohesion split:
Hypothesis N:
<file>holds two distinct concept clusters that should be separate modules. Evidence:analyze_cohesionscored the module low, and it is large. Confirming query: theanalyze_cohesionLCOM4 fields. A class withlcom4of 2 or more lists itscomponents, the disjoint method and field clusters: that is the named split boundary. Checklcom4_summary.modeled_kinds: a grammar absent from it was never judged. Confirms if:lcom4is 2 or more and thecomponentspartition the methods into groups sharing no state. Refutes if:lcom4is 1, or the grammar is absent frommodeled_kinds.
Interface bloat:
Hypothesis N:
<module>'s public API is wider than needed. Evidence:analyze_interface_bloatflagged it as over-exposed. Confirming query:referenceson each exported symbol. Confirms if: several exports have no external callers. Refutes if: every export has at least one external caller.
Report structure
# Boundary Analysis: <project name>
## Boundary Map
Current module structure with cluster sizes and labels; which clusters are
cohesive and which are artificially grouped.
## Layer Architecture
(Only if analyze_layers ran.) Detected or user-specified layers; direction
consistency score.
## Extraction Candidates
Ranked by extraction score. Per candidate: files included, internal vs. external
edges, API surface width, cut cost (edges to sever), and the act MCP operations
that would perform the extraction.
## Layer Violations
(Only if analyze_layers ran.) Per violation: source layer, target layer, files
involved, imported symbols, fix. Distinguish inversions (higher layer imports from
lower) from skips (a layer bypasses an intermediate layer).
## Interface Width Assessment
(Only if analyze_interface_bloat ran.) Per over-wide module: exports used
externally, exports never called externally, recommended visibility reduction.
## Orphan Types
(Only if analyze_orphan_types ran.) Per orphan: where defined, where used,
recommended destination.
## Cohesion Assessment
(Only if analyze_cohesion ran.) Per low-cohesion module: cohesion score, the
`components` of any class with `lcom4` of 2 or more as the named split boundary,
and the next step. Quote `lcom4_summary.modeled_kinds`; a grammar absent from it was
never judged and is not reported as cohesive.
## Recommended Decomposition Steps
Ordered, cheapest and highest-value extractions first, invasive restructuring last.
Each step names a specific act MCP tool call or skill.
Before committing to a cut, simulate it: express the cut as `simulate` ops
(`split_file{file,groups}` for a class or module split, `move_file{from,to}` for a
relocation) and record the predicted deltas: `cycles.resolved` and
`cycles.introduced`, the `coupling` changes, `chokepoints`, and, when an
`[architecture]` contract exists in `.act/config.toml`, `violations.cleared` and
`violations.introduced`. `simulate` never writes to disk. Revise a cut that
introduces violations or leaves the target cycle unresolved. (The delta field names
match the architectural-refactoring skill's simulate step.)
To decide whether a suspected pass-through module is a real boundary, simulate
`delete_module{file}` and read the `deletions` delta in the protocol's canonical
order: `surface_consumers` first, `surface_modeled` as the honesty gate, then
`rewired_edges` and `severed_edges`.
Project map updates
Updates Module Map, Layer Architecture, and Key Boundaries. Adds newly refuted or re-characterized hypotheses to the Refuted & Re-characterized Findings ledger. Appends to the Analysis History table.