@dedesfr/prompter 0.8.23 → 1.0.0

package/prompt/epic-generator.md

@@ -1,198 +0,0 @@
-# EPIC Generation Prompt
-
-# Role & Expertise
-You 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.
-
-# Context
-You 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.
-
-# Primary Objective
-Generate 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.
-
-# Input Documents
-1. **FSD (Functional Specification Document)** - PRIMARY
-   - Business requirements and functional capabilities
-   - User workflows and business rules
-   - Acceptance criteria foundations
-
-2. **TDD (Technical Design Document)** - PRIMARY
-   - System architecture components
-   - Integration points and APIs
-   - Technical constraints and dependencies
-
-3. **UI Wireframes** - SUPPLEMENTARY
-   - User interface flows
-   - Screen-level functionality
-   - User interaction patterns
-
-# Process
-
-## Phase 1: Document Analysis
-1. Extract all functional requirements from FSD
-   - Identify business capabilities
-   - Map user journeys and workflows
-   - Note business rules and validations
-2. Extract technical components from TDD
-   - Identify system modules and services
-   - Map integration dependencies
-   - Note technical constraints
-3. Cross-reference UI Wireframes
-   - Link screens to functional requirements
-   - Identify user-facing features
-   - Note UI-specific requirements
-
-## Phase 2: EPIC Identification
-1. Group related requirements into logical feature areas
-2. Identify natural boundaries based on:
-   - Business domain separation
-   - Technical component boundaries
-   - User journey completeness
-   - Dependency chains
-3. Validate each EPIC can be independently deliverable
-
-## Phase 3: EPIC Definition
-For each identified EPIC, define:
-- Clear business value statement
-- Scope boundaries (in/out)
-- High-level acceptance criteria
-- Dependencies and prerequisites
-- Estimated complexity tier
-
-## Phase 4: Validation
-1. Verify complete coverage of all requirements
-2. Check for gaps between documents
-3. Identify any conflicting requirements
-4. Flag assumptions made
-
-# Output Format
-
-## 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 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
-```
-
-### 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
-
-```markdown
-# EPIC-[XXX]: [EPIC Title]
-
-## Business Value Statement
-[2-3 sentences describing the business outcome and user benefit]
-
-## Description
-[Detailed description of what this EPIC delivers]
-
-## Source Traceability
-| Document | Reference | Section/Page |
-|----------|-----------|--------------|
-| FSD | [Requirement ID] | [Location] |
-| TDD | [Component/Section] | [Location] |
-| Wireframe | [Screen Name] | [If applicable] |
-
-## Scope Definition
-| In Scope | Out of Scope |
-|----------|--------------|
-| [Item 1] | [Item 1] |
-| [Item 2] | [Item 2] |
-
-## High-Level Acceptance Criteria
-- [ ] [Criterion 1]
-- [ ] [Criterion 2]
-- [ ] [Criterion 3]
-- [ ] [Criterion 4]
-
-## Dependencies
-- **Prerequisite EPICs:** [EPIC-XXX, EPIC-XXX] or None
-- **External Dependencies:** [Systems, teams, data]
-- **Technical Prerequisites:** [Infrastructure, APIs, etc.]
-
-## Complexity Assessment
-- **Size:** [S / M / L / XL]
-- **Technical Complexity:** [Low / Medium / High]
-- **Integration Complexity:** [Low / Medium / High]
-- **Estimated Story Count:** [Range]
-
-## Risks & Assumptions
-**Assumptions:**
-- [Assumption 1]
-- [Assumption 2]
-
-**Risks:**
-- [Risk 1]
-- [Risk 2]
-
-## Related EPICs
-- **Depends On:** [EPIC-XXX]
-- **Blocks:** [EPIC-XXX]
-- **Related:** [EPIC-XXX]
-```
-
-# Quality Standards
-- Every functional requirement must map to at least one EPIC
-- Each EPIC must have clear, measurable acceptance criteria
-- Dependencies must form a valid directed acyclic graph (no circular dependencies)
-- EPIC sizing should allow decomposition into 5-15 user stories
-- Business value must be articulated in user/business terms, not technical terms
-- All assumptions must be explicitly stated
-
-# Special Instructions
-- If FSD and TDD conflict, note the conflict and use FSD as the authority for functional scope
-- If wireframes show features not in FSD/TDD, flag as "Potential Scope Addition"
-- Group infrastructure/DevOps requirements into dedicated technical EPICs
-- Non-functional requirements (security, performance) should be integrated into relevant EPICs AND have a dedicated NFR EPIC if substantial
-- Use consistent naming convention: EPIC-[3-digit number]: [Verb] [Object] [Qualifier]
-
-# Verification Checklist
-After generating EPICs, verify:
-- [ ] 100% of FSD functional requirements are covered
-- [ ] All TDD components have corresponding EPICs
-- [ ] No orphaned wireframe screens
-- [ ] Dependency chain is logical and achievable
-- [ ] Each EPIC is independently valuable
-- [ ] Complexity assessments are consistent
-- [ ] Traceability is complete and accurate

package/prompt/epic-single.md

@@ -1,47 +0,0 @@
-Your job is to take a user requirement and structure it into **a single, well-defined Jira Epic**.
-
-### Input
-{USER_REQUIREMENT}
-
-### Output Rules
-- Use **Markdown format only**
-- Focus on defining **one Epic** that captures the main capability or user workflow
-- Title must be **business-focused**, not technical
-- The Epic should represent a cohesive, deliverable outcome
-
-### Output Structure
-
-## 🧠 Epic: {Epic Title}
-
-### 🎯 Epic Goal
-We need to {MAIN OBJECTIVE} in order for {TARGET USER} to {EXPECTED VALUE}
-
-### 🚀 Definition of Done
-- DoD1
-- DoD2
-- DoD3
-(add more if needed)
-
-### 📌 High-Level Scope (Included)
-- Scope item 1
-- Scope item 2
-- Scope item 3
-
-### ❌ Out of Scope
-- OOS item 1
-- OOS item 2
-
-### 📁 Deliverables
-- Deliverable 1
-- Deliverable 2
-
-### 🧩 Dependencies
-- Dependency 1 (TBD if unknown)
-
-### ⚠️ Risks / Assumptions
-- Risk or assumption 1
-- Risk or assumption 2
-
-### 🎯 Success Metrics
-- Metric 1
-- Metric 2

package/prompt/erd-generator.md

@@ -1,130 +0,0 @@
-# Generated Prompt
-
-# Role & Expertise
-You 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.
-
-# Context
-You 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.
-
-# Primary Objective
-Analyze 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.
-
-# Process
-
-## Phase 1: Document Analysis
-1. Read through the entire FSD to understand the system scope
-2. Identify all nouns that represent potential entities (users, products, orders, etc.)
-3. Note all actions and processes that imply relationships between entities
-4. Extract business rules that define constraints and cardinalities
-
-## Phase 2: Entity Identification
-1. List all candidate entities from the document
-2. Eliminate duplicates and synonyms (e.g., "customer" and "client" may be the same)
-3. Distinguish between entities and attributes (is it a thing or a property of a thing?)
-4. Identify weak entities that depend on other entities for existence
-
-## Phase 3: Attribute Extraction
-1. For each entity, identify all properties mentioned or implied
-2. Determine primary keys (natural or surrogate)
-3. Identify required vs. optional attributes
-4. Note any derived or calculated attributes
-5. Specify data types based on context
-
-## Phase 4: Relationship Mapping
-1. Identify all relationships between entities
-2. Determine cardinality for each relationship (1:1, 1:N, M:N)
-3. Identify participation constraints (mandatory vs. optional)
-4. Name relationships with meaningful verbs
-5. Identify any recursive/self-referencing relationships
-
-## Phase 5: Normalization Review
-1. Verify entities are in at least 3NF
-2. Check for transitive dependencies
-3. Identify any intentional denormalization with justification
-
-# Input Specifications
-- **Document Type:** Functional Specification Document (FSD)
-- **Expected Content:** System overview, user stories, feature descriptions, business rules, workflow descriptions, UI specifications
-- **Format:** Text, markdown, or document content
-
-# Output Requirements
-
-## Section 1: Entity Catalog
-
-| Entity Name | Description | Type | Primary Key |
-|-------------|-------------|------|-------------|
-| [Name] | [Brief description] | [Strong/Weak] | [PK field(s)] |
-
-
-## Section 2: Entity Details
-For each entity:
-
-### [Entity Name]
-**Description:** [What this entity represents]
-**Type:** Strong Entity / Weak Entity (dependent on: [parent])
-
-**Attributes:**
-| Attribute | Data Type | Constraints | Description |
-|-----------|-----------|-------------|-------------|
-| [name] | [type] | [PK/FK/NOT NULL/UNIQUE] | [description] |
-
-**Business Rules:**
-- [Rule 1]
-- [Rule 2]
-
-## Section 3: Relationship Specifications
-
-| Relationship | Entity A | Entity B | Cardinality | Participation | Description |
-|--------------|----------|----------|-------------|---------------|-------------|
-| [verb phrase] | [Entity] | [Entity] | [1:1/1:N/M:N] | [Total/Partial] | [description] |
-
-
-## Section 4: ERD Notation (Text-Based)
-Provide a PlantUML or Mermaid diagram code that can be rendered:
-
-erDiagram
-    ENTITY1 ||--o{ ENTITY2 : "relationship"
-    ENTITY1 {
-        type attribute_name PK
-        type attribute_name
-    }
-
-## Section 5: Design Decisions & Notes
-- Key assumptions made during analysis
-- Alternative modeling options considered
-- Recommendations for implementation
-- Questions or ambiguities requiring clarification
-
-# Quality Standards
-- **Completeness:** All entities implied by the FSD must be captured
-- **Accuracy:** Cardinalities must reflect actual business rules
-- **Clarity:** Entity and relationship names must be self-explanatory
-- **Consistency:** Naming conventions must be uniform throughout
-- **Traceability:** Each entity/relationship should trace back to FSD requirements
-
-# Naming Conventions
-- **Entities:** PascalCase, singular nouns (e.g., `Customer`, `OrderItem`)
-- **Attributes:** snake_case (e.g., `first_name`, `created_at`)
-- **Relationships:** Descriptive verb phrases (e.g., "places", "contains", "belongs to")
-- **Primary Keys:** `id` or `[entity]_id`
-- **Foreign Keys:** `[referenced_entity]_id`
-
-# Special Instructions
-1. If the FSD mentions features without clear data requirements, infer necessary entities
-2. Include audit fields (`created_at`, `updated_at`, `created_by`) for transactional entities
-3. Consider soft delete patterns if deletion is mentioned
-4. Flag any circular dependencies or complex relationships
-5. If user authentication is implied, include standard auth entities (User, Role, Permission)
-6. For any M:N relationships, specify the junction/association entity
-
-# Verification Checklist
-After generating the ERD, verify:
-- [ ] Every feature in the FSD can be supported by the data model
-- [ ] All user roles mentioned have corresponding entities or attributes
-- [ ] Workflow states are captured (if applicable)
-- [ ] Reporting requirements can be satisfied by the structure
-- [ ] No orphan entities exist (every entity has at least one relationship)
-
----
-
-**Now analyze the following Functional Specification Document and generate the complete ERD specification:**

package/prompt/fsd-generator.md

@@ -1,157 +0,0 @@
-# Functional Specification Document (FSD) Generator Prompt
-
-# Role & Expertise
-You 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.
-
-# Context
-You 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.
-
-# Primary Objective
-Generate a complete, implementation-ready Functional Specification Document (FSD) that translates PRD requirements into precise functional specifications, system behaviors, data requirements, and acceptance criteria.
-
-# Process
-1. **Analyze the PRD**
-   - Extract all business requirements and user stories
-   - Identify core features and their priorities
-   - Map user personas to functional needs
-   - Note any constraints, assumptions, and dependencies
-
-2. **Define Functional Requirements**
-   - Convert each PRD item into specific, testable functional requirements
-   - Assign unique identifiers (FR-XXX format)
-   - Establish requirement traceability to PRD sections
-   - Define acceptance criteria for each requirement
-
-3. **Specify System Behavior**
-   - Document user interactions and system responses
-   - Define business rules and validation logic
-   - Specify error handling and edge cases
-   - Detail state transitions where applicable
-
-4. **Design Data Specifications**
-   - Identify data entities and attributes
-   - Define data validation rules
-   - Specify data relationships and constraints
-   - Document data flow between components
-
-5. **Create Interface Specifications**
-   - Define UI functional requirements (not visual design)
-   - Specify API contracts if applicable
-   - Document integration touchpoints
-   - Detail reporting/output requirements
-
-# Input Specifications
-- Product Requirements Document (PRD) in any text format
-- May include: user stories, epics, acceptance criteria, wireframes descriptions, business rules, constraints
-
-# Output Requirements
-
-**Format:** Structured FSD document with clear sections and subsections
-**Style:** Technical but accessible; precise language; no ambiguity
-**Requirement Format:** Each requirement must have ID, description, priority, acceptance criteria, and PRD traceability
-
-## Required FSD Structure:
-
-# Functional Specification Document
-## Document Information
-- Document Title
-- Version
-- Date
-- PRD Reference
-- Author
-- Reviewers/Approvers
-
-## 1. Executive Summary
-[Brief overview of what the system will do functionally]
-
-## 2. Scope
-### 2.1 In Scope
-[Functional boundaries covered by this FSD]
-### 2.2 Out of Scope
-[Explicitly excluded functionality]
-### 2.3 Assumptions
-[Technical and business assumptions]
-### 2.4 Dependencies
-[External systems, teams, or conditions]
-
-## 3. User Roles & Permissions
-| Role | Description | Key Capabilities |
-|------|-------------|------------------|
-[Define each user role and their functional access]
-
-## 4. Functional Requirements
-### 4.1 [Feature/Module Name]
-#### FR-001: [Requirement Title]
-- **Description:** [Detailed functional description]
-- **Priority:** [Must Have / Should Have / Could Have / Won't Have]
-- **PRD Reference:** [Section/Item from PRD]
-- **User Story:** As a [role], I want [capability] so that [benefit]
-- **Business Rules:**
-  - BR-001: [Rule description]
-- **Acceptance Criteria:**
-  - [ ] Given [context], when [action], then [expected result]
-  - [ ] [Additional criteria]
-- **Error Handling:**
-  - [Error condition] → [System response]
-
-[Repeat for each functional requirement]
-
-## 5. Business Rules Catalog
-| ID | Rule | Applies To | Validation |
-|----|------|------------|------------|
-[Consolidated list of all business rules]
-
-## 6. Data Specifications
-### 6.1 Data Entities
-#### [Entity Name]
-| Field | Type | Required | Validation Rules | Description |
-|-------|------|----------|------------------|-------------|
-
-### 6.2 Data Relationships
-[Entity relationship descriptions or diagram notation]
-
-### 6.3 Data Validation Rules
-[Comprehensive validation logic]
-
-## 7. Interface Specifications
-### 7.1 User Interface Requirements
-[Screen-by-screen functional requirements]
-
-### 7.2 API Specifications (if applicable)
-| Endpoint | Method | Input | Output | Business Logic |
-|----------|--------|-------|--------|----------------|
-
-### 7.3 Integration Requirements
-[Third-party system integration specifications]
-
-## 8. Non-Functional Considerations
-[Performance expectations, security requirements, accessibility needs - as they impact functionality]
-
-## 9. Reporting & Analytics Requirements
-[Functional requirements for reports and dashboards]
-
-## 10. Traceability Matrix
-| PRD Item | FSD Requirement(s) | Priority |
-|----------|-------------------|----------|
-[Map every PRD item to FSD requirements]
-
-## 11. Appendices
-### A. Glossary
-### B. Revision History
-### C. Open Questions/TBD Items
-
-# Quality Standards
-- Every PRD requirement must map to at least one functional specification
-- All requirements must be SMART (Specific, Measurable, Achievable, Relevant, Testable)
-- No ambiguous language (avoid "should," "might," "could" - use "shall," "will," "must")
-- Each acceptance criterion must be verifiable by QA
-- Business rules must be atomic and non-contradictory
-- Data specifications must cover all functional requirements
-
-# Special Instructions
-- If the PRD is vague on certain aspects, document them in "Open Questions/TBD Items"
-- Infer reasonable technical assumptions where PRD is silent, clearly marking them as assumptions
-- Prioritize requirements using MoSCoW method if not specified in PRD
-- Include negative test scenarios in acceptance criteria (what should NOT happen)
-- Flag any PRD inconsistencies or conflicts you identify
-- Use consistent terminology throughout - define terms in glossary

package/prompt/prd-agent-generator.md

@@ -1,147 +0,0 @@
-# PRD Generator (Non-Interactive Mode)
-
-Create detailed Product Requirements Documents that are clear, actionable, and suitable for implementation based solely on the user's initial input.
-
----
-
-## The Job
-
-1. Receive a feature description from the user
-2. Analyze the input and make reasonable assumptions where details are missing
-3. Generate a structured PRD based on the input
-
----
-
-## Handling Ambiguity
-
-When the user's input lacks specific details:
-
-- **Make reasonable assumptions** based on common patterns and best practices
-- **Document assumptions** in the PRD under "Assumptions Made"
-- **Flag critical unknowns** in the "Open Questions" section
-- **Err on the side of MVP scope** when scope is unclear
-- **Default to standard patterns** (e.g., CRUD operations, standard UI components)
-
----
-
-## PRD Structure
-
-Generate the PRD with these sections:
-
-### 1. Introduction/Overview
-Brief description of the feature and the problem it solves.
-
-### 2. Assumptions Made
-List key assumptions made due to missing details in the original request:
-- "Assumed target users are [X] based on feature context"
-- "Assumed MVP scope since no specific scope mentioned"
-- "Assumed standard authentication is already in place"
-
-### 3. Goals
-Specific, measurable objectives (bullet list).
-
-### 4. User Stories
-Each story needs:
-- **Title:** Short descriptive name
-- **Description:** "As a [user], I want [feature] so that [benefit]"
-- **Acceptance Criteria:** Verifiable checklist of what "done" means
-
-Each story should be small enough to implement in one focused session.
-
-**Format:**
-```markdown
-### US-001: [Title]
-**Description:** As a [user], I want [feature] so that [benefit].
-
-**Acceptance Criteria:**
-- [ ] Specific verifiable criterion
-- [ ] Another criterion
-- [ ] Typecheck/lint passes
-- [ ] **[UI stories only]** Verify in browser using dev-browser skill
-```
-
-**Important:** 
-- Acceptance criteria must be verifiable, not vague. "Works correctly" is bad. "Button shows confirmation dialog before deleting" is good.
-- **For any story with UI changes:** Always include "Verify in browser using dev-browser skill" as acceptance criteria. This ensures visual verification of frontend work.
-
-### 5. Functional Requirements
-Numbered list of specific functionalities:
-- "FR-1: The system must allow users to..."
-- "FR-2: When a user clicks X, the system must..."
-
-Be explicit and unambiguous.
-
-### 6. Non-Goals (Out of Scope)
-What this feature will NOT include. Critical for managing scope.
-
-### 7. Design Considerations (Optional)
-- UI/UX requirements
-- Link to mockups if available
-- Relevant existing components to reuse
-
-### 8. Technical Considerations (Optional)
-- Known constraints or dependencies
-- Integration points with existing systems
-- Performance requirements
-
-### 9. Success Metrics
-How will success be measured?
-- "Reduce time to complete X by 50%"
-- "Increase conversion rate by 10%"
-
-### 10. Open Questions
-Remaining questions or areas needing clarification. This is where you document:
-- Critical unknowns that affect implementation
-- Areas where the original request was ambiguous
-- Decisions that may need stakeholder input
-
----
-
-## Writing for Junior Developers
-
-The PRD reader may be a junior developer or AI agent. Therefore:
-
-- Be explicit and unambiguous
-- Avoid jargon or explain it
-- Provide enough detail to understand purpose and core logic
-- Number requirements for easy reference
-- Use concrete examples where helpful
-
----
-
-## Output
-
-- **Format:** Markdown (`.md`)
-
----
-
-## Example PRD
-
-```markdown
-# PRD: Task Priority System
-
-## Introduction
-
-Add priority levels to tasks so users can focus on what matters most. Tasks can be marked as high, medium, or low priority, with visual indicators and filtering to help users manage their workload effectively.
-
-## Assumptions Made
-
-- Assumed this is for an existing task management system with a tasks table
-- Assumed standard web UI (not mobile app)
-- Assumed MVP scope - basic priority features without advanced automation
-- Assumed users are familiar with priority systems from other tools
-
-## Goals
-
-- Allow assigning priority (high/medium/low) to any task
-- Provide clear visual differentiation between priority levels
-- Enable filtering and sorting by priority
-- Default new tasks to medium priority
-
-## User Stories
-
-### US-001: Add priority field to database
-**Description:** As a developer, I need to store task priority so it persists across sessions.
-
-**Acceptance Criteria:**
-- [ ] Add priority column to tasks table: 'high' | 'medium' | 'low' (default 'medium')