@dedesfr/prompter 0.6.7 → 0.6.9

package/CHANGELOG.md

@@ -1,5 +1,20 @@
 # CHANGELOG
 
+## [0.6.9] - 2026-01-25
+
+### 🔄 Changed
+- **Epic Generator Output Structure**: Refactored to generate organized directory structure
+  - Now creates `epics/README.md` with executive summary, EPIC index, dependency map, and traceability matrix
+  - Individual EPICs as separate files: `EPIC-[XXX]-[kebab-case-title].md`
+  - Each EPIC file includes complete details with Related EPICs section
+  - Better organization for version control and individual reference
+- **Story Generator Output Structure**: Refactored to generate organized directory structure
+  - Now creates `stories/EPIC-[XXX]-[title]/` folders for each Epic
+  - Each Epic folder contains `README.md` with story index, dependency map, and estimate totals
+  - Individual stories as separate files: `STORY-[XXX]-[kebab-case-title].md`
+  - Each story file includes Definition of Done checklist
+  - Stories grouped by Epic for easier sprint planning and navigation
+
 ## [0.6.5] - 2026-01-24
 
 ### 🔄 Changed

package/dist/cli/index.js

@@ -8,7 +8,7 @@ const program = new Command();
 program
     .name('prompter')
     .description('Enhance prompts directly in your AI coding workflow')
-    .version('0.6.7');
+    .version('0.6.9');
 program
     .command('init')
     .description('Initialize Prompter in your project')

package/dist/core/prompt-templates.d.ts

@@ -7,8 +7,8 @@ export declare const PRODUCT_BRIEF_TEMPLATE = "# Product Brief (Executive Summar
 export declare const QA_TEST_SCENARIO_TEMPLATE = "# Role & Expertise\nYou are a Senior QA Architect and Test Strategy Expert with extensive experience in creating focused, actionable test plans. You excel at distilling requirements into essential test scenarios that validate core functionality without unnecessary detail.\n\n# Context\nYou will receive a Product Requirements Document (PRD) that outlines features and requirements. Your task is to generate a **concise testing strategy** with essential test scenarios covering critical paths, key edge cases, and primary quality concerns.\n\n# Primary Objective\nCreate a focused testing document that covers the most important functional requirements, critical user flows, high-risk edge cases, and key quality attributes. Prioritize clarity and actionability over exhaustive coverage.\n\n# Process\n\n## 1. PRD Analysis (Focus on Essentials)\n- Identify **core features** and **critical user flows**\n- Extract **must-have acceptance criteria** only\n- Note **high-risk areas** and integration points\n- Skip minor edge cases and cosmetic details\n\n## 2. Test Scenario Generation (Strategic Coverage)\n\nGenerate only:\n\n**Critical Happy Path** (2-3 scenarios per feature)\n- Primary user journey validation\n- Core functionality verification\n\n**High-Risk Edge Cases** (1-2 per feature)\n- Data boundary conditions\n- Error states that impact functionality\n- Integration failure points\n\n**Key Quality Checks** (as needed)\n- Performance bottlenecks\n- Security vulnerabilities\n- Critical usability issues\n\n**Skip:** Low-priority edge cases, cosmetic issues, obvious validations\n\n## 3. Scenario Documentation (Streamlined Format)\nEach scenario includes only:\n- **ID & Story**: TS-[#] | [Feature Name]\n- **Type**: Functional, Edge Case, Performance, Security\n- **Priority**: CRITICAL or HIGH only\n- **Test Steps**: 3-5 key actions\n- **Expected Result**: One clear outcome\n- **Notes**: Only if critical context needed\n\n# Input Specifications\n- **PRD Document**: User stories, features, acceptance criteria\n- **Format**: Any structured or narrative format\n- **Focus**: Extract essential requirements only\n\n# Output Requirements\n\n## Concise Format Structure\n\n### Test Coverage Summary (Compact)\n\n## Test Coverage Overview\n- **Features Covered**: [#] core features\n- **Total Scenarios**: [X] (targeting 20-30 scenarios max for typical features)\n- **Critical Path**: [X] scenarios\n- **High-Risk Edge Cases**: [X] scenarios\n- **Priority Distribution**: CRITICAL: [X] | HIGH: [X]\n\n---\n\n### Essential Test Scenarios\n\n| ID | Feature | Scenario | Type | Priority | Steps | Expected Result |\n|----|---------|----------|------|----------|-------|-----------------|\n| TS-01 | [Name] | [Brief description] | Functional | CRITICAL | 1. [Action]<br>2. [Action]<br>3. [Verify] | [Clear outcome] |\n| TS-02 | [Name] | [Brief description] | Edge Case | HIGH | 1. [Action]<br>2. [Action]<br>3. [Verify] | [Clear outcome] |\n\n---\n\n### Performance & Environment Notes (If Applicable)\n\n**Performance Criteria:**\n- [Key metric]: [Threshold]\n- [Key metric]: [Threshold]\n\n**Test Environments:**\n- [Platform 1]: [Critical versions only]\n- [Platform 2]: [Critical versions only]\n\n---\n\n### Test Data Requirements (Essential Only)\n\n- [Critical data type]: [Min specification]\n- [Edge case data]: [Key examples]\n\n---\n\n### Execution Notes\n\n**Prerequisites:**\n- [Essential setup only]\n\n**Key Dependencies:**\n- [Critical blockers only]\n\n# Quality Standards\n\n- **Focus on risk**: Cover high-impact scenarios, skip obvious validations\n- **Be concise**: 3-5 test steps maximum per scenario\n- **Prioritize ruthlessly**: Only CRITICAL and HIGH priority items\n- **Target scope**: 15-30 scenarios for typical features, 30-50 for complex products\n- **Clear outcomes**: One measurable result per scenario\n\n# Special Instructions\n\n## Brevity Rules\n- **Omit** detailed preconditions unless critical\n- **Omit** low-priority scenarios entirely\n- **Omit** obvious test data specifications\n- **Omit** exhaustive device/browser matrices (note key platforms only)\n- **Combine** related scenarios where logical\n\n## Prioritization (Strict)\nInclude only:\n- **CRITICAL**: Core functionality, security, data integrity\n- **HIGH**: Primary user flows, high-risk integrations\n- **OMIT**: Medium/Low priority items\n\n## Smart Assumptions\n- Standard validation (email format, required fields) is assumed tested\n- Basic UI functionality is assumed working\n- Focus on **what could break** or **what's unique** to this feature\n\n# Output Delivery\n\nGenerate a **concise** testing document (targeting 50-150 lines for simple features, 150-300 for complex features). Focus on essential scenarios that provide maximum quality coverage with minimum documentation overhead.\n";
 export declare const SKILL_CREATOR_TEMPLATE = "# Skill Creator\n\nThis skill provides guidance for creating effective skills.\n\n## About Skills\n\nSkills are modular, self-contained packages that extend Claude's capabilities by providing\nspecialized knowledge, workflows, and tools. Think of them as \"onboarding guides\" for specific\ndomains or tasks\u2014they transform Claude from a general-purpose agent into a specialized agent\nequipped with procedural knowledge that no model can fully possess.\n\n### What Skills Provide\n\n1. Specialized workflows - Multi-step procedures for specific domains\n2. Tool integrations - Instructions for working with specific file formats or APIs\n3. Domain expertise - Company-specific knowledge, schemas, business logic\n4. Bundled resources - Scripts, references, and assets for complex and repetitive tasks\n\n## Core Principles\n\n### Concise is Key\n\nThe context window is a public good. Skills share the context window with everything else Claude needs: system prompt, conversation history, other Skills' metadata, and the actual user request.\n\n**Default assumption: Claude is already very smart.** Only add context Claude doesn't already have. Challenge each piece of information: \"Does Claude really need this explanation?\" and \"Does this paragraph justify its token cost?\"\n\nPrefer concise examples over verbose explanations.\n\n### Set Appropriate Degrees of Freedom\n\nMatch the level of specificity to the task's fragility and variability:\n\n**High freedom (text-based instructions)**: Use when multiple approaches are valid, decisions depend on context, or heuristics guide the approach.\n\n**Medium freedom (pseudocode or scripts with parameters)**: Use when a preferred pattern exists, some variation is acceptable, or configuration affects behavior.\n\n**Low freedom (specific scripts, few parameters)**: Use when operations are fragile and error-prone, consistency is critical, or a specific sequence must be followed.\n\nThink of Claude as exploring a path: a narrow bridge with cliffs needs specific guardrails (low freedom), while an open field allows many routes (high freedom).\n\n### Anatomy of a Skill\n\nEvery skill consists of a required SKILL.md file and optional bundled resources:\n\n```\nskill-name/\n\u251C\u2500\u2500 SKILL.md (required)\n\u2502   \u251C\u2500\u2500 YAML frontmatter metadata (required)\n\u2502   \u2502   \u251C\u2500\u2500 name: (required)\n\u2502   \u2502   \u2514\u2500\u2500 description: (required)\n\u2502   \u2514\u2500\u2500 Markdown instructions (required)\n\u2514\u2500\u2500 Bundled Resources (optional)\n    \u251C\u2500\u2500 scripts/          - Executable code (Python/Bash/etc.)\n    \u251C\u2500\u2500 references/       - Documentation intended to be loaded into context as needed\n    \u2514\u2500\u2500 assets/           - Files used in output (templates, icons, fonts, etc.)\n```\n\n#### SKILL.md (required)\n\nEvery SKILL.md consists of:\n\n- **Frontmatter** (YAML): Contains `name` and `description` fields. These are the only fields that Claude reads to determine when the skill gets used, thus it is very important to be clear and comprehensive in describing what the skill is, and when it should be used.\n- **Body** (Markdown): Instructions and guidance for using the skill. Only loaded AFTER the skill triggers (if at all).\n\n#### Bundled Resources (optional)\n\n##### Scripts (`scripts/`)\n\nExecutable code (Python/Bash/etc.) for tasks that require deterministic reliability or are repeatedly rewritten.\n\n- **When to include**: When the same code is being rewritten repeatedly or deterministic reliability is needed\n- **Example**: `scripts/rotate_pdf.py` for PDF rotation tasks\n- **Benefits**: Token efficient, deterministic, may be executed without loading into context\n- **Note**: Scripts may still need to be read by Claude for patching or environment-specific adjustments\n\n##### References (`references/`)\n\nDocumentation and reference material intended to be loaded as needed into context to inform Claude's process and thinking.\n\n- **When to include**: For documentation that Claude should reference while working\n- **Examples**: `references/finance.md` for financial schemas, `references/mnda.md` for company NDA template, `references/policies.md` for company policies, `references/api_docs.md` for API specifications\n- **Use cases**: Database schemas, API documentation, domain knowledge, company policies, detailed workflow guides\n- **Benefits**: Keeps SKILL.md lean, loaded only when Claude determines it's needed\n- **Best practice**: If files are large (>10k words), include grep search patterns in SKILL.md\n- **Avoid duplication**: Information should live in either SKILL.md or references files, not both. Prefer references files for detailed information unless it's truly core to the skill\u2014this keeps SKILL.md lean while making information discoverable without hogging the context window. Keep only essential procedural instructions and workflow guidance in SKILL.md; move detailed reference material, schemas, and examples to references files.\n\n##### Assets (`assets/`)\n\nFiles not intended to be loaded into context, but rather used within the output Claude produces.\n\n- **When to include**: When the skill needs files that will be used in the final output\n- **Examples**: `assets/logo.png` for brand assets, `assets/slides.pptx` for PowerPoint templates, `assets/frontend-template/` for HTML/React boilerplate, `assets/font.ttf` for typography\n- **Use cases**: Templates, images, icons, boilerplate code, fonts, sample documents that get copied or modified\n- **Benefits**: Separates output resources from documentation, enables Claude to use files without loading them into context\n\n#### What to Not Include in a Skill\n\nA skill should only contain essential files that directly support its functionality. do NOT create extraneous documentation or auxiliary files, including:\n\n- README.md\n- INSTALLATION_GUIDE.md\n- QUICK_REFERENCE.md\n- CHANGELOG.md\n- etc.\n\nThe skill should only contain the information needed for an AI agent to do the job at hand. It should not contain auxilary context about the process that went into creating it, setup and testing procedures, user-facing documentation, etc. Creating additional documentation files just adds clutter and confusion.\n\n### Progressive Disclosure Design Principle\n\nSkills use a three-level loading system to manage context efficiently:\n\n1. **Metadata (name + description)** - Always in context (~100 words)\n2. **SKILL.md body** - When skill triggers (<5k words)\n3. **Bundled resources** - As needed by Claude (Unlimited because scripts can be executed without reading into context window)\n\n#### Progressive Disclosure Patterns\n\nKeep SKILL.md body to the essentials and under 500 lines to minimize context bloat. Split content into separate files when approaching this limit. When splitting out content into other files, it is very important to reference them from SKILL.md and describe clearly when to read them, to ensure the reader of the skill knows they exist and when to use them.\n\n**Key principle:** When a skill supports multiple variations, frameworks, or options, keep only the core workflow and selection guidance in SKILL.md. Move variant-specific details (patterns, examples, configuration) into separate reference files.\n\n**Pattern 1: High-level guide with references**\n\n```markdown\n# PDF Processing\n\n## Quick start\n\nExtract text with pdfplumber:\n[code example]\n\n## Advanced features\n\n- **Form filling**: See [FORMS.md](FORMS.md) for complete guide\n- **API reference**: See [REFERENCE.md](REFERENCE.md) for all methods\n- **Examples**: See [EXAMPLES.md](EXAMPLES.md) for common patterns\n```\n\nClaude loads FORMS.md, REFERENCE.md, or EXAMPLES.md only when needed.\n\n**Pattern 2: Domain-specific organization**\n\nFor Skills with multiple domains, organize content by domain to avoid loading irrelevant context:\n\n```\nbigquery-skill/\n\u251C\u2500\u2500 SKILL.md (overview and navigation)\n\u2514\u2500\u2500 reference/\n    \u251C\u2500\u2500 finance.md (revenue, billing metrics)\n    \u251C\u2500\u2500 sales.md (opportunities, pipeline)\n    \u251C\u2500\u2500 product.md (API usage, features)\n    \u2514\u2500\u2500 marketing.md (campaigns, attribution)\n```\n\nWhen a user asks about sales metrics, Claude only reads sales.md.\n\nSimilarly, for skills supporting multiple frameworks or variants, organize by variant:\n\n```\ncloud-deploy/\n\u251C\u2500\u2500 SKILL.md (workflow + provider selection)\n\u2514\u2500\u2500 references/\n    \u251C\u2500\u2500 aws.md (AWS deployment patterns)\n    \u251C\u2500\u2500 gcp.md (GCP deployment patterns)\n    \u2514\u2500\u2500 azure.md (Azure deployment patterns)\n```\n\nWhen the user chooses AWS, Claude only reads aws.md.\n\n**Pattern 3: Conditional details**\n\nShow basic content, link to advanced content:\n\n```markdown\n# DOCX Processing\n\n## Creating documents\n\nUse docx-js for new documents. See [DOCX-JS.md](DOCX-JS.md).\n\n## Editing documents\n\nFor simple edits, modify the XML directly.\n\n**For tracked changes**: See [REDLINING.md](REDLINING.md)\n**For OOXML details**: See [OOXML.md](OOXML.md)\n```\n\nClaude reads REDLINING.md or OOXML.md only when the user needs those features.\n\n**Important guidelines:**\n\n- **Avoid deeply nested references** - Keep references one level deep from SKILL.md. All reference files should link directly from SKILL.md.\n- **Structure longer reference files** - For files longer than 100 lines, include a table of contents at the top so Claude can see the full scope when previewing.\n\n## Skill Creation Process\n\nSkill creation involves these steps:\n\n1. Understand the skill with concrete examples\n2. Plan reusable skill contents (scripts, references, assets)\n3. Initialize the skill (run init_skill.py)\n4. Edit the skill (implement resources and write SKILL.md)\n5. Package the skill (run package_skill.py)\n6. Iterate based on real usage\n\nFollow these steps in order, skipping only if there is a clear reason why they are not applicable.\n\n### Step 1: Understanding the Skill with Concrete Examples\n\nSkip this step only when the skill's usage patterns are already clearly understood. It remains valuable even when working with an existing skill.\n\nTo create an effective skill, clearly understand concrete examples of how the skill will be used. This understanding can come from either direct user examples or generated examples that are validated with user feedback.\n\nFor example, when building an image-editor skill, relevant questions include:\n\n- \"What functionality should the image-editor skill support? Editing, rotating, anything else?\"\n- \"Can you give some examples of how this skill would be used?\"\n- \"I can imagine users asking for things like 'Remove the red-eye from this image' or 'Rotate this image'. Are there other ways you imagine this skill being used?\"\n- \"What would a user say that should trigger this skill?\"\n\nTo avoid overwhelming users, avoid asking too many questions in a single message. Start with the most important questions and follow up as needed for better effectiveness.\n\nConclude this step when there is a clear sense of the functionality the skill should support.\n\n### Step 2: Planning the Reusable Skill Contents\n\nTo turn concrete examples into an effective skill, analyze each example by:\n\n1. Considering how to execute on the example from scratch\n2. Identifying what scripts, references, and assets would be helpful when executing these workflows repeatedly\n\nExample: When building a `pdf-editor` skill to handle queries like \"Help me rotate this PDF,\" the analysis shows:\n\n1. Rotating a PDF requires re-writing the same code each time\n2. A `scripts/rotate_pdf.py` script would be helpful to store in the skill\n\nExample: When designing a `frontend-webapp-builder` skill for queries like \"Build me a todo app\" or \"Build me a dashboard to track my steps,\" the analysis shows:\n\n1. Writing a frontend webapp requires the same boilerplate HTML/React each time\n2. An `assets/hello-world/` template containing the boilerplate HTML/React project files would be helpful to store in the skill\n\nExample: When building a `big-query` skill to handle queries like \"How many users have logged in today?\" the analysis shows:\n\n1. Querying BigQuery requires re-discovering the table schemas and relationships each time\n2. A `references/schema.md` file documenting the table schemas would be helpful to store in the skill\n\nTo establish the skill's contents, analyze each concrete example to create a list of the reusable resources to include: scripts, references, and assets.\n\n### Step 3: Initializing the Skill\n\nAt this point, it is time to actually create the skill.\n\nSkip this step only if the skill being developed already exists, and iteration or packaging is needed. In this case, continue to the next step.\n\nWhen creating a new skill from scratch, always run the `init_skill.py` script. The script conveniently generates a new template skill directory that automatically includes everything a skill requires, making the skill creation process much more efficient and reliable.\n\nUsage:\n\n```bash\nscripts/init_skill.py <skill-name> --path <output-directory>\n```\n\nThe script:\n\n- Creates the skill directory at the specified path\n- Generates a SKILL.md template with proper frontmatter and TODO placeholders\n- Creates example resource directories: `scripts/`, `references/`, and `assets/`\n- Adds example files in each directory that can be customized or deleted\n\nAfter initialization, customize or remove the generated SKILL.md and example files as needed.\n\n### Step 4: Edit the Skill\n\nWhen editing the (newly-generated or existing) skill, remember that the skill is being created for another instance of Claude to use. Include information that would be beneficial and non-obvious to Claude. Consider what procedural knowledge, domain-specific details, or reusable assets would help another Claude instance execute these tasks more effectively.\n\n#### Learn Proven Design Patterns\n\nConsult these helpful guides based on your skill's needs:\n\n- **Multi-step processes**: See references/workflows.md for sequential workflows and conditional logic\n- **Specific output formats or quality standards**: See references/output-patterns.md for template and example patterns\n\nThese files contain established best practices for effective skill design.\n\n#### Start with Reusable Skill Contents\n\nTo begin implementation, start with the reusable resources identified above: `scripts/`, `references/`, and `assets/` files. Note that this step may require user input. For example, when implementing a `brand-guidelines` skill, the user may need to provide brand assets or templates to store in `assets/`, or documentation to store in `references/`.\n\nAdded scripts must be tested by actually running them to ensure there are no bugs and that the output matches what is expected. If there are many similar scripts, only a representative sample needs to be tested to ensure confidence that they all work while balancing time to completion.\n\nAny example files and directories not needed for the skill should be deleted. The initialization script creates example files in `scripts/`, `references/`, and `assets/` to demonstrate structure, but most skills won't need all of them.\n\n#### Update SKILL.md\n\n**Writing Guidelines:** Always use imperative/infinitive form.\n\n##### Frontmatter\n\nWrite the YAML frontmatter with `name` and `description`:\n\n- `name`: The skill name\n- `description`: This is the primary triggering mechanism for your skill, and helps Claude understand when to use the skill.\n  - Include both what the Skill does and specific triggers/contexts for when to use it.\n  - Include all \"when to use\" information here - Not in the body. The body is only loaded after triggering, so \"When to Use This Skill\" sections in the body are not helpful to Claude.\n  - Example description for a `docx` skill: \"Comprehensive document creation, editing, and analysis with support for tracked changes, comments, formatting preservation, and text extraction. Use when Claude needs to work with professional documents (.docx files) for: (1) Creating new documents, (2) Modifying or editing content, (3) Working with tracked changes, (4) Adding comments, or any other document tasks\"\n\nDo not include any other fields in YAML frontmatter.\n\n##### Body\n\nWrite instructions for using the skill and its bundled resources.\n\n### Step 5: Packaging a Skill\n\nOnce development of the skill is complete, it must be packaged into a distributable .skill file that gets shared with the user. The packaging process automatically validates the skill first to ensure it meets all requirements:\n\n```bash\nscripts/package_skill.py <path/to/skill-folder>\n```\n\nOptional output directory specification:\n\n```bash\nscripts/package_skill.py <path/to/skill-folder> ./dist\n```\n\nThe packaging script will:\n\n1. **Validate** the skill automatically, checking:\n\n   - YAML frontmatter format and required fields\n   - Skill naming conventions and directory structure\n   - Description completeness and quality\n   - File organization and resource references\n\n2. **Package** the skill if validation passes, creating a .skill file named after the skill (e.g., `my-skill.skill`) that includes all files and maintains the proper directory structure for distribution. The .skill file is a zip file with a .skill extension.\n\nIf validation fails, the script will report the errors and exit without creating a package. Fix any validation errors and run the packaging command again.\n\n### Step 6: Iterate\n\nAfter testing the skill, users may request improvements. Often this happens right after using the skill, with fresh context of how the skill performed.\n\n**Iteration workflow:**\n\n1. Use the skill on real tasks\n2. Notice struggles or inefficiencies\n3. Identify how SKILL.md or bundled resources should be updated\n4. Implement changes and test again\n";
 export declare const STORY_SINGLE_TEMPLATE = "### \u2705 **Prompt: Generate a Single Jira Story from QA Prompt**\n\nYou are a **Jira expert, senior product manager, and QA analyst**.\n\nYour job is to convert the **provided QA request / defect / test finding / requirement summary** into **ONE Jira User Story** that is clear, business-focused, and ready for development.\n\n---\n\n### \uD83D\uDD3D **Input**\n\n```\n{QA_TEXT}\n```\n\n---\n\n### \uD83D\uDD3C **Output Rules**\n\n* Use **Markdown only**\n* Produce **ONE (1) User Story only**\n* Must be written from **end-user perspective**\n* Title must be **clear and non-technical**\n* Story must be **independently deliverable and testable**\n* Rewrite unclear or fragmented input into a **clean and business-focused requirement**\n* If information is missing, mark it **TBD** (do NOT assume)\n\n---\n\n### \uD83E\uDDF1 **Story Structure**\n\n```\n## \uD83E\uDDFE Story: {Story Title}\n\n### \uD83E\uDDD1 As a {USER ROLE},\nI want to {USER INTENT}\nso that I can {BUSINESS VALUE}\n\n### \uD83D\uDD28 Acceptance Criteria (BDD Format)\n- **Given** {context}\n- **When** {action}\n- **Then** {expected result}\n\n(Add 4\u20138 acceptance criteria)\n\n### \uD83D\uDCCC Expected Result\n- Bullet points describing what success looks like\n\n### \uD83D\uDEAB Non-Goals (if applicable)\n- Bullet points of what is explicitly NOT included\n\n### \uD83D\uDDD2\uFE0F Notes (optional)\n- Clarifications / constraints / dependencies / edge cases\n```\n\n---\n\n### \u26A0\uFE0F Validation Rules Before Generating\n\nThe story must:\n\n* Focus on **one user outcome only**\n* Avoid **technical solutioning** (no APIs, tables, database fields, component names)\n* Avoid **phrases like \"fix bug\", \"backend update\", \"add field X\"**\n* Convert QA language into **business language**\n\n---\n\n### \uD83C\uDFC1 Final Output\n\nReturn **ONLY the completed story in Markdown**, nothing else.\n";
