Register REVIEW.md and PROPOSE.md as skills for design panel access

[tburny]

Problem

The allium plugin ships with a sophisticated 9-member design review panel (TEAM.md) and two prompt templates that invoke it (REVIEW.md for fixes, PROPOSE.md for features). However, neither REVIEW.md nor PROPOSE.md is registered as a skill in the marketplace manifest.

The installation page documents three slash commands: /allium, /allium:elicit, and /allium:distill. These map to the three entries in marketplace.json:

"skills": [
  "./plugins/allium",
  "./plugins/allium/skills/distill",
  "./plugins/allium/skills/elicit"
]

There is no way for a user to trigger the design review panel via a skill invocation. The TEAM.md debate protocol, REVIEW.md, and PROPOSE.md are unreachable reference files from the user's perspective.

Expected behaviour

Two additional skills registered in the manifest:

Skill	File	Trigger
allium:review	REVIEW.md	/allium:review — convene the 9-member panel on a proposed fix
allium:propose	PROPOSE.md	/allium:propose — convene the 9-member panel on a proposed feature

Each would need SKILL.md-style frontmatter (name, description, keywords) and an entry in marketplace.json's skills array.

Current workaround

None via skill invocation. A user would have to manually read REVIEW.md/PROPOSE.md and paste the prompt, which defeats the purpose of the plugin system.

Context

Discovered while using allium v1 (commit 29dbf9ddd532) installed via the JUXT plugin marketplace in Claude Code.

[henrygarner]

Thanks for the detailed write-up. The design review panel exists to debate changes to the Allium language itself, not to specification files. TEAM.md, REVIEW.md and PROPOSE.md are development tools for people working on Allium's syntax and semantics, not part of the plugin's user-facing surface. Exposing them as skills would imply they're part of the normal spec-writing workflow, which would be misleading.

If you're working on Allium directly (e.g. in a checked-out branch of the repo), you can convene the panel with a prompt along the lines of:

Read PROPOSE.md and TEAM.md. Create an agent team to debate the proposal: [your proposal]

That said, I'm curious what drew you to the panel. If you're finding that you want a structured review process for your own specs, that's an interesting signal worth understanding, even if the language governance panel isn't the right mechanism for it.

[tburny]

If you're finding that you want a structured review process for your own specs, that's an interesting signal worth understanding, even if the language governance panel isn't the right mechanism for it.

That is exactly the case. I am currently developing https://www.weltenwanderer.dev/ and I am writing lots of new features each day. What I did is: Given the existsing requirements I want to implement this new feature. I want to convene the review panel to get different perspectives on its implementation, given the allium spec.

OT: Other use cases I have:

• alium-expert agent whose sole responsiblity is to manage allium files (e.g. reviewing and updating them, identifying gaps etc.). For that I added a rule matching on .allium files (use the agent, load the skill)
• Modeling the development process, describing the CI/CD process or the documentation structure, as it prevents AI drift.
• Drift detection between allium and implementation

I also learned the hard way that it worked too good to misuse allium for project management (e.g. managing roadmap and issues until I replaced it with a real workflow yesterday).

If you want I can send some PRs and we can have a discussion