prd-writer-mcp 0.1.0

package/dist/templates/chapters/01-overview.xml

@@ -0,0 +1,41 @@
+<section id="1" title="Overview">
+  <subsection id="1.1" title="Purpose">
+    <description>Briefly describe the overall purpose and overview of the document.</description>
+  </subsection>
+  <subsection id="1.2" title="Document Name">
+    <description>Provide the official name of the document.</description>
+  </subsection>
+  <subsection id="1.3" title="Target Users">
+    <description>Define the primary target users or personas for this product.</description>
+    <example>
+- Small business owners who need to manage inventory
+- Marketing teams in mid-sized companies
+    </example>
+  </subsection>
+  <subsection id="1.4" title="Core Problem">
+    <description>Describe the core problem that this product aims to solve.</description>
+    <example>
+- Users spend too much time manually tracking inventory across multiple spreadsheets.
+    </example>
+  </subsection>
+  <subsection id="1.5" title="Solution Strategy">
+    <description>Explain the high-level approach to solving the core problem.</description>
+    <example>
+- Provide a centralized dashboard that automatically syncs inventory data from multiple sources.
+    </example>
+  </subsection>
+  <subsection id="1.6" title="Success Criteria">
+    <description>Define the criteria that will determine whether the product is successful.</description>
+    <example>
+- 80% of users can complete inventory updates in under 5 minutes.
+- User satisfaction score of 4.0 or higher.
+    </example>
+  </subsection>
+  <subsection id="1.7" title="Key Differentiators">
+    <description>List the unique features or advantages that set this product apart from competitors.</description>
+    <example>
+- AI-powered demand forecasting
+- One-click integration with major e-commerce platforms
+    </example>
+  </subsection>
+</section>

package/dist/templates/chapters/02-mvp-goals.xml

@@ -0,0 +1,14 @@
+<section id="2" title="MVP Goals and Key Metrics">
+  <subsection id="2.1" title="Purpose">
+    <description>Briefly describe the hypothesis or goals to be validated through the MVP.</description>
+    <example>
+If we provide a 30% discount coupon upon sign-up, the revisit rate within 14 days will increase.
+    </example>
+  </subsection>
+  <subsection id="2.2" title="Key Performance Indicators (KPIs)">
+    <description>Define the quantitative metrics to evaluate the purpose (hypothesis) stated above.</description>
+    <example>
+Revisit rate within 14 days after sign-up: 30% or higher
+    </example>
+  </subsection>
+</section>

package/dist/templates/chapters/03-demo-scenario.xml

@@ -0,0 +1,12 @@
+<section id="3" title="Demo Scenario">
+  <description>
+- Briefly describe the demo scenario that shows how key hypotheses can be validated.
+- Ensure the scenario aligns with Section 2.
+  </description>
+  <example>
+1. Amanda visited the shoes category page on our shopping website a week ago.
+2. Amanda received a 30% discount coupon via email.
+3. Amanda clicks the link in the email, which redirects her to the shoes category page.
+4. Amanda buys a pair of shoes using the discount coupon, which is automatically applied to the order.
+  </example>
+</section>

package/dist/templates/chapters/04-architecture.xml

@@ -0,0 +1,33 @@
+<section id="4" title="High-Level Architecture">
+  <subsection id="4.1" title="System Diagram">
+    <description>
+- Provide Context and Container diagrams (C4 model) illustrating the overall system architecture of the project.
+- The Context diagram is essential; the Container diagram is optional.
+- Component and Code diagrams are excluded.
+    </description>
+    <example>
+```mermaid
+C4Context
+
+title System Context Diagram for {Project Name}
+
+Person(user, "User", "User")
+
+System_Ext(system_ext, "System Ext", "External System")
+System(system, "System", "Target System")
+
+Rel(user, system_ext, "Uses", "HTTPS")
+Rel(user, system, "Uses", "HTTPS")
+```
+    </example>
+  </subsection>
+  <subsection id="4.2" title="Technology Stack">
+    <description>List the key technologies and frameworks to be used in the MVP.</description>
+    <example>
+- Frontend: React (Tailwind CSS)
+- Backend: Node.js (Express)
+- Database: MongoDB
+- Infrastructure: AWS (EC2), GitHub Actions (CI/CD)
+    </example>
+  </subsection>
+</section>

