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:

1. Open the selected capability's sibling SKILL.md.
2. Open every topic reference needed for the answer.
3. 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

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

1. Run lamina work prepare without --workflow first. Never invent a workflow ref; narrow only a genuinely ambiguous result with an exact ref.
2. 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.
3. 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.
4. Implement the mapped work.
5. 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.