realign

What this skill does

# Realign Skill

Project Direction Horizon Fusion — when the user wants the project guide's direction line to remain a faithful fusion of (i) what is currently inscribed, (ii) what externally surfaced direction signals jointly testify, and (iii) what the user presently pre-understands the project to be doing, scan and elicit each horizon, propose a fused candidate with a per-horizon transformation trace, shape the candidate through dialectical exchange, and write the confirmed line back to the project guide. Type: `(HorizonsUnfused, AI, INDUCE-with-fusion, ThreeHorizons) → FusedDirection`.

Invoke directly with `/realign` when the project guide's current direction line no longer fuses with the external work landscape and the user's present sense of the project.

## Definition

**Realign** (Periagoge specialization, "fusing horizons"): A dialogical act of resolving the unfusion of three horizons — the project guide's currently inscribed direction, externally surfaced direction signals from configured channels, and the user's present pre-understanding — into a single recognized direction line, where AI scans the inscribed direction and the configured channels, elicits the user's pre-understanding as a separate horizon (not as an attribute list of the channel signals), composes a fusion candidate with a per-horizon trace marking what was preserved, what was transformed, and what was dropped in each horizon, shapes the candidate through dialectical moves, and inscribes the confirmed line back to the project guide. Direction mutation belongs to the user's per-step verdict and final confirmation acts.

This skill is a Periagoge family extension. Generic Periagoge (`/induce`) crystallizes an unnamed essence from an instance set into a session-text abstraction. Realign narrows the instance axis to *three named horizons* (each independently surfaced) and extends the output axis with a fusion trace plus a writable project-guide line update. The dialectical triangulation core is preserved (Phase 2 candidate shaping realizes the same widen / narrow / fuse / reorient / confirm / dismiss vocabulary as `/induce`), but the pre-shaping step adds a verifiable per-horizon fusion trace and the post-confirmation step adds a write that crosses the `preserves`/`mutates` boundary that `/induce` itself respects.

**Horizon-fusion discipline**: An additive paste that appends the user's pre-understanding to the inscribed direction line as a clause is not horizon fusion — it is an addendum. Fusion requires that any of the three horizons may be transformed or dropped in service of the fused candidate; the per-horizon trace surfaces this explicitly so the user can verify that no horizon was preserved by silent default. The constraint applies symmetrically: the inscribed line is not privileged over the external signals or the user's pre-understanding, and vice versa.

**Pre-understanding elicitation discipline**: The user's pre-understanding is a separate horizon, not a derivation from the surfaced channel signals. Phase 1's pre-understanding sub-step elicits the user's present sense of the project as a free utterance before the channel-derived fusion candidate is composed; conflating the channel attribute list with the user's pre-understanding collapses two horizons into one and produces a fused candidate that fails the symmetry condition above.

**Self-referential consistency**: When the project guide whose direction line is the write target prescribes principles that this skill's prose should also follow (for example, the project-agnostic discipline of this skill's vocabulary), the skill's own SKILL.md must satisfy those principles. This is not a chicken-and-egg paradox but a fixed point: the user's act of confirming the fused candidate is what guarantees the consistency between the candidate and the principles it is expected to satisfy.

## When to Use

Invoke this skill when:
- The project guide's direction line was inscribed at an earlier point and the externally surfaced work landscape has shifted since
- The user senses the inscribed direction no longer captures what the project is actually doing across open work, recent reviews, and current sessions
- The user wants the inscribed direction line to be re-derived from the three horizons rather than edited piecemeal
- A direction-fusion artifact (the per-horizon trace) is needed alongside the new line for downstream review

Skip when:
- The deficit is forward-looking deficit-recognition fit review (use `/probe`)
- The audit target is a calibration profile rather than the project guide direction line (use `/steer`)
- The user wants in-conversation abstraction crystallization without project-guide line inscription (use `/induce` directly)

## Distinction from Adjacent Skills

| Skill | Subject | Operation | Output | Persistence |
|-------|---------|-----------|--------|-------------|
| `/probe` | Deficit recognition fit review | RECOGNIZE | ProtocolRoute or FitReviewNote | Session text |
| `/induce` | Abstraction crystallization | INDUCE | CrystallizedAbstraction | Session text |
| `/steer` | Calibration profile recalibration | INDUCE-with-inscription | UpdatedProjectProfile | Project profile rule file |
| `/realign` | Three-horizon fusion of project guide direction | INDUCE-with-fusion | FusedDirection or NoFusionNote | Project guide direction line |

The skill family coexists by subject and persistence — none replaces the others. Realign is for keeping the project guide's direction line a faithful fusion of three horizons; the other skills serve forward-looking, in-conversation, or calibration-profile needs.

## Protocol

### Phase 0: Scope Determination

Determine the audit scope before scanning. Two decisions:

- **External channels** — the set of substrates whose contents are surfaced as the external-signals horizon; default set is `{ open issues, pull-request reviews including bot reviews, closed disposition trajectory, current session utterances }`; the user may add, remove, or substitute channels
- **Cross-session evidence** — default off; reading prior session direction history beyond the current session requires explicit user confirmation

If the user invocation does not specify scope, present a Constitution interaction soliciting the two decisions before proceeding to Phase 1. If scope is fully specified, accept it and proceed. The project guide path is not bound at Phase 0 — substrate discovery for Horizon A happens within Phase 1 (the inscribed-direction surfacing sub-step) so that the binding can absorb the convention-inference and ambiguity-resolution work without pre-formalization at scope time.

### Phase 1: Prejudgment — Three-Horizon Surfacing

Surface each of the three horizons independently before composing any fusion candidate.

**Horizon A — inscribed direction**: Search the project's substrate for the inscribed direction. Convention-inferred candidate guides (for example, `CLAUDE.md`, `AGENTS.md`, `README.md` at the project root); within each candidate, enumerated marker headers (for example, `Northstar`, `Mission`, `Vision`, `Direction`, `Statement of Intent`) plus an Emergent slot for project-specific markers. If a single candidate × marker pair is found, present it as Horizon A. If multiple candidates or markers are found, present them as a Constitution interaction so the user constitutes which pair is Horizon A (and therefore the Phase 3 write target). If nothing is found, Horizon A is empty — the fusion still proceeds with Horizons B and C, and the user is invited to designate a path × marker for the Phase 3 write target during Phase 2 shaping or Phase 3 approval. The `--guide=<path>` invocation argument, when supplied, overrides convention-inference and binds Horizon A directly to the given path; the marker is then either auto-detected within the file or supplied by `--direction-marker=<header>`.

**Horizon B — external-signals direction**: Scan the configured channels and aggregate the directi