phase 4: fold in allium rules content

- Symlink allium-main/.claude/rules/allium.md into references as allium-rules.md
- Add 'Syntax rules' section to elicit, distill, and propagate skills
- Instructs model to read rules before writing .allium files

.claude/settings.local.json

@@ -0,0 +1,25 @@
+{
+  "permissions": {
+    "allow": [
+      "WebFetch(domain:raw.githubusercontent.com)",
+      "WebFetch(domain:github.com)",
+      "WebSearch",
+      "Bash(curl:*)",
+      "Bash(python3:*)",
+      "Bash(gh api:*)",
+      "WebFetch(domain:api.github.com)",
+      "WebFetch(domain:deepwiki.com)",
+      "WebFetch(domain:www.agentpatterns.ai)",
+      "Bash(pi:*)",
+      "Bash(/Users/willem/.local/share/mise/shims/pi:*)",
+      "Bash(npx --yes pi --version)",
+      "Bash(git clone:*)",
+      "Bash(test:*)",
+      "Bash(ln:*)",
+      "Bash(chmod:*)",
+      "Bash(bash:*)",
+      "Bash(git ls-remote:*)",
+      "Bash(node --version:*)"
+    ]
+  }
+}

.pi/skills/distill/SKILL.md

@@ -870,7 +870,12 @@ 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.
 
+## 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.
+
 ## References
 
 - [Language reference](references/language-reference.md), full Allium syntax
 - [Worked examples](references/worked-examples.md), complete code-to-spec examples in Python, TypeScript and Java
+- [Allium rules](../../allium/references/allium-rules.md), syntax gotchas and anti-patterns

.pi/skills/elicit/SKILL.md

@@ -342,7 +342,12 @@ 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.
 
+## 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.
+
 ## References
 
 - [Language reference](references/language-reference.md), full Allium syntax
 - [Recognising library spec opportunities](references/library-spec-signals.md), signals, questions and decision framework for identifying library specs during elicitation
+- [Allium rules](../../allium/references/allium-rules.md), syntax gotchas and anti-patterns

.pi/skills/propagate/SKILL.md

@@ -199,6 +199,10 @@ When generator specs are available, use them to produce valid test data:
 - For invariants, generate states that exercise boundary conditions
 - For config parameters, use declared defaults unless testing overrides
 
+## Syntax rules
+
+When reading `.allium` specs, be aware of the syntax distinctions documented in `../../allium/references/allium-rules.md`. This covers `with` vs `where`, `transitions_to` vs `becomes`, capitalised vs lowercase pipe values, and other gotchas that affect correct interpretation of the spec.
+
 ## Interaction with other tools
 
 - /skill:distill produces specs from code. Those specs feed propagate.

turn-limit-repo

@@ -0,0 +1 @@
+Subproject commit cab445e60346bd57ea0999af71555fdb29db28fd