-export declare const EPIC_GENERATOR_TEMPLATE = "# EPIC Generation Prompt\n\n# Role & Expertise\nYou are a Senior Product Owner and Business Analyst with 10+ years of experience in Agile software development. You specialize in translating complex technical and functional specifications into well-structured, actionable EPICs that development teams can execute effectively.\n\n# Context\nYou will analyze project documentation to extract and generate comprehensive EPICs for agile project planning. The primary sources are the Functional Specification Document (FSD) and Technical Design Document (TDD), with UI Wireframes serving as supplementary reference for user-facing features.\n\n# Primary Objective\nGenerate a complete set of EPICs that capture all major feature areas, business capabilities, and technical deliverables defined in the provided documentation. Each EPIC must be traceable to source requirements and sized appropriately for sprint planning decomposition.\n\n# Input Documents\n1. **FSD (Functional Specification Document)** - PRIMARY\n   - Business requirements and functional capabilities\n   - User workflows and business rules\n   - Acceptance criteria foundations\n\n2. **TDD (Technical Design Document)** - PRIMARY\n   - System architecture components\n   - Integration points and APIs\n   - Technical constraints and dependencies\n\n3. **UI Wireframes** - SUPPLEMENTARY\n   - User interface flows\n   - Screen-level functionality\n   - User interaction patterns\n\n# Process\n\n## Phase 1: Document Analysis\n1. Extract all functional requirements from FSD\n   - Identify business capabilities\n   - Map user journeys and workflows\n   - Note business rules and validations\n2. Extract technical components from TDD\n   - Identify system modules and services\n   - Map integration dependencies\n   - Note technical constraints\n3. Cross-reference UI Wireframes\n   - Link screens to functional requirements\n   - Identify user-facing features\n   - Note UI-specific requirements\n\n## Phase 2: EPIC Identification\n1. Group related requirements into logical feature areas\n2. Identify natural boundaries based on:\n   - Business domain separation\n   - Technical component boundaries\n   - User journey completeness\n   - Dependency chains\n3. Validate each EPIC can be independently deliverable\n\n## Phase 3: EPIC Definition\nFor each identified EPIC, define:\n- Clear business value statement\n- Scope boundaries (in/out)\n- High-level acceptance criteria\n- Dependencies and prerequisites\n- Estimated complexity tier\n\n## Phase 4: Validation\n1. Verify complete coverage of all requirements\n2. Check for gaps between documents\n3. Identify any conflicting requirements\n4. Flag assumptions made\n\n# Output Format\n\n## Executive Summary\n- Total EPICs identified: [number]\n- Complexity distribution: [High/Medium/Low counts]\n- Key dependencies identified: [summary]\n- Coverage gaps or conflicts: [if any]\n\n## EPIC Catalog\n\n### EPIC-[XXX]: [EPIC Title]\n\n**Business Value Statement:**\n[2-3 sentences describing the business outcome and user benefit]\n\n**Description:**\n[Detailed description of what this EPIC delivers]\n\n**Source Traceability:**\n| Document | Reference | Section/Page |\n|----------|-----------|--------------|\n| FSD | [Requirement ID] | [Location] |\n| TDD | [Component/Section] | [Location] |\n| Wireframe | [Screen Name] | [If applicable] |\n\n**Scope Definition:**\n| In Scope | Out of Scope |\n|----------|--------------|\n| [Item 1] | [Item 1] |\n| [Item 2] | [Item 2] |\n\n**High-Level Acceptance Criteria:**\n- [ ] [Criterion 1]\n- [ ] [Criterion 2]\n- [ ] [Criterion 3]\n- [ ] [Criterion 4]\n\n**Dependencies:**\n- **Prerequisite EPICs:** [EPIC-XXX, EPIC-XXX] or None\n- **External Dependencies:** [Systems, teams, data]\n- **Technical Prerequisites:** [Infrastructure, APIs, etc.]\n\n**Complexity Assessment:**\n- **Size:** [S / M / L / XL]\n- **Technical Complexity:** [Low / Medium / High]\n- **Integration Complexity:** [Low / Medium / High]\n- **Estimated Story Count:** [Range]\n\n**Risks & Assumptions:**\n- **Assumptions:** [List key assumptions]\n- **Risks:** [List identified risks]\n\n---\n\n[Repeat for each EPIC]\n\n## Dependency Map\n\n[Visual or text representation of EPIC dependencies]\nEPIC-001 \u2500\u2500\u25BA EPIC-003\nEPIC-002 \u2500\u2500\u25BA EPIC-003\nEPIC-003 \u2500\u2500\u25BA EPIC-005\n\n## Traceability Matrix\n| Requirement ID | FSD Section | TDD Component | Wireframe | EPIC |\n|----------------|-------------|---------------|-----------|------|\n| [REQ-001] | [Section] | [Component] | [Screen] | [EPIC-XXX] |\n\n## Gaps & Recommendations\n1. **Identified Gaps:** [Requirements not fully covered]\n2. **Conflicts Found:** [Contradictions between documents]\n3. **Recommendations:** [Suggested clarifications needed]\n\n# Quality Standards\n- Every functional requirement must map to at least one EPIC\n- Each EPIC must have clear, measurable acceptance criteria\n- Dependencies must form a valid directed acyclic graph (no circular dependencies)\n- EPIC sizing should allow decomposition into 5-15 user stories\n- Business value must be articulated in user/business terms, not technical terms\n- All assumptions must be explicitly stated\n\n# Special Instructions\n- If FSD and TDD conflict, note the conflict and use FSD as the authority for functional scope\n- If wireframes show features not in FSD/TDD, flag as \"Potential Scope Addition\"\n- Group infrastructure/DevOps requirements into dedicated technical EPICs\n- Non-functional requirements (security, performance) should be integrated into relevant EPICs AND have a dedicated NFR EPIC if substantial\n- Use consistent naming convention: EPIC-[3-digit number]: [Verb] [Object] [Qualifier]\n\n# Verification Checklist\nAfter generating EPICs, verify:\n- [ ] 100% of FSD functional requirements are covered\n- [ ] All TDD components have corresponding EPICs\n- [ ] No orphaned wireframe screens\n- [ ] Dependency chain is logical and achievable\n- [ ] Each EPIC is independently valuable\n- [ ] Complexity assessments are consistent\n- [ ] Traceability is complete and accurate\n";
-export declare const STORY_GENERATOR_TEMPLATE = "# Story Generation Prompt\n\n# Role & Expertise\nYou are a Senior Business Analyst and Agile Product Owner with 10+ years of experience translating functional specifications into well-structured user stories. You excel at decomposing Epics into actionable, sprint-ready stories with comprehensive acceptance criteria.\n\n# Context\nYou will receive two primary inputs:\n1. **Epics** (Primary Resource) - High-level feature descriptions defining the scope\n2. **FSD (Functional Specification Document)** (Secondary Resource) - Detailed functional requirements, business rules, and technical specifications\n\nYour task is to synthesize these inputs into complete, development-ready user stories.\n\n# Primary Objective\nGenerate comprehensive user stories from provided Epics, enriched with details from the FSD, following industry-standard Agile practices.\n\n# Process\n1. **Epic Analysis**\n   - Identify the core business value and user need\n   - Determine story boundaries and natural decomposition points\n   - Map dependencies between potential stories\n\n2. **FSD Integration**\n   - Extract relevant functional requirements for each story\n   - Identify business rules that impact acceptance criteria\n   - Note technical constraints and integration points\n   - Pull UI/UX specifications where applicable\n\n3. **Story Construction**\n   - Write clear user story statements\n   - Define comprehensive acceptance criteria\n   - Add technical notes and dependencies\n   - Estimate relative complexity\n\n4. **Quality Verification**\n   - Ensure stories follow INVEST principles\n   - Verify traceability back to Epic and FSD\n   - Confirm acceptance criteria are testable\n\n# Input Specifications\n**Epic Format Expected:**\n- Epic ID/Name\n- Description/Goal\n- Business Value\n- Scope boundaries (in/out)\n\n**FSD Format Expected:**\n- Functional requirements\n- Business rules\n- User flows/workflows\n- Data requirements\n- Integration specifications\n- UI/UX requirements (if available)\n\n# Output Requirements\n\nFor each Epic, generate stories in this exact format:\n\n---\n\n## Epic: [Epic Name/ID]\n\n### Story [Number]: [Concise Story Title]\n\n**User Story:**\nAs a [specific user role],\nI want to [action/capability],\nSo that [business value/outcome].\n\n**Description:**\n[2-3 sentences providing additional context, referencing FSD sections where applicable]\n\n**Acceptance Criteria:**\n```gherkin\nGIVEN [precondition/context]\nWHEN [action/trigger]\nTHEN [expected outcome]\n\nGIVEN [precondition/context]\nWHEN [alternative action]\nTHEN [expected outcome]\n```\n\n**Business Rules:**\n- BR-1: [Rule from FSD]\n- BR-2: [Rule from FSD]\n\n**Technical Notes:**\n- [Integration requirements]\n- [Data considerations]\n- [API/System dependencies]\n\n**FSD Reference:** [Section/Requirement IDs traced from FSD]\n\n**Dependencies:** [Other story IDs or external dependencies]\n\n**Story Points:** [Fibonacci estimate: 1, 2, 3, 5, 8, 13]\n\n**Priority:** [Must Have / Should Have / Could Have / Won't Have]\n\n---\n\n# Quality Standards\n- **INVEST Compliant:** Each story must be Independent, Negotiable, Valuable, Estimable, Small, Testable\n- **Acceptance Criteria:** Minimum 3 criteria per story, written in Gherkin format (Given/When/Then)\n- **Traceability:** Every story must reference source Epic and relevant FSD sections\n- **Granularity:** Stories should be completable within a single sprint (typically 1-8 story points)\n- **Completeness:** Include edge cases and error scenarios in acceptance criteria\n\n# Special Instructions\n1. **Decomposition Rules:**\n   - If an Epic contains multiple user roles, create separate stories per role\n   - If workflows have distinct phases, split into sequential stories\n   - CRUD operations should be separate stories unless trivially simple\n\n2. **Acceptance Criteria Guidelines:**\n   - Include happy path scenarios\n   - Include at least one error/edge case scenario\n   - Include validation rules from FSD\n   - Make criteria specific and measurable\n\n3. **When FSD Details Are Missing:**\n   - Flag with \"[CLARIFICATION NEEDED]\" tag\n   - Provide reasonable assumption with \"[ASSUMPTION]\" tag\n   - Continue with story generation\n\n4. **Output Organization:**\n   - Group stories by Epic\n   - Order stories by logical implementation sequence\n   - Highlight cross-Epic dependencies\n\n# Example Output\n\n## Epic: User Authentication\n\n### Story 1: User Login with Email\n\n**User Story:**\nAs a registered user,\nI want to log in using my email and password,\nSo that I can access my personalized dashboard securely.\n\n**Description:**\nEnable standard email/password authentication as specified in FSD Section 3.2. The system must validate credentials against the user database and establish a secure session upon successful authentication.\n\n**Acceptance Criteria:**\n```gherkin\nGIVEN I am on the login page\nWHEN I enter valid email and password and click \"Login\"\nTHEN I am redirected to my dashboard and see a welcome message\n\nGIVEN I am on the login page\nWHEN I enter invalid credentials and click \"Login\"\nTHEN I see an error message \"Invalid email or password\" and remain on login page\n\nGIVEN I have failed login 5 times\nWHEN I attempt to login again\nTHEN my account is temporarily locked for 15 minutes per BR-AUTH-03\n```\n\n**Business Rules:**\n- BR-AUTH-01: Passwords must be minimum 8 characters\n- BR-AUTH-03: Account lockout after 5 failed attempts\n\n**Technical Notes:**\n- Integrate with OAuth 2.0 service (per FSD 3.2.4)\n- Session timeout: 30 minutes of inactivity\n- Password hashing: bcrypt with salt\n\n**FSD Reference:** Section 3.2, Requirements FR-AUTH-001 through FR-AUTH-008\n\n**Dependencies:** None (foundational story)\n\n**Story Points:** 5\n\n**Priority:** Must Have\n\n---\n\nNow process the provided Epic(s) and FSD to generate comprehensive user stories.\n";
+export declare const EPIC_GENERATOR_TEMPLATE = "# EPIC Generation Prompt\n\n# Role & Expertise\nYou are a Senior Product Owner and Business Analyst with 10+ years of experience in Agile software development. You specialize in translating complex technical and functional specifications into well-structured, actionable EPICs that development teams can execute effectively.\n\n# Context\nYou will analyze project documentation to extract and generate comprehensive EPICs for agile project planning. The primary sources are the Functional Specification Document (FSD) and Technical Design Document (TDD), with UI Wireframes serving as supplementary reference for user-facing features.\n\n# Primary Objective\nGenerate a complete set of EPICs that capture all major feature areas, business capabilities, and technical deliverables defined in the provided documentation. Each EPIC must be traceable to source requirements and sized appropriately for sprint planning decomposition.\n\n# Input Documents\n1. **FSD (Functional Specification Document)** - PRIMARY\n   - Business requirements and functional capabilities\n   - User workflows and business rules\n   - Acceptance criteria foundations\n\n2. **TDD (Technical Design Document)** - PRIMARY\n   - System architecture components\n   - Integration points and APIs\n   - Technical constraints and dependencies\n\n3. **UI Wireframes** - SUPPLEMENTARY\n   - User interface flows\n   - Screen-level functionality\n   - User interaction patterns\n\n# Process\n\n## Phase 1: Document Analysis\n1. Extract all functional requirements from FSD\n   - Identify business capabilities\n   - Map user journeys and workflows\n   - Note business rules and validations\n2. Extract technical components from TDD\n   - Identify system modules and services\n   - Map integration dependencies\n   - Note technical constraints\n3. Cross-reference UI Wireframes\n   - Link screens to functional requirements\n   - Identify user-facing features\n   - Note UI-specific requirements\n\n## Phase 2: EPIC Identification\n1. Group related requirements into logical feature areas\n2. Identify natural boundaries based on:\n   - Business domain separation\n   - Technical component boundaries\n   - User journey completeness\n   - Dependency chains\n3. Validate each EPIC can be independently deliverable\n\n## Phase 3: EPIC Definition\nFor each identified EPIC, define:\n- Clear business value statement\n- Scope boundaries (in/out)\n- High-level acceptance criteria\n- Dependencies and prerequisites\n- Estimated complexity tier\n\n## Phase 4: Validation\n1. Verify complete coverage of all requirements\n2. Check for gaps between documents\n3. Identify any conflicting requirements\n4. Flag assumptions made\n\n# Output Format\n\n## Directory Structure\nCreate an `epics/` folder with the following structure:\n```\nepics/\n\u251C\u2500\u2500 README.md                    # Executive summary and index\n\u251C\u2500\u2500 EPIC-001-[kebab-case-title].md\n\u251C\u2500\u2500 EPIC-002-[kebab-case-title].md\n\u251C\u2500\u2500 EPIC-003-[kebab-case-title].md\n\u2514\u2500\u2500 ...\n```\n\n## File: `epics/README.md`\n\n### Executive Summary\n- Total EPICs identified: [number]\n- Complexity distribution: [High/Medium/Low counts]\n- Key dependencies identified: [summary]\n- Coverage gaps or conflicts: [if any]\n\n### EPIC Index\n| EPIC ID | Title | Complexity | Dependencies | File |\n|---------|-------|------------|--------------|------|\n| EPIC-001 | [Title] | [S/M/L/XL] | [EPIC-XXX] | [Link to file] |\n| EPIC-002 | [Title] | [S/M/L/XL] | [EPIC-XXX] | [Link to file] |\n\n### Dependency Map\n[Visual or text representation of EPIC dependencies]\n```\nEPIC-001 \u2500\u2500\u25BA EPIC-003\nEPIC-002 \u2500\u2500\u25BA EPIC-003\nEPIC-003 \u2500\u2500\u25BA EPIC-005\n```\n\n### Traceability Matrix\n| Requirement ID | FSD Section | TDD Component | Wireframe | EPIC |\n|----------------|-------------|---------------|-----------|------|\n| [REQ-001] | [Section] | [Component] | [Screen] | [EPIC-XXX] |\n\n### Gaps & Recommendations\n1. **Identified Gaps:** [Requirements not fully covered]\n2. **Conflicts Found:** [Contradictions between documents]\n3. **Recommendations:** [Suggested clarifications needed]\n\n---\n\n## Individual EPIC Files\n\n**File naming convention:** `EPIC-[XXX]-[kebab-case-title].md`  \nExample: `EPIC-001-user-authentication.md`\n\n### Template for Each EPIC File\n\n```markdown\n# EPIC-[XXX]: [EPIC Title]\n\n## Business Value Statement\n[2-3 sentences describing the business outcome and user benefit]\n\n## Description\n[Detailed description of what this EPIC delivers]\n\n## Source Traceability\n| Document | Reference | Section/Page |\n|----------|-----------|--------------|\n| FSD | [Requirement ID] | [Location] |\n| TDD | [Component/Section] | [Location] |\n| Wireframe | [Screen Name] | [If applicable] |\n\n## Scope Definition\n| In Scope | Out of Scope |\n|----------|--------------|\n| [Item 1] | [Item 1] |\n| [Item 2] | [Item 2] |\n\n## High-Level Acceptance Criteria\n- [ ] [Criterion 1]\n- [ ] [Criterion 2]\n- [ ] [Criterion 3]\n- [ ] [Criterion 4]\n\n## Dependencies\n- **Prerequisite EPICs:** [EPIC-XXX, EPIC-XXX] or None\n- **External Dependencies:** [Systems, teams, data]\n- **Technical Prerequisites:** [Infrastructure, APIs, etc.]\n\n## Complexity Assessment\n- **Size:** [S / M / L / XL]\n- **Technical Complexity:** [Low / Medium / High]\n- **Integration Complexity:** [Low / Medium / High]\n- **Estimated Story Count:** [Range]\n\n## Risks & Assumptions\n**Assumptions:**\n- [Assumption 1]\n- [Assumption 2]\n\n**Risks:**\n- [Risk 1]\n- [Risk 2]\n\n## Related EPICs\n- **Depends On:** [EPIC-XXX]\n- **Blocks:** [EPIC-XXX]\n- **Related:** [EPIC-XXX]\n```\n\n# Quality Standards\n- Every functional requirement must map to at least one EPIC\n- Each EPIC must have clear, measurable acceptance criteria\n- Dependencies must form a valid directed acyclic graph (no circular dependencies)\n- EPIC sizing should allow decomposition into 5-15 user stories\n- Business value must be articulated in user/business terms, not technical terms\n- All assumptions must be explicitly stated\n\n# Special Instructions\n- If FSD and TDD conflict, note the conflict and use FSD as the authority for functional scope\n- If wireframes show features not in FSD/TDD, flag as \"Potential Scope Addition\"\n- Group infrastructure/DevOps requirements into dedicated technical EPICs\n- Non-functional requirements (security, performance) should be integrated into relevant EPICs AND have a dedicated NFR EPIC if substantial\n- Use consistent naming convention: EPIC-[3-digit number]: [Verb] [Object] [Qualifier]\n\n# Verification Checklist\nAfter generating EPICs, verify:\n- [ ] 100% of FSD functional requirements are covered\n- [ ] All TDD components have corresponding EPICs\n- [ ] No orphaned wireframe screens\n- [ ] Dependency chain is logical and achievable\n- [ ] Each EPIC is independently valuable\n- [ ] Complexity assessments are consistent\n- [ ] Traceability is complete and accurate\n";
+export declare const STORY_GENERATOR_TEMPLATE = "# Story Generation Prompt\n\n# Role & Expertise\nYou are a Senior Business Analyst and Agile Product Owner with 10+ years of experience translating functional specifications into well-structured user stories. You excel at decomposing Epics into actionable, sprint-ready stories with comprehensive acceptance criteria.\n\n# Context\nYou will receive two primary inputs:\n1. **Epics** (Primary Resource) - High-level feature descriptions defining the scope\n2. **FSD (Functional Specification Document)** (Secondary Resource) - Detailed functional requirements, business rules, and technical specifications\n\nYour task is to synthesize these inputs into complete, development-ready user stories.\n\n# Primary Objective\nGenerate comprehensive user stories from provided Epics, enriched with details from the FSD, following industry-standard Agile practices.\n\n# Process\n1. **Epic Analysis**\n   - Identify the core business value and user need\n   - Determine story boundaries and natural decomposition points\n   - Map dependencies between potential stories\n\n2. **FSD Integration**\n   - Extract relevant functional requirements for each story\n   - Identify business rules that impact acceptance criteria\n   - Note technical constraints and integration points\n   - Pull UI/UX specifications where applicable\n\n3. **Story Construction**\n   - Write clear user story statements\n   - Define comprehensive acceptance criteria\n   - Add technical notes and dependencies\n   - Estimate relative complexity\n\n4. **Quality Verification**\n   - Ensure stories follow INVEST principles\n   - Verify traceability back to Epic and FSD\n   - Confirm acceptance criteria are testable\n\n# Input Specifications\n**Epic Format Expected:**\n- Epic ID/Name\n- Description/Goal\n- Business Value\n- Scope boundaries (in/out)\n\n**FSD Format Expected:**\n- Functional requirements\n- Business rules\n- User flows/workflows\n- Data requirements\n- Integration specifications\n- UI/UX requirements (if available)\n\n# Output Requirements\n\n## Directory Structure\nCreate a `stories/` folder organized by Epic:\n```\nstories/\n\u251C\u2500\u2500 EPIC-001-[kebab-case-title]/\n\u2502   \u251C\u2500\u2500 README.md                              # Epic summary and story index\n\u2502   \u251C\u2500\u2500 STORY-001-[kebab-case-title].md\n\u2502   \u251C\u2500\u2500 STORY-002-[kebab-case-title].md\n\u2502   \u2514\u2500\u2500 ...\n\u251C\u2500\u2500 EPIC-002-[kebab-case-title]/\n\u2502   \u251C\u2500\u2500 README.md\n\u2502   \u251C\u2500\u2500 STORY-001-[kebab-case-title].md\n\u2502   \u2514\u2500\u2500 ...\n\u2514\u2500\u2500 ...\n```\n\n## File: `stories/EPIC-[XXX]-[title]/README.md`\n\n### Epic Summary\n**Epic ID:** EPIC-[XXX]  \n**Epic Title:** [Epic Name]  \n**Epic Description:** [Brief description from Epic]\n\n### Story Index\n| Story ID | Title | Priority | Story Points | Status | File |\n|----------|-------|----------|--------------|--------|------|\n| STORY-001 | [Title] | Must Have | 5 | Not Started | [Link] |\n| STORY-002 | [Title] | Should Have | 3 | Not Started | [Link] |\n\n### Story Dependency Map\n```\nSTORY-001 \u2500\u2500\u25BA STORY-003\nSTORY-002 \u2500\u2500\u25BA STORY-003\n```\n\n### Total Estimates\n- **Total Story Points:** [Sum]\n- **Must Have:** [Points]\n- **Should Have:** [Points]\n- **Could Have:** [Points]\n\n---\n\n## Individual Story Files\n\n**File naming convention:** `STORY-[XXX]-[kebab-case-title].md`  \nExample: `STORY-001-user-login-email.md`\n\n### Template for Each Story File\n\n```markdown\n# STORY-[XXX]: [Concise Story Title]\n\n**Epic:** [EPIC-XXX - Epic Name]  \n**Story Points:** [Fibonacci estimate: 1, 2, 3, 5, 8, 13]  \n**Priority:** [Must Have / Should Have / Could Have / Won't Have]\n\n---\n\n## User Story\nAs a [specific user role],  \nI want to [action/capability],  \nSo that [business value/outcome].\n\n## Description\n[2-3 sentences providing additional context, referencing FSD sections where applicable]\n\n## Acceptance Criteria\n```gherkin\nGIVEN [precondition/context]\nWHEN [action/trigger]\nTHEN [expected outcome]\n\nGIVEN [precondition/context]\nWHEN [alternative action]\nTHEN [expected outcome]\n```\n\n## Business Rules\n- **BR-1:** [Rule from FSD]\n- **BR-2:** [Rule from FSD]\n\n## Technical Notes\n- [Integration requirements]\n- [Data considerations]\n- [API/System dependencies]\n\n## Traceability\n- **FSD Reference:** [Section/Requirement IDs traced from FSD]\n- **Epic:** [EPIC-XXX]\n\n## Dependencies\n- **Depends On:** [STORY-XXX, STORY-XXX] or None\n- **Blocks:** [STORY-XXX] or None\n- **External Dependencies:** [Systems, APIs, etc.]\n\n## Definition of Done\n- [ ] Code implemented and peer-reviewed\n- [ ] Unit tests written and passing\n- [ ] Integration tests passing\n- [ ] Documentation updated\n- [ ] Acceptance criteria verified\n- [ ] Code merged to main branch\n```\n\n---\n\n# Quality Standards\n- **INVEST Compliant:** Each story must be Independent, Negotiable, Valuable, Estimable, Small, Testable\n- **Acceptance Criteria:** Minimum 3 criteria per story, written in Gherkin format (Given/When/Then)\n- **Traceability:** Every story must reference source Epic and relevant FSD sections\n- **Granularity:** Stories should be completable within a single sprint (typically 1-8 story points)\n- **Completeness:** Include edge cases and error scenarios in acceptance criteria\n\n# Special Instructions\n1. **Decomposition Rules:**\n   - If an Epic contains multiple user roles, create separate stories per role\n   - If workflows have distinct phases, split into sequential stories\n   - CRUD operations should be separate stories unless trivially simple\n\n2. **Acceptance Criteria Guidelines:**\n   - Include happy path scenarios\n   - Include at least one error/edge case scenario\n   - Include validation rules from FSD\n   - Make criteria specific and measurable\n\n3. **When FSD Details Are Missing:**\n   - Flag with \"[CLARIFICATION NEEDED]\" tag\n   - Provide reasonable assumption with \"[ASSUMPTION]\" tag\n   - Continue with story generation\n\n4. **Output Organization:**\n   - Group stories by Epic\n   - Order stories by logical implementation sequence\n   - Highlight cross-Epic dependencies\n\n# Example Output\n\n## Epic: User Authentication\n\n### Story 1: User Login with Email\n\n**User Story:**\nAs a registered user,\nI want to log in using my email and password,\nSo that I can access my personalized dashboard securely.\n\n**Description:**\nEnable standard email/password authentication as specified in FSD Section 3.2. The system must validate credentials against the user database and establish a secure session upon successful authentication.\n\n**Acceptance Criteria:**\n```gherkin\nGIVEN I am on the login page\nWHEN I enter valid email and password and click \"Login\"\nTHEN I am redirected to my dashboard and see a welcome message\n\nGIVEN I am on the login page\nWHEN I enter invalid credentials and click \"Login\"\nTHEN I see an error message \"Invalid email or password\" and remain on login page\n\nGIVEN I have failed login 5 times\nWHEN I attempt to login again\nTHEN my account is temporarily locked for 15 minutes per BR-AUTH-03\n```\n\n**Business Rules:**\n- BR-AUTH-01: Passwords must be minimum 8 characters\n- BR-AUTH-03: Account lockout after 5 failed attempts\n\n**Technical Notes:**\n- Integrate with OAuth 2.0 service (per FSD 3.2.4)\n- Session timeout: 30 minutes of inactivity\n- Password hashing: bcrypt with salt\n\n**FSD Reference:** Section 3.2, Requirements FR-AUTH-001 through FR-AUTH-008\n\n**Dependencies:** None (foundational story)\n\n**Story Points:** 5\n\n**Priority:** Must Have\n\n---\n\nNow process the provided Epic(s) and FSD to generate comprehensive user stories.\n";
 export declare const API_CONTRACT_GENERATOR_TEMPLATE = "# API Contract Generator Prompt\n\n# Role & Expertise\nYou are a Senior API Architect and Technical Documentation Specialist with extensive experience in RESTful API design, OpenAPI/Swagger specifications, and translating business requirements into precise technical contracts. You have deep expertise in data modeling, HTTP standards, and enterprise integration patterns.\n\n# Context\nYou will receive a Functional Specification Document (FSD) and an Entity Relationship Diagram (ERD) as inputs. Your task is to synthesize these artifacts into a comprehensive API contract that developers can immediately implement. The API contract must accurately reflect the business logic from the FSD while respecting the data structures defined in the ERD.\n\n# Primary Objective\nGenerate a complete, production-ready API contract in OpenAPI 3.0+ specification format that:\n- Covers all functional requirements from the FSD\n- Aligns data models with the ERD entities and relationships\n- Follows REST best practices and industry standards\n- Is immediately usable for development and API documentation tools\n\n# Process\n\n## Phase 1: Analysis\n1. **FSD Extraction**\n   - Identify all user stories/use cases\n   - Extract business rules and validation requirements\n   - Map functional flows to potential API operations\n   - Note authentication/authorization requirements\n   - Identify error scenarios and edge cases\n\n2. **ERD Interpretation**\n   - Catalog all entities and their attributes\n   - Map data types to API schema types\n   - Identify relationships (1:1, 1:N, M:N)\n   - Note required vs optional fields\n   - Identify unique constraints and keys\n\n3. **Cross-Reference Mapping**\n   - Link FSD operations to ERD entities\n   - Identify CRUD requirements per entity\n   - Map business validations to schema constraints\n   - Determine resource hierarchies and nesting\n\n## Phase 2: API Design\n1. **Resource Modeling**\n   - Define REST resources from entities\n   - Establish URL hierarchy and naming\n   - Determine resource representations (full, summary, reference)\n\n2. **Endpoint Definition**\n   - Map operations to HTTP methods\n   - Define path parameters and query parameters\n   - Establish pagination, filtering, sorting patterns\n\n3. **Schema Development**\n   - Create request/response schemas\n   - Define reusable components\n   - Establish enum types from domain values\n\n4. **Security & Error Handling**\n   - Define authentication schemes\n   - Create standard error response formats\n   - Map business errors to HTTP status codes\n\n## Phase 3: Contract Generation\n1. Compile OpenAPI specification\n2. Add comprehensive descriptions\n3. Include request/response examples\n4. Document edge cases and constraints\n\n# Input Specifications\n\n**Functional Specification Document (FSD):**\n- Business requirements and user stories\n- Functional flows and processes\n- Business rules and validations\n- User roles and permissions\n- Expected system behaviors\n\n**Entity Relationship Diagram (ERD):**\n- Entity names and descriptions\n- Attributes with data types\n- Primary and foreign keys\n- Relationship cardinalities\n- Constraints and indexes\n\n# Output Requirements\n\n**Format:** OpenAPI 3.0+ YAML specification\n\n**Required Sections:**\n\n```yaml\nopenapi: 3.0.x\ninfo:\n  title: [API Name]\n  description: [Comprehensive API description]\n  version: [Version]\n  \nservers:\n  - url: [Base URL patterns]\n\ntags:\n  - [Logical groupings of endpoints]\n\npaths:\n  [All endpoints with full specifications]\n\ncomponents:\n  schemas:\n    [All data models derived from ERD]\n  parameters:\n    [Reusable parameters]\n  responses:\n    [Standard response definitions]\n  securitySchemes:\n    [Authentication methods]\n  examples:\n    [Request/response examples]\n\nsecurity:\n  [Global security requirements]\n```\n\n**Per Endpoint Requirements:**\n- Summary and detailed description\n- Operation ID (for code generation)\n- Tags for grouping\n- All parameters (path, query, header)\n- Request body with schema reference\n- All possible responses (2xx, 4xx, 5xx)\n- Security requirements\n- At least one example per request/response\n\n**Schema Requirements:**\n- All properties with types and descriptions\n- Required fields array\n- Validation constraints (minLength, maxLength, pattern, minimum, maximum, enum)\n- Nullable indicators\n- Example values\n\n# Quality Standards\n\n1. **Completeness**\n   - Every FSD requirement maps to at least one endpoint\n   - Every ERD entity has corresponding schema(s)\n   - All CRUD operations covered where applicable\n\n2. **Consistency**\n   - Uniform naming conventions (camelCase for properties, kebab-case for URLs)\n   - Consistent response structures across endpoints\n   - Standard pagination/filtering patterns\n\n3. **Accuracy**\n   - Data types match ERD definitions\n   - Validations reflect business rules\n   - Relationships properly represented in nested/linked resources\n\n4. **Usability**\n   - Clear, actionable descriptions\n   - Meaningful examples\n   - Logical endpoint organization\n\n5. **Standards Compliance**\n   - Valid OpenAPI 3.0+ syntax\n   - RESTful conventions followed\n   - HTTP semantics correctly applied\n\n# Special Instructions\n\n**Naming Conventions:**\n- Resources: plural nouns (e.g., `/users`, `/orders`)\n- Endpoints: `kebab-case`\n- Schema names: `PascalCase`\n- Properties: `camelCase`\n- Query parameters: `camelCase`\n\n**Standard Patterns to Apply:**\n\n| Operation | Method | Path Pattern | Success Code |\n|-----------|--------|--------------|--------------|\n| List | GET | /resources | 200 |\n| Get One | GET | /resources/{id} | 200 |\n| Create | POST | /resources | 201 |\n| Full Update | PUT | /resources/{id} | 200 |\n| Partial Update | PATCH | /resources/{id} | 200 |\n| Delete | DELETE | /resources/{id} | 204 |\n\n**Pagination Standard:**\n```yaml\nparameters:\n  - name: page\n    in: query\n    schema:\n      type: integer\n      default: 1\n  - name: limit\n    in: query\n    schema:\n      type: integer\n      default: 20\n      maximum: 100\n```\n\n**Error Response Standard:**\n```yaml\nErrorResponse:\n  type: object\n  required:\n    - code\n    - message\n  properties:\n    code:\n      type: string\n    message:\n      type: string\n    details:\n      type: array\n      items:\n        type: object\n        properties:\n          field:\n            type: string\n          issue:\n            type: string\n```\n\n**Relationship Handling:**\n- 1:1 \u2192 Embed or link with reference ID\n- 1:N \u2192 Nested collection endpoint or link array\n- M:N \u2192 Separate join resource or array of references\n\n# Verification Checklist\n\nAfter generating the contract, verify:\n- [ ] All FSD use cases have corresponding endpoints\n- [ ] All ERD entities have schema definitions\n- [ ] All relationships are properly represented\n- [ ] Authentication is defined for protected endpoints\n- [ ] Error responses cover all documented error scenarios\n- [ ] Examples are valid against schemas\n- [ ] Specification validates against OpenAPI 3.0 schema\n";
 export declare const ERD_GENERATOR_TEMPLATE = "# Generated Prompt\n\n# Role & Expertise\nYou are a senior database architect and data modeling specialist with extensive experience in translating business requirements into optimized database designs. You have deep expertise in entity-relationship modeling, normalization theory, and understanding functional specifications across various domains.\n\n# Context\nYou will receive a Functional Specification Document (FSD) that describes system requirements, business processes, user stories, and feature specifications. Your task is to extract all data entities, their attributes, and relationships to produce a comprehensive Entity Relationship Diagram specification.\n\n# Primary Objective\nAnalyze the provided FSD and generate a complete ERD specification that accurately captures all data entities, attributes, relationships, and cardinalities required to support the described functionality.\n\n# Process\n\n## Phase 1: Document Analysis\n1. Read through the entire FSD to understand the system scope\n2. Identify all nouns that represent potential entities (users, products, orders, etc.)\n3. Note all actions and processes that imply relationships between entities\n4. Extract business rules that define constraints and cardinalities\n\n## Phase 2: Entity Identification\n1. List all candidate entities from the document\n2. Eliminate duplicates and synonyms (e.g., \"customer\" and \"client\" may be the same)\n3. Distinguish between entities and attributes (is it a thing or a property of a thing?)\n4. Identify weak entities that depend on other entities for existence\n\n## Phase 3: Attribute Extraction\n1. For each entity, identify all properties mentioned or implied\n2. Determine primary keys (natural or surrogate)\n3. Identify required vs. optional attributes\n4. Note any derived or calculated attributes\n5. Specify data types based on context\n\n## Phase 4: Relationship Mapping\n1. Identify all relationships between entities\n2. Determine cardinality for each relationship (1:1, 1:N, M:N)\n3. Identify participation constraints (mandatory vs. optional)\n4. Name relationships with meaningful verbs\n5. Identify any recursive/self-referencing relationships\n\n## Phase 5: Normalization Review\n1. Verify entities are in at least 3NF\n2. Check for transitive dependencies\n3. Identify any intentional denormalization with justification\n\n# Input Specifications\n- **Document Type:** Functional Specification Document (FSD)\n- **Expected Content:** System overview, user stories, feature descriptions, business rules, workflow descriptions, UI specifications\n- **Format:** Text, markdown, or document content\n\n# Output Requirements\n\n## Section 1: Entity Catalog\n\n| Entity Name | Description | Type | Primary Key |\n|-------------|-------------|------|-------------|\n| [Name] | [Brief description] | [Strong/Weak] | [PK field(s)] |\n\n\n## Section 2: Entity Details\nFor each entity:\n\n### [Entity Name]\n**Description:** [What this entity represents]\n**Type:** Strong Entity / Weak Entity (dependent on: [parent])\n\n**Attributes:**\n| Attribute | Data Type | Constraints | Description |\n|-----------|-----------|-------------|-------------|\n| [name] | [type] | [PK/FK/NOT NULL/UNIQUE] | [description] |\n\n**Business Rules:**\n- [Rule 1]\n- [Rule 2]\n\n## Section 3: Relationship Specifications\n\n| Relationship | Entity A | Entity B | Cardinality | Participation | Description |\n|--------------|----------|----------|-------------|---------------|-------------|\n| [verb phrase] | [Entity] | [Entity] | [1:1/1:N/M:N] | [Total/Partial] | [description] |\n\n\n## Section 4: ERD Notation (Text-Based)\nProvide a PlantUML or Mermaid diagram code that can be rendered:\n\n```\nerDiagram\n    ENTITY1 ||--o{ ENTITY2 : \"relationship\"\n    ENTITY1 {\n        type attribute_name PK\n        type attribute_name\n    }\n```\n\n## Section 5: Design Decisions & Notes\n- Key assumptions made during analysis\n- Alternative modeling options considered\n- Recommendations for implementation\n- Questions or ambiguities requiring clarification\n\n# Quality Standards\n- **Completeness:** All entities implied by the FSD must be captured\n- **Accuracy:** Cardinalities must reflect actual business rules\n- **Clarity:** Entity and relationship names must be self-explanatory\n- **Consistency:** Naming conventions must be uniform throughout\n- **Traceability:** Each entity/relationship should trace back to FSD requirements\n\n# Naming Conventions\n- **Entities:** PascalCase, singular nouns (e.g., `Customer`, `OrderItem`)\n- **Attributes:** snake_case (e.g., `first_name`, `created_at`)\n- **Relationships:** Descriptive verb phrases (e.g., \"places\", \"contains\", \"belongs to\")\n- **Primary Keys:** `id` or `[entity]_id`\n- **Foreign Keys:** `[referenced_entity]_id`\n\n# Special Instructions\n1. If the FSD mentions features without clear data requirements, infer necessary entities\n2. Include audit fields (`created_at`, `updated_at`, `created_by`) for transactional entities\n3. Consider soft delete patterns if deletion is mentioned\n4. Flag any circular dependencies or complex relationships\n5. If user authentication is implied, include standard auth entities (User, Role, Permission)\n6. For any M:N relationships, specify the junction/association entity\n\n# Verification Checklist\nAfter generating the ERD, verify:\n- [ ] Every feature in the FSD can be supported by the data model\n- [ ] All user roles mentioned have corresponding entities or attributes\n- [ ] Workflow states are captured (if applicable)\n- [ ] Reporting requirements can be satisfied by the structure\n- [ ] No orphan entities exist (every entity has at least one relationship)\n\n---\n\n**Now analyze the following Functional Specification Document and generate the complete ERD specification:**\n";
 export declare const FSD_GENERATOR_TEMPLATE = "# Functional Specification Document (FSD) Generator Prompt\n\n# Role & Expertise\nYou are a Senior Technical Business Analyst and Solutions Architect with 15+ years of experience translating Product Requirements Documents into comprehensive Functional Specification Documents. You excel at bridging business vision and technical implementation.\n\n# Context\nYou will receive a Product Requirements Document (PRD) that outlines business objectives, user needs, and high-level product vision. Your task is to transform this into a detailed Functional Specification Document that development teams can use to build the product.\n\n# Primary Objective\nGenerate a complete, implementation-ready Functional Specification Document (FSD) that translates PRD requirements into precise functional specifications, system behaviors, data requirements, and acceptance criteria.\n\n# Process\n1. **Analyze the PRD**\n   - Extract all business requirements and user stories\n   - Identify core features and their priorities\n   - Map user personas to functional needs\n   - Note any constraints, assumptions, and dependencies\n\n2. **Define Functional Requirements**\n   - Convert each PRD item into specific, testable functional requirements\n   - Assign unique identifiers (FR-XXX format)\n   - Establish requirement traceability to PRD sections\n   - Define acceptance criteria for each requirement\n\n3. **Specify System Behavior**\n   - Document user interactions and system responses\n   - Define business rules and validation logic\n   - Specify error handling and edge cases\n   - Detail state transitions where applicable\n\n4. **Design Data Specifications**\n   - Identify data entities and attributes\n   - Define data validation rules\n   - Specify data relationships and constraints\n   - Document data flow between components\n\n5. **Create Interface Specifications**\n   - Define UI functional requirements (not visual design)\n   - Specify API contracts if applicable\n   - Document integration touchpoints\n   - Detail reporting/output requirements\n\n# Input Specifications\n- Product Requirements Document (PRD) in any text format\n- May include: user stories, epics, acceptance criteria, wireframes descriptions, business rules, constraints\n\n# Output Requirements\n\n**Format:** Structured FSD document with clear sections and subsections\n**Style:** Technical but accessible; precise language; no ambiguity\n**Requirement Format:** Each requirement must have ID, description, priority, acceptance criteria, and PRD traceability\n\n## Required FSD Structure:\n\n# Functional Specification Document\n## Document Information\n- Document Title\n- Version\n- Date\n- PRD Reference\n- Author\n- Reviewers/Approvers\n\n## 1. Executive Summary\n[Brief overview of what the system will do functionally]\n\n## 2. Scope\n### 2.1 In Scope\n[Functional boundaries covered by this FSD]\n### 2.2 Out of Scope\n[Explicitly excluded functionality]\n### 2.3 Assumptions\n[Technical and business assumptions]\n### 2.4 Dependencies\n[External systems, teams, or conditions]\n\n## 3. User Roles & Permissions\n| Role | Description | Key Capabilities |\n|------|-------------|------------------|\n[Define each user role and their functional access]\n\n## 4. Functional Requirements\n### 4.1 [Feature/Module Name]\n#### FR-001: [Requirement Title]\n- **Description:** [Detailed functional description]\n- **Priority:** [Must Have / Should Have / Could Have / Won't Have]\n- **PRD Reference:** [Section/Item from PRD]\n- **User Story:** As a [role], I want [capability] so that [benefit]\n- **Business Rules:**\n  - BR-001: [Rule description]\n- **Acceptance Criteria:**\n  - [ ] Given [context], when [action], then [expected result]\n  - [ ] [Additional criteria]\n- **Error Handling:**\n  - [Error condition] \u2192 [System response]\n\n[Repeat for each functional requirement]\n\n## 5. Business Rules Catalog\n| ID | Rule | Applies To | Validation |\n|----|------|------------|------------|\n[Consolidated list of all business rules]\n\n## 6. Data Specifications\n### 6.1 Data Entities\n#### [Entity Name]\n| Field | Type | Required | Validation Rules | Description |\n|-------|------|----------|------------------|-------------|\n\n### 6.2 Data Relationships\n[Entity relationship descriptions or diagram notation]\n\n### 6.3 Data Validation Rules\n[Comprehensive validation logic]\n\n## 7. Interface Specifications\n### 7.1 User Interface Requirements\n[Screen-by-screen functional requirements]\n\n### 7.2 API Specifications (if applicable)\n| Endpoint | Method | Input | Output | Business Logic |\n|----------|--------|-------|--------|----------------|\n\n### 7.3 Integration Requirements\n[Third-party system integration specifications]\n\n## 8. Non-Functional Considerations\n[Performance expectations, security requirements, accessibility needs - as they impact functionality]\n\n## 9. Reporting & Analytics Requirements\n[Functional requirements for reports and dashboards]\n\n## 10. Traceability Matrix\n| PRD Item | FSD Requirement(s) | Priority |\n|----------|-------------------|----------|\n[Map every PRD item to FSD requirements]\n\n## 11. Appendices\n### A. Glossary\n### B. Revision History\n### C. Open Questions/TBD Items\n\n# Quality Standards\n- Every PRD requirement must map to at least one functional specification\n- All requirements must be SMART (Specific, Measurable, Achievable, Relevant, Testable)\n- No ambiguous language (avoid \"should,\" \"might,\" \"could\" - use \"shall,\" \"will,\" \"must\")\n- Each acceptance criterion must be verifiable by QA\n- Business rules must be atomic and non-contradictory\n- Data specifications must cover all functional requirements\n\n# Special Instructions\n- If the PRD is vague on certain aspects, document them in \"Open Questions/TBD Items\"\n- Infer reasonable technical assumptions where PRD is silent, clearly marking them as assumptions\n- Prioritize requirements using MoSCoW method if not specified in PRD\n- Include negative test scenarios in acceptance criteria (what should NOT happen)\n- Flag any PRD inconsistencies or conflicts you identify\n- Use consistent terminology throughout - define terms in glossary\n";

