
Use when writing or reviewing Gherkin features, especially after discovering examples or edge cases that reveal a new business rule
Use when mutation testing reveals survived mutants — guides deep analysis of whether each mutant signals a missing test, a design improvement opportunity, or an equivalent mutation
Pick up ready leaf yaks and implement them — dispatch subagents in isolated worktrees, then merge back to main
Use when designing event-driven architectures, evaluating aggregate boundaries, deciding between event sourcing and current-state storage, building read models, or when a codebase has overlapping domain objects emitting events
Use when a feature feels under-tested, after implementing new functionality, or before a release to discover edge cases, UX issues, and bugs through hands-on CLI exploration
Use when multiple independent leaf yaks are ready to implement and can be worked on concurrently with separate agents in worktrees
Prepare a yak for implementation by establishing spec, acceptance criteria, and breaking into sub-yaks
Use when a yak needs requirements, examples, and a plan before implementation - prepares a yak so it's ready for subagent-driven development
Use when evaluating the ubiquitous language in a codebase - produces a glossary of domain terms with references and commentary on inconsistencies, awkward names, or overlapping concepts
Use when planning work by approaching goals and discovering blockers, before creating comprehensive plans
Use when writing new Gherkin scenarios, refining existing feature files, or reviewing scenarios for clarity - applies BRIEF principles and BDD best practices to craft scenarios that serve as living documentation
Use when running yx commands that create, modify, or delete yaks outside of real project work — provides an isolated temp environment
Use when starting work on a yak - sets up an isolated git worktree, reads yak context, and guides the full cycle from claiming through merge and cleanup
Discover work structure by approaching goals and finding blockers — emergent planning through action, not top-down decomposition