skills

Use when the user asks to generate, compose, design, or orchestrate a multi-agent workflow, wants a dynamic workflow built on the fly, or names a baseline like ping-pong or no-mistakes as the shape a workflow should follow. Provides composable baseline workflow definitions - the ping-pong build loop, the no-mistakes ship gate, and cross-cutting workflow primitives (goal anchors, evidence rules, gate semantics, refusal, tier routing, durability) - plus a copy-ready example composition.

Use when the user wants an HTML discussion artifact — a page generated and revised over the life of a conversation. Best for planning a feature, comparing options, surfacing decisions with options grids, recapping analysis, dogfooding a design. Pages save to docs/discussions/<YYYY-MM-DD>-<slug>.html with a sibling .json manifest as source of truth. Sections are byte-addressable by ID via shell scripts in bin/, so revisions cost ~10 tokens each instead of re-reading a 30KB file. Every page has a built-in review mode - the user selects text or sections, comments, and pastes a section-addressed feedback block back into chat for revision. Not a build system; not for one-shot diagrams that never get revised.

Use when creating temporary scripts, debug artifacts, or one-off investigation files in a project (they belong in the project-local `.scratch/` folder), when the user asks what `.scratch/` is for, or when deciding whether to delete, keep, or promote ad-hoc work into committed project code.

Use in any subagent whose frontmatter sets memory to project, user, or local. Observational memory discipline: captures what was learned each invocation as dated bullets in MEMORY.md, compressing via a reflection pass before the file hits the 200-line harness injection cliff. Mirrors the working_memory style: priority-emoji bullets, date grouping.

Test-first pair programming with an independent auditor, for autonomous execution of implementation work. Point it at a task, a list of tasks, or a plan with scoped scenarios — the lead decomposes as needed and dispatches a per-scenario trio (pp-ping = navigator, writes the failing test; pp-pong = driver, implements to green; pp-auditor = QC). Use when the user invokes /ping-pong, asks to execute a plan or task list autonomously with TDD discipline, wants implementation with built-in independent review, or when prior attempts produced premature-done or wrong-diagnosis loops.