Beyond Vibe Coding: Engineering with the SDD Command Playbook”

The Command Playbook is an orchestration framework for Spec-Driven Development (SDD). It provides a repeatable, high-integrity workflow that bridges the gap between System Architecture and AI-Assisted Implementation.

From a blank repo to a shipped feature, every phase is tracked, reviewed, and logged automatically — ensuring that Product Requirements and Security Policies are never lost in the ‘vibe’ of the conversation.

This article is not about the system itself. It is about the workflow — how Spec-Driven Development (SDD) structures AI development into a predictable, repeatable process.

The Problem With “Vibe Coding”

When you ask an AI to “build me a multi-agent system,” you get something fast — but you also get something fragile. Without clear boundaries, testable increments, or a shared understanding of “done,” the development process quickly devolves into a cycle of “prompt-and-iterate” that lacks long-term maintainability.

Spec-Driven Development (SDD) is a discipline for working with AI coding assistants the same way you’d work with a capable but junior engineer: you write the spec first, the AI implements it, and the spec remains the permanent source of truth.

SDD Project Development

This diagram represents the core of Spec-Driven Development (SDD). It emphasizes on providing the right level of details to generate high quality context and separates the system into two layers:

• A stable Constitution layer (global rules and direction)
• An iterative Feature layer (execution and delivery)

Everything in the system follows this structure.

The “Constitution”

The Constitution (project level) provides the high-level specification what product to be created, what tech stack will be adopted and how we deliver it by phases. it consists of three foundational documents: mission.md, roadmap.md and tech-stack.md.

• mission.md (The “why”): What it does, what problems it solves, who it’s for, and the principles that constraints every design decision (e.g. security at the boundary, not in prompts).
• roadmap.md (The “what and when”): How the project deliver in ordered phases from core agent logic to production hardening, each with a checkbox list so you can see at a glance what’s done and what’s still open.
• tech-stack.md (The “How”): The specific languages, frameworks, and AWS services chosen, plus a deliberate-exclusions table explaining what was ruled out and why.

Iterative Feature Phases

Each feature follows a strict lifecycle: Specification Stage defines what to build, Implementation Stage instructs AI to executes the plan, and Validation Stage apply check rule to ensure correctness.

Each feature or phase begins with three specific files rather than a prompt:

• requirements.md (The Contract): Defines data shapes, API contracts, and explicit decisions with their rationale. It answers what the component does and why key decisions were made.
• plan.md (The Implementation Steps): Breaks the work into numbered, atomic steps. Each step must be specific enough that an AI can execute it without ambiguity.
• validation.md (Acceptance Criteria): Lists the specific test cases and behaviors that confirm the phase is complete.

In practice, validation determines the control flow of the system. If the validation passes, the process proceeds to the next step. If the validation fails, the system triggers a replanning phase to adjust the approach. If the task is identified as high-risk, it is escalated for further review or human intervention.

The Repeatable Command Playbook

To maintain this discipline, I have created a playbook to manage the 4-steps workflow with 4 simple commands (/init-specs, /feature-spec, /reiew-branch, and /ship).

Step 1: Bootstrap the constitution

/init-specs: Run once per project. It reads the user inputs from README.md file and all input documents under /docs directory, and clarify the specification by interview you before starting to generate the source of truth (mission.md, roadmap.md and tech-stack.md) under /specs directory.

Step 2: Implement iterative feature

/feature-spec: A frequent command used to generate 3 key documents (requirements.md, plan.md and validation.md) for each phase. Coding agent finds the first incomplete phase in roadmap.md, creates a branch, interviews you in up to 2 rounds of 3 questions, writes the spec directory, and opens the CHANGELOG entry.

Step 3: Review feature Implementation

/review-branch: A pre-commit verification action. It checks the work done against the written specification, ensure the feature implementation and documents are in-sync and provides the recommended actions for improvement.

Step 4: Commit the change

