# Bc Carver

> Carve candidate business components from the confirmed domain concepts — cluster by CONCEPTS.md co-occurrence, name each BC with a canonical glossary term — and document the as-is → to-be diff in migration/CARVING.md without changing any code. Step between concept-clarifier and sbce in a legacy-to-BCE migration; the diff is the backlog for incremental (strangler) refactoring. Invoke explicitly as /bc-carver in the analyzed project. Never restructures code — /sbce and the composed stack skill execute the carving.

- Skill: `adambien/bc-carver` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add adambien/bc-carver`
- Raw SKILL.md: https://api.skillmd.com/api/skills/adambien/bc-carver/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Product & Planning
- Author: AdamBien (https://skillmd.com/u/adambien)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/adambien/bc-carver

---


# BC Carver

Decide the decomposition, don't perform it. Carving and executing are different acts: the carver produces a written, reviewable cut of the system into business components — the diff a human argues about *before* the first class moves. Candidates, not verdicts.

## Inputs

- `migration/GLOSSARY.md` — canonical terms and `## Decisions`: ground truth, never contradicted.
- `migration/CONCEPTS.md` — co-occurrence graph and evidence pointers.

No mining, no new concepts. Vocabulary missing here is an extractor defect — stop and re-run `/concept-extractor`, don't improvise.

## Carving Heuristics

- BCs are the dense clusters in the co-occurrence graph; cut along sparse edges.
- Homonym splits settled by the clarifier are the strongest boundary signals — a word that means two things marks two components.
- Name each BC with one canonical glossary term as a single lowercase token (`contracts`, `pricing`) — this is the future sbce BC name.
- Give each BC a one-line responsibility phrased in glossary language. If the line needs "and", reconsider the cut.
- Inter-BC references are directed (`uses`); cycles between candidates are a carving error, not a documentation fact.

## CARVING.md Format

Write `migration/CARVING.md` — regenerable, diffable:

```markdown
# Carving: <system name>

## Components
### <bc-name>
- **Responsibility:** <one line, glossary language>
- **Concepts:** <canonical terms>
- **Uses:** <bc-name>, ...

## Diff
| Current | Target BC | Layer |
|---|---|---|
| com.legacy.contractmgmt | contracts | — |
| com.legacy.common.ContractValidator | contracts | control |

## Unmapped
<technical noise, dead-code candidates, shared utilities — with reasons>

## Open Questions
### Q<n> — <one-line question>
<evidence; candidate assignments>
```

- **Diff granularity:** package-level rows by default; class-level rows only where a package splits across BCs — that is where the information matters, and full class listings on large systems are enormous and instantly stale.
- **Layer** (boundary | control | entity) only where the evidence supports it; leave `—` otherwise.
- **Unmapped is mandatory** — silent omission reads as "covered".
- **Open Questions** continue the shared Q-id space from `CONCEPTS.md`: never reuse or renumber ids, continue counting. Ambiguous assignments ("Tariff → contracts or pricing?") are questions, not guesses — resolve via `/concept-clarifier`.

## Rules

- Documentation only — zero code changes; `/sbce` + the stack skill execute the carving, one BC at a time.
- A human confirms the cut before anything downstream consumes it.
- Respect `GLOSSARY.md` `## Decisions` on re-runs: resolved assignments stay resolved.
- Never overwrite a human-edited `CARVING.md` — regenerate to `migration/CARVING.new.md` (same convention as `CONCEPTS.md`).