|
| 1 | +import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js"; |
| 2 | +import { z } from "zod"; |
| 3 | +import { SPEC_PILOT_CONSTANTS } from "../shared/constants"; |
| 4 | +import { createLanguagePolicySection } from "../shared/language-policy"; |
| 5 | +import { resolveStoredLocale } from "../shared/locale"; |
| 6 | +import { createPromptResponse, joinPromptSections } from "../shared/prompt-factory"; |
| 7 | + |
| 8 | +export const registerSpecDesignPrompt = (server: McpServer) => { |
| 9 | + server.registerPrompt( |
| 10 | + "spec.design", |
| 11 | + { |
| 12 | + title: "create system design", |
| 13 | + description: "Generate comprehensive system design document from requirements.", |
| 14 | + argsSchema: { |
| 15 | + specName: z |
| 16 | + .string() |
| 17 | + .min(3, "Please provide at least 3 characters for the spec name.") |
| 18 | + .describe( |
| 19 | + "The folder name created by spec.init (slug). Used to locate the spec workspace.", |
| 20 | + ), |
| 21 | + }, |
| 22 | + }, |
| 23 | + async ({ specName }) => { |
| 24 | + // ロケール解決（設定ファイルの更新のため実行するが、この場所では値は使用しない） |
| 25 | + resolveStoredLocale(); |
| 26 | + |
| 27 | + const prompt = joinPromptSections( |
| 28 | + "# Spec Design Development", |
| 29 | + "", |
| 30 | + createLanguagePolicySection(SPEC_PILOT_CONSTANTS.CONFIG_FILE), |
| 31 | + "", |
| 32 | + "## Inputs", |
| 33 | + `- specName: ${specName}`, |
| 34 | + "- specDescription: (read from config.json and treat as authoritative source)", |
| 35 | + "- requirements: (read from requirements.md and analyze for design implications)", |
| 36 | + "", |
| 37 | + "## Workspace Context", |
| 38 | + `- Base directory: \`${SPEC_PILOT_CONSTANTS.BASE_DIR}\``, |
| 39 | + `- Spec folder path: \`${SPEC_PILOT_CONSTANTS.BASE_DIR}/${specName}\``, |
| 40 | + `- Mandatory config file: \`${SPEC_PILOT_CONSTANTS.BASE_DIR}/${specName}/${SPEC_PILOT_CONSTANTS.SPEC_CONFIG_FILE}\``, |
| 41 | + `- Requirements file to read: \`${SPEC_PILOT_CONSTANTS.BASE_DIR}/${specName}/${SPEC_PILOT_CONSTANTS.REQUIREMENTS_FILE}\``, |
| 42 | + `- Design file to create/update: \`${SPEC_PILOT_CONSTANTS.BASE_DIR}/${specName}/${SPEC_PILOT_CONSTANTS.DESIGN_FILE}\``, |
| 43 | + "", |
| 44 | + "## Goal", |
| 45 | + "- Transform structured requirements into a comprehensive, implementable system design.", |
| 46 | + "- Generate a design document that enables seamless transition from specification to implementation.", |
| 47 | + "", |
| 48 | + "## Tasks", |
| 49 | + "1. Verify the workspace:", |
| 50 | + ` - Ensure \`${SPEC_PILOT_CONSTANTS.BASE_DIR}\` and \`${SPEC_PILOT_CONSTANTS.BASE_DIR}/${specName}\` are directories.`, |
| 51 | + ` - Confirm \`${SPEC_PILOT_CONSTANTS.BASE_DIR}/${specName}/${SPEC_PILOT_CONSTANTS.SPEC_CONFIG_FILE}\` exists, parse as JSON, and capture the current title and description for context.`, |
| 52 | + ` - Verify \`${SPEC_PILOT_CONSTANTS.BASE_DIR}/${specName}/${SPEC_PILOT_CONSTANTS.REQUIREMENTS_FILE}\` exists and read its content for requirements analysis.`, |
| 53 | + " - Note any mismatches or missing files that could affect design generation.", |
| 54 | + "", |
| 55 | + "2. Analyze requirements:", |
| 56 | + " - Parse requirements.md to extract functional and non-functional requirements.", |
| 57 | + " - Identify system boundaries, key components, and integration points.", |
| 58 | + " - Determine appropriate architectural patterns based on requirements complexity and scale.", |
| 59 | + " - Extract technology constraints, performance requirements, and security considerations.", |
| 60 | + "", |
| 61 | + "3. Generate design document structure:", |
| 62 | + " - Create a comprehensive design document with these mandatory sections:", |
| 63 | + " - `# Design Document`", |
| 64 | + " - `## Overview` - concise summary of design goals and approach", |
| 65 | + " - `## Architecture` - system structure and component relationships", |
| 66 | + " - `## Component Design` - detailed component specifications", |
| 67 | + " - `## Data Flow` - data movement and processing patterns", |
| 68 | + " - `## Error Handling Strategy` - error management approach", |
| 69 | + " - `## Migration Strategy` - implementation phases and steps", |
| 70 | + " - `## Test Strategy` - testing approach and coverage", |
| 71 | + " - `## Performance Considerations` - scalability and optimization", |
| 72 | + " - `## Security` - security measures and compliance", |
| 73 | + "", |
| 74 | + "4. Create architectural representations:", |
| 75 | + " - Generate ASCII diagrams for system architecture using box-drawing characters.", |
| 76 | + " - Create Mermaid diagrams for complex flows when beneficial.", |
| 77 | + " - Include directory structures with clear file organization.", |
| 78 | + " - Show component interaction patterns with visual representations.", |
| 79 | + "", |
| 80 | + "5. Define implementation details:", |
| 81 | + " - Specify concrete technology choices with version numbers when relevant.", |
| 82 | + " - Provide code structure examples for key components.", |
| 83 | + " - Define API interfaces with request/response formats.", |
| 84 | + " - Include configuration examples and environment setup.", |
| 85 | + "", |
| 86 | + "6. Ensure design quality:", |
| 87 | + " - Verify all requirements are addressed in the design.", |
| 88 | + " - Ensure design is implementable with current technology standards.", |
| 89 | + " - Check for consistency across all sections.", |
| 90 | + " - Validate that migration strategy is realistic and phased.", |
| 91 | + "", |
| 92 | + "7. Write the design document:", |
| 93 | + ` - Write to \`${SPEC_PILOT_CONSTANTS.DESIGN_FILE}\` in Markdown format.`, |
| 94 | + " - Use clear headings, bullet points, and code blocks for readability.", |
| 95 | + " - Include practical examples and concrete specifications.", |
| 96 | + " - Ensure each section provides actionable information for developers.", |
| 97 | + "", |
| 98 | + "## Design Document Requirements", |
| 99 | + "- **Overview**: Single paragraph summarizing the design approach and key architectural decisions.", |
| 100 | + "- **Architecture**: System structure with visual diagrams, technology stack, and component relationships.", |
| 101 | + "- **Component Design**: Detailed specifications for each major component including responsibilities and interfaces.", |
| 102 | + "- **Data Flow**: Visual representation of data movement through the system with explanatory text.", |
| 103 | + "- **Error Handling**: Comprehensive error management strategy across all system layers.", |
| 104 | + "- **Migration Strategy**: Phase-by-phase implementation plan with clear deliverables and dependencies.", |
| 105 | + "- **Test Strategy**: Testing approach covering unit, integration, and system-level testing.", |
| 106 | + "- **Performance**: Scalability considerations, optimization strategies, and performance metrics.", |
| 107 | + "- **Security**: Security measures, authentication/authorization, and compliance requirements.", |
| 108 | + "", |
| 109 | + "## Quality Standards", |
| 110 | + "- All architectural decisions must be justified based on requirements.", |
| 111 | + "- Code examples must be syntactically correct and follow best practices.", |
| 112 | + "- Visual diagrams must accurately represent system relationships.", |
| 113 | + "- Migration phases must be realistic and account for risk management.", |
| 114 | + "- Technical specifications must be detailed enough for implementation.", |
| 115 | + "", |
| 116 | + "## Checks", |
| 117 | + `- Report directory checks for \`${SPEC_PILOT_CONSTANTS.BASE_DIR}\` and \`${SPEC_PILOT_CONSTANTS.BASE_DIR}/${specName}\`.`, |
| 118 | + `- Confirm \`${SPEC_PILOT_CONSTANTS.SPEC_CONFIG_FILE}\` was readable and summarize key fields (title, description).`, |
| 119 | + `- Verify \`${SPEC_PILOT_CONSTANTS.REQUIREMENTS_FILE}\` was accessible and summarize requirement count and complexity.`, |
| 120 | + "- Confirm the design document includes all 9 mandatory sections in the correct order.", |
| 121 | + "- Ensure architectural decisions align with extracted requirements.", |
| 122 | + "- Verify all diagrams are properly formatted and meaningful.", |
| 123 | + "- Check that implementation examples are concrete and actionable.", |
| 124 | + `- If writing failed, describe the error and propose next actions (permissions, missing files, invalid content).`, |
| 125 | + "", |
| 126 | + "## Output", |
| 127 | + "- IMPORTANT: Translate all headings, bullet labels, and explanatory text into the resolved output language.", |
| 128 | + "- Keep code fences, paths, identifiers, and technical terms unchanged unless translation improves clarity.", |
| 129 | + "- Maintain consistent terminology throughout the document.", |
| 130 | + "", |
| 131 | + "# Spec Design Result", |
| 132 | + `- specFolder: "${specName}"`, |
| 133 | + `- designFile: "${SPEC_PILOT_CONSTANTS.BASE_DIR}/${specName}/${SPEC_PILOT_CONSTANTS.DESIGN_FILE}"`, |
| 134 | + `- workspaceCheck: "<directory, config, and requirements validation summary>"`, |
| 135 | + `- architecturalPattern: "<chosen architectural approach and justification>"`, |
| 136 | + `- componentCount: "<number of major components identified>"`, |
| 137 | + `- implementationComplexity: "<assessment of implementation complexity>"`, |
| 138 | + `- next: "<recommended follow-up prompt or action>"`, |
| 139 | + `- notes: "<design decisions, assumptions, or considerations>"`, |
| 140 | + "", |
| 141 | + "- If the workspace is invalid, requirements are missing, or information is insufficient, clearly state what needs to be fixed before retrying.", |
| 142 | + ); |
| 143 | + |
| 144 | + return createPromptResponse(prompt); |
| 145 | + }, |
| 146 | + ); |
| 147 | +}; |
0 commit comments