mcp-vdd
Run an AI-native, fully traceable software development pipeline — from a single vision statement through research, specs, planning, tasks, implementation, and impact validation.
vdd_init (Phase 0): generate
constitution.mdwith the immutable tech stack, conventions, and security rules.vdd_vision (Phase 1): expand a freeform vision into
vision.md(impact model, stakeholders, success metrics).vdd_strategize (Phase 2): two-pass research into
strategy.md(pillars, competitive analysis, risk register).vdd_tactics (Phase 3): audit the codebase into
tactics.md(technical debt, gap analysis, A-### action items).vdd_specify / vdd_clarify (Phase 4): generate a spec with acceptance criteria; find and resolve
[NEEDS CLARIFICATION]markers.vdd_plan (Phase 5): produce
plan.md,data-model.md, andcontracts/for one feature.vdd_tasks / vdd_get_next_task (Phase 6/7a): break the plan into atomic test-first tasks; fetch the next uncompleted one.
vdd_implement (Phase 7b): load constitution/spec/plan/contracts and return the implementation instruction plus traceable commit format.
vdd_validate (Phase 8): bidirectional traceability, drift/orphan detection, and 7 gates with 28 S&T checks into an impact report.
vdd_inspect: read-only traceability matrix (project scope) or per-feature spec metrics.
vdd_amend: plan a requirement-change cascade with the ordered edits and gates to re-run.
vdd_detect_environment: report which tools/MCPs each phase needs vs. what your host provides.
vdd_clone: crawl a live domain into a clone dataset plus a Next.js + Payload + Postgres scaffold manifest.
The root Dockerfile self-hosts the Streamable HTTP MCP server.
The project is hosted on GitHub, with badges for CI quality gates and releases.
The server can be installed and run via npx @simonmak-ascent/mcp.
Dependencies are installed and TypeScript packages are built using pnpm.
The MCP agent status badge is served from a Supabase edge function endpoint.
The server's packages are implemented in TypeScript and built with pnpm -r build.
This server has a remotely hosted endpoint. Open its connector listing for connection details, authentication requirements, and setup instructions:
Vision Driven Design
From vision to verified impact — an AI-native, fully autonomous software development methodology.
Overview
Provide a human vision statement. The AI autonomously researches, audits your codebase, generates specs and plans, implements, and validates — with bi-directional verification at every junction to ensure nothing is missed or invented.
graph LR
V[1. Vision<br/>Human Input] -->|<-->| S[2. Strategy<br/>AI Research]
S -->|<-->| T[3. Tactics<br/>AI Audit]
T -->|<-->| SP[4. Specs<br/>SDD]
SP -->|<-->| PL[5. Plan]
PL -->|<-->| TK[6. Tasks]
TK -->|<-->| IM[7. Implement]
IM -->|<-->| VS[8. Validate<br/>Impact Verified]
style V fill:#4CAF50,color:#fff
style S fill:#2196F3,color:#fff
style T fill:#FF9800,color:#fff
style SP fill:#9C27B0,color:#fff
style VS fill:#4CAF50,color:#fffRelated MCP server: mcp-hkex-filing
Table of Contents
Quick Start (≤ 5 minutes)
Fastest path: no install — connect an MCP client to the hosted endpoint
https://vdd.simonmak.com/api/mcp (Streamable HTTP); or run the one-line install below.
# One-line install
curl -sSL https://raw.githubusercontent.com/simonmak-ascent/vision-driven-design/main/scripts/install.sh | bashThen in your project:
/vdd:init # Generate project constitution
/vdd:vision "your vision here" # The only human input required
# Or run end-to-end in one command:
/vdd:e2e "your vision here" # Full chain: init→vision→...→validateThe AI handles the rest — researching, auditing, generating specs, planning, implementing, and validating — with self-gating at 7 bi-directional verification junctions.
Skill reference → — commands, the 8-phase chain, and the quality gates.
# Want human gates? Add to constitution.md:
## VDD Mode: GatedHow It Works
VDD follows Goldratt's recursive Strategy-Tactic decomposition: every phase is simultaneously the Tactic for its parent and the Strategy for its child.
Phase | S&T Role | Output |
0. Constitution | (pre-chain) |
|
1. Vision | L1 Strategy: What impact? |
|
2. Strategy | L1 Tactic → L2 Strategy |
|
3. Tactics | L2 Tactic → L3 Strategy |
|
4. Specs | L3 Tactic → L4 Strategy |
|
5. Plan | L4 Tactic → L5 Strategy |
|
6. Tasks | L5 Tactic → L6 Strategy |
|
7. Implement | L6 Tactic → L7 Strategy | Code — Per-task commits with full traceability |
8. Validate | L7 Tactic — Did it work? |
|
7 bi-directional gates verify both directions at every junction (108 total checks). Each gate validates 4 S&T assumptions: Necessity, Achievability, Sufficiency, Warnings.
Every code commit traces back to the original vision statement:
V-001 → S-002 → T-003 → SP-004 → PL-005 → TK-006 → commitThe pipeline and its 7 gates
flowchart TB
C["Phase 0 · Constitution<br/>constitution.md"] --> V["Phase 1 · Vision<br/>vision.md"]
V -.->|G1| S["Phase 2 · Strategy<br/>strategy.md"]
S -.->|G2| T["Phase 3 · Tactics<br/>tactics.md"]
T -.->|G3| SP["Phase 4 · Specs<br/>spec.md"]
SP -.->|G4| PL["Phase 5 · Plan<br/>plan.md · data-model · contracts"]
PL -.->|G5| TK["Phase 6 · Tasks<br/>tasks.md"]
TK -.->|G6| I["Phase 7 · Implement<br/>code + per-task commits"]
I -.->|G7| VA["Phase 8 · Validate<br/>impact-report.md"]Bi-directional traceability
Each gate checks forward (parent → children) and backward (children → parent), 108 checks in total.
flowchart LR
subgraph F["Forward: intent → code"]
direction LR
V1["Vision V-*"] --> S1["Strategy S-*"] --> T1["Tactics T-*"] --> SP1["Spec SP-*"] --> PL1["Plan PL-*"] --> TK1["Tasks TK-*"] --> C1["Commit"]
end
subgraph B["Backward: code → intent"]
direction LR
C2["Commit"] --> TK2["Tasks TK-*"] --> PL2["Plan PL-*"] --> SP2["Spec SP-*"] --> T2["Tactics T-*"] --> S2["Strategy S-*"] --> V2["Vision V-*"]
endChange cascade
flowchart TB
CH["Requirement change<br/>/vdd:amend"] --> FIND["Find the highest affected level"]
FIND --> U1["Update Vision"] --> U2["Update Strategy"] --> U3["Update Tactics"] --> U4["Update Specs"] --> U5["Update Plan"] --> U6["Update Tasks"]
U6 --> REG["Re-run affected gates G1–G7"]
REG --> IMPL["Re-implement only the changed tasks"]Commands
Command | Phase | Action |
| 0 | Generate |
| 1 | Expand freeform vision → structured |
| 2 | Load domain primers, spawn research subagents, synthesize |
| 3 | Audit repo → gap analysis → |
| 4 | Generate |
| 4 | Clarification pass on a spec |
| 5 | Generate |
| 6 | Generate |
| 7 | Extract next uncompleted task |
| 7 | Execute single task, verify, commit |
| 8 | Full-chain traceability + drift + impact report |
| any | Bidirectional traceability matrix |
| any | Cross-artifact consistency analysis |
| any | Cascade requirement change through full chain |
| any | Report per-phase tool/MCP requirements + available capabilities |
| 0–8 | End-to-end: run full 8-phase chain in one call, writes all 10+ template files |
| 7 | Clone: crawl site (browserless/fetch) into a full dataset + exact UI/UX + rebuilt backend + generated schema + AI tools + deployable dynamic site (vdd/clone-site/) from a domain (https/http/www/bare) |
Installation
# OpenCode
git clone https://github.com/simonmak-ascent/vision-driven-design.git \
~/.config/opencode/skills/vision-driven-design/
# Claude Code
git clone https://github.com/simonmak-ascent/vision-driven-design.git \
~/.claude/skills/vision-driven-design/
# Cursor
git clone https://github.com/simonmak-ascent/vision-driven-design.git \
.cursor/skills/vision-driven-design/Local MCP (from source)
To run the MCP server locally (stdio) instead of the hosted endpoint:
# 1. Clone the repo
git clone https://github.com/simonmak-ascent/vision-driven-design.git
# 2. Install deps + build the TypeScript packages
cd vision-driven-design
pnpm install
pnpm -r build
# 3. Point your agent at the built stdio entry pointOpenCode (opencode.json):
"vdd": {
"type": "local",
"command": ["node", "<repo>/packages/vdd-mcp/dist/stdio.js"],
"enabled": true
}Claude Desktop (claude_desktop_config.json):
"vdd": {
"command": "node",
"args": ["<repo>/packages/vdd-mcp/dist/stdio.js"],
"type": "stdio"
}MCP API
VDD is available as a public MCP server at https://vdd.simonmak.com — 15 tools, no API key required — over the MCP Streamable HTTP transport at https://vdd.simonmak.com/api/mcp (also reachable at /mcp). The legacy SSE endpoint is retired: https://vdd.simonmak.com/api/sse now returns an HTTP 308 redirect to /api/mcp.
Agent Configuration
OpenCode — add to opencode.json:
"vdd": {
"type": "remote",
"url": "https://vdd.simonmak.com/api/mcp",
"timeout": 120000
}Claude Desktop — add to claude_desktop_config.json:
"vdd": {
"command": "npx",
"args": ["-y", "@simonmak-ascent/mcp"],
"type": "stdio"
}Cursor — add MCP server URL: https://vdd.simonmak.com/api/mcp
Any Streamable HTTP client (Smithery, Claude Code, …) — MCP server URL: https://vdd.simonmak.com/api/mcp
MCP Tools (15)
vdd_init, vdd_vision, vdd_strategize, vdd_tactics, vdd_specify, vdd_clarify, vdd_plan, vdd_tasks, vdd_get_next_task, vdd_implement, vdd_validate, vdd_inspect, vdd_amend, vdd_clone, vdd_detect_environment.
The one-call e2e shortcut is not an MCP tool (it duplicates the phase sequence); use the CLI vdd e2e "vision" instead.
Each tool advertises only the parameters it reads. Shared inputs include statement, projectRoot, actionItemId, feature, taskId, description, and availableTools/capabilities (aliases) plus researchFindings. Filesystem-dependent tools additionally accept artifactFiles (path→content) — and vdd_tactics accepts codebaseAudit — for the hosted endpoint.
Hosted vs local (filesystem)
The hosted endpoint (https://vdd.simonmak.com/api/mcp) is stateless and has no filesystem. It returns artifacts and, for filesystem-dependent phases, a delegation envelope for the calling agent to execute locally:
Artifact-producing phases (
vdd_init,vdd_vision,vdd_strategize,vdd_tactics,vdd_specify,vdd_plan,vdd_tasks,vdd_validate,vdd_clone) return their content withpersisted: falseand awriteTargetslist — the agent writes them.Read phases (
vdd_tactics,vdd_clarify,vdd_get_next_task,vdd_inspect,vdd_validate,vdd_implement) return adelegationenvelope when given no content; re-call the same tool withartifactFiles(andcodebaseAuditfor tactics) to receive the real result.
For direct read/write of a local project, run the local stdio server instead — npx -y @simonmak-ascent/mcp (see Local MCP). It performs real filesystem I/O and returns mode: "local", persisted: true.
MCP Prompts (3)
start_vdd_project (vision → validated task list), implement_next_task (one test-first task with traceability) and change_requirement (cascade a change and re-run the gates). Available on the stdio server and the hosted endpoint.
MCP Registry (Glama)
The server is listed on Glama, which builds it from source and publishes a hosted remote endpoint plus a Tool Definition Quality Score and maintenance rating:
Maintainer notes:
glama.json(repo root) is Glama's registry file. Its schema consumes exactly one field —maintainers. Build/transport/description metadata belongs inpackage.jsonand this README, not here; Glama ignores it.Glama generates its own container build from the stdio entrypoint (
packages/vdd-mcp/dist/stdio.js), wrapped withmcp-proxy. The rootDockerfileis for self-hosting the Streamable HTTP server, not for Glama.After tool-definition changes: sync the repository and run Build & Release in the Glama admin. Tool-level scores refresh on the next sweep; the server-level coherence score re-runs less often.
Also published to the Official MCP Registry as
com.ascent-partners/vision-driven-design(manifest:server.json) — PulseMCP and other directories ingest from there.Listed in the
awesome-mcp-serverscommunity list under Developer Tools.Listed on Agent Status — an outside-in MCP reliability index that probes reach, catalog, and tool calls from real hosts (Cursor, Claude, VS Code, ChatGPT). The submission created the Free dashboard account; the score populates after the first probe.
API Reference
Method | Description |
POST | Streamable HTTP — JSON-RPC |
GET | HTML docs page for browsers; 405 for MCP clients (no server-initiated stream) |
DELETE | 204 — no session state to terminate |
| Retired — HTTP 308 redirect to |
# Streamable HTTP call example
curl -X POST https://vdd.simonmak.com/api/mcp \
-H "Content-Type: application/json" \
-H "Accept: application/json, text/event-stream" \
-d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'# tools/call example
curl -X POST https://vdd.simonmak.com/api/mcp \
-H "Content-Type: application/json" \
-d '{"jsonrpc":"2.0","method":"tools/call","params":{"name":"vdd_validate","arguments":{"projectRoot":"."}},"id":1}'The full TypeScript engine (packages/vdd-engine, packages/vdd-mcp, packages/vdd-cli) is included in this repo.
Domains Covered
VDD loads domain-specific research patterns during the Strategy phase based on your vision:
Domain | What it covers |
WebApp | UX, accessibility (WCAG 2.2), performance budgets, framework evaluation |
Data Storage | Schema design, indexing strategy, data governance, ACID vs eventual |
ETL | Pipeline architecture, data quality, batch vs streaming |
Infrastructure | CI/CD, observability, security, scaling, disaster recovery |
Human Factors | Behavioral economics, cognitive load, habit formation, accessibility cognition |
Verification Toolchain | Playwright, Browserless, Sentry, CI/CD quality pipeline |
Safety-Critical | FMEA/FTA, DO-178C/IEC 62304 safety integrity levels |
human-factors.md and verification-toolchain.md are loaded unconditionally for every project.
Best-Practice Benchmark
VDD is benchmarked against NASA SE, CMMI REQM, DO-178C, IEC 62304, DORA, ISO 29148, and GitHub Spec Kit:
47/47 criteria matched (100%), 11 exceeded, 0 gaps.
Standards & compliance evidence →
Documentation
File | Contents |
Full command reference and workflow | |
Local stdio / HTTP / hosted modes and the delegation contract | |
Step-by-step phase instructions (authoritative) | |
Copy-paste templates for all 11 artifacts | |
7 gates with 108 checks + CI/CD | |
24 failure modes and fixes | |
DO-178C/IEC 62304/CMMI/ISO 29148 evidence maps | |
Website cloning — crawl → dataset → deployable dynamic site | |
One-page cheat sheet |
Repository Structure
├── SKILL.md # Entry point — loaded by OpenCode
├── README.md # This file
├── AGENTS.md # Instructions for AI agents
├── constitution.md # Project constitution (dogfooded)
├── CHANGELOG.md # Versioned change history
├── CONTRIBUTING.md # Contribution guidelines
├── LICENSE # MIT
├── index.html # Vercel landing page (en / zh / hk)
├── pnpm-workspace.yaml # Workspace config
├── package.json # Root package (Vercel + workspace)
├── vercel.json # Vercel deployment config
├── Dockerfile # Self-host build — Streamable HTTP MCP server
├── glama.json # Glama registry file (maintainers only)
├── server.json # Official MCP Registry manifest
├── domain-primers/ # 7 domain research patterns
│ ├── webapp.md
│ ├── data-storage.md
│ ├── etl.md
│ ├── infrastructure.md
│ ├── human-factors.md # Loaded unconditionally
│ ├── verification-toolchain.md # Loaded unconditionally
│ └── safety-critical.md # FMEA/FTA, DO-178C/IEC 62304
├── references/ # 10 authoritative reference docs
│ ├── INDEX.md # Navigation map
│ ├── quick-reference.md # 1-page cheat sheet
│ ├── workflow-phases.md # Phase order (authoritative)
│ ├── artifact-templates.md # 11 artifact templates (authoritative)
│ ├── prompt-patterns.md # AI prompts (authoritative)
│ ├── quality-gates.md # 7 gates + 108 checks (authoritative)
│ ├── ai-agent-patterns.md # Agent orchestration (authoritative)
│ ├── anti-patterns.md # 24 failure modes (authoritative)
│ ├── traceability-matrix.md # RTM format + CI/CD
│ └── compliance-evidence.md # Evidence maps
├── vdd/ # VDD chain artifacts
│ ├── vision.md # Vision, impact model, 17 impacts
│ ├── strategy.md # 12 strategic pillars
│ ├── tactics.md # 38 action items (all DONE)
│ ├── impact-report.md # Full-chain traceability + drift
│ ├── docs/ # 16 guides and references
│ └── specs/ # 3 feature specs
├── packages/ # TypeScript monorepo
│ ├── vdd-engine/ # Shared core — 18 phase functions + meta.ts
│ ├── vdd-mcp/ # MCP server — 15 tools, stdio + Streamable HTTP
│ └── vdd-cli/ # CLI binary — 17 subcommands
├── api/ # Vercel MCP endpoint
│ ├── mcp.js # Streamable HTTP MCP endpoint (15 tools)
│ └── _vdd-rpc.js # Shared JSON-RPC core + browser docs page (not routed)
├── scripts/ # 4 installer/helper scripts
└── .github/ # GitHub config
├── CODEOWNERS
├── ISSUE_TEMPLATE/
└── workflows/Acknowledgements
Built on:
Goldratt's Strategy-and-Tactic Tree — recursive decomposition at every phase
Impact Mapping (Gojko Adzic) — goal → actors → impacts → deliverables
GitHub Spec Kit — spec-driven development with AI agents
NASA Systems Engineering — bidirectional traceability and verification chains
CMMI Requirements Management — bidirectional traceability of requirements
Use with Context7
Up-to-date Vision Driven Design documentation is indexed on Context7, so coding agents can pull it into context on demand. With the Context7 MCP server or ctx7 CLI installed, name the library in your prompt:
use library /simonmak-ascent/vision-driven-design for API and docsLicense
MIT — see LICENSE.
By Simon Mak.
If this saves you time, a ⭐ on GitHub helps others find it.
Available Tools
15 toolsvdd_amendAmend RequirementsARead-onlyIdempotentInspect
VDD Cross-phase: Plan a requirement-change cascade through the whole chain — identifies the highest affected level and returns the ordered steps to update downward V→S→T→SP→PL→TK and re-run affected gates (G1–G7). Read-only; returns the cascade plan without editing artifacts (the host agent applies the edits and commits). Pass the change as description. Use when a requirement changes after artifacts already exist; to build a phase from scratch the first time, run that phase's own tool instead of vdd_amend. The plan is an ordered step list naming the affected gates, not rewritten artifacts. Parameter relationships: description is the requirement change to cascade through the artifact chain; projectRoot must match the root used by earlier phases.
Inputs: description (required), projectRoot. Returns: _sdt, error, _phase, output, +3 more
vdd_clarifyClarify SpecARead-onlyIdempotentInspect
VDD Phase 4b: Clarify an existing spec — scans vdd/specs//spec.md and returns the items to resolve: every [NEEDS CLARIFICATION] marker, [e.g.] placeholder, and happy-path acceptance criterion (AC) still needing an edge-case counterpart (AC-E*). Read-only; returns the list without editing the file (the host agent then applies the resolutions). Pass feature (spec directory name). Run after vdd_specify when a spec has unresolved markers; to author a brand-new spec use vdd_specify instead. Parameter relationships: feature must be the exact spec directory name created by vdd_specify.
Inputs: feature (required), projectRoot. Returns: _sdt, error, _phase, output, +3 more
vdd_cloneClone WebsiteADestructiveInspect
Crawl and capture a target domain into a clone dataset + manifest — WordPress-aware schema inference, Payload collections, and a Next.js + Payload + Postgres scaffold manifest (vdd/clone-manifest.json). Pass the domain as description. Writes vdd/clone-dataset.json, vdd/clone-manifest.json, and vdd/clone.md, overwriting any existing versions in place. Open-world: makes network requests to the target site and reads its sitemap and same-origin links. Use for cloning an external site; it is not part of the VDD phase pipeline, so for the normal init→validate flow call those phase tools instead. Parameter relationships: description is the target domain and statement is the desired outcome (both optional); maxPages, timeoutMs, concurrency, crawl, and browser tune the crawl and refresh=true bypasses a cached dataset.
Inputs: crawl, browser, refresh, maxPages, +5 more. Returns: _sdt, error, _phase, output, +3 more
vdd_detect_environmentDetect EnvironmentARead-onlyIdempotentInspect
VDD Environment Detection: Report which tools/MCPs each VDD phase requires vs treats as optional — across the 8-phase pipeline (init through validate) plus the cross-phase helpers (amend, clone, inspect, get-next-task) — and which of the host agent availableTools are present vs missing. Read-only; returns a capability report without modifying files. Run before vdd_strategize to plan research-subagent dispatch, or when a phase fails for lack of a tool; to inspect artifacts instead of capabilities use vdd_inspect. Returns a fixed-shape capability report; tool-name matching is normalized, so pass names as your host exposes them. Parameter relationships: availableTools and capabilities are aliases; omit both to get the per-phase requirements without a present/missing comparison.
Inputs: projectRoot, capabilities, availableTools. Returns: _sdt, error, _phase, output, +3 more
vdd_get_next_taskGet Next TaskARead-onlyIdempotentInspect
VDD Phase 7a: Read vdd/specs//tasks.md and return the next uncompleted task (or a completion marker when none remain). Read-only; never edits tasks.md. Pass feature (the exact spec directory name). Use before each implementation session to keep context isolated; to regenerate the whole list use vdd_tasks, and to execute the returned task use vdd_implement. Parameter relationships: feature must match the spec directory; the returned taskId (TASK-###) is the argument to vdd_implement.
Inputs: feature (required), projectRoot. Returns: _sdt, error, _phase, output, +3 more
vdd_implementImplement TaskARead-onlyIdempotentInspect
VDD Phase 7b: Prepare one task for implementation — loads constitution, spec, plan, and contracts and returns the implementation instruction plus the impact-chain commit-message format. Read-only; the tool writes nothing — the host agent performs the code edits, verification, and commit. Pass taskId (e.g. "TASK-003") from the task returned by vdd_get_next_task. Run one task at a time, after vdd_get_next_task; for read-only inspection of tasks use vdd_get_next_task instead. Parameter relationships: taskId comes from vdd_get_next_task (format TASK-###); projectRoot must match the root used by earlier phases.
Inputs: taskId (required), projectRoot. Returns: _sdt, error, _phase, output, +3 more
vdd_initInitialize ConstitutionADestructiveInspect
VDD Phase 0: Generate constitution.md at the project root — the immutable tech stack, conventions, security constraints, naming rules, and banned patterns that every later phase obeys. Overwrites any existing constitution.md. Run this first, before vdd_vision; to change a constitution that already exists, use vdd_amend instead of re-running this. projectRoot sets the directory constitution.md is written to and that later phases resolve every vdd/ artifact against (default "."). Parameter relationships: projectRoot defaults to "." and must be the same root every later phase resolves against.
Inputs: projectRoot. Returns: _sdt, error, _phase, output, +3 more
vdd_inspectInspect ProjectARead-onlyIdempotentInspect
VDD Cross-phase: Read-only inspection of the current project in one call — scope selects the view. scope="project" (default) returns the bidirectional V→S→T→SP→PL→TK traceability matrix across all vdd/ artifacts; scope="feature" returns per-feature spec metrics (acceptance-criteria count, unresolved [NEEDS CLARIFICATION] markers, [e.g.] placeholder density, and whether plan.md/tasks.md exist). Never modifies files. Pass feature for the feature scope; for release-readiness validation with gates use vdd_validate, and to author a spec use vdd_specify. Output is a structured matrix/metrics object, not prose. Parameter relationships: scope="feature" requires feature, while scope="project" (the default) ignores it; projectRoot must match the root used by earlier phases.
Inputs: scope, feature, projectRoot. Returns: _sdt, error, _phase, output, +3 more
vdd_planGenerate PlanADestructiveInspect
VDD Phase 5: Generate the technical blueprint under vdd/specs// — plan.md (component breakdown, AC coverage map, technology choices, verification toolchain), data-model.md (entities, indexes, migrations), and contracts/ (request/response/error schemas). Overwrites these files. Requires an existing spec for the feature; run after vdd_specify or vdd_clarify and before vdd_tasks — if no spec exists yet, run vdd_specify first. Parameter relationships: feature must match the value passed to vdd_specify and vdd_tasks.
Inputs: feature (required), projectRoot. Returns: _sdt, error, _phase, output, +3 more
vdd_specifyGenerate SpecADestructiveInspect
VDD Phase 4: Generate vdd/specs//spec.md for one tactical action item — user stories, Always/Ask/Never boundaries, Given/When/Then acceptance criteria (AC), MoSCoW priorities, non-functional requirements, and impact verification. Overwrites the spec file. Pass actionItemId (e.g. "A-001") or a freeform description to skip the V/S/T chain. Use for a NEW spec; to resolve leftover [NEEDS CLARIFICATION] markers in an existing spec use vdd_clarify instead. Parameter relationships: feature names the vdd/specs// directory and must match the feature passed to vdd_clarify, vdd_plan, and vdd_tasks; actionItemId is the A-### id from tactics.md and is optional when authoring from a freeform description.
Inputs: feature, description, projectRoot, actionItemId. Returns: _sdt, error, _phase, output, +3 more
vdd_strategizeResearch StrategyADestructiveInspect
VDD Phase 2: Produce research-backed strategy into vdd/strategy.md — strategic pillars, competitive analysis, and a risk register, resolved from the vision target-domain primers. Overwrites vdd/strategy.md. Requires vdd/vision.md; run after vdd_vision and before vdd_tactics. Two-pass: call once with availableTools to get the research-subagent dispatch specs, then re-call with researchFindings to synthesize strategy.md (a first call with neither returns only the dispatch specs). To change strategy after artifacts exist, use vdd_amend. Parameter relationships: availableTools and capabilities are aliases (pass one); researchFindings only has an effect on the second call.
Inputs: projectRoot, capabilities, availableTools, researchFindings. Returns: _sdt, error, _phase, output, +3 more
vdd_tacticsAudit TacticsADestructiveInspect
VDD Phase 3: Audit the existing codebase into vdd/tactics.md — repo audit, technical-debt assessment, gap analysis, MoSCoW-prioritized action items (A-001, A-002, …), dependency map, and infrastructure requirements. Overwrites vdd/tactics.md. Requires vdd/strategy.md; run after vdd_strategize and before vdd_specify. Needs a filesystem-capable host to scan the repo, so check with vdd_detect_environment first if the host may lack one. Parameter relationships: projectRoot must match the root used by vdd_init, vdd_vision, and vdd_strategize; requires vdd/strategy.md to exist.
Inputs: projectRoot. Returns: _sdt, error, _phase, output, +3 more
vdd_tasksGenerate TasksADestructiveInspect
VDD Phase 6: Break the plan into atomic test-first tasks in vdd/specs//tasks.md — each references acceptance criteria (AC) and contracts, is sized S/M/L, and is marked [P] when parallelizable. Overwrites tasks.md. Requires plan.md; run after vdd_plan. To fetch the next uncompleted task from an existing tasks.md use vdd_get_next_task instead of re-running this. Parameter relationships: feature must match the value passed to vdd_plan.
Inputs: feature (required), projectRoot. Returns: _sdt, error, _phase, output, +3 more
vdd_validateValidate ImpactAIdempotentInspect
VDD Phase 8: Validate the full chain — bidirectional traceability matrix, drift detection, orphan detection, uncovered vision goals, impact metrics vs targets, and 28 S&T assumption checks across 7 gates. Writes vdd/impact-report.generated.md and never overwrites a hand-authored vdd/impact-report.md. Run after implementation is complete; for the traceability matrix or per-feature spec metrics use vdd_inspect. Parameter relationships: feature narrows the check to one spec; artifactFiles maps artifact path to content for serverless runs and is omitted when resolving against a local projectRoot.
Inputs: feature, projectRoot, artifactFiles. Returns: _sdt, error, _phase, output, +3 more
vdd_visionExpand VisionADestructiveInspect
VDD Phase 1: Expand a freeform vision statement into vdd/vision.md — Impact Model (Goal, Actors, Impacts), Stakeholder Map, Success Metrics (leading + lagging), Constraints & Boundaries, and Target Domains. Overwrites any existing vdd/vision.md. Requires statement (freeform 1-3 paragraph intent, not a title) and a prior vdd_init. Run once, after vdd_init and before vdd_strategize; to revise a vision once downstream artifacts exist, use vdd_amend so the change cascades instead of re-running this. Parameter relationships: statement must be freeform prose (1-3 paragraphs), not a title; projectRoot must match the root used by vdd_init.
Inputs: statement (required), projectRoot. Returns: _sdt, error, _phase, output, +3 more
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
TDQS
Scored across 15 tools
Each tool targets a distinct phase or cross-phase operation, and the descriptions explicitly clarify boundaries by directing users to alternatives (e.g., vdd_amend vs. re-running a phase, vdd_inspect vs. vdd_validate). Overlaps are minimal and well-resolved.
All tool names use the same snake_case convention with the vdd_ prefix, making the set highly predictable. Slight noun/verb variation (vdd_vision vs. vdd_implement) reflects phase artifacts vs. actions without breaking consistency.
The 15 tools map cleanly onto an 8-phase pipeline plus necessary cross-phase helpers such as amend, clone, inspect, and environment detection. No tool appears redundant, and the count is well-scoped for the methodology.
The surface covers the full VDD lifecycle from constitution creation through implementation and final validation, including clarification, task iteration, change management, and environment detection. No obvious domain gaps are present.
Maintenance
Related MCP Connectors
Autonomous AI developers on your own infrastructure: assign a task, get a pull request.
Generate architecture docs, implementation plans, and dev tickets from your project requirements.
Turn PRDs and product ideas into structured specs so coding agents build your intent, not theirs.
Read-only AI coding tools for change verification, release readiness, capacity, and guidance.
Related MCP Servers
- AlicenseBqualityDmaintenanceTransforms any prompt into a fully functional, production-ready product with zero human intervention by providing 150+ autonomous tools covering all aspects of software development.331MIT
- AlicenseAqualityBmaintenanceA read-only MCP server so AI agents can query the corpus or the live site.1216MIT
- AlicenseAqualityBmaintenanceStartup valuation calculators for AI agents: 14 MCP tools covering 80+ formulas from the Startup Valuation textbook — probability, time value, CAPM, pre-revenue methods (Scorecard, Berkus, VC Method), options, comparables, SaaS, marketplace, fintech, biotech, hardware, international, stakeholder equity, and emerging methods.143MIT
- AlicenseAqualityBmaintenance14 tools for intangible asset valuation: time value, discount rates, cost/market/income approaches, relief from royalty, MPEEM, IP, technology, customer and workforce assets, purchase price allocation, impairment, royalty analysis, Monte Carlo and decision trees. 124+ textbook formulas.1424 PyPI2MIT