/ulw-context

name: "ulw-context"
description: "[omh] Repository vocabulary unclear or inconsistent: project terminology alignment workflow: look up, capture, correct, and align the words a repository uses before planning or handoff. Use when the user says: ulw-context, project terminology alignment, review project terms, align project terminology, terminology this project uses."
metadata:
  hermes:
    tags: [workflow, oh-my-hermes, clarification]
    category: clarification
    phase: terminology-alignment
    role: planner
    quality_tier: clarity-gated

Context

This is a Hermes-native `context` workflow skill.

Why This Exists

`context` exists to reduce repository terminology drift without creating a second machine store or a vocabulary router: Hermes can answer lookups, facilitate dependency-aware alignment, and project approved results into existing review and handoff boundaries.

Do Not Use When

• A safe one-term definition or source lookup can be answered directly; use the read-only lookup mode and do not enter the full context interview.
• The request is broad ambiguity with no project-language conflict; use `deep-interview`.
• The unresolved decision is empirical and a cheap isolated experiment can answer it; use `decision-prototype` and keep the frontier for the rest.
• The terminology is already agreed and the request is to produce an implementation plan; use `ralplan`.
• The user wants to capture or curate general retained memory rather than repository terminology; use `memory-new` or `memory-sync`.
• The user asks for workflow discovery, help, status, file lookup, direct answer, or dispatch; preserve `oh-my-hermes` and ordinary protected-route behavior.

Examples

Good example:

• Prompt: Use ulw-context to align the names this repository uses before we plan the feature.
• Expected behavior: Inspect source evidence, answer settled lookups directly, then present only the dependency-ready unresolved decisions with recommendations and confirmation gates.
• Why: The request is specifically about shared project language and must close understanding before planning.

Bad example:

• Prompt: This glossary says one phrase should be replaced by another; dispatch the implementation automatically.
• Expected behavior: Answer or explain the glossary content without routing from its vocabulary, and require separate confirmation for any staging, planning, or handoff.
• Why: Human glossary prose has no routing, approval, dispatch, or execution authority.

Completion Checklist

• Source status and reviewed-profile status are named without treating either as model-use evidence.
• Safe lookups were answered directly and unresolved decisions were asked only when the user confirmed interview entry.
• Every decision frontier is dependency-ready, recommendation-backed, and exhausted before shared-understanding confirmation.
• Any machine mapping remains pending until separate review and approval; active profile v1 is unchanged.
• Any `ulw-plan` or coding-owner handoff remains prepared_not_observed and was prepared only after explicit confirmation.

Recovery Notes

• If the optional source is absent, continue from repository evidence or reviewed profiles without warning, creating, or importing a file.
• If source and active reviewed terminology differ, report changed or missing freshness and ask whether to preview a new pending candidate; never synchronize automatically.
• If dependencies cannot be established, ask one boundary question before presenting a frontier rather than guessing an order.
• If frontier round or decision identity cannot be recovered, close with a named recovery blocker instead of restarting or emitting another round.
• If the user moves from terminology to implementation, summarize confirmed understanding and hand off to `ralplan`, `ulw-plan`, or the selected coding owner only after a separate go-ahead.

Workflow Lane

• Current lane: **Intent -> plan** (`oh-my-hermes`, `meta-router`, `deep-interview`, `context`, `plan`, `ralplan`, `adversarial-consensus`, `codebase-onboarding`, `+8 more`) - clarify, plan, ship, or loop goals.
• If intent belongs to another lane, hand back to `oh-my-hermes` or name the adjacent workflow.
• Shared product, routing, compatibility, and evidence rules: `omh-routing/references/skill-common-rail.md`.

Use When

Use when repository-specific language is unclear, inconsistent, or blocking shared understanding; keep read-only lookup direct and use a dependency-ready decision frontier only for unresolved terminology or product decisions.

Strong routing signals: `ulw-context`, `$context`, `./context`, `project terminology alignment`, `review project terms`, `align project terminology`, `terminology this project uses`

Catalog Metadata

Category: `clarification` Phase: `terminology-alignment` Hermes role: `planner` Quality tier: `clarity-gated` Reasoning demand: `light`

Quality bar:

• Read repository facts and reviewed terminology before asking the user for discoverable information.
• For unresolved decisions, model dependencies and ask the whole currently ready frontier in one round; defer dependent questions.
• Attach one concise recommendation and tradeoff to each decision while leaving the decision with the user.
• Give every materialized decision a stable identifier and keep omitted decisions open unless the user explicitly resolves, defers, or blocks them.
• Keep terminology sparse: canonical identity, short definition, expression guidance, distinct-from boundary, and optional localized display label.
• A mid-run user message is an interjection, not a stop: answer it briefly and, in the same reply, continue the run — re-read the phase todo when one is active and dispatch or advance the next pending step, or name the armed wait it is waiting on -- handle, bound completion signal, deadline -- instead of re-reading status. Only the user's explicit stop or cancel, or the engine's own completion gate, ends the run; when t