specforge-mcp 0.7.0 → 0.8.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "specforge-mcp",
|
|
3
|
-
"version": "0.
|
|
3
|
+
"version": "0.8.0",
|
|
4
4
|
"description": "SpecForge — MCP Server for Spec Driven Development. Manages specs, estimations, reverse engineering, and auto-learning across any language/framework.",
|
|
5
5
|
"type": "module",
|
|
6
6
|
"main": "dist/index.js",
|
|
@@ -85,7 +85,7 @@
|
|
|
85
85
|
"notImplemented": "clarify_requirements is not yet implemented"
|
|
86
86
|
},
|
|
87
87
|
"create_spec": {
|
|
88
|
-
"description": "Create a full SDD spec from a description. Call this directly — no need to run clarify_requirements first. IMPORTANT:
|
|
88
|
+
"description": "Create a full SDD spec from a description. Call this directly — no need to run clarify_requirements first. IMPORTANT — UX behavior: When the user describes something broad (e.g. 'build me a billing system', 'I want an e-commerce app'), DO NOT create a single spec. Instead: 1) Break it down into multiple specs (authentication, products, cart, payments, etc.). 2) Present the plan BEFORE creating anything: 'Based on what you told me, I am going to create X specs to cover everything you need: [list each spec with a one-line summary]. Each spec is a detailed plan with acceptance criteria — think of it as a checklist of what done looks like. Shall I go ahead?' 3) Wait for confirmation, then call create_spec once per feature. 4) After creating all specs, summarize: what was created, estimated total effort, and suggested order of implementation. For small/single features, explain briefly what the spec will contain and create it directly. Always be friendly and use plain language.",
|
|
89
89
|
"success": "Spec {id} created: {title}",
|
|
90
90
|
"notImplemented": "create_spec is not yet implemented"
|
|
91
91
|
},
|
|
@@ -85,7 +85,7 @@
|
|
|
85
85
|
"notImplemented": "clarify_requirements aún no está implementado"
|
|
86
86
|
},
|
|
87
87
|
"create_spec": {
|
|
88
|
-
"description": "Crear una spec SDD completa desde una descripción. Llamar directamente — no necesita ejecutar clarify_requirements primero. IMPORTANTE:
|
|
88
|
+
"description": "Crear una spec SDD completa desde una descripción. Llamar directamente — no necesita ejecutar clarify_requirements primero. IMPORTANTE — Comportamiento UX: Cuando el usuario describe algo amplio (ej: 'hazme un sistema de facturación', 'quiero una app de e-commerce'), NO crees una sola spec. En su lugar: 1) Descompón en múltiples specs (autenticación, productos, carrito, pagos, etc.). 2) Presenta el plan ANTES de crear nada: 'Basándome en lo que me contaste, voy a crear X specs para cubrir todo lo que necesitas: [lista cada spec con un resumen de una línea]. Cada spec es un plan detallado con criterios de aceptación — piénsalo como una checklist de qué significa que esté terminado. ¿Le damos?' 3) Espera confirmación, luego llama create_spec una vez por feature. 4) Después de crear todas, resume: qué se creó, esfuerzo total estimado y orden sugerido de implementación. Para features pequeñas/individuales, explica brevemente qué contendrá la spec y créala directamente. Siempre sé amigable y usa lenguaje simple.",
|
|
89
89
|
"success": "Spec {id} creada: {title}",
|
|
90
90
|
"notImplemented": "create_spec aún no está implementado"
|
|
91
91
|
},
|
|
@@ -85,7 +85,7 @@
|
|
|
85
85
|
"notImplemented": "clarify_requirements ainda não está implementado"
|
|
86
86
|
},
|
|
87
87
|
"create_spec": {
|
|
88
|
-
"description": "Criar uma spec SDD completa a partir de uma descrição. Chamar diretamente — não precisa executar clarify_requirements antes. IMPORTANTE:
|
|
88
|
+
"description": "Criar uma spec SDD completa a partir de uma descrição. Chamar diretamente — não precisa executar clarify_requirements antes. IMPORTANTE — Comportamento UX: Quando o usuário descreve algo amplo (ex: 'me faz um sistema de faturamento', 'quero um app de e-commerce'), NÃO crie uma única spec. Em vez disso: 1) Decomponha em múltiplas specs (autenticação, produtos, carrinho, pagamentos, etc.). 2) Apresente o plano ANTES de criar: 'Com base no que você me contou, vou criar X specs para cobrir tudo que precisa: [lista cada spec com resumo de uma linha]. Cada spec é um plano detalhado com critérios de aceitação — pense como uma checklist do que significa estar pronto. Posso ir em frente?' 3) Espere confirmação, depois chame create_spec uma vez por feature. 4) Após criar todas, resuma: o que foi criado, esforço total estimado e ordem sugerida de implementação. Para features pequenas/individuais, explique brevemente e crie direto. Sempre seja amigável e use linguagem simples.",
|
|
89
89
|
"success": "Spec {id} criada: {title}",
|
|
90
90
|
"notImplemented": "create_spec ainda não está implementado"
|
|
91
91
|
},
|