Up & Running with GitHub Spec Kit #5 - The /plan Command

Overview

The video explains the GitHub Spec Kit /plan command as the next stage after the earlier commands—constitution, specify, and clarify—with the goal of turning a finalized feature spec into a concrete implementation plan.

Key workflow guidance (before planning)

• After running the earlier Spec Kit commands, read through the spec and ensure it’s correct before you start planning.
• If edits are needed, do them now (manually or by asking the coding agent), because later planning/research/task generation will be based on the spec.
• Planning begins only when the spec is considered “polished” and unambiguous.

Using /plan and what to include

• Planning starts via the command: /plan (slash + plan), with optional details specifying implementation choices.
• The plan prompt is described as the place to outline technical implementation details, such as:
  • CSS/UI stack (example: Tailwind + shadcn UI components)
  • Theme configuration (example: Tailwind theme colors)
  • Data persistence approach (example: local storage)
  • Date utilities (example: date-fns for date formatting)
  • Testing expectations (example: no unit tests / integration tests / E2E tests)

What the plan prompt/automation does internally

Before generating the plan, the presenter shows the “setup plan” script and planning prompt logic. Main behaviors:

• A helper gathers relevant file/folder paths (repo root, current branch, feature directory/spec file, etc.).
• The script checks that you’re on a feature branch; otherwise it exits.
• It copies a plan template into the feature directory.
• The planning prompt instructs the coding agent to:
  1. Pause and ask about any unclarified spec areas.
  2. Read and analyze the feature spec.
  3. Read the constitution to apply non-negotiable constraints.
  4. Fill out the plan template by executing its staged checklist steps, including generating supporting artifacts.

Outputs/files created as part of planning

After /plan completes, the system creates/updates a structured set of documents under the feature directory (the video emphasizes the following):

• plan file: includes the technical plan plus constitutional checks
• Data model documentation: example described includes a goal type with properties like:
  • id, title, end date, status, created at, completed at
  • plus an enum for goal status
• Contracts:
  • example includes a goal interface
  • UI component prop interfaces such as goal card props, including handlers like on complete and on delete
• Research file:
  • contains justifications/decisions
  • does not browse the internet unless explicitly instructed
• Other helper docs like quick start (mentioned as present)

Constitutional constraints applied to the plan

The generated plan includes a constitution check enforcing items such as:

• clean code
• simple UX
• responsive design
• minimal dependencies
• no testing

These are explicitly tied back to the constitution file and validated during planning.

Practical benefit of the artifacts

• The data model and contracts serve as structured documentation for the next phase (coding), reducing ambiguity and preventing the coding agent from “freelancing,” because:
  • the coding agent can follow the plan’s described folder structure (e.g., app/components/lib, etc.)
  • implementation can use the defined types/enums
  • UI/components can be built using explicit prop interfaces

Review/tutorial content type

This content functions as a tutorial/guide on:

• When to start planning
• How to parameterize /plan with technical preferences
• What files the planning stage generates (plan output, data models, contracts, research)
• How the constitution is enforced during plan generation

It concludes by previewing that a future step will convert the plan into a task list for the coding agent.

Main speakers/sources

• The presenter/host of the YouTube video (primary speaker)
• GitHub Spec Kit automation described in the video:
  • the /plan command
  • the setup plan script
  • the plan prompt template
  • the constitution/spec files maintained by the tool (secondary “sources” described in the video)