@dedesfr/prompter 0.9.0 → 1.1.0

package/skills/story-generator/SKILL.md

@@ -1,285 +0,0 @@
----
-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

@@ -1,86 +0,0 @@
----
-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

@@ -1,300 +0,0 @@
----
-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
-