mostalive/pi-allium-port
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

phase 6: add allium check verification to elicit and distill

Browse Source 
- Add 'Verification' section instructing model to run 'allium check <file>'
  after writing .allium files
- Applies to elicit and distill (tend/weed already had it from phase 5)
This commit is contained in:
Willem 2026-04-23 14:19:10 +01:00 committed by Willem van den Ende
parent 9cebc8321c
commit 98e458022d
2 changed files with 8 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
.pi/skills/distill/SKILL.md
View File

@ -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. 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 <file>` if the CLI is available. Fix any reported issues before presenting the result.
## Syntax rules ## 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. 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.

4
.pi/skills/elicit/SKILL.md
View File

@ -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. 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 <file>` if the CLI is available. Fix any reported issues before presenting the result.
## Syntax rules ## 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. 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.