--- name: Steer slug: steer category: AI Engineering description: Steer audits a target session for calibration drift, groups evidence by cluster, and drafts an updated project-profile rule for user approval. It also records settled directions in the project guide when a resolution has become a recurring convention. github: "https://github.com/jongwony/epistemic-protocols/tree/main/epistemic-cooperative/skills/steer" language: JavaScript stars: 161 forks: 15 install: "npx degit https://github.com/jongwony/epistemic-protocols/tree/main/epistemic-cooperative/skills/steer ~/.claude/skills/steer" installs_to: ~/.claude/skills/steer source_path: epistemic-cooperative/skills/steer/SKILL.md collection_size: 25 category_size: 3670 collection_url: "https://dirskills.com/collections/jongwony/epistemic-protocols" added: 2026-09-08T05:36:07.550Z last_synced: 2026-09-08T05:36:07.550Z canonical_url: "https://dirskills.com/skills/steer" --- # Steer Steer audits a target session for calibration drift, groups evidence by cluster, and drafts an updated project-profile rule for user approval. It also records settled directions in the project guide when a resolution has become a recurring convention. **Install:** ```bash npx degit https://github.com/jongwony/epistemic-protocols/tree/main/epistemic-cooperative/skills/steer ~/.claude/skills/steer ``` ## README # Steer Skill Project Profile Recalibration via Calibration Drift Audit — when the user wants to refresh the user-global or project-local project-profile rule layer based on observed Cognitive Partnership Move calibration drift in a target session, scan calibration moves for Constitution overapplication, Extension misapplication, and existing-profile drift, surface per-cluster evidence for user-constituted verdict, assemble a profile diff, and write an updated rule file with timestamped backup. Type: `(CalibrationDriftOpaque, AI, INDUCE-with-inscription, SessionCalibrationMoves) → UpdatedProjectProfile`. Invoke directly with `/steer` when the user wants the project profile to track observed calibration practice rather than remain frozen at initialization time. ## Definition **Steer** (Periagoge specialization, "turning the helm"): A dialogical act of resolving the opacity of project profile drift into a recognized profile update, where AI scans target session calibration moves against the existing project-profile rule layer, classifies each move into drift clusters, presents per-cluster evidence for user-constituted verdict, assembles a diff over the six profile variables, and inscribes the approved diff back into the rule file — profile mutation belongs to the user's per-cluster verdict and final approval acts. This skill is a Periagoge family extension. Generic Periagoge (`/induce`) crystallizes an unnamed essence from an instance set into a session-text abstraction. Steer narrows the instance axis to *Cognitive Partnership Move calibration moves observed in a target session* and extends the output axis with a writable rule inscription step — the inscribed `project-profile.md` becomes the new prejudgment baseline for the next invocation. This closing of the loop (audit → inscription → next invocation reads the inscribed baseline) is referred to as **Circular Return** in this skill: the inscribed artifact becomes the prejudgment input the next audit reads from, making the operation self-referential across sessions. The dialectical triangulation core is preserved (Phase 3 per-cluster verdicts and Phase 5 final approval realize the Confirm / Dismiss / Reorient pattern), but the write step crosses the `preserves`/`mutates` boundary that `/induce` itself respects. This skill stands in time-axis dual relationship to `/probe` (prospective fit recognition). Both refuse AI-side resolution and treat user recognition as the constitutive act. The writable persistence layer is what makes Steer useful for keeping the profile current as a project's needs change. Steer maintains a **second inscription target** alongside the profile: a **Settled Directions registry**. When a confirmed cluster shows that a resolution direction has been recurringly constituted the same way — observed practice consistently auto-resolves (relays) what the profile would gate — that direction has *settled*, and it graduates into a citable convention clause. Downstream gate decisions cite such a clause to present a finding as relay rather than re-gating a direction the project has already decided. The registry lives in the project guide (`AGENTS.md` / `CLAUDE.md`), in a `## Settled Directions` section placed adjacent to the project's Northstar/mission section (the section is created if absent). Both write targets are governed by the same Phase 5 final approval; the profile rolls back through a timestamped backup (when an existing profile is present) and the registry through version control (the project guide is git-tracked, matching the `/realign` convention for that file). A settled-directions clause is the output when a cluster's implication names a settled direction rather than a profile-variable value. Phase 3 per-cluster recognition is verification-category — the user verifies the AI's classification accuracy of an already-detected drift cluster, not a forward-trajectory selection. The Differential Future Requirement does not apply to the per-cluster verdict gate by the same logic that exempts Anamnesis Phase 2 recognition gates (past-identity synthesis, not future-trajectory commitment): a 1-correct option structure (was-drift / was-aligned) is legitimate by purpose because downstream diff assembly is a deterministic consequence of the verdict, not a user-selected trajectory. Phase 5 final approve gate IS forward-looking (write or not write) and follows the Differential Future Requirement. Paths below written `{config_dir}/…` take `{config_dir}` = `CLAUDE_CONFIG_DIR` when set, else `~/.claude`. Resolve it ONCE per invocation with Bash `printf '%s\n' "${CLAUDE_CONFIG_DIR-$HOME/.claude}"` and substitute the absolute result before any Read/Glob/Grep call. ## When to Use Invoke this skill when: - The project profile was set at initialization but the user senses observed calibration practice has drifted from the inscribed defaults - The user wants to refresh `{config_dir}/rules/project-profile.md` (user-global) or `.claude/rules/project-profile.md` (project-local) based on a recent session's calibration moves - The user wants empirical evidence about which Cognitive Partnership Move axes (Constitution / Extension / six profile variables) need recalibration - A target session contains enough calibration moves (gate interactions, auto-resolutions, agent boundary actions) to support a meaningful audit - A resolution direction has been constituted the same way often enough that re-gating it is over-gating, and the user wants it recorded as a citable Settled Directions clause adjacent to the project Northstar Skip when: - The deficit is forward-looking (use `/probe` for prospective deficit recognition) - The audit target is past protocol contract integrity rather than calibration drift in Cognitive Partnership Move - The session contains too few calibration moves to support audit (Phase 0 deactivates with no-op note) - The user wants in-conversation abstraction crystallization without rule inscription (use `/induce` directly) ## Distinction from Adjacent Skills | Skill | Time axis | Subject | Operation | Output | Persistence | |-------|-----------|---------|-----------|--------|-------------| | `/probe` | Prospective (present situation) | Deficit recognition fit review | RECOGNIZE | ProtocolRoute or FitReviewNote | Session text | | `/induce` | In-process (instance set) | Abstraction crystallization | INDUCE | CrystallizedAbstraction | Session text | | `/steer` | Retrospective (target session) | Cognitive Partnership Move calibration drift | INDUCE extended with writable inscription, with routing to operational layer when finding shape mismatches | UpdatedProjectProfile, NoUpdateNote, DiffArtifact, or OperationalLayerRecommendation | Writable rule file + Settled Directions registry (Approve disposition) or session text (other dispositions) | The skill family coexists by operation and persistence — none replaces the others. Steer is for keeping the project profile current with observed practice; the other skills serve forward-looking or in-conversation needs. ## Protocol ### Phase 0: Scope Determination Determine the audit scope before scanning. Three decisions: - **Target session** — default is the current session only; the user may pass a session_id argument to target a different session - **Layer** — `user_global` (`{config_dir}/rules/project-profile.md`) or `project_local` (`.claude/rules/project-profile.md`); when both files exist, default to the layer the user invoked from (project_local when CWD is inside a project with a local file, user_global otherwise); the user may override - **Cross-session evidence** — default off; reading prior session calibration history beyond the target session requires explicit user confirmation If the user invocation does not specify scope, present a Constitution interaction soliciting the three decisions before proceeding to Phase 1. If scope is fully specified, accept it and proceed. Phase 0 is otherwise silent. If the target session contains fewer than the minimum-viable calibration move count (default: 3 moves), deactivate with a brief no-op note and route the user to invoke `/steer` against a richer session. ### Phase 1: Prejudgment — Load Existing Profile Read the existing project-profile rule file at the chosen layer: - For `user_global`: `{config_dir}/rules/project-profile.md` - For `project_local`: `.claude/rules/project-profile.md` Parse the existing six profile variables (revision_cost, deploy_fan_out, dependency_lock_in, runtime_persistence, hermeneutic_circle_availability, notation_maturity) and the calibration result (Extension-default vs Constitution-default vs mixed). When the file does not exist, treat the existing profile as the empty profile P_∅ — the audit then operates as a first-time profile induction rather than a recalibration. Phase 1 emits no surfacing. The loaded profile becomes the prejudgment baseline against which Phase 2 trial inscription operates. ### Phase 2: Trial Inscription — Scan and Classify Scan the target session for calibration moves and classify each into a drift cluster. Scan procedure: 1. Read the target session transcript (`{config_dir}/projects/{slug}/{session-id}.jsonl`) 2. Extract calibration move candidates — gate interactions (Constitution / Extension presentations per TOOL GROUNDING), auto-resolutions where AI proceeded without user gate, agent boundary actions (Skill / Agent / SendMessage invocations), Standing-authority delegations 3. For each candidate, identify the move kind (Constitution / Extension / BoundaryAction) and the axis it implicates (which of the six profile variables it bears on, when applicable) Classification — assign each move to one cluster of the partition: - **ConstitutionOverapplied** — moves where AI presented a Constitution gate that the loaded profile would have routed to Extension; evidence: existing profile classification → Extension, observed move → Constitution gate. Implication: the existing profile's Extension scope may be too narrow; observed practice prefers user gating. - **ExtensionMisapplied** — moves where AI auto-resolved (Extension) what the loaded profile would have routed to Constitution; evidence: existing profile classification → Constitution, observed move → auto-resolution. Implication: the existing profile's Constitution-required category may be too broad; observed practice prefers auto-resolution. - **ProfileDriftConflict** — moves whose evidence supports a profile variable value different from the inscribed value. Implication: the variable assignment itself needs revision toward the value the observed evidence supports. - **Emergent** — moves whose evidence signals a calibration concern that does not fit the named clusters. The Emergent cluster admits axes outside the six named variables and surfaces them as candidates for taxonomy revision pending accumulated use evidence under the project's calibration mechanism. Phase 2 produces no cumulative score or rate. No "calibration accuracy index", no "drift percentage", no "profile fitness metric". Per-move classification is the entire structured output. ### Phase 3: Validation — Per-Cluster Recognition (Constitution Loop) For each non-empty cluster, present the cluster's evidence for user-constituted verdict. Present cluster context as text output before the Constitution interaction. Format per cluster: ``` Cluster [Type] — N moves For each move (up to 5 representative moves; remaining counted): Move K — turn Move kind: Axis: Evidence: Existing-profile expectation: Observed move: Cluster implication: ``` Then propose AI verdict before yielding turn for user constitution: `AI proposed verdict: ` — one-paragraph classification justification: cluster evidence, counter-evidence considered, and why the cluster IS (or IS NOT) drift under the proposed verdict. Phase 3 is verification-category (1-correct option structure per definition section); the rationale supports classification accuracy, not competitive ranking among peer alternatives. Then present the recognition Constitution interaction: ``` Did this cluster surface a real calibration drift? Options: 1. Confirm — the cluster represents real drift; carry into the assembled diff 2. Dismiss — the cluster is noise (the moves were appropriate as-is); exclude from diff 3. Reorient — the cluster is real but the implication should be different from presented; specify the alternative implication 4. Stop — exit /steer without further cluster review (assembled-so-far diff goes to Phase 4) ``` Each cluster verdict belongs to the user — confirmation is constituted by the user's selection at this Constitution interaction. After response: - **Confirm** — record the cluster as confirmed drift; carry implication into Phase 4 tier resolution - **Dismiss** — record the cluster as user-dismissed noise; exclude from diff - **Reorient** — accept the user's alternative implication; record cluster as confirmed-with-modified-implication; carry into Phase 4 - **Stop** — break loop; proceed to Phase 4 with whatever has been confirmed so far Loop Phase 3 over clusters in evidential-strength order (highest-evidence first). Phase 3 honors the cluster set as enumerated in Phase 2 — no dynamic cluster injection during the loop. ### Phase 4: Tier Resolution — Assemble Diff and Fit-Shape Check Assemble a profile diff from confirmed cluster implications. First **partition** the confirmed clusters by implication target: a cluster whose implication names a *settled direction* routes to the settled-directions delta (assembled below) and is excluded from profile translation; every other confirmed cluster routes to the profile diff. The two targets are disjoint per cluster — no cluster contributes to both, so a registry-only cluster never becomes a (spurious) profile-variable change. 1. For each confirmed cluster **routed to the profile diff** (i.e., not partitioned to the settled-directions delta), translate the cluster implication into a concrete profile variable change (or calibration result change, when the cluster's implication is structural rather than per-variable) 2. Resolve cross-cluster conflicts where two or more clusters propose incompatible values for the same variable; when the conflict requires user judgment, surface it in Phase 5 alongside the candidate values 3. Construct the diff representation: `before` (existing profile) → `after` (proposed profile), variable-by-variable, with provenance citing the confirming cluster(s) 4. Fit-shape check — evaluate whether the assembled diff fits the project profile rule file structure (six variables + Floor / Bounded zone + calibration result). Mismatch signals: - **Programmatic-trigger material**: the diff's enforcement requires deterministic detection of a specific tool / command / event (e.g., a particular Bash invocation, a specific slash command, a tool result shape) — prose interpretation cannot reliably substitute - **Layer mixing**: the diff compresses universal principle, specific instance, recognition mechanism, and falsification metrics into a single rule-file bullet — the resulting contract is ambiguous between universal rule and concrete operational guidance - **Behavioral enforcement focus**: the diff's load-bearing requirement is *what AI does at runtime*, not *what is visible to user judgment* — behavioral enforcement is operational-substrate territory (system prompts, hooks, CI/CD, settings.json), distinct from the epistemic substrate where calibration prose belongs When one or more signals fire, accumulate them into `mismatch_signals` (Set(MismatchSignal)) and carry it into Phase 5; the diff itself is still assembled (the user retains override authority — picking Approve forces prose inscription regardless of the recommendation). Assemble the settled-directions delta in parallel with the profile diff. For each confirmed cluster whose implication names a *settled direction* — a resolution direction observed practice has constituted the same way often enough that re-gating it would be over-gating (commonly an ExtensionMisapplied cluster, where practice auto-resolves what the profile gates) — construct a `SettledDirection` clause: a one-line statement of the direction, the basis (the cluster evidence that settled it), and the originating cluster type. Clusters whose implication is a profile-variable value contribute to the profile diff, not the delta; the two outputs are disjoint per cluster. When no confirmed cluster names a settled direction, the delta is empty and the registry is left untouched at Phase 5. Phase 4 emits no surfacing. The assembled diff and settled-directions delta (with `mismatch_signals` set, possibly empty) become the input to Phase 5. ### Phase 5: Circular Return — Final Approve and Write Present the assembled diff for final user approval. Format: ``` Project Profile Diff — [layer: user_global | project_local] Before (existing profile): : — ... After (proposed profile): : — ... Calibration result delta: Before: After: Settled Directions delta (when non-empty): — basis: (origin: ) ... (one line per settled-direction clause; merged into the registry by clause identity) Conflicting clusters (if any): : vs — needs user choice Backup target (when an existing profile is present; skipped on first-time induction): .bak.YYYYMMDD-HHMMSS Write target: Registry write target (when delta non-empty): (## Settled Directions, adjacent to Northstar; rollback via version control) ``` When `mismatch_signals` is non-empty (Phase 4 fit-shape check fired one or more signals), surface them as text output between the diff presentation and the approval interaction: ``` Fit-shape mismatches detected: — Recommended operational layer: Realization template (if RouteToOperationalLayer is selected): ``` Then propose AI disposition before yielding turn for user constitution: `AI proposed disposition: ` — one-paragraph rationale referencing diff scope, fit-shape signals (mismatch_signals), backup/rollback availability, and why the proposed disposition dominates alternatives. When mismatch_signals is non-empty, the rationale must address whether prose inscription or operational-layer routing better fits the diff. Then present the final approval Constitution interaction. The option set includes RouteToOperationalLayer only when the Phase 4 fit-shape check fired one or more mismatch_signals; otherwise present the first four options only: ``` How would you like to proceed with this diff? Options: 1. Approve — write the proposed profile to ; create backup at first (skipped on first-time induction, when no existing profile is present); also writes the Settled Directions registry when the settled-directions delta is non-empty, and appends this trial to the persistent trial index 2. Modify — adjust specific profile variables and/or settled-direction clauses before write (specify which and how) 3. Reject — discard the diff; the existing profile remains unchan