package/dist/templates/chapters/05-design-spec.xml

@@ -0,0 +1,22 @@
+<section id="5" title="Design Specification">
+  <description>Define the UX guidelines and page flow that will be directly reflected in MVP development.</description>
+  <subsection id="5.1" title="User Flow and Page Structure">
+    <subsection id="5.1.1" title="Key Pages (Features)">
+      <description>List the key pages that must be implemented in the MVP. (Use the same feature IDs as Section 6.1 where applicable.)</description>
+      <example>
+- F3: Main Screen
+- F4: Post Creation Screen
+- F5: Post List/Detail Screen
+      </example>
+    </subsection>
+    <subsection id="5.1.2" title="Page Navigation">
+      <description>Summarize how users navigate between pages and key scenarios.</description>
+      <example>
+1. The user accesses the main screen.
+2. Sign-up/Login → Redirects to the main screen upon successful login.
+3. View post list → Enter the post details screen → Create a post (Login required).
+(Optional) This flow can be visualized using a Mermaid Sequence Diagram.
+      </example>
+    </subsection>
+  </subsection>
+</section>

package/dist/templates/chapters/06-requirements.xml

@@ -0,0 +1,60 @@
+<section id="6" title="Requirements Summary">
+  <description>
+- List all core features (functional requirements) and non-functional requirements for the MVP.
+- Each core feature is assigned a unique ID (F1, F2, …), and will be mapped to Section 7.
+- Prioritize each requirement using: Must-Have, Should-Have, or Nice-to-Have.
+- Only features defined in this section are included in the MVP scope; additional features must be listed in Section 9.
+- Up to 3 non-functional requirements are allowed.
+  </description>
+  <subsection id="6.1" title="Core Features (Functional Requirements)">
+    <example>
+| ID | Feature | Priority |
+|----|---------|----------|
+| F1 | Email Sign-up | Must-Have |
+| F2 | Email Login | Must-Have |
+| F3 | Main Screen | Must-Have |
+| F4 | Post Creation | Should-Have |
+| F5 | Post List/Detail | Nice-to-Have |
+    </example>
+  </subsection>
+  <subsection id="6.2" title="Non-Functional Requirements">
+    <description>
+- Define non-functional requirements such as security, performance, and scalability.
+- Set the minimum standards for the MVP phase.
+- Non-functional requirements are validated through Section 8 (MVP Metrics) or release testing.
+    </description>
+    <example>
+| ID | Requirement | Priority |
+|----|-------------|----------|
+| NF1 | Minimum security (no email verification) | Must-Have |
+| NF2 | Performance (up to 1,000 daily users) | Should-Have |
+| NF3 | Latency (under 3 seconds) | Must-Have |
+    </example>
+  </subsection>
+  <subsection id="6.3" title="Feature Dependency Diagram">
+    <description>
+- After completing 6.1 and 6.2, the AI automatically analyzes feature dependencies and generates this diagram.
+- Visualize the dependency relationships between features using a Mermaid diagram.
+- Use a top-down tree structure (graph TD) to show which features depend on other features.
+- An arrow from A to B means "A depends on B" (B must be implemented before A).
+- Features with no dependencies are root nodes in the tree.
+- This diagram helps determine the implementation order and identify critical paths.
+- Present the auto-generated diagram to the user for confirmation or correction.
+    </description>
+    <example>
+```mermaid
+graph TD
+    F1[F1: Email Sign-up]
+    F2[F2: Email Login]
+    F3[F3: Main Screen]
+    F4[F4: Post Creation]
+    F5[F5: Post List/Detail]
+
+    F2 -->|depends on| F1
+    F3 -->|depends on| F2
+    F4 -->|depends on| F2
+    F5 -->|depends on| F3
+```
+    </example>
+  </subsection>
+</section>

package/dist/templates/chapters/07-feature-spec.xml

