diff --git a/.pi/skills/distill/SKILL.md b/.pi/skills/distill/SKILL.md index 28c69b2..90e069e 100644 --- a/.pi/skills/distill/SKILL.md +++ b/.pi/skills/distill/SKILL.md @@ -870,6 +870,10 @@ If any remain, ask: "Would a stakeholder include this in a requirements doc?" The extracted spec is a starting point. For targeted changes as requirements evolve, use /skill:tend. For checking ongoing alignment between the spec and implementation, use /skill:weed. +## Verification + +After writing any `.allium` file, run `allium check ` if the CLI is available. Fix any reported issues before presenting the result. + ## Syntax rules Before writing any `.allium` file, read `../../allium/references/allium-rules.md` for syntax gotchas, naming conventions and anti-patterns. This covers common model mistakes (e.g. `with` vs `where`, `transitions_to` vs `becomes`, capitalised vs lowercase pipe values) that the language reference does not emphasise. diff --git a/.pi/skills/elicit/SKILL.md b/.pi/skills/elicit/SKILL.md index c275b68..92d8e9b 100644 --- a/.pi/skills/elicit/SKILL.md +++ b/.pi/skills/elicit/SKILL.md @@ -342,6 +342,10 @@ A comment noting that two terms are equivalent is not a resolution. It guarantee For targeted changes where you already know what you want, use /skill:tend. For substantial additions that need structured discovery (new feature areas, complex entity relationships, unclear requirements), elicit is still the right tool even if a spec already exists. Checking alignment between specs and implementation belongs to /skill:weed. +## Verification + +After writing any `.allium` file, run `allium check ` if the CLI is available. Fix any reported issues before presenting the result. + ## Syntax rules Before writing any `.allium` file, read `../../allium/references/allium-rules.md` for syntax gotchas, naming conventions and anti-patterns. This covers common model mistakes (e.g. `with` vs `where`, `transitions_to` vs `becomes`, capitalised vs lowercase pipe values) that the language reference does not emphasise.