PoseCap: Skill for Codex

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

1. Read CONTEXT.md if it exists. Anchor domain vocabulary; deepening proposals must use Customer, Order, Triage role — not Service, Handler, Manager.
2. Read ARCHITECTURE.md if it exists. Read accepted ADRs in doc/adr/ covering the surface you are about to walk.
3. 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.