Lessons from Spec-driven Development — Simon Martinelli

The AI Unified Process is Simon Martinelli's process-centric, spec-driven approach where system use cases are the central, stable artifact and code is generated/regenerated from them via AI agents equipped with skills, MCP servers, and architectural guardrails. The approach works best paired with self-contained systems (not microservices, not modular monoliths), and is scoped to business applications — lessons are drawn from six customer projects including a large ERP modernization.

Standard lookup procedure — apply to every task

Unless a task section says otherwise, follow this pipeline for every answer:

1. Read outline.md to locate the relevant section, then read that section of transcript.md.
2. Check quotes.md first for strong pre-extracted citable evidence before searching the full transcript.md.
3. Quote verbatim from transcript.md when attributing words to Simon. Never put quotation marks around paraphrased content.
4. Cite by transcript line range whenever possible.
5. If a claim isn't in transcript.md, say "the talk doesn't address this" — do not infer positions from outside knowledge.
6. Speaker attribution in Q&A is unreliable — the source has no per-speaker labels. The main talk body is clearly Simon speaking, but during Q&A use phrasing like "an audience member asked..." and "Simon replied..." only when context makes turn-taking clear. Do not invent attributions.
7. The transcript has significant speech-to-text artifacts (garbled names, malapropisms like "spectrum development" for "spec-driven development", "Tessl" appears, "Ivar Jakob's own" for "Ivar Jacobson"). Quote verbatim but note [likely: X] when meaning is clearly garbled.

Bundle files: This skill depends on outline.md, transcript.md, and quotes.md. These files should be present in the skill bundle. If any are missing at runtime, tell the user which file is absent before proceeding.

How to help with this talk

Apply the speaker's approach to current work

When the user asks "how would Simon tackle ?" or wants the AI Unified Process applied to their own situation:

1. Use outline.md → "Named frameworks / concepts" to find the relevant framework (AI Unified Process, system use case structure, self-contained systems, skills+MCP guardrails).
2. Read the corresponding range of transcript.md for Simon's exact wording.
3. Anchor your suggestion in a verbatim quote of how Simon 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 (e.g. they're building a product/tool, not a business application), say so. Simon explicitly scopes his approach to business applications.

Audit the user's situation against the AI Unified Process

When the user asks to "audit", "score", "review", or "gap-analyse" their current setup:

1. Walk the user through these dimensions in order, grounded in transcript.md:
   • Specs as system use cases (vs user stories / PRDs)
   • Entity / domain model alongside use cases
   • Architecture style (self-contained systems vs microservices vs modular monolith)
   • Skills matching the chosen tech stack
   • MCP servers for large in-house framework documentation
   • Guardrails / rules (architecture docs, coding guidelines — but kept small)
   • Review intensity tied to risk of the module
   • Team structure (smaller teams, continuous flow, no two-week sprints)
2. For each dimension, quote Simon verbatim when stating what "good" looks like.
3. Give a clear verdict per dimension (covered / partial / missing). If a dimension doesn't apply (e.g. the user isn't doing modernization), say so explicitly.
4. Summarise gaps and quote Simon on how to close them.

Draft an artifact following the speaker's specification

When the user asks to draft a system use case (the primary artifact Simon prescribes):

1. Locate Simon's spec in outline.md → "Named frameworks / concepts" → "System use case structure" and read the corresponding lines in transcript.md for his exact description of the required sections and his contrast with user stories.
2. Produce a draft with: Actor, Preconditions, Main success scenario, Alternative flows, Postconditions (acceptance criteria). Include an API section if relevant — Simon's reverse-engineered doctor-list example included one.
3. Mark anything you add beyond Simon's prescription as [not from talk — added as a starting placeholder].

Factual Q&A about the talk

For any question about what Simon said, did, or argued, follow the Standard lookup procedure above. If the answer genuinely isn't in the transcript, say so explicitly.

Surface this talk proactively when relevant

When the user's current work touches themes Simon addressed (AI coding agents, modernization, microservices regret, requirements engineering, spec-driven development, drift between code and docs), briefly note the connection, provide one verbatim quote from transcript.md, and add a single sentence linking it to the user's situation. Don't over-cite — if the connection feels strained, stay quiet.

Teach / explain concepts from the talk

When the user wants to understand a concept Simon covered (system use case, self-contained system, skills vs MCP server, drift management, reflection pipeline, AI Unified Process):

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