@@ -0,0 +1,84 @@
+<section id="7" title="Feature-Level Specification">
+  <description>
+- For every feature listed in Section 6.1, provide a detailed design using the same Fx ID and feature name.
+- Each subsection must match the feature ID, name, and priority defined in Section 6.1.
+- No additional features beyond those in Section 6.1 may be specified here.
+  </description>
+  <template id="7.x" title="Feature Template">
+    <header>Feature ID: Fx | Priority: Must-Have / Should-Have / Nice-to-Have</header>
+    <subsection id="7.x.1" title="User Story">
+      <description>
+- Describe the user scenario for implementing this feature.
+- Use this format: As a [persona], I want to [action], so that [benefit].
+      </description>
+      <example>
+- As a new user, I want to sign up with my email, so that I can access the service.
+      </example>
+    </subsection>
+    <subsection id="7.x.2" title="User Flow">
+      <description>
+- Describe the user flow for this feature.
+- Keep the flow simple and concise.
+      </description>
+      <example>
+1. Display a sign-up form with:
+   - Email input field
+   - Password input field
+   - "Sign Up" button
+2. When the user submits the form:
+   - Validate input
+   - Trigger an API call
+   - Redirect to the main screen upon successful sign-up
+      </example>
+    </subsection>
+    <subsection id="7.x.3" title="Technical Description">
+      <description>
+- Describe the implementation details from a developer's perspective.
+- Break down each user story into detailed technical steps.
+      </description>
+      <example>
+1. Email Validation
+   - Validate email format using regex
+   - Check for duplicate emails in the database
+2. Password Processing
+   - Ensure a minimum of 8 characters, including at least one special character
+   - Hash the password using bcrypt
+3. User Creation Process
+   - Insert a new record into the users table
+   - Generate and return a JWT token
+      </example>
+    </subsection>
+    <subsection id="7.x.4" title="Edge Cases">
+      <description>List potential edge cases and how they should be handled.</description>
+      <example>
+- User submits an already registered email → Show "Email already exists" error
+- User enters a password with less than 8 characters → Show validation error
+- Network timeout during API call → Show retry option
+      </example>
+    </subsection>
+    <subsection id="7.x.5" title="Error Handling">
+      <description>Define error scenarios and appropriate responses.</description>
+      <example>
+| Error Type | HTTP Code | User Message |
+|------------|-----------|--------------|
+| Validation failure | 400 | "Please check your input" |
+| Duplicate email | 409 | "Email already registered" |
+| Server error | 500 | "Something went wrong. Please try again." |
+      </example>
+    </subsection>
+    <subsection id="7.x.6" title="Acceptance Criteria">
+      <description>
+- Define the conditions that must be met for this feature to be considered complete.
+- Use clear, testable statements.
+      </description>
+      <example>
+- [ ] User can enter email and password in the sign-up form
+- [ ] Form validates email format before submission
+- [ ] Password must be at least 8 characters with one special character
+- [ ] Successful sign-up redirects user to main screen
+- [ ] Duplicate email shows appropriate error message
+- [ ] All error states display user-friendly messages
+      </example>
+    </subsection>
+  </template>
+</section>

package/dist/templates/chapters/08-mvp-metrics.xml

@@ -0,0 +1,29 @@
+<section id="8" title="MVP Metrics">
+  <description>
+- List the key data points and methods for collecting them to measure the MVP's success.
+- Define success thresholds for each key performance indicator.
+- Non-functional requirements (from Section 6.2) are also validated here or through dedicated release testing.
+  </description>
+  <subsection id="8.1" title="Data Collection Methods">
+    <example>
+| Metric | Collection Method | Related Feature/KPI |
+|--------|-------------------|---------------------|
+| Sign-up button clicks | Event tracking (Analytics) | F1 |
+| Post creation count | Database query | F4 |
+| Revisit count within 14 days | User session tracking | KPI |
+| Average response latency | APM monitoring | NF3 |
+| Uptime logs | Infrastructure monitoring | NF4 |
+    </example>
+  </subsection>
+  <subsection id="8.2" title="Success Thresholds">
+    <description>Define the target values that indicate MVP success.</description>
+    <example>
+| KPI | Baseline | Target | Measurement Period |
+|-----|----------|--------|-------------------|
+| Sign-up conversion rate | N/A | ≥ 20% | First 30 days |
+| Revisit rate (14 days) | N/A | ≥ 30% | Ongoing |
+| Average response latency | N/A | &lt; 3 seconds | Ongoing |
+| System uptime | N/A | ≥ 99.5% | Ongoing |
+    </example>
+  </subsection>
+</section>

