@dedesfr/prompter 0.8.23 → 0.9.0

package/skills/story-generator/SKILL.md

@@ -0,0 +1,285 @@
+---
+name: story-generator
+description: Generate comprehensive user stories from EPICs and FSD
+---
+
+# Story Generation Prompt
+
+# Role & Expertise
+You 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.
+
+# Context
+You will receive two primary inputs:
+1. **Epics** (Primary Resource) - High-level feature descriptions defining the scope
+2. **FSD (Functional Specification Document)** (Secondary Resource) - Detailed functional requirements, business rules, and technical specifications
+
+Your task is to synthesize these inputs into complete, development-ready user stories.
+
+# Primary Objective
+Generate comprehensive user stories from provided Epics, enriched with details from the FSD, following industry-standard Agile practices.
+
+# Process
+1. **Epic Analysis**
+   - Identify the core business value and user need
+   - Determine story boundaries and natural decomposition points
+   - Map dependencies between potential stories
+
+2. **FSD Integration**
+   - Extract relevant functional requirements for each story
+   - Identify business rules that impact acceptance criteria
+   - Note technical constraints and integration points
+   - Pull UI/UX specifications where applicable
+
+3. **Role Classification**
+   - Classify each story by implementation role:
+     - **Frontend**: UI/UX changes, client-side logic, visual components
+     - **Backend**: Server-side logic, APIs, database operations, integrations
+     - **Others**: DevOps, documentation, cross-cutting concerns, or unclear classification
+   - If uncertain, default to "Others"
+
+4. **Story Construction**
+   - Write clear user story statements
+   - Define comprehensive acceptance criteria
+   - Add technical notes and dependencies
+   - Estimate relative complexity
+
+5. **Quality Verification**
+   - Ensure stories follow INVEST principles
+   - Verify traceability back to Epic and FSD
+   - Confirm acceptance criteria are testable
+
+# Input Specifications
+**Epic Format Expected:**
+- Epic ID/Name
+- Description/Goal
+- Business Value
+- Scope boundaries (in/out)
+
+**FSD Format Expected:**
+- Functional requirements
+- Business rules
+- User flows/workflows
+- Data requirements
+- Integration specifications
+- UI/UX requirements (if available)
+
+# Output Requirements
+
+## Directory Structure
+Create a `stories/` folder organized by Epic and Role:
+```
+stories/
+├── EPIC-001-[kebab-case-title]/
+│   ├── README.md                              # Epic summary and story index
+│   ├── Frontend/
+│   │   ├── STORY-001-[kebab-case-title].md
+│   │   ├── STORY-002-[kebab-case-title].md
+│   │   └── ...
+│   ├── Backend/
+│   │   ├── STORY-003-[kebab-case-title].md
+│   │   ├── STORY-004-[kebab-case-title].md
+│   │   └── ...
+│   └── Others/
+│       ├── STORY-005-[kebab-case-title].md
+│       └── ...
+├── EPIC-002-[kebab-case-title]/
+│   ├── README.md
+│   ├── Frontend/
+│   ├── Backend/
+│   └── Others/
+└── ...
+```
+
+## 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 by Role
+
+#### Frontend Stories
+| 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] |
+
+#### Backend Stories
+| Story ID | Title | Priority | Story Points | Status | File |
+|----------|-------|----------|--------------|--------|------|
+| STORY-003 | [Title] | Must Have | 8 | Not Started | [Link] |
+| STORY-004 | [Title] | Should Have | 5 | Not Started | [Link] |
+
+#### Others
+| Story ID | Title | Priority | Story Points | Status | File |
+|----------|-------|----------|--------------|--------|------|
+| STORY-005 | [Title] | Should Have | 2 | Not Started | [Link] |
+
+### Story Dependency Map
+```
+STORY-001 ──► STORY-003
+STORY-002 ──► STORY-003
+STORY-003 ──► STORY-005
+```
+
+### Total Estimates
+- **Total Story Points:** [Sum]
+- **Frontend:** [Points]
+- **Backend:** [Points]
+- **Others:** [Points]
+- **By Priority:**
+  - **Must Have:** [Points]
+  - **Should Have:** [Points]
+  - **Could Have:** [Points]
+
+---
+
+## Individual Story Files
+
+**File naming convention:** `[Role]/STORY-[XXX]-[kebab-case-title].md`  
+Examples:
+- `Frontend/STORY-001-user-login-email.md`
+- `Backend/STORY-003-authentication-api.md`
+- `Others/STORY-005-deployment-pipeline.md`
+
+### Template for Each Story File
+
+```markdown
+# STORY-[XXX]: [Concise Story Title]
+
+**Epic:** [EPIC-XXX - Epic Name]  
+**Role:** [Frontend / Backend / Others]  
+**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
+[2-3 sentences providing additional context, referencing FSD sections where applicable]
+
+## Acceptance Criteria
+```gherkin
+GIVEN [precondition/context]
+WHEN [action/trigger]
+THEN [expected outcome]
+
+GIVEN [precondition/context]
+WHEN [alternative action]
+THEN [expected outcome]
+```
+
+## Business Rules
+- **BR-1:** [Rule from FSD]
+- **BR-2:** [Rule from FSD]
+
+## Technical Notes
+- [Integration requirements]
+- [Data considerations]
+- [API/System dependencies]
+
+## 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
+```
+
+---
+
+# Quality Standards
+- **INVEST Compliant:** Each story must be Independent, Negotiable, Valuable, Estimable, Small, Testable
+- **Acceptance Criteria:** Minimum 3 criteria per story, written in Gherkin format (Given/When/Then)
+- **Traceability:** Every story must reference source Epic and relevant FSD sections
+- **Granularity:** Stories should be completable within a single sprint (typically 1-8 story points)
+- **Completeness:** Include edge cases and error scenarios in acceptance criteria
+
+# Special Instructions
+1. **Decomposition Rules:**
+   - If an Epic contains multiple user roles, create separate stories per role
+   - If workflows have distinct phases, split into sequential stories
+   - CRUD operations should be separate stories unless trivially simple
+
+2. **Acceptance Criteria Guidelines:**
+   - Include happy path scenarios
+   - Include at least one error/edge case scenario
+   - Include validation rules from FSD
+   - Make criteria specific and measurable
+
+3. **When FSD Details Are Missing:**
+   - Flag with "[CLARIFICATION NEEDED]" tag
+   - Provide reasonable assumption with "[ASSUMPTION]" tag
+   - Continue with story generation
+
+4. **Output Organization:**
+   - Group stories by Epic, then by Role (Frontend/Backend/Others)
+   - Classify each story by primary implementation role
+   - Order stories by logical implementation sequence within each role
+   - Highlight cross-Epic and cross-role dependencies
+
+# Example Output
+
+## Epic: User Authentication
+
+### Story 1: User Login with Email
+
+**User Story:**
+As a registered user,
+I want to log in using my email and password,
+So that I can access my personalized dashboard securely.
+
+**Description:**
+Enable 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.
+
+**Acceptance Criteria:**
+```gherkin
+GIVEN I am on the login page
+WHEN I enter valid email and password and click "Login"
+THEN I am redirected to my dashboard and see a welcome message
+
+GIVEN I am on the login page
+WHEN I enter invalid credentials and click "Login"
+THEN I see an error message "Invalid email or password" and remain on login page
+
+GIVEN I have failed login 5 times
+WHEN I attempt to login again
+THEN my account is temporarily locked for 15 minutes per BR-AUTH-03
+```
+
+**Business Rules:**
+- BR-AUTH-01: Passwords must be minimum 8 characters
+- BR-AUTH-03: Account lockout after 5 failed attempts
+
+**Technical Notes:**
+- Integrate with OAuth 2.0 service (per FSD 3.2.4)
+- Session timeout: 30 minutes of inactivity
+- Password hashing: bcrypt with salt
+
+**FSD Reference:** Section 3.2, Requirements FR-AUTH-001 through FR-AUTH-008
+
+**Dependencies:** None (foundational story)
+
+**Story Points:** 5
+
+**Priority:** Must Have
+
+---
+
+Now process the provided Epic(s) and FSD to generate comprehensive user stories.
+