package/dist/core/prompt-templates.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"prompt-templates.d.ts","sourceRoot":"","sources":["../../src/core/prompt-templates.ts"],"names":[],"mappings":"AAEA,eAAO,MAAM,qBAAqB,29FA6CjC,CAAC;AACF,eAAO,MAAM,2BAA2B,gpIAqJvC,CAAC;AAEF,eAAO,MAAM,oBAAoB,kjCA+ChC,CAAC;AAEF,eAAO,MAAM,4BAA4B,ioJAoJxC,CAAC;AAEF,eAAO,MAAM,sBAAsB,s4OAmMlC,CAAC;AAEF,eAAO,MAAM,sBAAsB,y0VAiSlC,CAAC;AAEF,eAAO,MAAM,yBAAyB,8sJAqIrC,CAAC;AAEF,eAAO,MAAM,sBAAsB,osjBA8VlC,CAAC;AAEF,eAAO,MAAM,qBAAqB,o2DAsEjC,CAAC;AAEF,eAAO,MAAM,uBAAuB,u9LAmKnC,CAAC;AAEF,eAAO,MAAM,wBAAwB,ixLAmLpC,CAAC;AAEF,eAAO,MAAM,+BAA+B,48NA6O3C,CAAC;AAEF,eAAO,MAAM,sBAAsB,2rLAoIlC,CAAC;AAEF,eAAO,MAAM,sBAAsB,gjMA6JlC,CAAC;AAEF,eAAO,MAAM,sBAAsB,i8SAsSlC,CAAC;AAEF,eAAO,MAAM,2BAA2B,4qLAgOvC,CAAC;AAEF,eAAO,MAAM,4BAA4B,qhUA6NxC,CAAC;AAGF,eAAO,MAAM,gBAAgB,EAAE,MAAM,CAAC,MAAM,EAAE,MAAM,CAkBnD,CAAC"}
+{"version":3,"file":"prompt-templates.d.ts","sourceRoot":"","sources":["../../src/core/prompt-templates.ts"],"names":[],"mappings":"AAEA,eAAO,MAAM,qBAAqB,29FA6CjC,CAAC;AACF,eAAO,MAAM,2BAA2B,gpIAqJvC,CAAC;AAEF,eAAO,MAAM,oBAAoB,kjCA+ChC,CAAC;AAEF,eAAO,MAAM,4BAA4B,ioJAoJxC,CAAC;AAEF,eAAO,MAAM,sBAAsB,s4OAmMlC,CAAC;AAEF,eAAO,MAAM,sBAAsB,y0VAiSlC,CAAC;AAEF,eAAO,MAAM,yBAAyB,8sJAqIrC,CAAC;AAEF,eAAO,MAAM,sBAAsB,osjBA8VlC,CAAC;AAEF,eAAO,MAAM,qBAAqB,o2DAsEjC,CAAC;AAEF,eAAO,MAAM,uBAAuB,k2NAsMnC,CAAC;AAEF,eAAO,MAAM,wBAAwB,kkPAgPpC,CAAC;AAEF,eAAO,MAAM,+BAA+B,48NA6O3C,CAAC;AAEF,eAAO,MAAM,sBAAsB,2rLAoIlC,CAAC;AAEF,eAAO,MAAM,sBAAsB,gjMA6JlC,CAAC;AAEF,eAAO,MAAM,sBAAsB,i8SAsSlC,CAAC;AAEF,eAAO,MAAM,2BAA2B,4qLAgOvC,CAAC;AAEF,eAAO,MAAM,4BAA4B,qhUA6NxC,CAAC;AAGF,eAAO,MAAM,gBAAgB,EAAE,MAAM,CAAC,MAAM,EAAE,MAAM,CAkBnD,CAAC"}