package/dist/templates/chapters/09-out-of-scope.xml

@@ -0,0 +1,25 @@
+<section id="9" title="Out-of-Scope">
+  <description>
+- List requirements and features excluded from the MVP.
+- Provide a roadmap for managing technical debt and potential future enhancements.
+  </description>
+  <subsection id="9.1" title="Deferred Features">
+    <example>
+| Feature | Reason for Deferral | Target Phase |
+|---------|---------------------|--------------|
+| OAuth support | Not critical for MVP validation | Phase 2 |
+| Payment support | Requires additional compliance | Phase 2 |
+| Advanced analytics | Nice-to-have, not core | Phase 3 |
+    </example>
+  </subsection>
+  <subsection id="9.2" title="Technical Debt Roadmap">
+    <description>Document known technical debt and plans for addressing it.</description>
+    <example>
+| Item | Description | Priority | Target Phase |
+|------|-------------|----------|--------------|
+| Test coverage | Increase unit test coverage to 80% | High | Phase 2 |
+| Error logging | Implement centralized error logging | Medium | Phase 2 |
+| Code refactoring | Refactor authentication module | Low | Phase 3 |
+    </example>
+  </subsection>
+</section>

package/dist/templates/overview.md

@@ -0,0 +1,100 @@
+# Product Requirements Document (PRD) Template
+
+This document provides a comprehensive framework to capture and validate all essential information required for developing an MVP.
+
+## Sections
+
+1. Overview - Define the product vision, target users, core problem, solution strategy
+2. MVP Goals and Key Metrics - Articulate measurable goals that validate the MVP hypothesis
+3. Demo Scenario - Describe the demo scenario showing how key hypotheses can be validated _(references: Section 2)_
+4. High-Level Architecture - Provide C4 model diagrams illustrating the system architecture
+5. Design Specification - Detail the UX and page flow _(references: Section 6)_
+6. Requirements Summary - Enumerate all core functional and non-functional requirements
+7. Feature-Level Specification - Present complete user stories for each feature _(references: Section 6)_
+8. MVP Metrics - Detail methods for collecting and analyzing data _(references: Section 2, 6)_
+9. Out of Scope - List features deferred for future iterations
+
+---
+
+## Section Reference Rules
+
+<section-references>
+Some sections depend on other sections. Before working on a section with references, you MUST review the referenced sections first.
+
+<reference-map>
+- Section 3 (Demo Scenario) → MUST review Section 2 (MVP Goals)
+- Section 5 (Design Specification) → MUST review Section 6 (Requirements Summary)
+- Section 7 (Feature-Level Specification) → MUST review Section 6 (Requirements Summary)
+- Section 8 (MVP Metrics) → MUST review Section 2 (MVP Goals) AND Section 6.2 (Non-Functional Requirements)
+</reference-map>
+
+<mandatory-actions>
+1. Call `read_prd_section(N)` for each referenced section
+2. Summarize key points from referenced sections before asking questions
+3. If referenced sections are incomplete, warn user and suggest completing them first
+</mandatory-actions>
+</section-references>
+
+---
+
+## Conversation Guide
+
+<communication>
+<section-tracking>
+- Start each message with "Section" and its number (e.g., `## Section 1. Overview`).
+</section-tracking>
+
+<conversation-style>
+- Ask ONE or at most TWO focused questions at a time. For complex topics, ask exactly ONE.
+- Explain the purpose of each section before asking questions (1-2 sentences).
+- Wait for user response before proceeding.
+- Use numbered lists for decision points.
+- Avoid code examples unless explicitly requested.
+</conversation-style>
+
+<emoji-usage>
+- Use emojis purposefully, max 2 per section.
+- Place emojis at the end of statements, not beginning or middle.
+</emoji-usage>
+</communication>
+
+<conversation-flow>
+For EVERY section:
+1. Call `get_prd_section_guide(N)` before writing
+2. Briefly explain section purpose (1-2 sentences)
+3. Ask 1 (max 2) focused questions from the guide
+4. Integrate answers iteratively
+5. When complete, print FULL section and ask for confirmation
+6. Call `save_prd_section(N, content)` only AFTER explicit "yes"
+7. Move to next section only after confirmation
+
+<confirmation-required-sections>
+Must obtain explicit confirmation before proceeding:
+- Section 3. Demo Scenario
+- Section 6. Requirements Summary
+- Every subsection of Section 7 (confirm each 7.x individually)
+</confirmation-required-sections>
+</conversation-flow>
+
+<change-requests>
+When user asks to edit/update/modify/remove/add anything:
+1. Print only the modified subsection with `v{n}` suffix (e.g., `### 1.1 Purpose v2`)
+2. Include short change-log (1-3 bullets)
+3. Ask ONE follow-up question
+4. Do NOT reprint entire section unless requested
+5. After "no more changes", ask permission to proceed to next section
+</change-requests>
+
+<reference-document-handling>
+When user provides PDF, PRD, or any reference:
+1. Say: "I'll use this as reference, but let's go through each section together."
+2. For each question: show what you found, ask user to confirm or modify
+3. NEVER auto-generate entire document without Q&A
+</reference-document-handling>
+
+<rules>
+- NEVER generate multiple sections at once
+- NEVER write section without calling get_prd_section_guide() first
+- NEVER proceed without explicit user confirmation
+- ALWAYS ask 1-2 questions at a time (1 for complex topics)
+</rules>

