plan

Generate tasks.md from gherkin or proposal artifacts with multi-role review.

7|3|Updated Mar 5, 2026
One-click install
npx skills add https://github.com/kirkchen/beat --skill plan-kirkchen
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: plan
Source: https://github.com/kirkchen/beat/tree/main/skills/plan
Command: npx skills add https://github.com/kirkchen/beat --skill plan-kirkchen

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Planning Beat changes requires reading spec artifacts, coordinating multi-role reviews, and producing a clear tasks.md to guide implementation. This skill ensures artifacts are broken down into concrete tasks with guardrails before work begins.

Core Features & Use Cases

  • Spec-driven planning: reads gherkin, proposal, and design to surface a concrete task breakdown.
  • Multi-role review orchestration: suggests roles based on complexity; allows adjustment and confirmation.
  • Plan generation with quality guardrails: outputs tasks.md including a Quality Principles section and testing focus.
  • Prerequisite enforcement: ensures at least one spec artifact exists before planning; reads status.yaml to verify readiness.

Quick Start

Invoke /beat:plan after identifying a change to generate the initial tasks.md for beat/changes/<name>.

Frequently Asked Questions about plan

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I break down spec artifacts into actionable implementation tasks?

To break down spec artifacts into actionable tasks, you read gherkin or proposal documents and generate a tasks.md file. This planning process enforces writing-plans guardrails, includes a Quality Principles section, and defines a clear testing focus before implementation begins.

What is multi-role review orchestration for planning a beat change?

Multi-role review orchestration suggests review roles based on change complexity during the planning phase. It allows you to adjust and confirm these roles, ensuring spec artifacts are thoroughly evaluated before generating the final task breakdown.

Do I need a spec artifact before generating a tasks.md file?

Yes, prerequisite enforcement requires at least one spec artifact to exist before planning begins. The system reads status.yaml to verify readiness, ensuring a gherkin, proposal, or design document is present to surface a concrete task breakdown.

How do I start planning a beat change from a gherkin or proposal document?

To start planning a beat change, invoke the plan command after identifying a change. This reads your existing spec artifacts, coordinates multi-role reviews, and generates the initial tasks.md file to guide implementation within the beat/changes directory.

What's the best way to ensure implementation tasks include quality guardrails?

The best way to ensure quality guardrails is to use a spec-driven planning process that enforces writing-plans standards. This automatically outputs a tasks.md file containing a dedicated Quality Principles section and a targeted testing focus.