tpm-workflow

Use when validating TUI or CLI behavior end-to-end via tmux. Provides the canonical pattern for spawning any terminal application inside tmux, sending keystrokes or shell commands, capturing pane output as plain text, and asserting on screen state. Works for full TUI apps (ratatui, bubbletea, etc.), interactive CLIs (REPLs, prompts), and non-interactive CLIs whose output needs visual inspection beyond what stdout parsing gives you.

Transform vague acceptance criteria into concrete, machine-verifiable checks. Required for the planner agent when writing task ACs.

Use when the orchestrator needs to resolve any mode-sensitive decision for the current TPM task — which reviewer dispatch pattern to invoke, how to aggregate verdicts, whether to run merge-resolver and QA, what to name Step 6b cleanup sessions. Encapsulates ALL fast / standard / prod tier policy so the orchestrator stays lean and `skills/dispatch-session/` stays mechanism-only. Required for the orchestrator agent at every tier-variant branch point.

Use when spawning a new agent session via Agent of Empires (AoE). Provides the canonical command patterns for spawning planner, implementer, reviewer, and merge-resolver sessions with the correct system prompts, worktrees, groups, and per-session event monitors. Required for the orchestrator agent.

Structured ideation skill for the planner agent. Explores alternative architectures, surfaces tradeoffs, and identifies constraints before committing to a decomposition. Invoked in standard/prod tiers; skipped in fast tier.

Use to discover a target repo's engineering philosophy from its on-disk conventions (CLAUDE.md + .claude/skills/**/SKILL.md). Required for the Principal Engineer agent in prod tier; invoked at the start of its review so findings can be grounded in the repo's own rules rather than reviewer opinion.

Use when reviewing code changes adversarially. Three-layer review with information asymmetry — Blind Hunter (diff only), Edge Case Hunter (diff + code access), Acceptance Auditor (diff + spec). Required for the Blind Hunter / Edge Case Hunter / Acceptance Auditor agents and invoked transitively by the orchestrator when dispatching reviewers.

Use when reading a SUMMARY.md or REVIEW.md to identify long-term-valuable insights worth committing to project or user memory. Required for the orchestrator agent after each task completion.

Use when decomposing a feature into tasks that can be executed in parallel by independent sessions. Identifies file overlap, dependency chains, and assigns tasks to execution waves. Required for the planner agent.

Use when implementing tests for a feature. Guides test strategy across unit/integration/e2e layers based on what the feature does. Required for the implementer agent.