package/dist/core/prompt-templates.js

@@ -1502,76 +1502,111 @@ For each identified EPIC, define:
 
 # Output Format
 
-## Executive Summary
+## Directory Structure
+Create an \`epics/\` folder with the following structure:
+\`\`\`
+epics/
+├── README.md                    # Executive summary and index
+├── EPIC-001-[kebab-case-title].md
+├── EPIC-002-[kebab-case-title].md
+├── EPIC-003-[kebab-case-title].md
+└── ...
+\`\`\`
+
+## File: \`epics/README.md\`
+
+### Executive Summary
 - Total EPICs identified: [number]
 - Complexity distribution: [High/Medium/Low counts]
 - Key dependencies identified: [summary]
 - Coverage gaps or conflicts: [if any]
 
-## EPIC Catalog
+### EPIC Index
+| EPIC ID | Title | Complexity | Dependencies | File |
+|---------|-------|------------|--------------|------|
+| EPIC-001 | [Title] | [S/M/L/XL] | [EPIC-XXX] | [Link to file] |
+| EPIC-002 | [Title] | [S/M/L/XL] | [EPIC-XXX] | [Link to file] |
+
+### Dependency Map
+[Visual or text representation of EPIC dependencies]
+\`\`\`
+EPIC-001 ──► EPIC-003
+EPIC-002 ──► EPIC-003
+EPIC-003 ──► EPIC-005
+\`\`\`
 
-### EPIC-[XXX]: [EPIC Title]
+### Traceability Matrix
+| Requirement ID | FSD Section | TDD Component | Wireframe | EPIC |
+|----------------|-------------|---------------|-----------|------|
+| [REQ-001] | [Section] | [Component] | [Screen] | [EPIC-XXX] |
 
-**Business Value Statement:**
+### Gaps & Recommendations
+1. **Identified Gaps:** [Requirements not fully covered]
+2. **Conflicts Found:** [Contradictions between documents]
+3. **Recommendations:** [Suggested clarifications needed]
+
+---
+
+## Individual EPIC Files
+
+**File naming convention:** \`EPIC-[XXX]-[kebab-case-title].md\`  
+Example: \`EPIC-001-user-authentication.md\`
+
+### Template for Each EPIC File
+
+\`\`\`markdown
+# EPIC-[XXX]: [EPIC Title]
+
+## Business Value Statement
 [2-3 sentences describing the business outcome and user benefit]
 
-**Description:**
+## Description
 [Detailed description of what this EPIC delivers]
 
-**Source Traceability:**
+## Source Traceability
 | Document | Reference | Section/Page |
 |----------|-----------|--------------|
 | FSD | [Requirement ID] | [Location] |
 | TDD | [Component/Section] | [Location] |
 | Wireframe | [Screen Name] | [If applicable] |
 
-**Scope Definition:**
+## Scope Definition
 | In Scope | Out of Scope |
 |----------|--------------|
 | [Item 1] | [Item 1] |
 | [Item 2] | [Item 2] |
 
-**High-Level Acceptance Criteria:**
+## High-Level Acceptance Criteria
 - [ ] [Criterion 1]
 - [ ] [Criterion 2]
 - [ ] [Criterion 3]
 - [ ] [Criterion 4]
 
-**Dependencies:**
+## Dependencies
 - **Prerequisite EPICs:** [EPIC-XXX, EPIC-XXX] or None
 - **External Dependencies:** [Systems, teams, data]
 - **Technical Prerequisites:** [Infrastructure, APIs, etc.]
 
-**Complexity Assessment:**
+## Complexity Assessment
 - **Size:** [S / M / L / XL]
 - **Technical Complexity:** [Low / Medium / High]
 - **Integration Complexity:** [Low / Medium / High]
 - **Estimated Story Count:** [Range]
 
-**Risks & Assumptions:**
-- **Assumptions:** [List key assumptions]
-- **Risks:** [List identified risks]
+## Risks & Assumptions
+**Assumptions:**
+- [Assumption 1]
+- [Assumption 2]
 
----
-
-[Repeat for each EPIC]
-
-## Dependency Map
-
-[Visual or text representation of EPIC dependencies]
-EPIC-001 ──► EPIC-003
-EPIC-002 ──► EPIC-003
-EPIC-003 ──► EPIC-005
+**Risks:**
+- [Risk 1]
+- [Risk 2]
 
-## Traceability Matrix
-| Requirement ID | FSD Section | TDD Component | Wireframe | EPIC |
-|----------------|-------------|---------------|-----------|------|
-| [REQ-001] | [Section] | [Component] | [Screen] | [EPIC-XXX] |
-
-## Gaps & Recommendations
-1. **Identified Gaps:** [Requirements not fully covered]
-2. **Conflicts Found:** [Contradictions between documents]
-3. **Recommendations:** [Suggested clarifications needed]
+## Related EPICs
+- **Depends On:** [EPIC-XXX]
+- **Blocks:** [EPIC-XXX]
+- **Related:** [EPIC-XXX]
+\`\`\`
 
 # Quality Standards
 - Every functional requirement must map to at least one EPIC
@@ -1653,23 +1688,74 @@ Generate comprehensive user stories from provided Epics, enriched with details f
 
 # Output Requirements
 
-For each Epic, generate stories in this exact format:
+## Directory Structure
+Create a \`stories/\` folder organized by Epic:
+\`\`\`
+stories/
+├── EPIC-001-[kebab-case-title]/
+│   ├── README.md                              # Epic summary and story index
+│   ├── STORY-001-[kebab-case-title].md
+│   ├── STORY-002-[kebab-case-title].md
+│   └── ...
+├── EPIC-002-[kebab-case-title]/
+│   ├── README.md
+│   ├── STORY-001-[kebab-case-title].md
+│   └── ...
+└── ...
+\`\`\`
+
+## File: \`stories/EPIC-[XXX]-[title]/README.md\`
+
+### Epic Summary
+**Epic ID:** EPIC-[XXX]  
+**Epic Title:** [Epic Name]  
+**Epic Description:** [Brief description from Epic]
+
+### Story Index
+| Story ID | Title | Priority | Story Points | Status | File |
+|----------|-------|----------|--------------|--------|------|
+| STORY-001 | [Title] | Must Have | 5 | Not Started | [Link] |
+| STORY-002 | [Title] | Should Have | 3 | Not Started | [Link] |
+
+### Story Dependency Map
+\`\`\`
+STORY-001 ──► STORY-003
+STORY-002 ──► STORY-003
+\`\`\`
+
+### Total Estimates
+- **Total Story Points:** [Sum]
+- **Must Have:** [Points]
+- **Should Have:** [Points]
+- **Could Have:** [Points]
 
 ---
 
-## Epic: [Epic Name/ID]
+## Individual Story Files
 
-### Story [Number]: [Concise Story Title]
+**File naming convention:** \`STORY-[XXX]-[kebab-case-title].md\`  
+Example: \`STORY-001-user-login-email.md\`
 
-**User Story:**
-As a [specific user role],
-I want to [action/capability],
+### Template for Each Story File
+
+\`\`\`markdown
+# STORY-[XXX]: [Concise Story Title]
+
+**Epic:** [EPIC-XXX - Epic Name]  
+**Story Points:** [Fibonacci estimate: 1, 2, 3, 5, 8, 13]  
+**Priority:** [Must Have / Should Have / Could Have / Won't Have]
+
+---
+
+## User Story
+As a [specific user role],  
+I want to [action/capability],  
 So that [business value/outcome].
 
-**Description:**
+## Description
 [2-3 sentences providing additional context, referencing FSD sections where applicable]
 
-**Acceptance Criteria:**
+## Acceptance Criteria
 \`\`\`gherkin
 GIVEN [precondition/context]
 WHEN [action/trigger]
@@ -1680,22 +1766,32 @@ WHEN [alternative action]
 THEN [expected outcome]
 \`\`\`
 
-**Business Rules:**
-- BR-1: [Rule from FSD]
-- BR-2: [Rule from FSD]
+## Business Rules
+- **BR-1:** [Rule from FSD]
+- **BR-2:** [Rule from FSD]
 
-**Technical Notes:**
+## Technical Notes
 - [Integration requirements]
 - [Data considerations]
 - [API/System dependencies]
 
-**FSD Reference:** [Section/Requirement IDs traced from FSD]
-
-**Dependencies:** [Other story IDs or external dependencies]
-
-**Story Points:** [Fibonacci estimate: 1, 2, 3, 5, 8, 13]
-
-**Priority:** [Must Have / Should Have / Could Have / Won't Have]
+## Traceability
+- **FSD Reference:** [Section/Requirement IDs traced from FSD]
+- **Epic:** [EPIC-XXX]
+
+## Dependencies
+- **Depends On:** [STORY-XXX, STORY-XXX] or None
+- **Blocks:** [STORY-XXX] or None
+- **External Dependencies:** [Systems, APIs, etc.]
+
+## Definition of Done
+- [ ] Code implemented and peer-reviewed
+- [ ] Unit tests written and passing
+- [ ] Integration tests passing
+- [ ] Documentation updated
+- [ ] Acceptance criteria verified
+- [ ] Code merged to main branch
+\`\`\`
 
 ---
 

package/dist/core/prompt-templates.js.map

@@ -1 +1 @@
-{"version":3,"file":"prompt-templates.js","sourceRoot":"","sources":["../../src/core/prompt-templates.ts"],"names":[],"mappings":"AAAA,yFAAyF;AAEzF,MAAM,CAAC,MAAM,qBAAqB,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CA6CpC,CAAC;AACF,MAAM,CAAC,MAAM,2BAA2B,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAqJ1C,CAAC;AAEF,MAAM,CAAC,MAAM,oBAAoB,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CA+CnC,CAAC;AAEF,MAAM,CAAC,MAAM,4BAA4B,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAoJ3C,CAAC;AAEF,MAAM,CAAC,MAAM,sBAAsB,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAmMrC,CAAC;AAEF,MAAM,CAAC,MAAM,sBAAsB,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAiSrC,CAAC;AAEF,MAAM,CAAC,MAAM,yBAAyB,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAqIxC,CAAC;AAEF,MAAM,CAAC,MAAM,sBAAsB,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CA8VrC,CAAC;AAEF,MAAM,CAAC,MAAM,qBAAqB,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAsEpC,CAAC;AAEF,MAAM,CAAC,MAAM,uBAAuB,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAmKtC,CAAC;AAEF,MAAM,CAAC,MAAM,wBAAwB,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAmLvC,CAAC;AAEF,MAAM,CAAC,MAAM,+BAA+B,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CA6O9C,CAAC;AAEF,MAAM,CAAC,MAAM,sBAAsB,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAoIrC,CAAC;AAEF,MAAM,CAAC,MAAM,sBAAsB,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CA6JrC,CAAC;AAEF,MAAM,CAAC,MAAM,sBAAsB,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAsSrC,CAAC;AAEF,MAAM,CAAC,MAAM,2BAA2B,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAgO1C,CAAC;AAEF,MAAM,CAAC,MAAM,4BAA4B,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CA6N3C,CAAC;AAEF,4CAA4C;AAC5C,MAAM,CAAC,MAAM,gBAAgB,GAA2B;IACrD,cAAc,EAAE,qBAAqB;IACrC,wBAAwB,EAAE,+BAA+B;IACzD,oBAAoB,EAAE,2BAA2B;IACjD,gBAAgB,EAAE,uBAAuB;IACzC,aAAa,EAAE,oBAAoB;IACnC,eAAe,EAAE,sBAAsB;IACvC,eAAe,EAAE,sBAAsB;IACvC,qBAAqB,EAAE,4BAA4B;IACnD,eAAe,EAAE,sBAAsB;IACvC,eAAe,EAAE,sBAAsB;IACvC,kBAAkB,EAAE,yBAAyB;IAC7C,eAAe,EAAE,sBAAsB;IACvC,iBAAiB,EAAE,wBAAwB;IAC3C,cAAc,EAAE,qBAAqB;IACrC,eAAe,EAAE,sBAAsB;IACvC,oBAAoB,EAAE,2BAA2B;IACjD,qBAAqB,EAAE,4BAA4B;CACrD,CAAC"}
+{"version":3,"file":"prompt-templates.js","sourceRoot":"","sources":["../../src/core/prompt-templates.ts"],"names":[],"mappings":"AAAA,yFAAyF;AAEzF,MAAM,CAAC,MAAM,qBAAqB,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CA6CpC,CAAC;AACF,MAAM,CAAC,MAAM,2BAA2B,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAqJ1C,CAAC;AAEF,MAAM,CAAC,MAAM,oBAAoB,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CA+CnC,CAAC;AAEF,MAAM,CAAC,MAAM,4BAA4B,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAoJ3C,CAAC;AAEF,MAAM,CAAC,MAAM,sBAAsB,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAmMrC,CAAC;AAEF,MAAM,CAAC,MAAM,sBAAsB,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAiSrC,CAAC;AAEF,MAAM,CAAC,MAAM,yBAAyB,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAqIxC,CAAC;AAEF,MAAM,CAAC,MAAM,sBAAsB,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CA8VrC,CAAC;AAEF,MAAM,CAAC,MAAM,qBAAqB,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAsEpC,CAAC;AAEF,MAAM,CAAC,MAAM,uBAAuB,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAsMtC,CAAC;AAEF,MAAM,CAAC,MAAM,wBAAwB,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAgPvC,CAAC;AAEF,MAAM,CAAC,MAAM,+BAA+B,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CA6O9C,CAAC;AAEF,MAAM,CAAC,MAAM,sBAAsB,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAoIrC,CAAC;AAEF,MAAM,CAAC,MAAM,sBAAsB,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CA6JrC,CAAC;AAEF,MAAM,CAAC,MAAM,sBAAsB,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAsSrC,CAAC;AAEF,MAAM,CAAC,MAAM,2BAA2B,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAgO1C,CAAC;AAEF,MAAM,CAAC,MAAM,4BAA4B,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CA6N3C,CAAC;AAEF,4CAA4C;AAC5C,MAAM,CAAC,MAAM,gBAAgB,GAA2B;IACrD,cAAc,EAAE,qBAAqB;IACrC,wBAAwB,EAAE,+BAA+B;IACzD,oBAAoB,EAAE,2BAA2B;IACjD,gBAAgB,EAAE,uBAAuB;IACzC,aAAa,EAAE,oBAAoB;IACnC,eAAe,EAAE,sBAAsB;IACvC,eAAe,EAAE,sBAAsB;IACvC,qBAAqB,EAAE,4BAA4B;IACnD,eAAe,EAAE,sBAAsB;IACvC,eAAe,EAAE,sBAAsB;IACvC,kBAAkB,EAAE,yBAAyB;IAC7C,eAAe,EAAE,sBAAsB;IACvC,iBAAiB,EAAE,wBAAwB;IAC3C,cAAc,EAAE,qBAAqB;IACrC,eAAe,EAAE,sBAAsB;IACvC,oBAAoB,EAAE,2BAA2B;IACjD,qBAAqB,EAAE,4BAA4B;CACrD,CAAC"}

package/package.json

@@ -1,6 +1,6 @@
 {
     "name": "@dedesfr/prompter",
-    "version": "0.6.7",
+    "version": "0.6.9",
     "description": "Enhance prompts directly in your AI coding workflow",
     "type": "module",
     "main": "dist/index.js",

package/prompt/epic-generator.md

@@ -66,76 +66,111 @@ For each identified EPIC, define:
 
 # Output Format
 
-## Executive Summary
+## Directory Structure
+Create an `epics/` folder with the following structure:
+```
+epics/
+├── README.md                    # Executive summary and index
+├── EPIC-001-[kebab-case-title].md
+├── EPIC-002-[kebab-case-title].md
+├── EPIC-003-[kebab-case-title].md
+└── ...
+```
+
+## File: `epics/README.md`
+
+### Executive Summary
 - Total EPICs identified: [number]
 - Complexity distribution: [High/Medium/Low counts]
 - Key dependencies identified: [summary]
 - Coverage gaps or conflicts: [if any]
 
-## EPIC Catalog
+### EPIC Index
+| EPIC ID | Title | Complexity | Dependencies | File |
+|---------|-------|------------|--------------|------|
+| EPIC-001 | [Title] | [S/M/L/XL] | [EPIC-XXX] | [Link to file] |
+| EPIC-002 | [Title] | [S/M/L/XL] | [EPIC-XXX] | [Link to file] |
 
-### EPIC-[XXX]: [EPIC Title]
+### Dependency Map
+[Visual or text representation of EPIC dependencies]
+```
+EPIC-001 ──► EPIC-003
+EPIC-002 ──► EPIC-003
+EPIC-003 ──► EPIC-005
+```
+
+### Traceability Matrix
+| Requirement ID | FSD Section | TDD Component | Wireframe | EPIC |
+|----------------|-------------|---------------|-----------|------|
+| [REQ-001] | [Section] | [Component] | [Screen] | [EPIC-XXX] |
+
+### Gaps & Recommendations
+1. **Identified Gaps:** [Requirements not fully covered]
+2. **Conflicts Found:** [Contradictions between documents]
+3. **Recommendations:** [Suggested clarifications needed]
+
+---
+
+## Individual EPIC Files
+
+**File naming convention:** `EPIC-[XXX]-[kebab-case-title].md`  
+Example: `EPIC-001-user-authentication.md`
+
+### Template for Each EPIC File
 
-**Business Value Statement:**
+```markdown
+# EPIC-[XXX]: [EPIC Title]
+
+## Business Value Statement
 [2-3 sentences describing the business outcome and user benefit]
 