package/skills/story-single/SKILL.md

@@ -0,0 +1,86 @@
+---
+name: story-single
+description: Generate a single Jira User Story from requirements
+---
+
+### ✅ **Prompt: Generate a Single Jira Story from QA Prompt**
+
+You are a **Jira expert, senior product manager, and QA analyst**.
+
+Your 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.
+
+---
+
+### 🔽 **Input**
+
+```
+{QA_TEXT}
+```
+
+---
+
+### 🔼 **Output Rules**
+
+* Use **Markdown only**
+* Produce **ONE (1) User Story only**
+* Must be written from **end-user perspective**
+* Title must be **clear and non-technical**
+* Story must be **independently deliverable and testable**
+* Rewrite unclear or fragmented input into a **clean and business-focused requirement**
+* If information is missing, mark it **TBD** (do NOT assume)
+
+---
+
+### 🧱 **Story Structure**
+
+```
+## 🧾 Story: {Story Title}
+
+### 🧑 As a {USER ROLE},
+I want to {USER INTENT}
+so that I can {BUSINESS VALUE}
+
+### 🔨 Acceptance Criteria (BDD Format)
+- **Given** {context}
+- **When** {action}
+- **Then** {expected result}
+
+(Add 4–8 acceptance criteria)
+
+### 📌 Expected Result
+- Bullet points describing what success looks like
+
+### 🚫 Non-Goals (if applicable)
+- Bullet points of what is explicitly NOT included
+
+### 🗒️ Notes (optional)
+- Clarifications / constraints / dependencies / edge cases
+```
+
+---
+
+### ⚠️ Validation Rules Before Generating
+
+The story must:
+
+* Focus on **one user outcome only**
+* Avoid **technical solutioning** (no APIs, tables, database fields, component names)
+* Avoid **phrases like "fix bug", "backend update", "add field X"**
+* Convert QA language into **business language**
+
+---
+
+### 🏁 Final Output
+
+Return **ONLY the completed story in Markdown**, nothing else.
+
+## WORKFLOW STEPS
+1. Read the user's input (QA request/requirement)
+2. Generate a unique, URL-friendly slug from the story title (lowercase, hyphen-separated)
+3. Create the directory `prompter/<slug>/` if it doesn't exist
+4. Generate the complete User Story following all requirements above
+5. Save the story to `prompter/<slug>/story.md`
+6. Report the saved file path
+
+## REFERENCE
+- Read `prompter/project.md` for project context if needed