/ship: A commit action. It triggers automated sequence of commit actions, i.e: auto-generate summarized commit messages and commit, merges the branch, and lastly auto updates the CHANGELOG.md files for progress tracking.

Case Study: Sentinel MAS

To test this workflow, I built Sentinel MAS, a simplified version of my last production grade project. It completed within 3 days. Using SDD, the system structured in 12 independently shippable phases.

Phases 1-3: Establishing shared state schemas, the policy layer, and agent registries with stubs.
Phases 4-6: Wiring the router node, specialist subgraphs, and compiling the LangGraph.
Phases 7-9: Building the FastAPI service, SQS consumers, and the React dashboard.
Phases 10-12: Deploying via Terraform, setting up CI/CD pipe

Every phase of Sentinel MAS started with three files, not a prompt:

specs/
  2026-04-19-sentinel-policy-layer/
    requirements.md   ← the contract
    plan.md           ← the implementation steps
    validation.md     ← what "done" looks like

The spec is a contract between you and the AI. If the spec is wrong, the code is wrong. Garbage spec → garbage code.

This matters because AI assistants have no persistent memory between sessions. The spec is the memory. When you return to a feature two weeks later, you re-load the spec — not the conversation.

The demo project is simplified but include CI/CD and end-to-end deployment workflows, which comprising:

• Infra-as-Code: Use terraform to setup AWS infrastructure for sentinel mas deployment.

| Module | Resources |
|--------|-----------|
| `networking` | VPC, 2 public + 2 private subnets, IGW, NAT gateway, route tables, security groups |
| `iam` | ECS task execution role, ECS task role (per service), CodeDeploy role, ECR pull policy |
| `rds` | PostgreSQL 15 RDS instance (db.t3.micro), subnet group, parameter group, schema migration via `psql` |
| `sqs` | Standard queue + dead-letter queue (maxReceiveCount = 3), queue policy |
| `ecs` | ECS cluster, task definitions for `api`, `central`, and `ui` services, Fargate services with desired count = 1 |
| `alb` | ALB, HTTPS listener (port 443), HTTP → HTTPS redirect, target groups, listener rules: `/api/*` → api TG, `/*` → ui TG |
| `codedeploy` | CodeDeploy app, blue/green deployment group for `api` and `central`, 10-minute bake, auto-rollback on alarm |

• Github Actions: CI/CD Workflow: A complete CI/CD workflow that triggers code-quality check, run automated test cases, build/register/push images to ECR repository, and auto-deploy for new release.

push to main
    ↓
CI (lint + typecheck + test)
    ↓
Build & Push (Docker images → ECR, tagged with full commit SHA)
    ↓
Deploy
  ├── api: register new ECS task def → CodeDeploy canary blue/green
  ├── central: register new ECS task def → rolling update
  └── ui: register new ECS task def → rolling update

What SDD Changed

Building with SDD instead of prompt-and-iterate changed three things concretely:

1. Every phase was independently reviewable. The spec for each phase was a standalone document. Another engineer could read Phase 5’s requirements and understand exactly what the specialist agents do, what they don’t do, and why — without reading the code or the conversation that produced it.

2. Production bugs were scoped immediately. When issues appeared in production (cross-container task store isolation, ALB routing gaps, UI baking localhost URLs into the build), the fix was scoped to the specific requirement that had been missed or deferred. The phase structure made the blast radius visible.

3. The AI never had to “remember.” Each session started with the relevant spec loaded. The AI had full context for the phase, not a summary of previous phases. Specs are stateless context — they travel with the codebase.

What’s Next

The SDD workflow isn’t just for building the foundation; it scales to complex features like vector-search agents and real-time data integrations. The system grows one well-defined, spec-backed increment at a time.

Explore the methodology and the Sentinel MAS repo here: https://github.com/A0291221R/sdd-demo-sentinel-mas-workshop

Is there a specific part of the feature phase progression or the command automation you’d like to dive deeper into for the next post?