/ Directorio / Playground / Spec Workflow
● Comunidad Pimzino ⚡ Instantáneo

Spec Workflow

por Pimzino · Pimzino/spec-workflow-mcp

Flujo estructurado de Requisitos → Diseño → Tareas con panel en vivo y puertas de aprobación humana — para que Claude no se ponga a codificar sin control.

Spec Workflow convierte el desarrollo de funcionalidades en un pipeline de tres etapas: documento de requisitos, documento de diseño y lista de tareas. Cada etapa requiere aprobación (vía panel web o barra lateral de VSCode) antes de continuar. Claude no puede saltarse pasos, escribe registros de implementación y hace seguimiento del progreso en cada tarea. Se siente como un Jira para Claude.

Por qué usarlo

Características clave

Demo en vivo

Cómo se ve en la práctica

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

Instalar

Elige tu cliente

~/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"
      ]
    }
  }
}

Abre Claude Desktop → Settings → Developer → Edit Config. Reinicia después de guardar.

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

Cursor usa el mismo esquema mcpServers que Claude Desktop. La configuración del proyecto prevalece sobre la global.

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

Haz clic en el icono MCP Servers de la barra lateral de Cline y luego en "Edit Configuration".

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

Mismo formato que Claude Desktop. Reinicia Windsurf para aplicar.

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

Continue usa un array de objetos de servidor en lugar de un mapa.

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

Añádelo a context_servers. Zed recarga en caliente al guardar.

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

Un solo comando. Verifica con claude mcp list. Quita con claude mcp remove.

Casos de uso

Usos del mundo real: Spec Workflow

Construir una funcionalidad con especificación, no con un prompt a ciegas

👤 Desarrolladores que entregan funcionalidades de complejidad media ⏱ ~90 min intermediate

Cuándo usarlo: Estás a punto de pedirle a Claude que «añada OAuth» y temes el diff de 500 líneas que llegará de golpe.

Requisitos previos
  • Ruta del proyecto conocida — El MCP se lanza con /ruta/al/proyecto como argumento
Flujo
  1. Requisitos
    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?✓ Copiado
    → Documento de requisitos redactado, enlace al panel para aprobación
  2. Aprobar + Diseño
    I approved in the dashboard. Now write the design: components, data model, sequence diagram, error cases.✓ Copiado
    → Documento de diseño con arquitectura concreta
  3. Tareas + Ejecución
    I approved. Break into tasks. Then execute task 1.1 — just that one, stop after.✓ Copiado
    → Lista de tareas creada; solo la tarea 1.1 implementada con entrada en el registro

Resultado: Una funcionalidad entregada con artefactos intermedios revisables — no un diff misterioso.

Errores comunes
  • Claude intenta saltar directamente al código — El MCP lo bloquea — pero sé explícito en los prompts de todas formas: "no implementes aún"
Combinar con: github · filesystem

Conseguir que un stakeholder no técnico apruebe una especificación antes de que empiece el código

👤 Equipos con ciclos de aprobación de PM o diseño ⏱ ~60 min intermediate

Cuándo usarlo: Necesitas la aprobación del PM antes de la implementación y el PM no lee los PRs de GitHub.

Requisitos previos
  • URL del panel compartible — Redirige el puerto o expón localhost:5000 via ngrok para PMs remotos
Flujo
  1. Especificación
    Draft the requirements doc for checkout-v2 and share the dashboard URL.✓ Copiado
    → Documento + enlace compartible
  2. Iterar con feedback
    PM left 3 revision comments in the dashboard. Fetch them and revise the doc.✓ Copiado
    → Documento actualizado con historial de revisiones visible
  3. Ejecutar tras la aprobación
    Approval just went through — proceed to design.✓ Copiado
    → Comienza la siguiente etapa; timestamp de aprobación registrado

Resultado: Cadena de aprobación trazable por parte de stakeholders no técnicos.

Errores comunes
  • Panel no accesible para usuarios remotos — Usa Tailscale o ngrok con autenticación
Combinar con: github

Combinaciones

Combínalo con otros MCPs para multiplicar por 10

spec-workflow-mcp + github

Abrir un PR por cada tarea aprobada

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

Guardar las especificaciones en el repositorio junto al código

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

Herramientas

Lo que expone este MCP

HerramientaEntradasCuándo llamarCoste
create_spec name: str Iniciar una nueva funcionalidad free
write_requirements spec_id, content: markdown Primera fase de cualquier especificación free
write_design spec_id, content: markdown Tras la aprobación de requisitos free
create_tasks spec_id, tasks: [] Tras la aprobación del diseño free
execute_task spec_id, task_id Implementar una tarea a la vez free
get_approval_status spec_id, stage Puerta de acceso a la siguiente etapa free

Coste y límites

Lo que cuesta ejecutarlo

Cuota de API
Local
Tokens por llamada
Proporcional al tamaño del documento o la tarea
Monetario
Gratuito
Consejo
Mantén los requisitos concisos — el coste de aprobación es tiempo humano, no tokens

Seguridad

Permisos, secretos, alcance

Ámbitos mínimos: filesystem-write (for spec docs)
Almacenamiento de credenciales: Ninguno
Salida de datos: Ninguno — panel en localhost

Resolución de problemas

Errores comunes y soluciones

El panel no carga

Lánzalo explícitamente: npx -y @pimzino/spec-workflow-mcp@latest --dashboard

Verificar: Visit localhost:5000
Puerto 5000 en uso (AirPlay de macOS)

Pasa --port 5050 o desactiva AirPlay Receiver en Configuración del Sistema

Verificar: Check with `lsof -i :5000`
Las tareas siguen en pendiente después de aprobar

El cliente MCP puede estar cacheando resultados antiguos — reinícialo

Alternativas

Spec Workflow vs otros

AlternativaCuándo usarlaContrapartida
Plain Markdown in /docsDesarrollador en solitario sin necesidad de ciclo de aprobaciónSin estructura forzada, sin panel
Linear MCPYa usas Linear para tareas y quieres que Claude trabaje directamente con los issuesSin capa de documentación de especificaciones

Más

Recursos

📖 Lee el README oficial en GitHub

🐙 Ver issues abiertas

🔍 Ver todos los 400+ servidores MCP y Skills