cookoff_skill

Overview

This skill organizes the transition from design to implementation by running parallel implementation teams (a cookoff) or offering single-agent or local options. It ensures each agent generates its own implementation plan from a shared design so genuine variation appears. Use it when a design doc is approved and you are about to start coding.

How this skill works

On trigger phrases like “let's build” or “implement this,” the skill presents three implementation paths: a cookoff (recommended), a single subagent, or local implementation. For cookoff, it assesses complexity, spawns N parallel subagents in a single dispatch message, creates per-implementation worktrees/branches, and enforces plan-first then implement workflows. After implementations finish it diffs outputs, runs fresh-eyes reviews, invokes a scoring judge, verifies the winner, and performs cleanup.

When to use it

• After brainstorming when a design.md exists and the user says “looks good, let's do it”
• When you want multiple independent approaches evaluated against the same design
• When feature complexity or risk merits exploration of different technical choices
• If you need a disciplined workflow: plan → implement → test → verify
• When you want an auditable result directory with plans, implementations, and a winner report

Best practices

• Always start from the design doc; never share a pre-made implementation plan among teams
• Assess complexity to determine N implementations (2–5) and create worktrees/branches per impl
• Dispatch all parallel subagents in one single message to ensure true parallelism
• Require each subagent to run writing-plans then executing-plans and follow TDD/verification before claiming done
• Diff implementations before fresh-eyes; flag >95% identical outputs as planning failure
• Invoke the judge skill with test results and fresh-eyes findings to produce the official scorecard

Example use cases

• Implementing a new auth flow where multiple architectures (component-first, data-layer-first) should be compared
• Converting a design doc for a payments integration into competing implementations to surface edge cases
• Medium-complex features where independent planning reveals trade-offs before merging
• When a team prefers a judged selection workflow with automated verification and cleanup