zak-keown/moe

Use when an iteration has just finished and you need to verify behavior evidence quality in three tiers — deep evidence for current stories, impacted behavior for touched scenarios, and sentinel corpus for high-value regression detection.

You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.

Use when working with Claude Code CLI, plugins, hooks, MCP servers, skills, configuration, or any Claude Code feature - routes to the official documentation instead of guessing, and can cache it locally for offline use

Use when working on Claude Code plugins (creating, modifying, testing, releasing, or maintaining) - provides streamlined workflows, patterns, and examples for the complete plugin lifecycle

Shared vocabulary for designing deep modules. Use when the user wants to design or improve a module's interface, find deepening opportunities, decide where a seam goes, make code more testable or AI-navigable, or when another skill needs the deep-module vocabulary.

Use when facing 2+ independent tasks that can be worked on without shared state or sequential dependencies

Generate or update project documentation verified against the codebase — use when docs are missing, stale, or need an accuracy audit

Build and sharpen a project's domain model. Use when discussing codebase terminology, writing or editing a CONTEXT.md, or recording or editing an ADR.

Use when you have a written implementation plan to execute in a separate session with review checkpoints

Use when starting an iterate run on human spec collateral — reads the spec, produces per-epic requirement files with proof obligations and behavior scenario cards with stable IDs.

Use when auditing a codebase for semantic duplication - functions that do the same thing but have different names or implementations. Especially useful for LLM-generated codebases where new functions are often created rather than reusing existing ones.

Use when implementation is complete, all tests pass, and you need to decide how to integrate the work

Use when a review report already exists and its findings need working off — a CODEBASE-REVIEW.md, an inherited audit, or any list of defects someone else wrote that now has to become commits

Use when executing a batch of TDD-sized tasks inside a run-iteration call — dispatches an implementer subagent per task following red-green-refactor discipline and returns per-task completion status.

Scan a codebase for deepening opportunities, present them as a visual HTML report, then work through whichever one you pick.

Use when implementing a project with a large, comprehensive, or ambiguous spec — extracts requirements with proof obligations, defines a walking skeleton with its first journey scenario, then loops through audited sprints that continuously build a behavior evidence corpus. Completion means passing evidence, not just finished stories.

Use MCP servers on-demand via the mcp CLI tool - discover tools, resources, and prompts without polluting context with pre-loaded MCP integrations

Use when merging, rebasing, cherry-picking, or otherwise integrating one line of work into another — before treating the operation as done, verify the result and own any lint or test failure it surfaces, whether or not the failure traces to your own changes

Use when planning, implementing, or reviewing any feature or change to the Moe project itself — enforces integration-completeness and multi-harness awareness as non-negotiable development constraints

Use during any implementation task to shape HOW you work — minimal changes, proportional responses, scope containment, and honest gap reporting; fires alongside the task itself rather than at completion time

Build a throwaway prototype to answer a design question. Use when the user wants to sanity-check whether a state model or logic feels right, or explore what a UI should look like.

Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation

Use when completing tasks, implementing major features, or before merging to verify work meets requirements

Use when you need to resolve an in-progress git merge, rebase, or cherry-pick conflict — <<<<<<< markers are present, or git status shows unmerged paths.

Use before answering any question about code, conventions, ownership or past decisions that is not already on disk in front of you — routes the question to the right retrieval backend, on a token budget, and decides where what you learn gets written back

Use when reviewing a whole repository rather than a diff — an inherited codebase, a pre-release sweep, a security pass, or any request to find what is wrong across a tree too large to hold in one context

Use when executing the next pending iteration from an iterate roadmap — picks the iteration, decomposes into code and evidence tasks, runs sentinel corpus baseline, dispatches implement-tasks, runs impacted + sentinel scenarios, and updates artifacts.

Use when turning extracted requirements into a roadmap — selects the walking skeleton iteration with its first journey scenario, orders remaining work into follow-on iterations, and applies story splitting when ACs have different dependency profiles.

Use when executing implementation plans with independent tasks in the current session

Use when a project has more than one plan and you need to know which is runnable next — reads a committed manifest, runs a Kahn topological ready-set, and dispatches one plan at a time. Do NOT use for intra-plan step order (that is write-plan and sdd) or for greenfield spec work (that is iterate).

Use when a developer wants to reduce repeated agent permission prompts, audit permanent tool permissions, or inspect recent Claude Code and Codex sessions for safe allow rules

Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes

Use when implementing any feature or bugfix, before writing implementation code

Use when you need to run interactive CLI tools (vim, git rebase -i, Python REPL, etc.) that require real-time input/output - provides tmux-based approach for controlling interactive sessions through detached sessions and send-keys

Use when starting feature work that needs isolation from current workspace or before executing implementation plans - ensures an isolated workspace exists via native tools or git worktree fallback

Use when starting any conversation - establishes how to find and use skills, requiring skill invocation before ANY response including clarifying questions

Use when about to claim work is complete, fixed, or passing, before committing or creating MRs - requires running verification commands and confirming output before making any success claims; evidence before assertions always

Create, manage, or connect to a headless Windows 11 VM running in Docker with SSH access. Use when the user wants to spin up, stop, restart, or SSH into a Windows VM.

Apply Strunk's timeless writing rules to ANY prose humans will read—documentation, commit messages, error messages, explanations, reports, or UI text. Makes your writing clearer, stronger, and more professional.

Use when you have a spec or requirements for a multi-step task, before touching code

Use when creating new skills, editing existing skills, or verifying skills work before deployment