/ Directory / Playground / Spec Workflow
● Community Pimzino ⚡ Instant

Spec Workflow

by Pimzino · Pimzino/spec-workflow-mcp

Structured Requirements → Design → Tasks workflow with a live dashboard and human approval gates — stop Claude YOLO-coding features.

Spec Workflow turns feature development into a three-stage pipeline: Requirements doc, Design doc, Task list. Each stage requires approval (via web dashboard or VSCode sidebar) before moving on. Claude can't skip ahead, writes implementation logs, and tracks progress bar state on every task. Feels like Jira-for-Claude.

Why use it

Key features

Live Demo

What it looks like in practice

spec-workflow-mcp.replay ▶ ready
0/0

Install

Pick your client

~/Library/Application Support/Claude/claude_desktop_config.json  · Windows: %APPDATA%\Claude\claude_desktop_config.json
{
  "mcpServers": {
    "spec-workflow-mcp": {
      "command": "npx",
      "args": [
        "-y",
        "@pimzino/spec-workflow-mcp@latest",
        "/path/to/project"
      ]
    }
  }
}

Open Claude Desktop → Settings → Developer → Edit Config. Restart after saving.

~/.cursor/mcp.json · .cursor/mcp.json
{
  "mcpServers": {
    "spec-workflow-mcp": {
      "command": "npx",
      "args": [
        "-y",
        "@pimzino/spec-workflow-mcp@latest",
        "/path/to/project"
      ]
    }
  }
}

Cursor uses the same mcpServers schema as Claude Desktop. Project config wins over global.

VS Code → Cline → MCP Servers → Edit
{
  "mcpServers": {
    "spec-workflow-mcp": {
      "command": "npx",
      "args": [
        "-y",
        "@pimzino/spec-workflow-mcp@latest",
        "/path/to/project"
      ]
    }
  }
}

Click the MCP Servers icon in the Cline sidebar, then "Edit Configuration".

~/.codeium/windsurf/mcp_config.json
{
  "mcpServers": {
    "spec-workflow-mcp": {
      "command": "npx",
      "args": [
        "-y",
        "@pimzino/spec-workflow-mcp@latest",
        "/path/to/project"
      ]
    }
  }
}

Same shape as Claude Desktop. Restart Windsurf to pick up changes.

~/.continue/config.json
{
  "mcpServers": [
    {
      "name": "spec-workflow-mcp",
      "command": "npx",
      "args": [
        "-y",
        "@pimzino/spec-workflow-mcp@latest",
        "/path/to/project"
      ]
    }
  ]
}

Continue uses an array of server objects rather than a map.

~/.config/zed/settings.json
{
  "context_servers": {
    "spec-workflow-mcp": {
      "command": {
        "path": "npx",
        "args": [
          "-y",
          "@pimzino/spec-workflow-mcp@latest",
          "/path/to/project"
        ]
      }
    }
  }
}

Add to context_servers. Zed hot-reloads on save.

claude mcp add spec-workflow-mcp -- npx -y @pimzino/spec-workflow-mcp@latest /path/to/project

One-liner. Verify with claude mcp list. Remove with claude mcp remove.

Use Cases

Real-world ways to use Spec Workflow

Build a feature with a spec, not a vibe prompt

👤 Devs shipping medium-complexity features ⏱ ~90 min intermediate

When to use: You're about to ask Claude to "add OAuth" and dread the 500-line diff that will land in one go.

Prerequisites
  • Project path known — MCP is launched with /path/to/project as arg
Flow
  1. Requirements
    Use spec-workflow. Create a spec named oauth-login. Start with requirements — what are we adding, who is it for, what are the non-goals?✓ Copied
    → Requirements doc drafted, link to dashboard for approval
  2. Approve + Design
    I approved in the dashboard. Now write the design: components, data model, sequence diagram, error cases.✓ Copied
    → Design doc with concrete architecture
  3. Tasks + Execute
    I approved. Break into tasks. Then execute task 1.1 — just that one, stop after.✓ Copied
    → Task list created; only task 1.1 implemented with log entry

Outcome: A feature shipped with reviewable intermediate artifacts — not a mystery diff.

Pitfalls
  • Claude tries to skip straight to code — The MCP blocks it — but be explicit in prompts anyway: "do not implement yet"
Combine with: github · filesystem

Get a non-engineer stakeholder to approve a spec before code happens

👤 Teams with PM/design sign-off loops ⏱ ~60 min intermediate

When to use: You need PM approval before implementation and the PM doesn't read GitHub PRs.

Prerequisites
  • Dashboard URL shareable — Port-forward or expose localhost:5000 via ngrok for remote PMs
Flow
  1. Spec
    Draft the requirements doc for checkout-v2 and share the dashboard URL.✓ Copied
    → Doc + shareable link
  2. Iterate via feedback
    PM left 3 revision comments in the dashboard. Fetch them and revise the doc.✓ Copied
    → Doc updated with revision history visible
  3. Execute post-approval
    Approval just went through — proceed to design.✓ Copied
    → Next stage starts; approval timestamp logged

Outcome: Traceable approval chain from non-engineer stakeholders.

Pitfalls
  • Dashboard not reachable for remote users — Use Tailscale or ngrok with auth
Combine with: github

Combinations

Pair with other MCPs for X10 leverage

spec-workflow-mcp + github

Open a PR per approved task

After executing task 2.1, open a GitHub PR titled "feat(oauth): task 2.1" with the diff.✓ Copied
spec-workflow-mcp + filesystem

Store specs in-repo alongside code

Save the approved spec to /docs/specs/oauth-login.md and commit.✓ Copied

Tools

What this MCP exposes

ToolInputsWhen to callCost
create_spec name: str Start a new feature free
write_requirements spec_id, content: markdown First phase of any spec free
write_design spec_id, content: markdown After requirements approved free
create_tasks spec_id, tasks: [] After design approved free
execute_task spec_id, task_id Implement one task at a time free
get_approval_status spec_id, stage Gate next stage free

Cost & Limits

What this costs to run

API quota
Local
Tokens per call
Proportional to doc/task size
Monetary
Free
Tip
Keep requirements concise — the approval cost is human time, not tokens

Security

Permissions, secrets, blast radius

Minimum scopes: filesystem-write (for spec docs)
Credential storage: None
Data egress: None — localhost dashboard

Troubleshooting

Common errors and fixes

Dashboard won't load

Start it explicitly: npx -y @pimzino/spec-workflow-mcp@latest --dashboard

Verify: Visit localhost:5000
Port 5000 already in use (macOS AirPlay)

Pass --port 5050 or disable AirPlay Receiver in System Settings

Verify: Check with `lsof -i :5000`
Tasks stay in pending after approval

MCP client may be caching old tool results — restart the client

Alternatives

Spec Workflow vs others

AlternativeWhen to use it insteadTradeoff
Plain Markdown in /docsSolo dev with no approval loop neededNo structure enforcement, no dashboard
Linear MCPYou already use Linear for tasks and want Claude to touch issues directlyNo spec-doc layer

More

Resources

📖 Read the official README on GitHub

🐙 Browse open issues

🔍 Browse all 400+ MCP servers and Skills