talk-graziano-spec-driven-development

name	talk-graziano-spec-driven-development
description	Spec-Driven Development: From Prompting to Production-Ready Systems

Spec-Driven Development: From Prompting to Production-Ready Systems — Alfonso Graziano

---

name: talk-graziano-spec-driven-development description: Use when the user asks about Alfonso Graziano's talk "Spec-Driven Development: From Prompting to Production-Ready Systems" (Nearform, 2026) — including questions about Spec-Driven Development (SDD), the Spec Kit four-phase workflow (specify → plan → tasks → implement), comparisons with BMAD or other SDD frameworks, vibe coding vs spec-driven, the constitution file, adversarial spec review, model selection for spec vs implementation, the EARS requirements format, problem-space vs solution-space, or applying the speaker's hands-on workshop approach to their own AI-assisted coding work. metadata: generated-by: talk-to-skill source: file:user-provided-transcript generated-at: 2026-06-02

Spec-Driven Development: From Prompting to Production-Ready Systems — Alfonso Graziano

Alfonso Graziano (AI Tech Lead at Nearform) argues that AI-assisted coding only graduates from prototyping toy to reliable engineering discipline when specifications become first-class artifacts. The talk walks through Spec Kit's four-phase workflow (specify → plan → tasks → implement), the verification loop that replaces line-by-line code review, and field-tested patterns his teams use across dozens of projects — including using a stronger model for the spec and a smaller one for implementation, treating the spec as a contract between human and AI, and running adversarial reviews to catch internal inconsistencies.

Grounding rules — MUST follow when answering

1. Before answering any specific question, read outline.md to locate the relevant section, then read that section of transcript.md.
2. When attributing words, quote verbatim from transcript.md. Never put quotation marks around paraphrased content.
3. If a claim isn't in transcript.md, say "the talk doesn't address this" — do not infer positions from outside knowledge.
4. Cite by transcript line range whenever possible.
5. Speaker attribution is unreliable for this transcript — the source has no per-speaker labels, and there appear to be at least two presenters (Alfonso Graziano and a co-presenter who fields audience questions) plus audience interjections. Prefer phrasing like "the speaker said...", "a presenter argued...", or "one attendee asked..." unless context makes the speaker unambiguous. Do not invent attributions.
6. The transcript is heavily speech-to-text garbled in places (e.g. "psyched" for "Spec Kit", "be matched" / "be mat" / "vmod" / "bm" / "demed" / "vmatch" / "beam ads" / "BAD" / "BMS" all appear to mean BMAD; "biocoding" / "bipoding" / "by coding" mean vibe coding; "self working AI" likely means agentic AI; "stat" / "spat" / "spike" / "spike pay" / "Spekit" / "psyched" mean Spec Kit or spec). When quoting, preserve the garbled text verbatim but you may add [Spec Kit] style bracketed clarifications.

How to help with this talk

Apply the speaker's approach to current work

When the user asks "how would Graziano tackle ?" or wants the talk's framework applied to their own situation:

1. Use outline.md → "Named frameworks / concepts" to find the relevant framework (Spec Kit four-phase loop, problem-space vs solution-space, adversarial review, model-tier split, etc.).
2. Read the corresponding range of transcript.md for the speaker's exact wording.
3. Anchor your suggestion in a verbatim quote of how the speaker articulates the framework. Then walk through applying it step-by-step to the user's case.
4. If the framework genuinely doesn't fit the user's situation, say so. Do not stretch the speaker's words to cover cases they don't actually address (e.g. the talk gives a deliberately small JS/React example — don't pretend it prescribes enterprise migration patterns it doesn't cover).

Audit the user's situation against the speaker's framework

When the user asks to "audit", "score", "review", "grade", "check", or "gap-analyse" their AI-coding setup against the talk's framework:

1. Use outline.md → "Named frameworks / concepts" to locate the four Spec Kit phases (specify, plan, tasks, implement) plus the supporting guardrails (constitution, project context, human-in-the-loop review, adversarial review).
2. For each dimension, read the speaker's definition in transcript.md and quote it verbatim when stating what "good" looks like.
3. Walk the user through every phase in order — don't skip ones that seem weak.
4. For each dimension, give a clear verdict (covered / partial / missing) grounded in the speaker's criteria, not your own intuition.
5. If a dimension genuinely doesn't apply (e.g. solo dev with no PM to co-create specs), say so and explain why.
6. Summarise gaps at the end with verbatim quotes anchoring what the speaker said about closing them.

Draft an artifact following the speaker's specification

When the user asks to draft a spec, plan, tasks file, constitution, or EARS-format requirement:

1. Locate the speaker's specification in outline.md and transcript.md.
2. Capture every constraint the speaker mentions (e.g. spec.md should contain user scenarios, user stories, acceptance criteria; EARS format is "when this happens I want that").
3. Before producing the artifact, quote verbatim the speaker's prescription so the user can see what the draft is grounded in.
4. Match the speaker's structure and terminology. Where the user's context needs fields the speaker didn't prescribe, mark them clearly as [not from talk — added as a starting placeholder].
5. If the user's situation requires elements the speaker didn't address, ask the user rather than inventing.

Teach / explain concepts from the talk

When the user wants to understand a concept Graziano covered (SDD, constitution, adversarial review, problem-space vs solution-space, vibe coding vs SDD, etc.):

1. Look up the term in outline.md → "Terminology glossary".
2. Read the speaker's explanation in transcript.md.
3. Re-explain using the speaker's own framing and examples first, with verbatim quotes for key claims.
4. You may add modern context or comparisons afterwards — but mark them clearly as "not from the talk".

Factual Q&A about the talk

For any question about what the speaker said:

1. Read outline.md first to find the relevant section(s).
2. Read the matching range of transcript.md.
3. Answer using verbatim quotes. Do not paraphrase the speaker's words while presenting them as a quote.
4. Cite line ranges.
5. If the answer isn't in the transcript, say so explicitly. Note: this transcript is unusually noisy from speech-to-text errors — if a passage is garbled beyond reliable interpretation, say so rather than guessing meaning.

Surface this talk proactively when relevant

When the user's current work touches on AI-assisted coding, prompt engineering, spec writing, AI agent guardrails, or drift between code and intent (even if they haven't asked about this talk):

1. Briefly note: "Graziano made a related point in his SDD talk..."
2. Quote verbatim from transcript.md — one quote is usually enough.
3. Add one sentence connecting the quote to the user's situation.
4. Do not over-cite. If the connection feels strained, stay quiet.

Key quotes

quotes.md contains pre-extracted verbatim highlights from this talk, organised by theme. When formulating answers, check quotes.md first for strong citable evidence before searching the full transcript.md.