Mycelium plugin setup

When this skill runs, do the following sequence. The skill is designed to be safe to re-run — every step is idempotent.

Step 1: Detect initialization state

Check whether the user's project already has Mycelium project-state. The signal that initialization has happened:

test -f "$CLAUDE_PROJECT_DIR/.claude/diamonds/active.yml"

If the file exists, print:

"Mycelium project state is already initialized. Existing canvas, diamonds, and memory are preserved. Run /mycelium:diamond-assess to see current state."

Then exit. Do NOT touch existing files.

If the file does NOT exist, continue to Step 2.

Step 2: Create project-state directory structure

Resolve the project root: use $CLAUDE_PROJECT_DIR if set, else fall back to pwd. (Claude Code sets it automatically; non-Claude-Code agents may not.)

Create these directories in the user's project (using Bash mkdir -p):

<project_root>/.claude/canvas/
<project_root>/.claude/diamonds/
<project_root>/.claude/memory/
<project_root>/.claude/harness/
<project_root>/.claude/evals/
<project_root>/.claude/jit-tooling/

These directories hold project-specific state that the user's project owns and commits to git. Framework reference content (skills, hooks, theory gates) lives in the plugin cache and is not duplicated here.

A .claude/state/ directory may also be present — that one is created and owned by Claude Code itself for runtime state (audit logs, etc.), not by Mycelium. Mycelium does not write to it; if you see it, it's expected.

Important — empty dirs and git: directories that don't get a starter file in Step 3 (canvas/, evals/, jit-tooling/) are empty after Step 2 and would not survive a git commit. Drop a .gitkeep stub in each so they remain in the user's repo:

touch <project_root>/.claude/canvas/.gitkeep
touch <project_root>/.claude/evals/.gitkeep
touch <project_root>/.claude/jit-tooling/.gitkeep

Step 3: Write minimal starter files

Use the Write tool to create each file. Each file gets a small starter content, NOT a full canvas template — the canvas-population skills (/mycelium:interview, /mycelium:canvas-update, etc.) populate them when the user runs them.

Note: these files don't yet exist, so the Read-before-Write convention does NOT apply (it applies only to existing files). Use Write directly.

.claude/diamonds/active.yml

# Mycelium active diamonds state
# Populated by /mycelium:interview on first project-onboarding run.
# See plugin reference for diamond scales (L0 Purpose -> L5 Market).
project_type: ""
dogfood: false
active_diamonds: []
last_updated: null

.claude/memory/corrections.md

# Project corrections

Mistakes the agent made on this project, with prevention rules.
Populated as the project evolves. Read at the start of every task
(per Mandatory Pre-Task Protocol).

Empty until the first correction lands.

.claude/memory/patterns.md

# Project patterns

Successful patterns worth reusing on this project.
Populated as the project evolves.

Empty until the first pattern lands.

.claude/harness/decision-log.md

# Decision log

Significant decisions made on this project, with context, alternatives
considered, theory grounding, evidence, and confidence. Required
structured field: `why_not_alternatives` (per-alternative rejection
rationale, contrastive XAI).

Empty until the first decision is logged.

.claude/harness/warnings-log.md

IMPORTANT — write the file content literally; do NOT expand $CLAUDE_PLUGIN_ROOT. When the Write tool processes the content below, it must preserve $CLAUDE_PLUGIN_ROOT as a literal string (so any user reading the file later sees the variable name, not the maintainer's absolute path). Detected during 2026-05-09 plugin-form dogfood: a previous agent expanded the variable while writing, baking the maintainer's absolute path into every user's warnings-log.md. Use prose in the file body to make path expansion semantically wrong (the file is documentation, not a runnable command).

# Warnings log

Auto-populated by the plugin's `ingest_warnings.py` script from CI signals
(validator/upgrade WARN+FAIL lines). Consumed by
/mycelium:corrections-audit for cross-source pattern detection.

Empty until the ingestor runs.

Step 4: Optionally write AGENTS.md at project root

Ask the user — and give them the basis to decide, not just the menu (per opp-002 decision-without-context pattern). The prompt MUST cover what AGENTS.md is, when it earns its keep, and when it's safe to skip:

"Should I create an AGENTS.md at your project root?

AGENTS.md is the cross-agent-portable instructions file (read by Codex, Cursor, Aider, Copilot, and Claude Code as fallback). It will reference Mycelium plugin discipline.

• Say yes if you use (or might use) other agents on this project — AGENTS.md lets them read the same Mycelium discipline.
• Say no / skip if you use Claude Code only. Mycelium runs via the plugin hooks regardless; AGENTS.md adds nothing in a Claude-only flow and just leaves an extra file at your project root.
• If you already have an AGENTS.md, I'll append a Mycelium reference section instead of overwriting — I won't touch the rest of your file.

Default if you're not sure: skip. You can run /mycelium:setup again later to add it once you know you need it."

Auto-mode default: if running non-interactively (no terminal user to prompt), default to creating AGENTS.md when absent and skipping when present. Never overwrite an existing AGENTS.md without explicit consent.

If yes:

• Check if <project_root>/AGENTS.md exists.
• If absent: write a minimal AGENTS.md template (see template content below).
• If present: prompt before appending. Show the user what would be appended. Append only on explicit yes.

NEVER touch CLAUDE.md, README.md, CONTRIBUTORS.md, or LICENSE. Those are the user's project root files.

AGENTS.md template (when absent)

# AGENTS.md

This project uses [Mycelium](https://github.com/haabe/mycelium) for product-thinking discipline.

The Mycelium plugin ships skills, agents, and hooks that auto-load when Claude Code is run in this project. Cross-agent users (Codex, Cursor, Aider, Copilot) read this file for orientation.

## Project state

Project-specific state lives in `.claude/`:
- `canvas/*.yml` — product knowledge (purpose, opportunities, JTBD, landscape, etc.)
- `diamonds/active.yml` — active discovery/delivery diamonds
- `memory/corrections.md`, `patterns.md` — project learnings
- `harness/decision-log.md` — significant decisions

These are gitted. Read them to orient on the project.

## Framework discipline

Mycelium imposes evidence-gated progression: discovery before delivery, theory gates at every transition, contrastive decision logging, post-task verification. The framework auto-fires via plugin hooks in Claude Code; for other agents, treat this discipline as advisory.

Run `/mycelium:diamond-assess` (Claude Code) to see current state.
For cross-agent guidance: read `.claude/canvas/*.yml` first; act on populated evidence.

AGENTS.md append (when file exists)

---

## Mycelium plugin

This project also uses the [Mycelium plugin](https://github.com/haabe/mycelium). Project-specific state lives in `.claude/canvas/`, `.claude/diamonds/`, `.claude/memory/`. The framework auto-fires via Claude Code plugin hooks; cross-agent users should read canvas state for orientation.

Run `/mycelium:diamond-assess` for current state.

Step 5: Confirmation message

After all writes succeed, build the confirmation by checking what was actually created. Use test -f <project_root>/AGENTS.md to determine whether the AGENTS.md line should appear.

The output has two parts: a short welcome (closes the install→setup void for users who invoked /mycelium:setup directly rather than /mycelium:start),