Lamina dependencies
Map prerequisite, data, lifecycle, and reachability dependencies between typed product-graph nodes, including explicit behavior when a dependency is unmet.From its SKILL.md
npx -y skills add aryaniyaps/lamina --skill lamina-dependenciesAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
SKILL.md
1.6 KB, 321 tokens by cl100k_base, as published. Nobody here has run it
Dependencies
Use top-level dependencies[] when one product behavior relies on another node. Dependencies prevent silent happy paths when setup, ownership, state, or another workflow is missing.
{
"id": "accept-requires-live-invite",
"type": "prerequisite",
"from": "workflow.accept-invite",
"to": "entity.invitation",
"required_state": "pending",
"unmet_behavior": "Reject acceptance, explain expiry or prior use, and offer a new invitation path",
"criticality": "critical",
"source": "derived",
"confidence": "high",
"relevance_reason": "The workflow cannot succeed without a pending invitation"
}
Procedure
- Inspect every critical workflow and relationship.
- Add only dependencies that change reachability, fidelity, lifecycle, or recovery.
- Use typed
fromandtoreferences. - State observable
unmet_behavior; do not use vague precondition prose. - Add one scenario with a distinct
risk_keywhen the unmet behavior materially affects the product. - During verification, force the unmet state and confirm the product blocks, degrades, or recovers exactly as contracted.
- For timezone data, schedulers, identity, delivery, storage, or runtime-version-specific APIs, name the current-slice adapter/runtime, owner, activation path, health check, cadence/tolerance, and fail-closed production posture.
Avoid infrastructure/vendor dependencies unless they alter user-visible product behavior.