specforge-mcp 0.9.0 → 0.10.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/dist/index.js
CHANGED
|
@@ -61,6 +61,13 @@ const server = new McpServer({
|
|
|
61
61
|
'4. When presenting lists or results, use plain language headers — not jargon.',
|
|
62
62
|
'5. If the user seems confused, offer to explain further. Never assume knowledge.',
|
|
63
63
|
"6. Adapt your language to the user's locale (English, Spanish, or Portuguese).",
|
|
64
|
+
'',
|
|
65
|
+
'GIT WORKFLOW — suggest branches at key moments:',
|
|
66
|
+
'- After creating spec(s): suggest creating a feature branch (e.g., "git checkout -b feat/SPEC-XXX-feature-name").',
|
|
67
|
+
'- When a spec moves to "implementing": remind the user to work in a dedicated branch, not directly on main or develop.',
|
|
68
|
+
'- Use manage_git to create branches, generate PR descriptions, and link them to specs.',
|
|
69
|
+
'- Branch naming convention: feat/SPEC-XXX-short-name for features, fix/SPEC-XXX-short-name for fixes.',
|
|
70
|
+
'- Explain why: "Working in a separate branch keeps your main code safe while you build this feature. When it is ready, you merge it back."',
|
|
64
71
|
].join('\n'),
|
|
65
72
|
});
|
|
66
73
|
// ---------------------------------------------------------------------------
|
package/dist/index.js.map
CHANGED
|
@@ -1 +1 @@
|
|
|
1
|
-
{"version":3,"file":"index.js","sourceRoot":"","sources":["../src/index.ts"],"names":[],"mappings":";AACA,mDAAmD;AACnD,mFAAmF;AAEnF,OAAO,EAAE,SAAS,EAAE,MAAM,yCAAyC,CAAC;AACpE,OAAO,EAAE,oBAAoB,EAAE,MAAM,2CAA2C,CAAC;AAEjF,OAAO,EAAE,iBAAiB,EAAE,MAAM,yBAAyB,CAAC;AAC5D,OAAO,EAAE,iBAAiB,EAAE,MAAM,gCAAgC,CAAC;AACnE,OAAO,EAAE,qBAAqB,EAAE,MAAM,oCAAoC,CAAC;AAC3E,OAAO,EAAE,qBAAqB,EAAE,MAAM,oCAAoC,CAAC;AAC3E,OAAO,EAAE,qBAAqB,EAAE,MAAM,oCAAoC,CAAC;AAC3E,OAAO,EAAE,sBAAsB,EAAE,MAAM,qCAAqC,CAAC;AAC7E,OAAO,EAAE,uBAAuB,EAAE,MAAM,sCAAsC,CAAC;AAC/E,OAAO,EAAE,kBAAkB,EAAE,MAAM,iCAAiC,CAAC;AACrE,OAAO,EAAE,oBAAoB,EAAE,MAAM,mCAAmC,CAAC;AACzE,OAAO,EAAE,wBAAwB,EAAE,MAAM,uCAAuC,CAAC;AACjF,OAAO,EAAE,kBAAkB,EAAE,MAAM,iCAAiC,CAAC;AACrE,OAAO,EAAE,sBAAsB,EAAE,MAAM,qCAAqC,CAAC;AAC7E,OAAO,EAAE,mBAAmB,EAAE,MAAM,kCAAkC,CAAC;AACvE,OAAO,EAAE,kBAAkB,EAAE,MAAM,iCAAiC,CAAC;AACrE,OAAO,EAAE,6BAA6B,EAAE,MAAM,gCAAgC,CAAC;AAC/E,OAAO,EAAE,kBAAkB,EAAE,MAAM,iCAAiC,CAAC;AACrE,OAAO,EAAE,qBAAqB,EAAE,MAAM,oCAAoC,CAAC;AAC3E,OAAO,EAAE,iBAAiB,EAAE,MAAM,qBAAqB,CAAC;AAExD,8EAA8E;AAC9E,eAAe;AACf,8EAA8E;AAE9E,MAAM,MAAM,GAAG,IAAI,SAAS,CAC1B;IACE,IAAI,EAAE,WAAW;IACjB,OAAO,EAAE,iBAAiB;CAC3B,EACD;IACE,YAAY,EAAE;QACZ,iGAAiG;QACjG,EAAE;QACF,wDAAwD;QACxD,EAAE;QACF,wFAAwF;QACxF,0FAA0F;QAC1F,qFAAqF;QACrF,8EAA8E;QAC9E,yEAAyE;QACzE,6EAA6E;QAC7E,6EAA6E;QAC7E,+HAA+H;QAC/H,oGAAoG;QACpG,qFAAqF;QACrF,2FAA2F;QAC3F,oGAAoG;QACpG,gHAAgH;QAChH,0FAA0F;QAC1F,qFAAqF;QACrF,gGAAgG;QAChG,yEAAyE;QACzE,kGAAkG;QAClG,sHAAsH;QACtH,yFAAyF;QACzF,yEAAyE;QACzE,qFAAqF;QACrF,EAAE;QACF,6DAA6D;QAC7D,sEAAsE;QACtE,+EAA+E;QAC/E,kFAAkF;QAClF,gFAAgF;
|
|
1
|
+
{"version":3,"file":"index.js","sourceRoot":"","sources":["../src/index.ts"],"names":[],"mappings":";AACA,mDAAmD;AACnD,mFAAmF;AAEnF,OAAO,EAAE,SAAS,EAAE,MAAM,yCAAyC,CAAC;AACpE,OAAO,EAAE,oBAAoB,EAAE,MAAM,2CAA2C,CAAC;AAEjF,OAAO,EAAE,iBAAiB,EAAE,MAAM,yBAAyB,CAAC;AAC5D,OAAO,EAAE,iBAAiB,EAAE,MAAM,gCAAgC,CAAC;AACnE,OAAO,EAAE,qBAAqB,EAAE,MAAM,oCAAoC,CAAC;AAC3E,OAAO,EAAE,qBAAqB,EAAE,MAAM,oCAAoC,CAAC;AAC3E,OAAO,EAAE,qBAAqB,EAAE,MAAM,oCAAoC,CAAC;AAC3E,OAAO,EAAE,sBAAsB,EAAE,MAAM,qCAAqC,CAAC;AAC7E,OAAO,EAAE,uBAAuB,EAAE,MAAM,sCAAsC,CAAC;AAC/E,OAAO,EAAE,kBAAkB,EAAE,MAAM,iCAAiC,CAAC;AACrE,OAAO,EAAE,oBAAoB,EAAE,MAAM,mCAAmC,CAAC;AACzE,OAAO,EAAE,wBAAwB,EAAE,MAAM,uCAAuC,CAAC;AACjF,OAAO,EAAE,kBAAkB,EAAE,MAAM,iCAAiC,CAAC;AACrE,OAAO,EAAE,sBAAsB,EAAE,MAAM,qCAAqC,CAAC;AAC7E,OAAO,EAAE,mBAAmB,EAAE,MAAM,kCAAkC,CAAC;AACvE,OAAO,EAAE,kBAAkB,EAAE,MAAM,iCAAiC,CAAC;AACrE,OAAO,EAAE,6BAA6B,EAAE,MAAM,gCAAgC,CAAC;AAC/E,OAAO,EAAE,kBAAkB,EAAE,MAAM,iCAAiC,CAAC;AACrE,OAAO,EAAE,qBAAqB,EAAE,MAAM,oCAAoC,CAAC;AAC3E,OAAO,EAAE,iBAAiB,EAAE,MAAM,qBAAqB,CAAC;AAExD,8EAA8E;AAC9E,eAAe;AACf,8EAA8E;AAE9E,MAAM,MAAM,GAAG,IAAI,SAAS,CAC1B;IACE,IAAI,EAAE,WAAW;IACjB,OAAO,EAAE,iBAAiB;CAC3B,EACD;IACE,YAAY,EAAE;QACZ,iGAAiG;QACjG,EAAE;QACF,wDAAwD;QACxD,EAAE;QACF,wFAAwF;QACxF,0FAA0F;QAC1F,qFAAqF;QACrF,8EAA8E;QAC9E,yEAAyE;QACzE,6EAA6E;QAC7E,6EAA6E;QAC7E,+HAA+H;QAC/H,oGAAoG;QACpG,qFAAqF;QACrF,2FAA2F;QAC3F,oGAAoG;QACpG,gHAAgH;QAChH,0FAA0F;QAC1F,qFAAqF;QACrF,gGAAgG;QAChG,yEAAyE;QACzE,kGAAkG;QAClG,sHAAsH;QACtH,yFAAyF;QACzF,yEAAyE;QACzE,qFAAqF;QACrF,EAAE;QACF,6DAA6D;QAC7D,sEAAsE;QACtE,+EAA+E;QAC/E,kFAAkF;QAClF,gFAAgF;QAChF,EAAE;QACF,iDAAiD;QACjD,mHAAmH;QACnH,wHAAwH;QACxH,wFAAwF;QACxF,uGAAuG;QACvG,4IAA4I;KAC7I,CAAC,IAAI,CAAC,IAAI,CAAC;CACb,CACF,CAAC;AAEF,8EAA8E;AAC9E,mCAAmC;AACnC,8EAA8E;AAE9E,iBAAiB,CAAC,MAAM,CAAC,CAAC;AAC1B,iBAAiB,CAAC,MAAM,CAAC,CAAC;AAC1B,qBAAqB,CAAC,MAAM,CAAC,CAAC;AAC9B,qBAAqB,CAAC,MAAM,CAAC,CAAC;AAC9B,qBAAqB,CAAC,MAAM,CAAC,CAAC;AAC9B,sBAAsB,CAAC,MAAM,CAAC,CAAC;AAC/B,uBAAuB,CAAC,MAAM,CAAC,CAAC;AAChC,kBAAkB,CAAC,MAAM,CAAC,CAAC;AAC3B,oBAAoB,CAAC,MAAM,CAAC,CAAC;AAC7B,wBAAwB,CAAC,MAAM,CAAC,CAAC;AACjC,kBAAkB,CAAC,MAAM,CAAC,CAAC;AAC3B,sBAAsB,CAAC,MAAM,CAAC,CAAC;AAC/B,mBAAmB,CAAC,MAAM,CAAC,CAAC;AAC5B,kBAAkB,CAAC,MAAM,CAAC,CAAC;AAC3B,6BAA6B,CAAC,MAAM,CAAC,CAAC;AACtC,kBAAkB,CAAC,MAAM,CAAC,CAAC;AAC3B,qBAAqB,CAAC,MAAM,CAAC,CAAC;AAE9B,8EAA8E;AAC9E,eAAe;AACf,8EAA8E;AAE9E,KAAK,UAAU,IAAI;IACjB,MAAM,SAAS,GAAG,IAAI,oBAAoB,EAAE,CAAC;IAC7C,MAAM,MAAM,CAAC,OAAO,CAAC,SAAS,CAAC,CAAC;AAClC,CAAC;AAED,OAAO,CAAC,EAAE,CAAC,mBAAmB,EAAE,CAAC,KAAc,EAAE,EAAE;IACjD,sBAAsB;IACtB,OAAO,CAAC,KAAK,CAAC,iCAAiC,EAAE,KAAK,CAAC,CAAC;AAC1D,CAAC,CAAC,CAAC;AAEH,OAAO,CAAC,EAAE,CAAC,oBAAoB,EAAE,CAAC,MAAe,EAAE,EAAE;IACnD,sBAAsB;IACtB,OAAO,CAAC,KAAK,CAAC,kCAAkC,EAAE,MAAM,CAAC,CAAC;AAC5D,CAAC,CAAC,CAAC;AAEH,IAAI,EAAE,CAAC,KAAK,CAAC,CAAC,KAAc,EAAE,EAAE;IAC9B,OAAO,CAAC,KAAK,CAAC,uCAAuC,EAAE,KAAK,CAAC,CAAC;IAC9D,OAAO,CAAC,IAAI,CAAC,CAAC,CAAC,CAAC;AAClB,CAAC,CAAC,CAAC"}
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "specforge-mcp",
|
|
3
|
-
"version": "0.
|
|
3
|
+
"version": "0.10.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 — 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.",
|
|
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. 5) ALWAYS suggest creating a git branch for implementation: 'Now I recommend creating a branch to work on this safely: git checkout -b feat/SPEC-XXX-feature-name. This keeps your main code protected while you build.' Use manage_git to help. 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
|
},
|
|
@@ -95,7 +95,7 @@
|
|
|
95
95
|
"notImplemented": "list_specs is not yet implemented"
|
|
96
96
|
},
|
|
97
97
|
"update_status": {
|
|
98
|
-
"description": "Move a plan forward in its lifecycle. Plans go through these stages: draft (work in progress) → review (ready for someone to check) → approved (ready to build) → implementing (being built) → done (finished and verified).",
|
|
98
|
+
"description": "Move a plan forward in its lifecycle. Plans go through these stages: draft (work in progress) → review (ready for someone to check) → approved (ready to build) → implementing (being built) → done (finished and verified). IMPORTANT: When moving to 'implementing', ALWAYS suggest creating a dedicated git branch: 'Before you start building, let me create a branch for this spec so your changes are isolated: git checkout -b feat/SPEC-XXX-name.' When moving to 'done', suggest merging: 'This feature is complete! You can now merge your branch back and create a pull request.' Use manage_git to help with branch creation and PR descriptions.",
|
|
99
99
|
"success": "Spec {specId} status updated to {status}",
|
|
100
100
|
"notImplemented": "update_status is not yet implemented"
|
|
101
101
|
},
|
|
@@ -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 — 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.",
|
|
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. 5) SIEMPRE sugiere crear una rama git para implementar: 'Ahora te recomiendo crear una rama para trabajar de forma segura: git checkout -b feat/SPEC-XXX-nombre-feature. Así tu código principal queda protegido mientras construyes.' Usa manage_git para ayudar. 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
|
},
|
|
@@ -95,7 +95,7 @@
|
|
|
95
95
|
"notImplemented": "list_specs aún no está implementado"
|
|
96
96
|
},
|
|
97
97
|
"update_status": {
|
|
98
|
-
"description": "Mover un plan hacia adelante en su ciclo de vida. Los planes pasan por estas etapas: borrador (trabajo en progreso) → revisión (listo para que alguien lo revise) → aprobado (listo para construir) → implementando (se está construyendo) → terminado (completado y verificado).",
|
|
98
|
+
"description": "Mover un plan hacia adelante en su ciclo de vida. Los planes pasan por estas etapas: borrador (trabajo en progreso) → revisión (listo para que alguien lo revise) → aprobado (listo para construir) → implementando (se está construyendo) → terminado (completado y verificado). IMPORTANTE: Al mover a 'implementando', SIEMPRE sugiere crear una rama git dedicada: 'Antes de empezar a construir, vamos a crear una rama para esta spec así tus cambios quedan aislados: git checkout -b feat/SPEC-XXX-nombre.' Al mover a 'terminado', sugiere mergear: '¡Esta feature está completa! Ahora puedes mergear tu rama y crear un pull request.' Usa manage_git para ayudar con la creación de ramas y descripciones de PR.",
|
|
99
99
|
"success": "Spec {specId} actualizada a estado {status}",
|
|
100
100
|
"notImplemented": "update_status aún no está implementado"
|
|
101
101
|
},
|
|
@@ -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 — 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.",
|
|
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. 5) SEMPRE sugira criar uma branch git para implementação: 'Agora recomendo criar uma branch para trabalhar com segurança: git checkout -b feat/SPEC-XXX-nome-feature. Assim seu código principal fica protegido enquanto você constrói.' Use manage_git para ajudar. 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
|
},
|
|
@@ -95,7 +95,7 @@
|
|
|
95
95
|
"notImplemented": "list_specs ainda não está implementado"
|
|
96
96
|
},
|
|
97
97
|
"update_status": {
|
|
98
|
-
"description": "Mover um plano adiante no seu ciclo de vida. Os planos passam por estas etapas: rascunho (trabalho em progresso) → revisão (pronto para alguém verificar) → aprovado (pronto para construir) → implementando (sendo construído) → concluído (terminado e verificado).",
|
|
98
|
+
"description": "Mover um plano adiante no seu ciclo de vida. Os planos passam por estas etapas: rascunho (trabalho em progresso) → revisão (pronto para alguém verificar) → aprovado (pronto para construir) → implementando (sendo construído) → concluído (terminado e verificado). IMPORTANTE: Ao mover para 'implementando', SEMPRE sugira criar uma branch git dedicada: 'Antes de começar a construir, vamos criar uma branch para esta spec assim suas mudanças ficam isoladas: git checkout -b feat/SPEC-XXX-nome.' Ao mover para 'concluído', sugira fazer merge: 'Esta feature está completa! Agora você pode fazer merge da sua branch e criar um pull request.' Use manage_git para ajudar com criação de branches e descrições de PR.",
|
|
99
99
|
"success": "Spec {specId} atualizada para status {status}",
|
|
100
100
|
"notImplemented": "update_status ainda não está implementado"
|
|
101
101
|
},
|