From mycelium
Advances diamond through phases: runs theory gate checks, validates evidence, applies cognitive forcing, resolves perspective conflicts, executes DoD checklist.
npx claudepluginhub haabe/mycelium --plugin myceliumThis skill uses the workspace's default tool permissions.
Progress a diamond through phases with full theory gate validation. At delivery completion, runs an executable checklist that GATES progression.
Evaluates current state of a diamond project by checking theory gates, confidence thresholds, anti-patterns, and recommending next action.
Guides 4-step Shape Up process to shape work into pitches for betting. Supports established (fixed time, variable scope) and new product modes for cycle planning and PM coaching.
Share bugs, ideas, or general feedback.
Progress a diamond through phases with full theory gate validation. At delivery completion, runs an executable checklist that GATES progression.
1b. Cognitive Forcing (before gate evaluation):
Before running gates, ask the human for their unprimed judgment:
"Before I check the gates — do you think we're ready to move from [current] to [next]? What's your gut say?"
Wait for the response. Record it. Then run the gates. After presenting results, compare:
"You said [X]. The gates say [Y]. Where do we differ?"
The human's instinct often catches risks the gates miss. If the human says "not ready" but gates pass, investigate — the human may be sensing something the evidence hasn't captured yet.
Source: Buçinca, Malaya & Gajos (Cognitive Forcing Functions, Harvard CHI/CSCW 2021). Applied after Hoskins transcript analysis — Drew's product judgment consistently outperformed the agent's gate-based assessment.
Run all required theory gates (per ${CLAUDE_PLUGIN_ROOT}/engine/theory-gates.md transition matrix):
/skill-name to satisfy this gate."
c. Evaluate pass criteria against available evidence.
d. Record Pass / Fail / Insufficient Evidence.
e. If Fail: document what is missing, recommend the skill to run, and do NOT proceed.CRITICAL — Perspective conflict check (do this BEFORE evaluating any other gate):
Before checking any gate status, read .claude/canvas/opportunities.yml and inspect the Four Risks risk LEVELS for the active solution. Do NOT rely on theory_gates_status.four_risks in active.yml — that only records whether risks are documented, not whether they conflict. You must read the actual value.level, usability.level, feasibility.level, viability.level values.
If TWO OR MORE risk dimensions are rated HIGH, or if perspectives directly contradict each other (e.g., value says "build it" but usability/feasibility say "don't"), this is a perspective conflict — not a simple gate failure. STOP evaluating other gates and jump to step 2b immediately. This takes priority over all other gate checks.
2b. Resolve perspective conflict (if detected in step 2): Do NOT continue to steps 3-6. A perspective conflict must be resolved before any other gate evaluation matters. Follow this procedure:
${CLAUDE_PLUGIN_ROOT}/engine/perspective-resolution.md (value-vs-feasibility, usability-vs-feasibility, value-vs-viability, usability-vs-viability, three-way)./mycelium:assumption-test on the riskiest assumption)The perspective resolution framework (${CLAUDE_PLUGIN_ROOT}/engine/perspective-resolution.md) is the authoritative reference. The anti-pattern to avoid is Perspective Suppression — resolving a conflict by ignoring one perspective.
2c. Build-to-learn awareness NUDGE (Define → Develop transitions only): At the point of entering Develop, surface this prompt to the human:
"Are you building to learn or building to earn right now? Discovery work (prototypes, spikes, experiments) can use lighter gates. Delivery work (shipping to users) must meet full DoD." This is awareness only — it does not change gate requirements or routing. The human's answer is informational context, not a gate input. Source: Cagan (SVPG), Patton (build to learn vs build to earn). Added as NUDGE per risk analysis — conceptual awareness, not process gate.
Calculate confidence:
${CLAUDE_PLUGIN_ROOT}/engine/confidence-thresholds.yml.project_type and dogfood from .claude/diamonds/active.yml.project_type_adaptations from ${CLAUDE_PLUGIN_ROOT}/engine/confidence-thresholds.yml:
effective_threshold = base_threshold * threshold_multiplierdogfood: true: effective_threshold *= dogfood_modifier.additional_threshold_multipliereffective_min_sources = ceil(base_min_sources * min_sources_multiplier)Check human approval requirement:
"Reply yes to advance, no to stay. Re-invoking
/mycelium:diamond-progressis also treated as approval (shortcut). Type evaluate again to re-run gates from scratch."
/mycelium:diamond-progress while a previous invocation is awaiting approval, that re-invocation IS treated as approval — but only because the convention has been surfaced in the prompt above. Without the prompt-line, the behavior is a footgun (corrections.md 2026-05-06 — /mycelium:diamond-progress re-invocation interpreted as approval).Run bias check: Execute bias-check for the current stage.
Run corrections check: Review corrections.md for relevant entries.
6b. Check trio perspective coverage (Torres Product Trio):
${CLAUDE_PLUGIN_ROOT}/engine/theory-gates.md §Trio Perspective Requirement for per-scale guidance.If transition is Deliver -> Complete: RUN EXECUTABLE DoD CHECKLIST (see below)
Decision:
If progressing:
.claude/diamonds/active.yml.${CLAUDE_PLUGIN_ROOT}/engine/wayfinding.md to show the user where they've moved to. This makes the transition visible — the user sees their position shift on the map..claude/harness/decision-log.md. If threshold was adapted, include: "Threshold adapted from [base] to [effective] because project_type=[type]. Would increase with [action].".claude/memory/product-journal.md.If blocked or needs evidence:
.claude/jit-tooling/active-metrics.yml is configured, suggest /mycelium:metrics-pull as one route to strengthen external signal. If .claude/jit-tooling/active-metrics.yml is missing, suggest /mycelium:metrics-detect first. (v0.14: external_data from snapshots satisfies the Evidence gate's behavioral-data criterion but does NOT replace external_human requirements at L2 Develop->Deliver.)Always communicate in plain language:
When transitioning from Deliver to Complete, run this checklist. Items marked REVIEW block progression. Items marked PROMPTED are asked but don't block.
Check product_type from .claude/diamonds/active.yml to determine which auto-checks apply.
For software and ai_tool (code components):
Testing (G-V7 REVIEW):
Type Safety (REVIEW for typed languages):
Linting (REVIEW if linter detected):
For content products (content_course, content_publication, content_media):
Content Quality (REVIEW):
content-metrics.yml#quality_review flags all true? (sme_reviewed, accessibility_checked, fact_checked, style_consistent, learning_objectives_met)For ai_tool:
Eval & Safety (REVIEW):
ai-tool-metrics.yml#prompt_quality fields populated (not null)? Specifically: accuracy_score, consistency_score, safety_score.ai-tool-metrics.yml#prompt_quality.last_evaluated set?For all product types:
Secrets (G-S1 BLOCK):
For user_facing work (G-V2, G-V8, G-V9 REVIEW):
For api_service or permission_requiring work (G-S2 REVIEW):
For data-handling work (G-S3 REVIEW):
Success criteria declared (G-V11 REVIEW):
/mycelium:preflight)?/mycelium:preflight and declare what will be true after delivery and how to verify it."Decision log (G-P4):
BVSSH Quick-Check (Smart -- Fix 6):
Prompt the user/agent with product-type-appropriate questions:
Happier covers four stakeholders (Smart): customers, colleagues, citizens, and climate.
Software:
Content (course, publication, media):
AI tool:
Service offering:
Record in bvssh-health.yml assessment_history
REVIEW: Must answer all 5 (even briefly) before completing
Delivery journal (PROMPTED):
Patterns (PROMPTED):
Retrospective (PROMPTED):
Not every diamond makes forward progress. Sometimes the right move is to reframe, pause, or abandon. /mycelium:diamond-progress handles these paths too, via subcommands:
/mycelium:diamond-progress pivot — reframe the diamond's scope, audience, or JTBD with new evidence/mycelium:diamond-progress park — mark the diamond as inactive-pending-conditions/mycelium:diamond-progress kill — abandon with a documented reasonAll three are sanctioned exits from a stuck diamond. They are not failure modes — they are the system working correctly when evidence tells you the current direction is wrong.
Addresses dogfood report finding T5: "Stop-the-diamond pattern has no escape valve."
Use when evidence invalidates the current framing but the underlying need is still valid. Example: macos-fileviewer pivoted from "replace QuickLook for all devs" to "serve terminal-resistant devs specifically" after mocked-persona findings.
Workflow:
.claude/diamonds/active.yml:
pivot_history entry listing old and new framingsUse when the diamond cannot progress right now but may be revisitable later. Example: "park until I have time to do real user interviews" or "park until upstream dependency X ships."
Workflow:
.claude/diamonds/active.yml:
parkedparked_reason, parked_at, resume_conditions fields.claude/diamonds/active.yml but do not count against WIP limits/mycelium:feedback-review and /mycelium:diamond-assess surface parked diamonds with their resume conditions at session startUse when the diamond cannot be rescued via pivot or park. Example: the opportunity turned out to be imaginary (no real users, no demand), or the solution space has been exhausted, or the project direction has fundamentally changed.
Workflow:
.claude/diamonds/active.yml:
killed_diamonds section (NOT deleted — canvas data is preserved)killed_at, killed_reason, learnings fields.claude/memory/patterns.md and .claude/memory/corrections.md as appropriate.claude/canvas/cycle-history.yml: Killed diamonds are terminal states. Record predicted ICE/effort, actual outcome as "killed", reason, and phase at kill. This feeds adaptive thresholds and pattern detection.When the project has dogfood: true set, stop conditions become Mycelium learnings rather than project deaths. In dogfood mode, a killed diamond generates a dogfood report entry in .claude/evals/dogfood-reports/ instead of only being logged as a project kill. The framework gap caught is the real deliverable.
After EVERY successful transition (not just Deliver->Complete):
Draft entries for the user. Present for confirmation before saving. This captures learning at the moment of discovery, not retrospectively.
Before progressing the diamond OR signing off on a phase transition, draft a one-line counter-argument: "What's the strongest case AGAINST this transition — what gate is borderline, what evidence is weakest, what regression risk is being underweighted?" If you can't articulate one, run /mycelium:devils-advocate before proceeding.
This addresses the bias cluster documented in corrections.md (L5 sycophancy 2026-04-20, eval overfitting 2026-04-30, sharper-framing-isn't-righter 2026-05-03). Common shape: agent prefers what feels right over what evidence supports under competing pressure (be helpful vs. be honest, advance vs. regress). Phase-transition reviews are the canonical context — the agent is incentivized to move forward and may underweight the case for staying or regressing.
Especially important at L4→complete (DoD signoff) and L5 transitions (where the L5-sycophancy correction explicitly named promotional-language drift).