lamina-design
Shape intended product behavior in Lamina's transactional graph when explicitly invoked as lamina-design or when passive…
Use only when explicitly invoked as lamina-init. Establish business evidence and canonical Product, Actor, and Persona resources in Lamina's transactional graph.
$ npx -y skills add aryaniyaps/lamina --skill lamina-init --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
/lamina-initContext preview
The summary Claude sees to decide when to auto-load this skill.
Use only when explicitly invoked as lamina-init. Establish business evidence and canonical Product, Actor, and Persona resources in Lamina's transactional graph.
name: lamina-init description: "Use only when explicitly invoked as lamina-init. Establish business evidence and canonical Product, Actor, and Persona resources in Lamina's transactional graph."
Before any evidence or graph mutation, read and apply `../lamina/orchestrator/prerequisites/cli-required.md`.
Read `../lamina/orchestrator/audit-profiles.yaml`. Load the `init.always` references, then only those `init.conditional` references whose `when` signal is present. For each selected entry, open the named capability `SKILL.md` and then its exact reference; do not load sibling topics.
For a directory that is not yet a Git project, initialize Git metadata as specified by that prerequisite before writing evidence. Do not ask for or create an initial commit.
Init writes evidence files only under `.lamina/` and canonical knowledge through graphd. It never edits application source.
Write `.lamina/business-context.md` with frontmatter containing `lamina.maturity`, `platform`, and `last_updated`, followed by exactly these non-placeholder sections: Problem statement, Business goals, Success metrics, Scope, Users & market, Product posture, Constraints, Stakeholders, Risks & unknowns, Research posture, Triad check.
Write `.lamina/personas.json` as evidence-source JSON with evidence-grounded personas. Goals, constraints, and evidence are arrays. Do not invent demographics. These files are indexable evidence, not canonical graph state.
Run the shipped init/persona validators when available, then `lamina graph observe` so CocoIndex produces explicit source Observation envelopes. The CLI automatically replaces an incompatible graphd and retries observation once; do not repeatedly rebuild observations to repair daemon compatibility.
If observation exits nonzero after that recovery, treat observation as degraded and optional. Core graph initialization may continue, but do not create Evidence Resources or attach evidence claims for the unavailable snapshot. Do not describe aliases, observation view names, or generation labels as evidence.
When observation succeeds, use `observed.resource_ids` from its output (or the exact `Resource.id` values returned by querying that active observation view) as graph evidence. Never substitute a path alias, source key, view name, or generation for an Observation Resource id.
Start one explicit session. Propose:
Publish atomically. Agents must not submit epistemic class or approval. Never cap Personas. Record the actual returned Resource ids for Product, Personas, Actors, and Evidence; generated canonical Resources normally use `res_*` ids. Do not report input aliases as ids.
All agent-accessible proposal methods use inferred ingress, including `claim.add`. Never select an epistemic class by choosing a method name. Intended knowledge requires a trusted engine-owned intent ingress; until that ingress supplies it, preserve the user's words as provenance and keep the proposal inferred.
Merge changed business evidence, append a dated changelog, rerun observations, and propose new Statements or aliases without replacing stable Resource identity. Preserve conflicting valid facts as Contradictions.
Report canonical graph initialization and observation as separate outcomes. Always report the GraphVersion, source revision, actual Product/Persona/Actor Resource ids, contradictions, and evidence gaps. Install or refresh passive provider rules with `lamina setup --agent <provider>`, then state that future ordinary product requests automatically prepare graph-backed implementation context, complete design gaps, implement, and verify. Do not recommend another slash command.
Only report observation coverage and Observation Resource ids when `lamina graph observe` exited zero and its completion checks passed. After a nonzero observation command, report observation as degraded/unavailable and explicitly state that the published GraphVersion has no current observation-backed evidence. Never claim complete observation coverage on that path.
Headless product design for AI coding agents, backed by a transactional product graph | Design how it works, verify what you ship.
Shape intended product behavior in Lamina's transactional graph when explicitly invoked as lamina-design or when passive…
Judge product usability and evidence quality. Use when running Persona-based walkthroughs on a built product, planning an expert…
Define authoritative runtime product truth across actors and views. Use when modeling domain behavior, setting product density,…
Frame product problems and decide what to build. Use when establishing business context, aligning actors with conflicting goals,…
Plan and synthesize evidence-grounded product research. Use when deciding what evidence is needed, designing actor walkthroughs,…
Reason about causal product systems and change over time. Use when mapping stocks, flows, delays, purposes, or interconnections;…