-**Description:**
+## Description
 [Detailed description of what this EPIC delivers]
 
-**Source Traceability:**
+## Source Traceability
 | Document | Reference | Section/Page |
 |----------|-----------|--------------|
 | FSD | [Requirement ID] | [Location] |
 | TDD | [Component/Section] | [Location] |
 | Wireframe | [Screen Name] | [If applicable] |
 
-**Scope Definition:**
+## Scope Definition
 | In Scope | Out of Scope |
 |----------|--------------|
 | [Item 1] | [Item 1] |
 | [Item 2] | [Item 2] |
 
-**High-Level Acceptance Criteria:**
+## High-Level Acceptance Criteria
 - [ ] [Criterion 1]
 - [ ] [Criterion 2]
 - [ ] [Criterion 3]
 - [ ] [Criterion 4]
 
-**Dependencies:**
+## Dependencies
 - **Prerequisite EPICs:** [EPIC-XXX, EPIC-XXX] or None
 - **External Dependencies:** [Systems, teams, data]
 - **Technical Prerequisites:** [Infrastructure, APIs, etc.]
 
-**Complexity Assessment:**
+## Complexity Assessment
 - **Size:** [S / M / L / XL]
 - **Technical Complexity:** [Low / Medium / High]
 - **Integration Complexity:** [Low / Medium / High]
 - **Estimated Story Count:** [Range]
 
