# The ONLY guide you’ll need for GitHub Spec Kit

Source: The ONLY guide you’ll need for GitHub Spec Kit - YouTube

  • What SpecKit is: an open-source toolkit from GitHub for spec-driven development (SDD) (see Spec-Driven Development) that helps teams avoid “vibe coding” by structuring work around specs instead of ad-hoc prompts.

  • Core workflow (tools & artifacts):

    • Constitution – non-negotiable principles (e.g., static-first, accessibility baseline).
    • Spec – the what & why (user stories, acceptance criteria, no implementation details).
    • Plan – the technical how that must respect the constitution.
    • Tasks – broken-down, executable steps; helper scripts handle deterministic actions (git branches, JSON, etc.).
    • VS Code slash commands (custom prompts) power this flow; everything lives as markdown/json in the repo.

  • Getting started options:

    • Use the specify CLI (installable via uvx directly from the repo; PyPI publish planned).
    • Or download templates from GitHub Releases (supports multiple agents and script types).
    • Agents supported: Copilot, Claude Code, Gemini CLI, Cursor (new).
      Scripts: PowerShell and shell; Windows now works natively with PowerShell.

  • Why SDD: reduces ambiguity, keeps teams out of rabbit holes, separates requirements from implementation so you can re-generate code with different frameworks or models using the same spec.

  • Demo highlight: bootstrapped a podcast website (“podsite”)

    • Used GPT-5 for constitution/spec/plan; used Sonnet 4 to implement.
    • Stack: Next.js in static mode, no DB, responsive design; generated Landing (featured episode), Episodes, About, FAQ with mocked data.
    • Built and ran locally; artifacts (spec, plan, research, data model, tasks) grouped per feature for easy re-runs or model switching.

  • Best practices & guidance:

    • Keep specs implementation-agnostic; use the acceptance checklist and clear “needs clarification” items (or let the model take best-guess, then update the checklist).
    • Prefer scripts for deterministic steps; let LLMs handle drafting and code.
    • Models have different strengths—experiment and switch models as needed.
    • You can integrate MCP tools (e.g., Figma) to align with a design system.

  • Community & contributions:

    • File issues with context (not “DR?”) and discuss big changes first.
    • Don’t open a PR that rewrites everything (e.g., into a single MCP server) without prior discussion.
    • Feedback is actively monitored; more agent integrations and packaging improvements are coming.