ad-deepen
SkillDev toolsSurface deepening opportunities in the codebase using the Ousterhout/Feathers vocabulary from WORKFLOW §8 (Module / Interface / Depth / Seam / Adapter / Leverage / Locality). Three-phase process — explore organically, present numbered candidates with deletion-test framing, grilling loop on the chosen candidate. Pairs with `ad-drift` (audit detects drift; deepen proposes refactors). Triggers on "deepen", "refactor for depth", "shallow module", "deletion test", "two-adapters rule", "interface is the test surface", "leverage", "locality", "/ad-deepen". Profile-scoped to `team` and `mature` only — premature for `poc` and `solo` per ADR-0020 §4.
Available today. Use it from your connected AI after setup.
No other account needed.
Connect ahel once, and every AI you use reads what you have installed.
Then ask your AI: use the ad-deepen skill
What this skill tells your AI
The instructions your AI receives, as published by corridortech/posecap in .agents/skills/ad-deepen/SKILL.md and read by ahel’s review.
<background_information>
Implements ADR-0020 (doc/adr/0020-deep-modules-vocabulary.md) — operational counterpart to the WORKFLOW §8 architectural vocabulary. Surfaces deepening opportunities and walks the user through them. Process scaffold; no primary file output.
Profile scope: team and mature only. Architectural deepening is premature for ≤200-line experiments. poc and solo users do not have this skill installed; to enable deepening, re-init the project at team profile (agentic profile set team) once the codebase has stabilized enough to warrant it. Per ADR-0020 §4.
Codex auto-trigger on description keywords is less mature than Claude Code's. If auto-invocation does not fire when the user mentions deepening, shallow modules, the deletion test, or the two-adapters rule, invoke this skill manually. </background_information>
Route elsewhere when:
- The change is a one-line fix or mechanical refactor → no scaffold needed.
- The codebase is
poc-shaped (one-shot script, ≤200 lines, no callers): deepening is premature; ship the experiment first. - The friction is a bug, not a shape —
ad-diagnose(WORKFLOW §15). - The friction is a naming/vocabulary drift —
ad-domain. - The friction is missing context, not module shape —
ad-grill-me.
Step 1 — explore organically. Before naming candidates, read.
- Read
CONTEXT.mdif it exists. Anchor domain vocabulary; deepening proposals must use Customer, Order, Triage role — not Service, Handler, Manager. - Read
ARCHITECTURE.mdif it exists. Read accepted ADRs indoc/adr/covering the surface you are about to walk. - Walk the codebase noting friction:
- Concepts bouncing between modules (locality fault).
- Interfaces as wide as their implementations (shallow modules — apply the deletion test).
- Tests that mock four things to exercise one path (test-surface fault).
- Adapters with one concrete implementation (two-adapters-rule violation, if no second is planned).
Read with eyes for shape, not bugs. The friction is in module geometry; the bug-finding skill is ad-diagnose.
Step 2 — present candidates numbered. For each deepening opportunity, produce a short numbered entry:
### Candidate N: <one-line title using domain + architectural vocabulary>
**Files involved:** `src/foo.ts:42`, `src/bar.ts`.
**Friction:** <one-paragraph plain English — what hurts today, who feels it, when>.
**Proposal:** <one-paragraph plain English — what changes about the module shape>.
**Vocabulary check:** <Module / Interface / Seam / Adapter / Depth / Leverage / Locality applied here, per WORKFLOW §8>.
**Deletion test:** <if you imagine deleting the module today, what happens? Complexity vanishes → delete instead of refactoring. Complexity reappears across N callers → it earns its keep, deepen it>.
**Two-adapters check:** <if introducing a seam: name the second concrete adapter that justifies it. If only one adapter exists or is planned, the seam is hypothetical — drop it from the proposal>.
**Test surface impact:** <does the new shape make the right pattern testable at the call site? If not, the proposal is wrong-shaped>.
**ADR conflicts:** <name any accepted ADR this proposal contradicts. Flag for reopening only if the friction warrants it; otherwise the candidate is rejected>.
Number candidates 1, 2, 3, ... Order by leverage × locality (largest impact first, lowest blast radius among ties). Cap at five.
Step 3 — grilling loop on the chosen candidate. The user picks one candidate by number. Drop into a grilling loop on that one:
- Walk the decision tree of the proposal branch by branch (one question per turn, recommendation included). Reuse the
ad-grill-mediscipline. - Add new domain terms to
CONTEXT.mdlazily viaad-domainas the proposal surfaces them. - Offer an ADR only when the three criteria pass (hard to reverse, surprising without context, real trade-off —' ' Most refactors do not need an ADR.
- When the proposal stabilizes: route to
ad-tdg(WORKFLOW §9) for the implementation pass with ground-truth pair + TDM + criterion-based selection.
Reject candidates the grilling loop reveals as wrong-shaped. Better to discard at this stage than to ship a deepening that doesn't deepen.
Vocabulary discipline (always on). Per ADR-0020, use the canonical vocabulary verbatim:
- Module — any unit with an interface and an implementation.
- Interface — what callers see.
- Implementation — what they don't.
- Depth — behavior leverage at the interface. Deep modules hide a lot of behavior behind a small interface.
- Seam — where behavior can be altered without editing in place (Feathers).
- Adapter — a concrete thing satisfying an interface at a seam. Role, not substance.
- Leverage — what callers gain from depth.
- Locality — what maintainers gain from depth (concentrated change, bugs, knowledge).
Never use:
- "Boundary" (overloaded with DDD bounded contexts) — use Seam or Interface.
- "Service" / "Handler" / "Manager" / "Helper" without a domain noun in front.
- "Depth = implementation lines / interface lines" — explicitly rejected by ADR-0020. Rewards padding.
When the candidate's friction touches a domain noun, use the domain noun from CONTEXT.md ("the Order aggregate"), not a generic placeholder ("the order service").
<output_contract> Structured conversation. No primary file written. Side-effects:
CONTEXT.mdupdates land viaad-domainwhen the proposal surfaces new domain terms.- ADR drafts land via
ad-adrwhen the three-criteria test passes. - Implementation lands via
ad-tdgafter the proposal stabilizes — that skill produces the verified code change.
Each session produces:
- A numbered list of candidates (Step 2), capped at five.
- A picked candidate with the grilling loop transcript (Step 3).
- Routing to
ad-tdgwith the ground-truth pair seeded from the proposal. </output_contract>
Next
- After candidates surface but before picking:
/ad-driftfor a broader drift check; the audit may reorder priorities. - After picking and grilling stabilizes:
/ad-tdgto implement under WORKFLOW §9 discipline. - If the proposal touches load-bearing architecture:
/ad-adrto record the decision (only when the three-criteria test passes). - If the deepening exposed a domain-vocabulary drift:
/ad-domainto updateCONTEXT.md. - If the candidates all turned out to be bug-symptoms rather than shape-symptoms:
/ad-diagnose(WORKFLOW §15).
Signals
- GitHub stars
- 206
- Forks
- 16
- Last commit
- Sep 2026
ahel recommends instead
Advanced
- Catalog kind
- skill
- Gateway key
ad-deepen-corridortech- Source
- github.com/corridortech/posecap