compose

What this skill does

# Compose: Protocol Composition Authoring

Build composition SKILL.md files from protocol chains. Validates graph constraints, catalogs gates, proposes dispositions, and generates a pipeline template following the `/review` structural pattern.

**This is an authoring tool, not a runtime executor.** The output is a SKILL.md file that the user can install and invoke independently.

## Pipeline Overview

```
SPECIFY → VALIDATE → CATALOG → DISPOSITION → GENERATE
  (gated)                        (gated)       (gated)
```

3 user gates across 5 phases. Phases 1-2 are autonomous (validation and collection).

## Phase 0: Specify (Chain Input)

Accept a protocol chain specification from the user.

**Input forms**:
- Inline argument: `/compose elicit → bound → inquire`
- Conversational: user describes the desired chain
- Cluster shortcut: `/compose planning` (resolve via the built-in Cluster Shortcuts table below)

**Normalization**: Accept protocol names (Aitesis), slash commands (/inquire), skill names (inquire), or short names. Case-insensitive. Arrow separators (`→`, `->`, `,`, spaces) all accepted. Resolve to canonical `(protocol_name, slash_command)` pairs using the registry below.

**Output path**: Ask the user where to write the generated SKILL.md. Default: `~/.claude/skills/{chain-name}/SKILL.md` for user-level skills, or suggest a project-level path if appropriate.

**Gate #1** (Qc — Phase 1 validates):

Present the interpreted chain with canonical protocol names, slash commands, and proposed output path. Options:
1. **Confirm** — proceed with this chain
2. **Modify** — adjust protocols, order, or output path

**Protocol registry**:

| Protocol | Slash | Skill token |
|----------|-------|-------------|
| Horismos | `/bound` | `bound` |
| Aitesis | `/inquire` | `inquire` |
| Prothesis | `/frame` | `frame` |
| Analogia | `/ground` | `ground` |
| Periagoge | `/induce` | `induce` |
| Euporia | `/elicit` | `elicit` |
| Syneidesis | `/gap` | `gap` |
| Prosoche | `/attend` | `attend` |
| Epharmoge | `/contextualize` | `contextualize` |
| Elenchus | `/sublate` | `sublate` |
| Diylisis | `/distill` | `distill` |
| Anamnesis | `/recollect` | `recollect` |
| Katalepsis | `/grasp` | `grasp` |

## Phase 1: Validate (Graph Constraints)

Read `references/graph.json` (bundled with this skill). Check three constraints:

### 1.1 Precondition Order

For each precondition edge `(source, target)` in graph.json: if both source and target are in the chain, source must appear before target.

On violation: present the precondition edge with its `satisfies` description and suggest reordering. Return to Phase 0 with the corrected chain.

### 1.2 Suppression Conflict

For each suppression edge `(source, target)`: if both are in the chain, warn. Present the `satisfies` description explaining why co-activation is problematic.

Options:
- Remove one protocol from the chain
- Confirm with explicit scope differentiation (user declares the protocols address different scopes)

### 1.3 Missing Preconditions

For each protocol in the chain: check if any precondition source is missing. The wildcard `"source": "*"` (Katalepsis) is excluded from this check — it means "structurally last" not "requires all."

On missing precondition: suggest inserting the missing protocol at the correct position.

**Design note — chain-position × regret interaction**: The concern that unbounded-regret gates positioned late in a chain degrade user judgment quality is valid but not yet addressed. Phase 3 disposition operates per-gate without chain-position awareness. A future revision will introduce a decision load model that quantifies remaining gate cost (loop depth × regret weight) per disposition choice, replacing the removed position-ratio advisory with a structurally sound, Phase 2-integrated mechanism.

**On all validations passing**: proceed to Phase 2 with the validated chain.

## Phase 2: Catalog (Gate Inventory)

Read all protocol SKILL.md files in parallel (paths are deterministic after Phase 1 validation). For each protocol:

1. **Locate SKILL.md**: Read `{protocol}/skills/{skill}/SKILL.md`
2. **Extract TOOL GROUNDING**: Grep for `TOOL GROUNDING` section
3. **Parse each entry**: Extract Phase number, label, classification (`constitution` or `extension`), inline condition (parenthetical text after the entry, if any), and downstream safety reference (if stated)

Build the gate inventory:

```
List<{
  protocol: String,
  phase: Number,
  kind: Qc | Qs,
  label: String,
  classification: constitution | extension,
  condition: String?,            -- inline condition text for split (extension) entries (e.g., "when explicit_arg(U)")
  safety_net: String?            -- downstream Constitution gate reference
}>
```

Constitution entries are gated (user judgment required); Extension entries are conditional auto-resolutions whose condition is recorded inline. Pairs of (extension)/(constitution) entries within the same Phase represent split conditional gates — the Extension path takes the auto-resolution when its condition fires; otherwise the Constitution path requires user judgment.

Present the inventory as an informational summary (no gate — Phase 3 is where the user reviews):

```
## Gate Inventory

{protocol}: {N} entries ({M} Constitution, {K} Extension)
  - Phase {X} ({label}): {classification}{ — when condition if Extension}
  ...

Chain Total: {total} entries ({total_constitution} Constitution, {total_extension} Extension)
```

## Phase 3: Disposition (Composition-Level Gate Analysis)

Apply the disposition decision flow to each gate in the inventory. Constitution/Extension classification (parsed from TOOL GROUNDING) is the input; composition-level disposition determines whether each Constitution gate becomes PRESENT, PRUNE, or ELIDE within this specific chain. Extension entries (split conditional auto-resolutions) require no disposition — they fire when their inline condition holds and otherwise fall through to the paired Constitution entry within the same Phase.

### Disposition Decision Flow

For each Constitution gate G in the composition context:

```
1. Qs(G)?                                              → PRESENT
2. domain(G) ∈ Dismissed?                               → PRUNE
3. unbounded_regret(G)?                                 → PRESENT
4. domain(G) ∈ UserSupplies ∪ AIPropose?                 → PRESENT
5. Qc(G) ∧ bounded_regret(G) ∧ epistemic_access(G)?    → ELIDE candidate
6. otherwise                                            → PRESENT (conservative default)
```

Steps 2 and 4 are **conditional** — apply only when Horismos is in the chain and BoundaryMap is available. When Horismos is absent, skip steps 2 and 4 (flow reduces to steps 1, 3, 5, 6). Generate BoundaryMap-dependent steps as conditional rules in the template, not fixed dispositions.

**Epistemic access** in composition context — any of:
- `system_state(G)`: answer derivable from codebase/environment (AI can self-resolve)
- `answer(G) ⊆ output(prior)`: prior protocol in the chain produces output that entails this gate's answer (e.g., ResolvedEndpoint from Euporia entails Horismos Phase 0 scope confirmation)
- `BoundaryMap(domain(G)) = AIAutonomous`: user delegated decision authority to AI via Horismos (only when Horismos is in the chain)

**RESOLVE-OR-PRESENT** (for Qs gates in AIAutonomous domains): The Qs gate itself is never elided — instead, the protocol's Phase 1 context collection scope expands for AIAutonomous domains. If Phase 1 resolves the uncertainty (entropy → 0), the Qs gate is never reached. If entropy remains > 0, the Qs gate fires as PRESENT. Encode this as a conditional pipeline context rule when applicable.

### Catch-Chain Invariant

For every Constitution gate G whose disposition is ELIDE, verify:

```
disposition(G) = ELIDE ⟹ disposition(safety_net(G)) ≠ ELIDE
```

If violated: promote the safety net gate to PRESENT. This prevents cascading composition-time delegation from removing all user checkpoint