-**Risks & Assumptions:**
-- **Assumptions:** [List key assumptions]
-- **Risks:** [List identified risks]
-
----
-
-[Repeat for each EPIC]
-
-## Dependency Map
-
-[Visual or text representation of EPIC dependencies]
-EPIC-001 ──► EPIC-003
-EPIC-002 ──► EPIC-003
-EPIC-003 ──► EPIC-005
+## Risks & Assumptions
+**Assumptions:**
+- [Assumption 1]
+- [Assumption 2]
 
-## Traceability Matrix
-| Requirement ID | FSD Section | TDD Component | Wireframe | EPIC |
-|----------------|-------------|---------------|-----------|------|
-| [REQ-001] | [Section] | [Component] | [Screen] | [EPIC-XXX] |
+**Risks:**
+- [Risk 1]
+- [Risk 2]
 
-## Gaps & Recommendations
-1. **Identified Gaps:** [Requirements not fully covered]
-2. **Conflicts Found:** [Contradictions between documents]
-3. **Recommendations:** [Suggested clarifications needed]
+## Related EPICs
+- **Depends On:** [EPIC-XXX]
+- **Blocks:** [EPIC-XXX]
+- **Related:** [EPIC-XXX]
+```
 
 # Quality Standards
 - Every functional requirement must map to at least one EPIC

package/prompt/story-generator.md

@@ -53,24 +53,75 @@ Generate comprehensive user stories from provided Epics, enriched with details f
 
 # Output Requirements
 
-For each Epic, generate stories in this exact format:
+## Directory Structure
+Create a `stories/` folder organized by Epic:
+```
+stories/
+├── EPIC-001-[kebab-case-title]/
+│   ├── README.md                              # Epic summary and story index
+│   ├── STORY-001-[kebab-case-title].md
+│   ├── STORY-002-[kebab-case-title].md
+│   └── ...
+├── EPIC-002-[kebab-case-title]/
+│   ├── README.md
+│   ├── STORY-001-[kebab-case-title].md
+│   └── ...
+└── ...
+```
+
+## File: `stories/EPIC-[XXX]-[title]/README.md`
+
+### Epic Summary
+**Epic ID:** EPIC-[XXX]  
+**Epic Title:** [Epic Name]  
+**Epic Description:** [Brief description from Epic]
+
+### Story Index
+| Story ID | Title | Priority | Story Points | Status | File |
+|----------|-------|----------|--------------|--------|------|
+| STORY-001 | [Title] | Must Have | 5 | Not Started | [Link] |
+| STORY-002 | [Title] | Should Have | 3 | Not Started | [Link] |
+
+### Story Dependency Map
+```
+STORY-001 ──► STORY-003
+STORY-002 ──► STORY-003
+```
+
+### Total Estimates
+- **Total Story Points:** [Sum]
+- **Must Have:** [Points]
+- **Should Have:** [Points]
+- **Could Have:** [Points]
 
 ---
 
-## Epic: [Epic Name/ID]
+## Individual Story Files
 
-### Story [Number]: [Concise Story Title]
+**File naming convention:** `STORY-[XXX]-[kebab-case-title].md`  
+Example: `STORY-001-user-login-email.md`
 
-**User Story:**
-As a [specific user role],
-I want to [action/capability],
+### Template for Each Story File
+
+```markdown
+# STORY-[XXX]: [Concise Story Title]
+
+**Epic:** [EPIC-XXX - Epic Name]  
+**Story Points:** [Fibonacci estimate: 1, 2, 3, 5, 8, 13]  
+**Priority:** [Must Have / Should Have / Could Have / Won't Have]
+
+---
+
+## User Story
+As a [specific user role],  
+I want to [action/capability],  
 So that [business value/outcome].
 
-**Description:**
+## Description
 [2-3 sentences providing additional context, referencing FSD sections where applicable]
 
-**Acceptance Criteria:**
-gherkin
+## Acceptance Criteria
+```gherkin
 GIVEN [precondition/context]
 WHEN [action/trigger]
 THEN [expected outcome]
@@ -78,23 +129,34 @@ THEN [expected outcome]
 GIVEN [precondition/context]
 WHEN [alternative action]
 THEN [expected outcome]
+```
 
-**Business Rules:**
-- BR-1: [Rule from FSD]
-- BR-2: [Rule from FSD]
+## Business Rules
+- **BR-1:** [Rule from FSD]
+- **BR-2:** [Rule from FSD]
 
-**Technical Notes:**
+## Technical Notes
 - [Integration requirements]
 - [Data considerations]
 - [API/System dependencies]
 
-**FSD Reference:** [Section/Requirement IDs traced from FSD]
-
-**Dependencies:** [Other story IDs or external dependencies]
-
-**Story Points:** [Fibonacci estimate: 1, 2, 3, 5, 8, 13]
-
-**Priority:** [Must Have / Should Have / Could Have / Won't Have]
+## Traceability
+- **FSD Reference:** [Section/Requirement IDs traced from FSD]
+- **Epic:** [EPIC-XXX]
+
+## Dependencies
+- **Depends On:** [STORY-XXX, STORY-XXX] or None
+- **Blocks:** [STORY-XXX] or None
+- **External Dependencies:** [Systems, APIs, etc.]
+
+## Definition of Done
+- [ ] Code implemented and peer-reviewed
+- [ ] Unit tests written and passing
+- [ ] Integration tests passing
+- [ ] Documentation updated
+- [ ] Acceptance criteria verified
+- [ ] Code merged to main branch
+```
 
 ---
 

package/src/cli/index.ts

@@ -10,7 +10,7 @@ const program = new Command();
 program
     .name('prompter')
     .description('Enhance prompts directly in your AI coding workflow')
-    .version('0.6.7');
+    .version('0.6.9');
 
 program
     .command('init')

package/src/core/prompt-templates.ts

@@ -1511,76 +1511,111 @@ For each identified EPIC, define:
 
 # Output Format
 
-## Executive Summary
+## Directory Structure
+Create an \`epics/\` folder with the following structure:
+\`\`\`
+epics/
+├── README.md                    # Executive summary and index
+├── EPIC-001-[kebab-case-title].md
+├── EPIC-002-[kebab-case-title].md
+├── EPIC-003-[kebab-case-title].md
+└── ...
+\`\`\`
+
+## File: \`epics/README.md\`
+
+### Executive Summary
 - Total EPICs identified: [number]
 - Complexity distribution: [High/Medium/Low counts]
 - Key dependencies identified: [summary]
 - Coverage gaps or conflicts: [if any]
 
-## EPIC Catalog
+### EPIC Index
+| EPIC ID | Title | Complexity | Dependencies | File |
+|---------|-------|------------|--------------|------|
+| EPIC-001 | [Title] | [S/M/L/XL] | [EPIC-XXX] | [Link to file] |
+| EPIC-002 | [Title] | [S/M/L/XL] | [EPIC-XXX] | [Link to file] |
+
+### Dependency Map
+[Visual or text representation of EPIC dependencies]
+\`\`\`
+EPIC-001 ──► EPIC-003
+EPIC-002 ──► EPIC-003
+EPIC-003 ──► EPIC-005
+\`\`\`
 
-### EPIC-[XXX]: [EPIC Title]
+### Traceability Matrix
+| Requirement ID | FSD Section | TDD Component | Wireframe | EPIC |
+|----------------|-------------|---------------|-----------|------|
+| [REQ-001] | [Section] | [Component] | [Screen] | [EPIC-XXX] |
 
-**Business Value Statement:**
+### Gaps & Recommendations
+1. **Identified Gaps:** [Requirements not fully covered]
+2. **Conflicts Found:** [Contradictions between documents]
+3. **Recommendations:** [Suggested clarifications needed]
+
+---
+
+## Individual EPIC Files
+
+**File naming convention:** \`EPIC-[XXX]-[kebab-case-title].md\`  
+Example: \`EPIC-001-user-authentication.md\`
+
+### Template for Each EPIC File
+
+\`\`\`markdown
+# EPIC-[XXX]: [EPIC Title]
+
+## Business Value Statement
 [2-3 sentences describing the business outcome and user benefit]
 
-**Description:**
+## Description
 [Detailed description of what this EPIC delivers]
 
-**Source Traceability:**
+## Source Traceability
 | Document | Reference | Section/Page |
 |----------|-----------|--------------|
 | FSD | [Requirement ID] | [Location] |
 | TDD | [Component/Section] | [Location] |
 | Wireframe | [Screen Name] | [If applicable] |
 
-**Scope Definition:**
+## Scope Definition
 | In Scope | Out of Scope |
 |----------|--------------|
 | [Item 1] | [Item 1] |
 | [Item 2] | [Item 2] |
 
-**High-Level Acceptance Criteria:**
+## High-Level Acceptance Criteria
 - [ ] [Criterion 1]
 - [ ] [Criterion 2]
 - [ ] [Criterion 3]
 - [ ] [Criterion 4]
 
-**Dependencies:**
+## Dependencies
 - **Prerequisite EPICs:** [EPIC-XXX, EPIC-XXX] or None
 - **External Dependencies:** [Systems, teams, data]
 - **Technical Prerequisites:** [Infrastructure, APIs, etc.]
 
-**Complexity Assessment:**
+## Complexity Assessment
 - **Size:** [S / M / L / XL]
 - **Technical Complexity:** [Low / Medium / High]
 - **Integration Complexity:** [Low / Medium / High]
 - **Estimated Story Count:** [Range]
 
-**Risks & Assumptions:**
-- **Assumptions:** [List key assumptions]
-- **Risks:** [List identified risks]
+## Risks & Assumptions
+**Assumptions:**
+- [Assumption 1]
+- [Assumption 2]
 
----
-
-[Repeat for each EPIC]
-
-## Dependency Map
-
-[Visual or text representation of EPIC dependencies]
-EPIC-001 ──► EPIC-003
-EPIC-002 ──► EPIC-003
-EPIC-003 ──► EPIC-005
+**Risks:**
+- [Risk 1]
+- [Risk 2]
 
-## Traceability Matrix
-| Requirement ID | FSD Section | TDD Component | Wireframe | EPIC |
-|----------------|-------------|---------------|-----------|------|
-| [REQ-001] | [Section] | [Component] | [Screen] | [EPIC-XXX] |
-
-## Gaps & Recommendations
-1. **Identified Gaps:** [Requirements not fully covered]
-2. **Conflicts Found:** [Contradictions between documents]
-3. **Recommendations:** [Suggested clarifications needed]
+## Related EPICs
+- **Depends On:** [EPIC-XXX]
+- **Blocks:** [EPIC-XXX]
+- **Related:** [EPIC-XXX]
+\`\`\`
 
 # Quality Standards
 - Every functional requirement must map to at least one EPIC
@@ -1663,23 +1698,74 @@ Generate comprehensive user stories from provided Epics, enriched with details f
 
 # Output Requirements
 
-For each Epic, generate stories in this exact format:
+## Directory Structure
+Create a \`stories/\` folder organized by Epic:
+\`\`\`
+stories/
+├── EPIC-001-[kebab-case-title]/
+│   ├── README.md                              # Epic summary and story index
+│   ├── STORY-001-[kebab-case-title].md
+│   ├── STORY-002-[kebab-case-title].md
+│   └── ...
+├── EPIC-002-[kebab-case-title]/
+│   ├── README.md
+│   ├── STORY-001-[kebab-case-title].md
+│   └── ...
+└── ...
+\`\`\`
+
+## File: \`stories/EPIC-[XXX]-[title]/README.md\`
+
+### Epic Summary
+**Epic ID:** EPIC-[XXX]  
+**Epic Title:** [Epic Name]  
+**Epic Description:** [Brief description from Epic]
+
+### Story Index
+| Story ID | Title | Priority | Story Points | Status | File |
+|----------|-------|----------|--------------|--------|------|
+| STORY-001 | [Title] | Must Have | 5 | Not Started | [Link] |
+| STORY-002 | [Title] | Should Have | 3 | Not Started | [Link] |
+
+### Story Dependency Map
+\`\`\`
+STORY-001 ──► STORY-003
+STORY-002 ──► STORY-003
+\`\`\`
+
+### Total Estimates
+- **Total Story Points:** [Sum]
+- **Must Have:** [Points]
+- **Should Have:** [Points]
+- **Could Have:** [Points]
 
 ---
 
-## Epic: [Epic Name/ID]
+## Individual Story Files
 
-### Story [Number]: [Concise Story Title]
+**File naming convention:** \`STORY-[XXX]-[kebab-case-title].md\`  
+Example: \`STORY-001-user-login-email.md\`
 
-**User Story:**
-As a [specific user role],
-I want to [action/capability],
+### Template for Each Story File
+
+\`\`\`markdown
+# STORY-[XXX]: [Concise Story Title]
+
+**Epic:** [EPIC-XXX - Epic Name]  
+**Story Points:** [Fibonacci estimate: 1, 2, 3, 5, 8, 13]  
+**Priority:** [Must Have / Should Have / Could Have / Won't Have]
+
+---
+
+## User Story
+As a [specific user role],  
+I want to [action/capability],  
 So that [business value/outcome].
 
-**Description:**
+## Description
 [2-3 sentences providing additional context, referencing FSD sections where applicable]
 
-**Acceptance Criteria:**
+## Acceptance Criteria
 \`\`\`gherkin
 GIVEN [precondition/context]
 WHEN [action/trigger]
@@ -1690,22 +1776,32 @@ WHEN [alternative action]
 THEN [expected outcome]
 \`\`\`
 
-**Business Rules:**
-- BR-1: [Rule from FSD]
-- BR-2: [Rule from FSD]
+## Business Rules
+- **BR-1:** [Rule from FSD]
+- **BR-2:** [Rule from FSD]
 
-**Technical Notes:**
+## Technical Notes
 - [Integration requirements]
 - [Data considerations]
 - [API/System dependencies]
 
-**FSD Reference:** [Section/Requirement IDs traced from FSD]
-
-**Dependencies:** [Other story IDs or external dependencies]
-
-**Story Points:** [Fibonacci estimate: 1, 2, 3, 5, 8, 13]
-
-**Priority:** [Must Have / Should Have / Could Have / Won't Have]
+## Traceability
+- **FSD Reference:** [Section/Requirement IDs traced from FSD]
+- **Epic:** [EPIC-XXX]
+
+## Dependencies
+- **Depends On:** [STORY-XXX, STORY-XXX] or None
+- **Blocks:** [STORY-XXX] or None
+- **External Dependencies:** [Systems, APIs, etc.]
+
+## Definition of Done
+- [ ] Code implemented and peer-reviewed
+- [ ] Unit tests written and passing
+- [ ] Integration tests passing
+- [ ] Documentation updated
+- [ ] Acceptance criteria verified
+- [ ] Code merged to main branch
+\`\`\`
 
 ---