Up & Running with GitHub Spec Kit #1 - Intro & Setup

Main idea: what Spec Kit is

• GitHub Spec Kit is presented as an AI prompting framework for spec-driven development.
• The workflow starts with a high-level specification (what the software should do) and then derives:
  1. a technical plan
  2. a list of actionable tasks
  3. the actual code
• Spec Kit aims to improve results from coding agents such as GitHub Copilot, Claude Code, Codeex, etc. by keeping the AI constrained and guided.
• The speaker prefers Spec Kit over “vibe coding” because free-form AI coding can:
  • wander
  • insert random buggy code
  • produce code that feels carelessly stitched together
• With Spec Kit, the user can see what the agent is doing and reduce drift.

Setup / installation process

• Easiest start: go to the Spec Kit repo (link mentioned in the video description).
• Requires uv (Python package manager).
  • uvx is described similarly to npx (runs a package/CLI without a full installation).
• uv installation instructions reference:
  • macOS: via brew
  • Windows: via winget
• To initialize Spec Kit, run a command to spin up a project using the Spec Kit CLI.
• Key CLI options highlighted:
  • --ai flag: choose the coding agent (e.g., Copilot, Claude Code, Gemini CLI, etc.)
  • --here flag: set up Spec Kit inside an existing project folder (instead of creating a new one)

Example project used in the walkthrough

• Uses a barebones Next.js (JavaScript) app scaffolded with create-next-app:
  • App Router
  • TypeScript
• The speaker customized it to make it “blank” by removing:
  • global CSS
  • public assets
  • most page content
• Changes were committed first to ensure a clean working directory.

What the Spec Kit installation generates in the project

After running the CLI, the tool downloads and creates Spec Kit folders/files tailored to the selected agent (example given: Copilot):

• git/
  • contains pre-made prompts
  • prompt files inside prompt/ become available to Copilot via chat slash commands
  • command name corresponds to the prompt filename (e.g., a plan prompt can be run with /plan)
• specit/
  • memory/
    • includes a constitution file that defines “ground rules” / governing principles
  • scripts/
    • example: PowerShell scripts on Windows to automate steps like creating branches and generating spec files
  • templates/
    • templates the coding agent uses to generate outputs for specs/plans/tasks

The speaker notes you generally don’t need to touch these files unless customizing behavior.

Typical feature development cycle (guided workflow)

1. /constitution
   • generates/fleshes out the constitution (core principles, e.g., accessibility + UX requirements)
2. /spec
   • creates a high-level feature spec (example: a dashboard page)
   • also creates a new git branch for the feature
3. /plan
   • turns the feature spec into a technical plan
   • accepts technical preferences such as:
     • Tailwind
     • a chart library
     • layout preferences (e.g., flex)
     • UI components library (e.g., “shadcn” mentioned)
4. /tasks
   • converts the plan into an actionable task list
5. /implement
   • runs the coding step: the agent starts implementing the feature based on the spec/plan/tasks

For future features:

• you typically repeat: /spec → /plan → /tasks → /implement
• rerun /constitution only if adding/modifying governing principles.

Optional quality-control commands

• /clarify
  • after /spec, asks questions / fills in underspecified parts of the spec
• /analyze
  • checks alignment and detects conflicting instructions across artifacts (spec/plan/task list, etc.)

Caution / review guidance

• Generated code/docs may sometimes be messy or not exactly what the user wants, even with Spec Kit.
• The speaker emphasizes reviewing and updating the outputs as needed.

Main speakers / sources

• Primary speaker: the video narrator (not named in the subtitles)
• Primary product source: GitHub Spec Kit / Spec Kit repository (as the referenced tooling source)