Lamina

/lamina

Use this as the compact Lamina router. The public catalog has four workflow

skills and six capability skills. Load only the entrypoint and topic references

needed for the current request.

Before graph work, read

the CLI prerequisite. /lamina-init

is the one explicit onboarding action. After initialization, ordinary product

implementation language is the primary route.

Workflow routes

• /lamina-init: use lamina-init.
• Ordinary feature, behavior fix, flow refactor, or UI work: prepare the graph

context, complete design gaps with lamina-design,

derive and check the WorkMap, implement, collect evidence, and run

lamina work verify.

• Explicit /lamina-design: use lamina-design as a

graph-only advanced override; never edit application source in that phase.

• Explicit /lamina-verify: use lamina-verify as a

source-read-only advanced override; never edit application source in that

phase.

• Focused product question: select one primary capability below, read its

SKILL.md, then read the smallest relevant topic set before answering. Start

the response with Using <capability>: <topic(s)> so routing is visible and

deprecated focused names are never implied.

Never recommend /lamina-design or /lamina-verify as a next step in normal

flow. Execute the required phase implicitly. Ask a question only when an

unresolved decision would materially change the product contract.

Classify wording by requested action, not by the presence of a product problem:

“help with,” “what should,” “how should,” critique, explanation, or planning

without a request to change repository files is a focused question. Answer it

through capability references without requiring initialization or entering the

implementation workflow. Requests to add, fix, redesign, refactor, or otherwise

change product behavior use the ordinary implementation route.

Focused-question protocol

For a focused question, do not answer from this router alone and do not suggest

the implementation lifecycle. You must:

• Open the selected capability's sibling SKILL.md.
• Open every topic reference needed for the answer.
• Begin the answer with Using <capability>: <topic(s)>.

If the sibling or reference cannot be read, report the missing installed path

instead of improvising its guidance.

Capability routes

| Need | Skill |

|---|---|

| Evidence scope, actor walks, grounding, synthesis, research communication | lamina-research |

| Problem framing, business context, priorities, requirements, tradeoffs | lamina-product-discovery |

| Flows, IA, navigation, forms, content, accessibility, feedback, trust | lamina-ux |

| Invariants, dependencies, consistency, concurrency, time, side effects | lamina-product-behavior |

| Structure, feedback loops, traps, leverage, evolution | lamina-systems |

| Persona usability, heuristic review, quantitative validation | lamina-evaluation |

For detailed signal-to-topic routing, read the

problem router. Old public names are a hard

cutover; use the installed legacy-name lookup to

locate their new capability and topic. Read the optional

glossary only when unfamiliar Lamina or product-design

terminology blocks routing; it is not a second topic index.

Ordinary implementation contract

• Run lamina work prepare without --workflow first. Never invent a

workflow ref; narrow only a genuinely ambiguous result with an exact ref.

• If design gaps exist, run one independent graph-resident Persona walk per

active Persona, union discoveries, expand the graph, and repeat the full

round until every discovery array is empty.

• Run lamina work map, resolve every obligation and Persona-bound Experience

Case to valid implementation and test files, then run lamina work check.

The checked map is immutable.

• Implement the mapped work.
• Reconcile with one-shot lamina graph observe, run and publish every active

Persona Mission, and pass lamina work verify with the unchanged map.

Every current Persona walk covers every operation node, including denied and

inapplicable nodes, and explicitly evaluates authorization, inputs,

relationship identity and cardinality, required states, declared Scenarios,

Invariant probes, transitions, and all required edge-case axes. Graph closure

is authoritative; source retrieval only localizes evidence and code.

Every compiled Experience Case needs one passing oracle event with a structured

observation and reproducible artifact. UI obligations require distinct

functional, visual, responsive, and accessibility evidence. Missing audit

capability blocks verification.

Hard rules

• Ladybug is canonical and graphd is the sole writer.
• Never expose raw Cypher or accept caller-supplied epistemic or approval state.
• Never treat legacy run files, graph dumps, generic screenshots, or broad

mappings as substitutes for current graph and Mission evidence.

• Use sessions for multi-fact design changes and preserve stable Resource

identity.

• Do not cap active Personas.
• Explicit design and verification phases do not edit application source.

Supporting orchestration is internal to this skill under

orchestrator/; it is not a public skill.