jason-hchsieh

Bootstraps new or existing projects with .mycelium/ workflow structure using progressive disclosure. Follows critical interactive rules (one question per turn, suggested answers, max 5 per section). Use when user says "setup mycelium", "initialize project", or when starting a new project. Git is optional but recommended for parallel features.

Resumes interrupted workflow from last checkpoint with context-aware scope detection. Use when user says "continue", "resume work", "keep going", "finish this", or after interruption. Supports --full to run all remaining phases (plan→work→review→capture) and --track to switch between multiple plans. Auto-detects whether to finish current phase or run full workflow.

Executes complete autonomous development workflow from planning to knowledge capture. Use when user says "build [feature]", "implement [functionality]", "fix [bug]", "debug [issue]", "investigate [problem]", "optimize [component]", or asks technical questions requiring systematic solution. Handles feature development, debugging, investigation, and optimization with full plan → work → review → capture cycle.

Creates structured implementation plans with TDD task breakdown, dependency management, and capability assignment. Use when user says "plan this", "create a plan for [task]", "break down [feature]", "how should we implement [x]", "list all plans", or "switch to [plan]". Assigns best-fit agent, relevant skills, and model tier to each task using cached capabilities from context loading phase (Phase 0).

Captures learnings from completed work to grow the knowledge layer. Use when user says "capture this", "document learnings", "save what we learned", or after finalizing work. Stores solutions, decisions, conventions, preferences, anti-patterns, and effective prompts. Does NOT handle commits, PRs, or pattern detection (see mycelium-finalize and mycelium-patterns).

Asks clarifying questions ONE at a time to understand user requirements, using cached capabilities from context loading. Use when user says "clarify this", "what do you need to know", "ask me questions", or when requirements are ambiguous. Determines if external research (Phase 1.5) is needed before planning.

Loads project context, institutional knowledge, and discovers all available capabilities (skills, agents, MCPs). Use when user says "load context", "discover capabilities", "what skills are available", or at the start of any workflow. Caches discovered capabilities in state.json for use by planning phase.

Creates git commit with Co-Author and pull request to finalize completed work. Use when user says "commit this", "create PR", "finalize changes", or after review passes. Handles platform detection (GitHub/GitLab/Gitea) and uses appropriate CLI tools (gh/glab/tea).

Quick, zero-friction input. Save any content into the inbox for later processing. Use when the user wants to capture a thought, article, URL, image, or any content.

Process inbox items into the knowledge base. Compiles raw inputs into wiki pages, extracts actions, classifies into PARA. Use when the user wants to process inbox items.

Health check the knowledge base. Finds contradictions, orphans, stale info, missing pages, and completed actions. Use when the user wants to maintain wiki quality.

Answer questions using the knowledge base. Searches the wiki index, reads relevant pages, and synthesizes answers with source citations. Use when the user asks a question about their knowledge base.

Generate weekly or monthly review reports. Analyzes log.jsonl, actions progress, and knowledge growth. Use when the user wants a periodic review.

Quick read-only dashboard showing inbox count, top actions, last review date, and knowledge base stats. Use when the user wants an overview.

Snapshot the current belief state (and optionally git-stash the working tree) under a label, so a risky action can be rolled back if it produces high surprise or breaks acceptance tests.

Given a goal and a set of candidate next actions, rank them by Expected Free Energy (pragmatic + epistemic value) using past similar episodes, and pick the winner. Delegates scoring to the policy-selector subagent.

Record an explicit predicted observation before a side-effecting tool call. Use whenever you are about to run a command, edit a file, or invoke any tool whose outcome you have not already observed. Upholds the predict-before-act invariant.

Run a cheap, reversible real probe to ground a belief instead of hallucinating. Use when dreamer confidence is low or when you catch yourself guessing about repository state.

Surprise-triggered reflection. When a PostToolUse hook reports high prediction error (surprise >= 0.6), invoke /reflect to update beliefs via the belief-reviser and decide whether to continue, replan, reclarify, or ask the user.

Read inline code review comments left by a human reviewer in the browser, then apply the requested fixes. Comments carry a scope (line / file / multi-file / view), one or more anchors (file + optional line range + blobSha + anchorText), and a viewContext saying which view the reviewer was in (tool-call / git-range / browse). Use when the user asks to "fix review comments", "apply review feedback", "read the review", or "address comments". Requires the code-review MCP server to be connected.

Print a one-screen situational summary of the current code review state — open vs resolved comment counts, the files most-commented-on, recent reviewer activity, orphan tool calls, and threads where Claude has replied but the human hasn't acknowledged. Use when the user asks "what's the review status", "any open comments", "where am I in the review", "summary of the queue", "anything pending", or just wants to pick the work back up after a break. Read-only — does not edit files, reply, or resolve.

Read every open code review comment, group them by risk / file / theme, and present a phased fix plan for the user to approve before any edits run. Use when the review backlog is large (rough cutoff ≥ 5 open comments), when the user says "triage the review", "plan the fixes", "what's the plan for the review backlog", "group these comments", or before invoking review-workflow on a big batch. Requires the code-review MCP server to be connected. Read-only — does not edit files or call mark_resolved.

Use this skill when the user wants to set up ntfy notifications for claude-ntfy. Triggers on requests like "set up ntfy", "configure notifications", "initialize ntfy", or "setup notification server". Supports both new server setup and configuration of existing servers.

Use this skill when the user wants to test, verify, or debug their ntfy notification setup. Triggers on requests like "test notification", "send test message", "verify ntfy works", or "check notification setup".

Use when the user wants to CREATE, AUDIT, or IMPROVE a Claude Agent Skill. Create scaffolds a new SKILL.md. Audit runs the R01-R20 rubric and emits severity-tagged findings. Improve applies fixes from an audit report. Mode is the first argument.