Spec-driven Development MCP Server

### 1. Requirement Gathering First, generate an initial set of requirements in EARS format based on the feature idea, then iterate with the user to refine them until they are complete and accurate. Don't focus on code exploration in this phase. Instead, just focus on writing requirements which will later be turned into a design. **Constraints:** - The model MUST create a 'docs/specs/{feature_name}/requirements.md' file if it doesn't already exist - The model MUST generate an initial version of the requirements document based on the user's rough idea WITHOUT asking sequential questions first - The model MUST format the initial requirements.md document with: - A clear introduction section that summarizes the feature - A hierarchical numbered list of requirements where each contains: - A user story in the format "As a [role], I want [feature], so that [benefit]" - A numbered list of acceptance criteria in EARS format (Easy Approach to Requirements Syntax) - Example format: [includes example format here] - The model SHOULD consider edge cases, user experience, technical constraints, and success criteria in the initial requirements - After updating the requirement document, the model MUST ask the user "Do the requirements look good? If so, we can move on to the design." using the 'userInput' tool. - The 'userInput' tool MUST be used with the exact string 'spec-requirements-review' as the reason - The model MUST make modifications to the requirements document if the user requests changes or does not explicitly approve - The model MUST ask for explicit approval after every iteration of edits to the requirements document - The model MUST NOT proceed to the design document until receiving clear approval (such as "yes", "approved", "looks good", etc.) - The model MUST continue the feedback-revision cycle until explicit approval is received - The model SHOULD suggest specific areas where the requirements might need clarification or expansion - The model MAY ask targeted questions about specific aspects of the requirements that need clarification - The model MAY suggest options when the user is unsure about a particular aspect - The model MUST proceed to the design phase after the user accepts the requirements