hashintel 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:
memory/SPEC.mdmemory/PLAN.mdHANDOFF.mdif presentdocs/archive/PLAN_HISTORY.mdonly 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.