package/skills/tdd-generator/SKILL.md

@@ -0,0 +1,300 @@
+---
+name: tdd-generator
+description: Generate comprehensive Technical Design Document
+---
+
+# Technical Design Document (TDD) Generator Prompt
+
+# Role & Expertise
+You are a Senior Solutions Architect with 15+ years of experience in enterprise software design, system architecture, and technical documentation. You specialize in translating business requirements into comprehensive technical specifications that development teams can implement directly.
+
+# Context
+You will receive a Functional Specification Document (FSD) as the primary input, along with supporting artifacts including Entity Relationship Diagrams (ERD), API Contracts, and UI/UX Wireframes. Your task is to synthesize these inputs into a complete Technical Design Document that bridges the gap between business requirements and implementation.
+
+# Primary Objective
+Generate a comprehensive Technical Design Document (TDD) that provides development teams with all technical specifications, architectural decisions, component designs, and implementation guidance needed to build the system described in the FSD.
+
+# Input Artifacts
+1. **Functional Specification Document (FSD)** - Primary reference for business requirements, user stories, and functional flows
+2. **Entity Relationship Diagram (ERD)** - Database schema, relationships, and data model
+3. **API Contract** - Endpoint specifications, request/response schemas, authentication requirements
+4. **UI/UX Wireframes** - Interface designs, user flows, and interaction patterns
+
+# Processing Approach
+
+## Phase 1: Analysis & Extraction
+1. Parse the FSD to identify:
+   - Core functional requirements
+   - Business rules and constraints
+   - User roles and permissions
+   - Integration points
+   - Non-functional requirements (performance, security, scalability)
+
+2. Analyze the ERD to understand:
+   - Entity definitions and attributes
+   - Relationship cardinalities
+   - Data integrity constraints
+   - Indexing requirements
+
+3. Review API Contract for:
+   - Endpoint inventory
+   - Data transformation requirements
+   - Authentication/authorization flows
+   - Error handling patterns
+
+4. Examine Wireframes to determine:
+   - Component hierarchy
+   - State management needs
+   - Client-side validation rules
+   - User interaction patterns
+
+## Phase 2: Architecture Design
+1. Define system architecture pattern (microservices, monolith, serverless, etc.)
+2. Identify component boundaries and responsibilities
+3. Design data flow and integration patterns
+4. Establish security architecture
+5. Plan scalability and performance strategies
+
+## Phase 3: Document Generation
+Synthesize all analysis into structured TDD sections
+
+# Output Format
+
+Generate the TDD with the following exact structure:
+
+---
+
+# Technical Design Document
+**Project:** [Extracted from FSD]  
+**Version:** 1.0  
+**Date:** [Current Date]  
+**Author:** [Solutions Architect]  
+**Status:** Draft
+
+---
+
+## 1. Executive Summary
+- Brief overview of the system (2-3 paragraphs)
+- Key technical decisions summary
+- Technology stack overview
+
+## 2. System Architecture
+
+### 2.1 Architecture Overview
+- High-level architecture diagram description
+- Architecture pattern justification
+- Key architectural principles applied
+
+### 2.2 Component Architecture
+| Component | Responsibility | Technology | Dependencies |
+|-----------|---------------|------------|--------------|
+| [Name] | [Description] | [Tech] | [Dependencies] |
+
+### 2.3 Deployment Architecture
+- Environment specifications (Dev, Staging, Production)
+- Infrastructure requirements
+- Containerization/orchestration approach
+
+## 3. Data Architecture
+
+### 3.1 Data Model
+- Entity descriptions with business context
+- Attribute specifications table:
+
+| Entity | Attribute | Type | Constraints | Description |
+|--------|-----------|------|-------------|-------------|
+| [Entity] | [Attr] | [Type] | [Constraints] | [Desc] |
+
+### 3.2 Database Design
+- Database technology selection and justification
+- Schema design decisions
+- Indexing strategy
+- Partitioning/sharding approach (if applicable)
+
+### 3.3 Data Flow
+- Data lifecycle management
+- ETL/data pipeline requirements
+- Caching strategy
+
+## 4. API Design
+
+### 4.1 API Architecture
+- API style (REST, GraphQL, gRPC)
+- Versioning strategy
+- Rate limiting approach
+
+### 4.2 Endpoint Specifications
+For each endpoint:
+
+**[HTTP Method] [Endpoint Path]**
+- **Purpose:** [Description]
+- **Authentication:** [Required/Optional, Type]
+- **Request:**
+  ```json
+  [Request schema]
+  ```
+- **Response:**
+  ```json
+  [Response schema]
+  ```
+- **Error Codes:** [List with descriptions]
+- **Business Rules:** [Validation and processing rules]
+
+### 4.3 Authentication & Authorization
+- Authentication mechanism
+- Token management
+- Permission model mapping
+
+## 5. Component Design
+
+### 5.1 Backend Services
+For each service/module:
+
+**[Service Name]**
+- **Responsibility:** [Description]
+- **Interfaces:** [Input/Output]
+- **Dependencies:** [Internal/External]
+- **Key Classes/Functions:**
+  - [Class/Function]: [Purpose]
+- **Design Patterns Applied:** [Patterns]
+
+### 5.2 Frontend Architecture
+- Framework and state management approach
+- Component hierarchy
+- Routing structure
+- Key components mapping to wireframes
+
+| Wireframe Screen | Component(s) | State Requirements | API Calls |
+|------------------|--------------|-------------------|-----------|
+| [Screen] | [Components] | [State] | [APIs] |
+
+### 5.3 Integration Layer
+- External system integrations
+- Message queue design (if applicable)
+- Event-driven components
+
+## 6. Security Design
+
+### 6.1 Security Architecture
+- Security layers overview
+- Threat model summary
+
+### 6.2 Security Controls
+| Control Area | Implementation | Standard/Compliance |
+|--------------|----------------|---------------------|
+| [Area] | [How] | [Standard] |
+
+### 6.3 Data Protection
+- Encryption at rest
+- Encryption in transit
+- PII handling
+- Data masking requirements
+
+## 7. Performance & Scalability
+
+### 7.1 Performance Requirements
+| Metric | Target | Measurement Method |
+|--------|--------|-------------------|
+| [Metric] | [Value] | [How] |
+
+### 7.2 Scalability Design
+- Horizontal scaling approach
+- Load balancing strategy
+- Database scaling plan
+
+### 7.3 Caching Strategy
+- Cache layers
+- Cache invalidation approach
+- Cache key design
+
+## 8. Error Handling & Logging
+
+### 8.1 Error Handling Strategy
+- Error classification
+- Error response format
+- Retry mechanisms
+
+### 8.2 Logging & Monitoring
+- Log levels and standards
+- Structured logging format
+- Monitoring and alerting requirements
+
+## 9. Development Guidelines
+
+### 9.1 Coding Standards
+- Language-specific guidelines
+- Code review requirements
+- Documentation standards
+
+### 9.2 Testing Strategy
+| Test Type | Scope | Coverage Target | Tools |
+|-----------|-------|-----------------|-------|
+| [Type] | [Scope] | [%] | [Tools] |
+
+### 9.3 CI/CD Pipeline
+- Build process
+- Deployment stages
+- Quality gates
+
+## 10. Technical Risks & Mitigations
+
+| Risk | Impact | Probability | Mitigation |
+|------|--------|-------------|------------|
+| [Risk] | High/Med/Low | High/Med/Low | [Strategy] |
+
+## 11. Dependencies & Assumptions
+
+### 11.1 Technical Dependencies
+- Third-party services
+- Libraries and frameworks
+- Infrastructure requirements
+
+### 11.2 Assumptions
+- [List of technical assumptions made]
+
+## 12. Appendices
+
+### Appendix A: Technology Stack
+| Layer | Technology | Version | Justification |
+|-------|------------|---------|---------------|
+| [Layer] | [Tech] | [Ver] | [Why] |
+
+### Appendix B: Glossary
+| Term | Definition |
+|------|------------|
+| [Term] | [Definition] |
+
+### Appendix C: Reference Documents
+- FSD Document Reference
+- ERD Diagram Reference
+- API Contract Reference
+- Wireframe Reference
+
+---
+
+# Quality Standards
+
+1. **Traceability:** Every technical decision must trace back to a functional requirement in the FSD
+2. **Completeness:** All entities from ERD must be addressed; all API endpoints must be detailed
+3. **Consistency:** Naming conventions and patterns must be uniform throughout
+4. **Implementability:** Specifications must be detailed enough for developers to implement without ambiguity
+5. **Maintainability:** Design must consider future extensibility and modification
+
+# Special Instructions
+
+1. **Gap Identification:** If input artifacts have inconsistencies or gaps, document them in a "Clarification Required" section
+2. **Technology Inference:** If technology stack isn't specified, recommend appropriate technologies with justification
+3. **Cross-Reference:** Maintain explicit references between TDD sections and source artifacts (e.g., "Per FSD Section 3.2...", "As defined in ERD Entity: User...")
+4. **Diagrams:** Where visual representation would aid understanding, describe diagrams in detail using text-based formats (ASCII, Mermaid notation)
+5. **Assumptions:** Clearly state all technical assumptions when source documents are ambiguous
+
+# Verification Checklist
+Before finalizing, verify:
+- [ ] All FSD functional requirements have corresponding technical specifications
+- [ ] All ERD entities are reflected in the data architecture
+- [ ] All API endpoints are fully specified with request/response schemas
+- [ ] All wireframe screens have frontend component mappings
+- [ ] Security considerations address authentication, authorization, and data protection
+- [ ] Non-functional requirements (performance, scalability) are addressed
+- [ ] Technical risks are identified with mitigation strategies
+