package/dist/tools/documents/controller.d.ts

@@ -0,0 +1,11 @@
+import { DocumentService } from "./service.js";
+export declare class DocumentController {
+    private service;
+    constructor(service: DocumentService);
+    initPrdDocument(projectName: string, outputPath: string): string;
+    loadPrdDocument(docPath: string): string;
+    savePrdSection(section: number, subsectionId: string, title: string, content: string): string;
+    readPrdSection(section: number, subsectionId?: string): string;
+    getPrdDocumentStatus(): string;
+    exportPrdMarkdown(outputPath?: string): string;
+}

package/dist/tools/documents/controller.js

@@ -0,0 +1,24 @@
+export class DocumentController {
+    service;
+    constructor(service) {
+        this.service = service;
+    }
+    initPrdDocument(projectName, outputPath) {
+        return this.service.initDocument(projectName, outputPath);
+    }
+    loadPrdDocument(docPath) {
+        return this.service.loadDocument(docPath);
+    }
+    savePrdSection(section, subsectionId, title, content) {
+        return this.service.saveSection(section, subsectionId, title, content);
+    }
+    readPrdSection(section, subsectionId) {
+        return this.service.readSection(section, subsectionId);
+    }
+    getPrdDocumentStatus() {
+        return this.service.getStatus();
+    }
+    exportPrdMarkdown(outputPath) {
+        return this.service.exportMarkdown(outputPath);
+    }
+}

package/dist/tools/documents/service.d.ts

@@ -0,0 +1,18 @@
+export declare class DocumentService {
+    private workingDoc;
+    private parseSections;
+    private parseSubsections;
+    private buildSubsection;
+    private buildSection;
+    private buildDocument;
+    private extractProjectName;
+    private get outputDir();
+    private expandPath;
+    initDocument(projectName: string, outputPath: string): string;
+    loadDocument(docPath: string): string;
+    saveSection(section: number, subsectionId: string, title: string, content: string): string;
+    readSection(section: number, subsectionId?: string): string;
+    getStatus(): string;
+    private contentToMarkdown;
+    exportMarkdown(outputPath?: string): string;
+}