compose

name

compose

description

Protocol composition authoring assistant — build composition SKILL.md files from protocol Lego blocks. Validates chains against graph.json, analyzes gate dispositions via the Constitution/Extension classification model, and generates pipeline templates. Use when the user asks to 'compose protocols', 'create composition skill', 'build protocol chain', 'combine protocols', or wants to author a composition workflow like /review.

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

Safety-net search scope: safety_net(G) searches forward within the same protocol — the next downstream Constitution gate after G in the protocol's phase order. Cross-protocol fallback: when a protocol's terminal Constitution gate is an ELIDE candidate and no within-protocol downstream Constitution gate remains, the next protocol's first Constitution gate in the chain serves as the cross-protocol safety net. If both fail (the chain's terminal Constitution gate is itself an ELIDE candidate), promote G to PRESENT — the catch-chain cannot be discharged. This preserves the invariant under future split-Extension migration where some Constitution gates become Extension entries.

Presentation

Present per-protocol sub-tables:

### {Protocol} /{command}

| Phase | Gate | Kind | Standalone | Composed | Rationale |
|-------|------|------|-----------|----------|-----------|
| ...   | ...  | ...  | ...       | ...      | ...       |

Summary: {N} gates → {M} user interactions ({K} elided, {J} pruned)

After all protocol tables, present aggregate:

### Chain Summary

Total: {total} gates → {interactions} user interactions
Elided: {elided} | Pruned: {pruned} | Presented: {presented}
Interaction reduction: ~{percent}%

Cost Profile

After Chain Summary, present cost visibility sub-section:

Gate density: {total_gates} / {protocol_count} = {density} gates/protocol Constitution ratio: {constitution_count} / {presented_gates}

System 2 load — ASCII timeline per protocol:

{Protocol1}  {Protocol2}  ...  {ProtocolN}
  ■ Qs         ■ Qc            ■ Qs
  ■ Qc         · (elided)      ■ Qc

Legend: ■ = presented, · = elided, × = pruned

Conditional entropy: Σ log₂(|options_i|) bits over presented gates — quantifies total user decision load. Higher entropy across gates indicates more user decision points; lower entropy indicates more auto-resolvable gates.

O_support visibility — each elided gate's justification:

Elided Gate	Supporting Output	Basis

The Basis column connects to the composition-time disposition model used in this skill — O_support (prior protocol output entails this gate's answer) is the primary justification source for ELIDE dispositions.

Gate #2 (Qc — Phase 4 allows regeneration):

Options:

1. Accept all — proceed to template generation
2. Modify — specify gates to change (promote elide→present or demote present→elide with rationale)

Phase 4: Generate (Template Output)

Generate the composition SKILL.md file following the /review structural pattern.

Template Structure

1. YAML Frontmatter

---
name: {user-defined name}
description: "{chain description — what this composition does}"
skills:
  - {protocol1}:{skill1}
  - {protocol2}:{skill2}
  - ...
---

The skills: field declares sub-protocol dependencies using the {plugin}:{skill} namespace.

2. Title and Purpose

Brief paragraph: what deficit pattern this composition addresses, why these protocols are composed, and what the combined output is.

3. Pipeline Overview

ASCII phase diagram showing the chain with gate annotations:

{Protocol1} → {Protocol2} → ... → {ProtocolN} → Summary
  ({M} gates)   ({K} gates)         ({J} gates)

4. Per-Protocol Sections

For each protocol in the chain, a section containing:

• The gate walk-through table from Phase 3 (Composed column only)
• Pipeline context rules — behavioral modifications to sub-protocol gates when called from this composition. Format:

**Pipeline context rules** (when /{command} is called from this pipeline):
- **{gate label}**: {ELIDE|PRESENT|PRUNE} — {rationale}
- ...

5. Materialized View

Template for the final output structure. Includes:

• Per-protocol output summary (what each protocol contributed)
• Decision log: for each elided gate, what was auto-decided and why
• Transformation trace: deficit-to-resolution mapping per protocol

6. Error Recovery

Suffix replay rules:

• On mid-chain discovery of upstream error: identify the first invalid gate
• Replay forward from that gate (not backward compensation)
• Same-reason replay capped at 2 attempts
• Present replay proposal to user with options: replay, proceed accepting mismatch, terminate preserving artifacts

7. Rules

Standard rules section:

1. No silent authority transfer — all Qs gates and Constitution Qc gates require user response
2. Catch-chain invariant — never elide both a gate and its safety net
3. BoundaryMap integration — conditional dispositions when Horismos is in the chain
4. Session Text Composition — inter-protocol data flows as natural language
5. Coexistence — composition does not absorb protocols; each remains independently invocable

Gate #3 (Qs — template is the final artifact)

Present the generated template for review. Options:

1. Accept — write to the specified output path
2. Modify — iterate on specific sections (user points to what needs change)
3. Regenerate — return to Phase 3 with modified dispositions

On Accept: write the template using the Write tool. Present the output path and suggest running /verify if the template is placed in a plugin directory.

Cluster Shortcuts

Predefined chain patterns based on the built-in concern clusters:

Shortcut	Chain	Rationale
planning	clarify → goal → bound → inquire	Planning cluster + boundary definition
analysis	frame → ground	Analysis cluster
decision	gap → attend	Decision + execution

Shortcuts are convenience aliases — the user can always specify a custom chain. Shortcuts resolve to their chain at Phase 0 and proceed through normal validation.

When to Use

• Creating a new composition workflow that chains 2+ epistemic protocols
• Formalizing an ad-hoc protocol chain that has proven useful across sessions
• Generating pipeline context rules for gate elision in multi-protocol workflows

When NOT to Use

• For general skill creation → use /skill-creator
• For running an existing composition → invoke the composition skill directly
• For single-protocol usage → invoke the protocol directly
• For understanding protocols → use /catalog or /onboard

Rules

1. Authoring, not execution: /compose generates SKILL.md files; it does not execute protocol chains at runtime
2. Graph authority: references/graph.json is the authoritative source for chain validation — do not override precondition or suppression edges without user explicit confirmation
3. Conservative default: When disposition is ambiguous, default to PRESENT (ask user) over ELIDE (auto-pass)
4. Catch-chain is structural: Catch-chain invariant violations block template generation — not advisory, not overridable
5. Inline decision flow: The composition-level disposition decision flow must be included in the generated template so the runtime agent can apply it without cross-referencing analysis documents
6. BoundaryMap conditionality: BoundaryMap-dependent dispositions are generated as conditional rules only when Horismos is in the chain; omit otherwise
7. No duplicate gates: The generated template references protocols by skills: frontmatter and pipeline context rules — it does not duplicate the protocol's own gate definitions
8. Template completeness: Every generated template must include: frontmatter with skills list, pipeline context rules, materialized view template, error recovery section, and rules section