PulseFlow Tecnologia
← Insights
·6 min read·framework-playbook·spec-driven-development·spec-kit·coding-agents
PulseFlow Tecnologia

A spec-driven development framework with AI

With more than 118,000 GitHub stars, 10,500 forks, and integration with more than 30 different coding agents - including GitHub Copilot, Claude Code, Gemini, and Codex CLI - Spec Kit stopped being an experiment and became a reference for how to structure spec-driven development in practice. The framework below uses Spec Kit's own commands as its skeleton.

The core commands as framework phases

Spec Kit organizes the process into six main commands: /speckit.constitution establishes project principles and guidelines before any feature spec; /speckit.specify defines requirements and user stories; /speckit.plan creates the technical implementation strategy; /speckit.tasks generates the breakdown into executable tasks; /speckit.implement executes implementation per the plan; and /speckit.converge assesses existing code against the specs - useful both for catching drift and for retrofitting specs into legacy code.

Optional commands that resolve ambiguity

Three additional commands cover cases where the initial spec isn't enough: /speckit.clarify resolves ambiguous requirements before proceeding; /speckit.analyze checks consistency across generated artifacts (spec, plan, tasks); /speckit.checklist allows custom quality validations per project.

The artifact structure that outlives the code

Once initialized, a project generates a specs/[feature-name]/ folder with spec.md, plan.md, tasks.md, data-model.md, and API contracts - artifacts versioned alongside the code, not external documentation that goes stale. A .specify/ folder holds the project's constitution, templates, and customization layers (extensions, presets, role-based bundles).

Intent-driven, not single-prompt

Spec Kit's central proposal is "intent-driven development" through multi-step refinement, instead of single-prompt code generation. That's the same distinction separating spec-driven development from vibe coding: describing intent and letting it be refined into specs, plans, and reviewable tasks, instead of asking for a final result directly and accepting whatever comes back.

The ten-step framework

  1. Requirement - the business need, before any spec
  2. Spec - user journey and success criteria (/speckit.specify)
  3. Acceptance criteria - part of the spec, not a separate document
  4. Technical plan - stack, architecture, constraints (/speckit.plan)
  5. Expected tests - defined before implementation, not after
  6. Agent execution - broken into reviewable tasks (/speckit.tasks, /speckit.implement)
  7. Validation - consistency check across spec, plan, and code (/speckit.analyze)
  8. Human review - over small units, not one monolithic PR
  9. Correction - an adjustment cycle via /speckit.clarify when the spec was ambiguous
  10. Documentation - the spec artifacts themselves, versioned alongside the code

Sources