// Lightweight triage for the ln-* skill set. Use when unsure which ln skill to use next, starting work on something new, or when the user asks for guidance on their development process.
Crystallize shared understanding into a reviewable spec, or update an existing one. Use when the problem needs a written specification, when assumptions or decisions have changed, or when the user says 'write a spec'.
Explore radically different module shapes before committing to one. Use when choosing an API surface, deciding what a module hides vs exposes, or when the user says 'design it twice'.
Collapse meaningful ambiguity with contrastive examples. Use when a plan/design has several plausible meanings, requirements feel vague, examples would clarify intent faster than grilling, or the user asks to disambiguate, find ambiguity, use behavioral kernels, or ask contrastive questions.
Audit code quality focusing on deep modules, naming, model hygiene, and architectural clarity. Use after a burst of development, when codebase structure needs assessment, or to make code more agent-navigable.
Refresh `memory/SPEC.md` and `memory/PLAN.md` in mature mode — restore canonical truth, archive retired plan history, delete stale derivative artifacts, and flag drift against code.
d3k assistant for debugging web apps
| name | ln-consult |
| description | Lightweight triage for the ln-* skill set. Use when unsure which ln skill to use next, starting work on something new, or when the user asks for guidance on their development process. |
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.
If this is a fresh thread or an unfamiliar area, reload the live context before routing:
memory/SPEC.mdmemory/PLAN.mdHANDOFF.md if presentdocs/archive/PLAN_HISTORY.md only if the current frontier or touched area is still unclearStart the assessment with 2-4 bullets naming:
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.
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:
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.
| 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 |
## Assessment
- [orientation bullet]
- [orientation bullet]
- [1-2 sentences on current state and work classification]
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.