Use only when explicitly invoked as lamina-init. Establish business evidence and canonical Product, Actor, and Persona resources in Lamina's transactional graph.
npx skills add https://github.com/aryaniyaps/lamina --skill lamina-init
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:
lamina:canAssume Statements between Personas and Actors;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.
Integration with protocols.io API for managing scientific protocols. This skill should be used when working with protocols.io to search, create, update, or publish protocols; manage protocol steps and materials; handle discussions and comments; organize workspaces; upload and manage files; or integrate protocols.io functionality into workflows. Applicable for protocol discovery, collaborative protocol development, experiment tracking, lab protocol management, and scientific documentation.
Analyzes job descriptions and generates tailored resumes that highlight relevant experience, skills, and achievements to maximize interview chances
Generate Excalidraw diagrams from natural language descriptions. Use when asked to "create a diagram", "make a flowchart", "visualize a process", "draw a system architecture", "create a mind map", or "generate an Excalidraw file". Supports flowcharts, relationship diagrams, mind maps, and system architecture diagrams. Outputs .excalidraw JSON files that can be opened directly in Excalidraw.
Build and distribute Expo development clients locally or via TestFlight
Use when you have a written implementation plan to execute in a separate session with review checkpoints
Data structure for annotated matrices in single-cell analysis. Use when working with .h5ad files or integrating with the scverse ecosystem. This is the data format skill—for analysis workflows use scanpy; for probabilistic models use scvi-tools; for population-scale queries use cellxgene-census.
Benchling R&D platform integration. Access registry (DNA, proteins), inventory, ELN entries, workflows via API, build Benchling Apps, query Data Warehouse, for lab data management automation.
Comprehensive molecular biology toolkit. Use for sequence manipulation, file parsing (FASTA/GenBank/PDB), phylogenetics, and programmatic NCBI/PubMed access (Bio.Entrez). Best for batch processing, custom bioinformatics pipelines, BLAST automation. For quick lookups use gget; for multi-service integration use bioservices.
Take aryaniyaps/lamina-init from the repository into ~/.claude/skills for personal
use, or into .claude/skills inside a project.
The agent identifies a skill by the name field in its header. Two skills with the
same name cannot sit side by side — one of them will be ignored.