Spec-Driven Development
The SDD Catalog
Spec-driven development has two halves. Definition workflows produce what to build — MRD, Press Release, FAQ, 6-Pager, PRD, TRD. Execution workflows install instructions into a coding agent — Claude Code, Codex, Cursor, Copilot — that then implements against those specs. This catalog defines both, and the pipelines that hand one to the other. Every entry is generated from the visionspec library — the same data VisionStudio runs on.
Definition → Execution Pipelines
The output of a definition workflow becomes the input of an execution workflow.
AWS Working Backwards → AI-DLC
Definition side runs Amazon Working Backwards (aws-one-way-door) to produce the six-pager, PRD, and TRD; the execution side hands those to AWS AI-DLC, whose Requirements Analysis absorbs them as the Vision and drives Construction.
Big Tech Product → OpenSpec
A Big Tech product definition produces a PRD and six-pager; OpenSpec's /opsx:propose consumes them into a change proposal, then delta specs, tasks, and implementation, archiving into the canonical capability specs.
PBHQ Lite → Spec-Kit
A lightweight PBHQ Lite definition produces a reconciled spec; Spec-Kit's /speckit.specify consumes it (or it is merged into specs/<feature>/spec.md), after which plan → tasks → implement proceeds.
Execution Workflows
Third-party workflow systems that drive implementation. None contains its own coding model: each installs workflow instructions into your coding agent — Claude Code, Codex, Cursor, Copilot, Kiro — which reads the repo, edits code, and runs tests. Modeled here so VisionStudio can detect each on disk and represent its status.
AWS AI-DLC Workflows
AI-Driven Development Life Cycle — a prompt/rules package that steers an AI coding agent through Inception, Construction, and Operations phases, emitting reviewable markdown artifacts at each human-gated stage. Not a CLI or MCP server: activated in-agent with the phrase "Using AI-DLC, ...".
AWS Kiro Spec-Driven Development
Kiro is an agentic IDE whose spec workflow turns a prompt into a three-file spec — requirements (EARS notation), design, and tasks — then implements task by task. Modeled from published documentation and the IDE (no public source repository), so the on-disk detail is lower-confidence than repo-modeled tools.
OpenSpec
Lightweight, brownfield-first SDD layer where humans and AI agents agree on written specs (requirements + scenarios) before code, using delta-based change proposals (ADDED/MODIFIED/REMOVED) that merge into a canonical spec set on archive. Current workflow surface is branded OPSX.
GitHub Spec-Kit
Spec-first toolkit ("Specify") that drives any AI coding agent from a natural-language feature description through specification, planning, and task breakdown to implementation. Spans its own requirements and design, but in the ProductBuildersHQ system the definition-side spec feeds its /speckit.specify step.
These systems are engineering-native — which is exactly why the definition workflows above exist: they supply the product half (Press Release, FAQ, 6-Pager) the execution side omits, rather than recreating what already works. ProductBuildersHQ's own engine is VisionSpec, which spans both halves and exports to these workflows; the PDLC specification defines the complete product→builder handoff around them.
Definition Workflows
Methodology configurations bundling spec requirements, synthesis rules, templates, and LLM-as-a-Judge rubrics. Start where you are: solo 0–1 projects run pbhq-lite (what PBHQ itself uses); the heavier definition stacks — Working Backwards, Big Tech — earn their ceremony when stakeholders and revenue do.
0-1
Minimal configuration for 0-1 product development. Focus on hypothesis validation.
aws-one-way-door
Amazon Working Backwards with one-way-door ceremony — for hard-to-reverse decisions (typically new product lines, public commitments, major investments). Starts with the human-authored Press Release (the founding artifact), stress-tests it with the FAQ, and requires the 6-pager decision narrative before build spend. Optional post-FAQ deepening: MRD (market validation, product scale) or OpportunitySpec (discovery, feature scale) — the door sets the ceremony; the scale picks the tool.
aws-two-way-door
Amazon Working Backwards with two-way-door ceremony — for reversible decisions (typically features, experiments, incremental bets). Starts with the human-authored Press Release (the same founding artifact regardless of scale), stress-tested by the FAQ; the iterative PR/FAQ review is the only formal gate and the 6-pager is optional. Optional post-FAQ deepening: OpportunitySpec (discovery, feature scale) or MRD (market validation, product scale) — the door sets the ceremony; the scale picks the tool.
big-tech
Comprehensive "best of all worlds" profile combining practices from 10 leading methodologies: - AWS Working Backwards (customer obsession, PR/FAQ, 6-pager) - Google Design Docs (OKRs, tradeoffs, alternatives, experimentation) - Stripe API-First (developer experience, documentation quality) - Netflix Freedom & Responsibility (context not control, transparency) - Spotify Bets (autonomous squads, fail fast) - Meta (move fast, bold bets) - Apple (DRI, focus) - Microsoft (growth mindset, accessibility) - Basecamp Shape Up (appetite, pitches, hill charts, circuit breaker) - Teresa Torres Continuous Discovery (weekly touchpoints, OST, assumption testing)
big-tech-essentials
Streamlined big-tech profile combining core practices from 3 leading methodologies: - AWS Working Backwards (customer obsession, PR/FAQ, 6-pager) - Google Design Docs (OKRs, tradeoffs, alternatives) - Stripe API-First (developer experience, documentation quality) This profile provides the essential big-tech rigor without the full 10-company synthesis. Teams get the core DNA (customer obsession, data-driven decisions, API-first thinking) with simplified evaluation criteria. For the full synthesis including Netflix, Spotify, Meta, Apple, Microsoft, Basecamp, and Teresa Torres practices, use big-tech-product or big-tech-feature instead.
big-tech-essentials-feature
Big Tech essentials for feature-level opportunities on existing products. Starts with OpportunitySpec + OKRs, uses PR/FAQ-driven development with design docs and API-first thinking. Simplified evaluation criteria focused on Amazon, Google, and Stripe practices.
big-tech-essentials-product
Big Tech essentials for new product lines. Starts with MRD + OKRs, uses PR/FAQ-driven development with design docs and API-first thinking. Simplified evaluation criteria focused on Amazon, Google, and Stripe practices.
big-tech-feature
Big Tech best practices for feature-level opportunities on existing products. Starts with OpportunitySpec + OKRs, uses PR/FAQ-driven development with design docs, API-first thinking, and autonomous team practices.
big-tech-product
Big Tech best practices for new product lines. Starts with MRD + OKRs, uses PR/FAQ-driven development with design docs, API-first thinking, and autonomous team practices.
continuous-discovery
Teresa Torres's Continuous Discovery Habits. Weekly customer touchpoints, opportunity solution trees, and assumption testing.
design-thinking
Stanford d.school Design Thinking methodology. Human-centered design with Empathize-Define-Ideate-Prototype-Test cycles.
enterprise
Comprehensive configuration for post-PMF enterprises. Full specs with security and compliance. MRD includes embedded Business Model Canvas.
Google Design Doc + RFC culture. Analytical, engineering-heavy approach with explicit tradeoffs, peer review, and OKR alignment.
growth
Metrics-driven configuration for 1-N growth phase. PRD, UXD, and FAQ required.
jtbd
Clayton Christensen's Jobs-to-be-Done framework. Focus on the job customers hire products to do, not demographics or features.
lean-startup
Eric Ries' Lean Startup methodology. Build-Measure-Learn cycles with validated learning, MVP focus, and pivot-or-persevere decisions.
pbhq-lite
ProductBuildersHQ Lite: the smallest spec set that keeps product, technology, plan, and roadmap distinct — PRD (what), TRD (how), PLAN (sequencing), ROADMAP (tracking). The four stay separate because they answer different questions and change on different cadences; merging any two couples their churn. Built to keep velocity high and development consistent across one-person, multi-repo initiatives: minimal ceremony keeps the loop turning fast, and the same four files committed alongside the code in every repo let humans and agents navigate any initiative the same way. This is the minimal set for the building phase — getting to shipped with verifiable success criteria; growth-phase product execution (GTM plans, growth experiments) adds artifacts or graduates to a heavier workflow rather than stretching these four.
quick-fix
Minimal workflow for small fixes and maintenance tasks. Only the ROADMAP (the machine-readable RMI ledger) is required, so a fix can be tracked and shipped without spec ceremony. PRD, TRD, and PLAN remain available as optional documents when a fix turns out to need more context.
shapeup
Basecamp's Shape Up methodology. Fixed time, variable scope. Appetite-based planning with betting table and hill charts.
startup
Lightweight configuration for pre-PMF startups. Only PRD required.
stripe
Stripe API-first methodology. Documentation as product, precise contracts, developer-centric specs where writing IS the product.
v2mom
V2MOM strategic planning framework (Vision, Values, Methods, Obstacles, Measures). Supports cascading alignment from Company → Department → Team → Individual levels.
v2mom-company
Company-level V2MOM. The top of the cascade - defines organizational vision and strategic priorities that flow down to departments.
v2mom-department
Department-level V2MOM. Aligns to Company V2MOM methods and cascades down to teams.
v2mom-team
Team-level V2MOM. Aligns to Department V2MOM methods. Most tactical level with direct links to capabilities and projects.
Definition Specs
Every spec is a definition-side artifact: product specs define the what and why, engineering specs define the how. Execution — in the VisionStudio sense — is the monitoring of actual building against these documents, not a kind of document.
Product Specs — the what and why
Market Requirements Document
Product Requirements Document
User Experience Design
Opportunity Specification
Press Release
Frequently Asked Questions
Six-Pager Narrative
One-Pager Executive Summary
Business Model Canvas
Hypothesis Document
Shape Up Pitch
Opportunity Solution Tree