Ln Consult

Assess where the user is, classify the work, and suggest the next ln-* skill.

If context is unclear, ask one clarifying question — then recommend.

The canonical rule is simple: durable planning state lives only in memory/SPEC.md and memory/PLAN.md, and new or uncertain work defaults to the canonical flow until a narrow exception is clearly justified.

Do not invent new planning documents, sidecar ledgers, or alternate storage locations without explicit user permission. If a fact matters beyond the current step, reconcile it into memory/SPEC.md or memory/PLAN.md; if it is temporary transfer state, keep it in HANDOFF.md; if it is a temporary multi-card execution queue inside one frontier item, keep it in memory/CARDS.md; if it is a temporary refactor execution plan, keep it in memory/REFACTOR.md. Derivative files stay live only while they still carry unfinished work.

Orient, then classify.

Fresh-thread re-entry

If this is a fresh thread or an unfamiliar area, reload the live context before routing:

1. memory/SPEC.md
2. memory/PLAN.md
3. HANDOFF.md if present
4. docs/archive/PLAN_HISTORY.md only if the current frontier or touched area is still unclear

Start the assessment with 2-4 bullets naming:

• the containing seam or subsystem
• the active frontier item or nearby priority
• volatile state or manual follow-up from handoff
• the main open risk

Work-type classification

Classify the request before routing.

Work type	Signals	Default handling
Structural	New seam, new boundary, durable architectural choice, invalidates assumptions	ln-spec / ln-plan / ln-scope as needed
Bounded feature	New capability inside settled seams	ln-scope with a light scope card, then ln-build
Hardening	Dependency audit, fixture work, perf, tooling upkeep	direct ln-build only if the seam is already settled and scope is obvious; otherwise ln-scope
Bugfix	Regression or incorrect behavior inside known seams	direct ln-build only if the seam is settled and reconciliation is likely to be a no-op
Refactor	Rename, extract, restructure without changing behavior	ln-refactor

If the work crosses more than two seams, changes a requirement, or would change future planning if it went differently, promote it to structural.

If you cannot name the containing seam from the live docs, treat the work as structural until proven otherwise.

Presume structural on a fresh thread when the work touches workflow closure, routed layout ownership, persistence schema, knowledge-graph behavior, observer sync, or transport contracts.

Canonical flow

Default rule:

ln-grill or ln-disambiguate → ln-spec → ln-plan → optional ln-design / ln-oracles → ln-scope → optional ln-spike → ln-build → ln-review → optional ln-refactor / ln-sync

Bounded exception:

ln-scope → ln-build

Bounded serial exception:

ln-scope → ln-build → commit → ln-build ... inside one already-settled frontier item, optionally with the prepared queue persisted in memory/CARDS.md

Direct-build exception:

ln-build

Only recommend the bounded or direct-build exceptions when all of these are true:

• the containing seam is already named in the live docs
• no durable requirement / assumption / decision / invariant change is expected
• post-build reconciliation can plausibly be a no-op

Only recommend the bounded serial exception when those same conditions hold and the next several commit-sized steps are obvious enough to queue without fresh planning.

Routing table

Situation	Work type	Suggest
Idea is vague, needs fleshing out	structural	ln-grill
Plausible interpretations diverge; examples would clarify faster than open-ended questioning	structural	ln-disambiguate
Understanding exists, needs a written spec	structural	ln-spec
Spec exists, needs work sequencing	structural	ln-plan
Verification strategy is the main uncertainty	structural	ln-oracles
Next work item needs precise boundaries	structural or bounded	ln-scope
One settled frontier item needs several small verified commits in sequence	bounded, hardening	ln-scope then serial ln-build loop, optionally via memory/CARDS.md
Module interface needs exploration	structural	ln-design
Full or light scope card exists, ready to code	bounded, hardening, bugfix	ln-build
Technical uncertainty blocks progress	any	ln-spike
Code works but needs restructuring	refactor	ln-refactor
Code works but quality / architecture needs audit	any	ln-review
Docs are stale, overweight, or milestone context needs cleanup	structural / maintenance	ln-sync
Session is ending or context is getting fragile	any	ln-handoff

Output

## Assessment
- [orientation bullet]
- [orientation bullet]
- [1-2 sentences on current state and work classification]

Routing

After assessment, present the top 2–3 relevant options from the routing table to the user (use tool-ask-question). Mark the best fit as recommended. If two skills are clearly sequential (for example ln-scope then ln-build), note the sequence in the recommended option's description.