probe

What this skill does

# Probe Skill

Deficit Recognition Probe — when the user is uncertain which epistemic deficit (and therefore which protocol) fits the current situation, surface AI-generated multi-hypothesis candidates with reverse-evidence conditions, and route on user-constituted recognition. Type: `(DeficitUnrecognized, AI, RECOGNIZE, UserSituation) → ProtocolRoute`.

Invoke directly with `/probe` when the user wants a fit review across the protocol catalog before committing to a single protocol invocation.

## Definition

**Probe** (ἐπίγνωσις, *epígnōsis*: knowing-upon, recognition of what was already there): A dialogical act of resolving a user's vague sense that "something is off" into a recognized deficit + protocol route, where AI scans the user's recent situation against the catalog of epistemic deficits, presents at minimum two hypotheses with falsification conditions, and the user constitutes the route via recognition — never AI-resolved scoring.

This skill stands in structural homology with Anamnesis (`/recollect`) — both realize the RECOGNIZE operation family. Anamnesis recognizes past context from vague recall; Probe recognizes present-situation deficit from vague unease. Anamnesis output is `RecalledContext`; Probe output is `ProtocolRoute`. Both treat user recognition as the constitutive act and refuse AI-side resolution.

## When to Use

Invoke this skill when:
- The user feels something is off but does not yet name which epistemic deficit fits
- A protocol invocation is being considered, and the user wants a fit review across alternatives before committing
- Multiple plausible routes coexist (e.g., "is this a goal problem or a context problem?") and the user wants the alternatives surfaced explicitly with their reverse-evidence conditions

Skip when:
- The deficit is already named with confidence (invoke the matching protocol directly)
- The user wants a passive reference handbook (use `/catalog`)
- The user wants pattern-based recommendation from session history with optional trial (use `/onboard`)
- The user wants accumulated session analytics (use `/report` or `/dashboard`)

## Distinction from /catalog and /onboard

| Skill | Stance | Input | Output |
|-------|--------|-------|--------|
| `/catalog` | Passive reference | Browse / lookup | Static handbook entries |
| `/onboard` | Pattern-based recommendation + optional trial | Session history patterns | Recommended protocol + scenario + trial |
| `/probe` | Active AI-hypothesized deficit recognition | Current user situation | At minimum two hypothesis candidates + user-constituted route |

The three coexist by design — none replaces the others. Probe is for experienced users with frame-binding uncertainty; `/catalog` is for users who already know the question; `/onboard` is for users who want pattern-based learning.

## Protocol

### Phase 0: Detection

Detect that the user's situation admits ambiguous deficit framing. Heuristics:

- The user's request describes symptoms ("something feels off", "not sure which protocol") rather than naming a deficit
- The session shows a pattern that maps to two or more candidate deficits with comparable plausibility
- The user explicitly invokes `/probe`

Phase 0 is silent — no surfacing. If detection fails (deficit is already clearly named), deactivate.

### Phase 1: Catalog Scan

Scan the user's situation against the full catalog of 14 epistemic deficits. For each candidate hypothesis, build a `Set(CoverageEntry)` where each entry pairs:

- A `deficit: DeficitName` matched against the situation
- The `protocol: ProtocolId` that addresses that deficit
- `evidence: Evidence` — the situation signal supporting the match
- `reverse_evidence: Evidence` — the observation that would shrink the coverage to exclude this entry

A hypothesis with `|coverage| = 1` is a single-protocol projection (preserves prior single-protocol behavior). A hypothesis with `|coverage| ≥ 2` is a set-valued coverage — multi-protocol projection within one hypothesis. This intra-hypothesis multi-protocol projection is structurally distinct from the inter-protocol composition defined in the `── COMPOSITION ──` block; do not conflate the two.

When `Λ.coverage_constraint` is set (from a prior `Narrow(CoverageSubset)`), filter the scan output to hypotheses whose coverage protocol set intersects with the constraint — this preserves user-directed narrowing across re-scan iterations.

Construct the candidate set. Keep at minimum two candidates with non-overlapping reverse-evidence conditions — singleton high-confidence framing is forbidden (see Rules section, Rule 5).

**Single-pass routing scope**: Phase 1 enumerates named deficits across the catalog as a one-shot fit review. Per-protocol convergence dynamics — including cycle iteration within a routed protocol such as `/elicit`'s reverse-induction loop — remain internal to that destination protocol; Probe does not surface, measure, or aggregate convergence efficiency across uses (Rule 7 reinforcement; cycle-counter visibility is the destination protocol's UX surface, not Probe's).

### Phase 2: Hypothesis Presentation

Present the candidate hypotheses as text output before the Constitution interaction. Each rendered line under `Coverage:` corresponds to one `CoverageEntry` (deficit, protocol, evidence, reverse_evidence). Format per hypothesis:

```
Hypothesis N — N interpretations possible / decision point is X
  Coverage:
    /<protocol_a> (<DeficitName>):
      Evidence: <quote or paraphrase>
      Reverse-evidence: <observation that would shrink coverage to exclude this entry>
    /<protocol_b> (<DeficitName>):
      Evidence: <...>
      Reverse-evidence: <...>
  (Singleton |coverage|=1: render the single CoverageEntry as one protocol line, equivalent to prior single-protocol format)
```

**Coverage option-set minimality**: When `|coverage| ≥ 2`, coverage subsets are NOT enumerated as additional options — the per-entry Evidence and Reverse-evidence within the Coverage block serve as the short descriptions that guide singleton selection. The user invokes a singleton through free response or `Narrow(CoverageSubset)`. This preserves option-set minimality and induces the Hermeneutic circle through iterative user-initiated dialogue rather than AI-side menu expansion. (Per Rule 14, this contextual rule informs the gate decision and therefore precedes the gate options.)

Present the recognition Constitution interaction as a free-response prompt:

```
Which hypothesis fits your present situation?

Free response — the disposition is constituted by the user's natural utterance.
Recognition / Redirect / Dismiss / Narrow scope / Stop are all reachable via free response;
Phase 3 parses the utterance into the corresponding R coproduct constructor.
The hypothesis surface above carries the full deficit space; no typed selection is required.
```

The disposition field belongs to the user. AI does not score, rank, or pre-resolve the choice. Free response preserves the user's implicit freedom to respond beyond any anticipated typed options — this freedom is inherent in conversation turn structure: gated does not mean unstructured; it means the user's response is constitutive (Rule 12 Recognition over Recall and Rule 14 Context-Question Separation, both inscribed in this SKILL.md).

### Phase 3: Route Integration

After user response (free-response utterance from Phase 2):

**Free-response parse**: Phase 3 resolves the utterance to the R coproduct constructor whose semantic intent most closely matches — affirmative adoption of a presented hypothesis routes to `Recognize`, alternative deficit/protocol nomination routes to `Redirect`, rejection of all hypotheses routes to `Dismiss`, scope restriction (situation slice or coverage subset) routes to `Narrow`, and exit signal routes to `Stop`. The presented hypotheses serve as the recognition substrate; no typed selection is required. When the utterance does not unambiguously resolve into a single constructor, Phas