Refactor planning prompts:
- Deleted obsolete feature build prompt. - Updated feature implementation prompt to enhance system architecture overview and API design sections. - Revised GitHub prompt to streamline quality standards context and remove redundant test strategy templates. - Removed implementation guide prompt to consolidate documentation. - Introduced a new comprehensive test planning prompt with detailed strategies, task breakdowns, and quality assurance plans.
This commit is contained in:
Craig Bekker
parent
70ff58f851
commit
1d28548312
@ -14,10 +14,10 @@ Ready-to-use prompt templates for this collection:
|
||||
| ----- | ----------- | ------- |
|
||||
| [Epic Architecture Specification Prompt](prompts/plan-epic-arch.prompt.md) | Prompt for creating the high-level technical architecture for an Epic, based on a Product Requirements Document. | [](https://vscode.dev/redirect?url=vscode%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fcollections%2Fplan%2Fprompts%2Fplan-epic-arch.prompt.md) [](https://insiders.vscode.dev/redirect?url=vscode-insiders%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fcollections%2Fplan%2Fprompts%2Fplan-epic-arch.prompt.md) |
|
||||
| [Epic Product Requirements Document (PRD) Prompt](prompts/plan-epic-pm.prompt.md) | Prompt for creating an Epic Product Requirements Document (PRD) for a new epic. This PRD will be used as input for generating a technical architecture specification. | [](https://vscode.dev/redirect?url=vscode%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fcollections%2Fplan%2Fprompts%2Fplan-epic-pm.prompt.md) [](https://insiders.vscode.dev/redirect?url=vscode-insiders%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fcollections%2Fplan%2Fprompts%2Fplan-epic-pm.prompt.md) |
|
||||
| [Feature Build Implementation Prompt](prompts/plan-feature-build.prompt.md) | Complete feature implementation prompt that builds the entire feature in VS Code using AI tools (GitHub Copilot, Claude CLI, Gemini CLI, etc.) with full context from all workflow artifacts. | [](https://vscode.dev/redirect?url=vscode%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fcollections%2Fplan%2Fprompts%2Fplan-feature-build.prompt.md) [](https://insiders.vscode.dev/redirect?url=vscode-insiders%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fcollections%2Fplan%2Fprompts%2Fplan-feature-build.prompt.md) |
|
||||
| [Feature Implementation Plan Prompt](prompts/plan-feature-implementation.prompt.md) | Prompt for creating detailed feature implementation plans, following Epoch monorepo structure. | [](https://vscode.dev/redirect?url=vscode%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fcollections%2Fplan%2Fprompts%2Fplan-feature-implementation.prompt.md) [](https://insiders.vscode.dev/redirect?url=vscode-insiders%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fcollections%2Fplan%2Fprompts%2Fplan-feature-implementation.prompt.md) |
|
||||
| [Feature PRD Prompt](prompts/plan-feature-prd.prompt.md) | Prompt for creating Product Requirements Documents (PRDs) for new features, based on an Epic. | [](https://vscode.dev/redirect?url=vscode%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fcollections%2Fplan%2Fprompts%2Fplan-feature-prd.prompt.md) [](https://insiders.vscode.dev/redirect?url=vscode-insiders%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fcollections%2Fplan%2Fprompts%2Fplan-feature-prd.prompt.md) |
|
||||
| [GitHub Issue Planning & Project Automation Prompt](prompts/plan-github.prompt.md) | Issue Planning and Automation prompt that generates comprehensive project plans with Epic > Feature > Story/Enabler > Test hierarchy, dependencies, priorities, and automated tracking. | [](https://vscode.dev/redirect?url=vscode%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fcollections%2Fplan%2Fprompts%2Fplan-github.prompt.md) [](https://insiders.vscode.dev/redirect?url=vscode-insiders%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fcollections%2Fplan%2Fprompts%2Fplan-github.prompt.md) |
|
||||
| [Test Planning & Quality Assurance Prompt](prompts/plan-test.prompt.md) | Test Planning and Quality Assurance prompt that generates comprehensive test strategies, task breakdowns, and quality validation plans for GitHub projects. | [](https://vscode.dev/redirect?url=vscode%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fcollections%2Fplan%2Fprompts%2Fplan-test.prompt.md) [](https://insiders.vscode.dev/redirect?url=vscode-insiders%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fcollections%2Fplan%2Fprompts%2Fplan-test.prompt.md) |
|
||||
|
||||
> 💡 **Usage**: Use `/prompt-name` in VS Code chat, run `Chat: Run Prompt` command, or hit the run button while you have a prompt open.
|
||||
|
||||
|
||||
@ -1,159 +1,111 @@
|
||||
# GitHub Copilot Prompt Library
|
||||
|
||||
This directory contains specialized prompt files designed to work with GitHub Copilot to streamline the development process for the Epoch platform using a comprehensive hierarchical breakdown approach.
|
||||
This directory contains specialized prompt files designed to work with GitHub Copilot to streamline the development process using a comprehensive hierarchical breakdown approach.
|
||||
|
||||
## Unified Epic, Feature, and Testing Workflow
|
||||
## Core Planning Workflow
|
||||
|
||||
This workflow integrates user story UX design, technical breakdown, and comprehensive testing automation into a single, traceable process. All steps, prompts, and best practices are consolidated here for clarity and efficiency.
|
||||
This streamlined workflow covers the essential planning stages from epic definition through project management setup, with integrated testing and quality assurance.
|
||||
|
||||
### Hierarchical Work Breakdown Structure
|
||||
|
||||
Our workflow follows the Agile hierarchy: **Epic → Feature → Story/Enabler → Test → Task**, with each level providing specific value and granularity:
|
||||
Our workflow follows the Agile hierarchy: **Epic → Feature → Implementation → Project Management**, with each level providing specific value and granularity:
|
||||
|
||||
- **Epic**: Large business capability spanning multiple features (milestone level)
|
||||
- **Feature**: Deliverable user-facing functionality within an epic
|
||||
- **Story**: User-focused requirement that delivers value independently
|
||||
- **Enabler**: Technical infrastructure or architectural work supporting stories
|
||||
- **Test**: Quality assurance work for validating stories and enablers
|
||||
- **Task**: Implementation-level work breakdown for stories/enablers
|
||||
- **Feature**: Deliverable user-facing functionality within an epic
|
||||
- **Implementation**: Technical planning and architecture for feature delivery
|
||||
- **Project Management**: GitHub issues, automation, and delivery tracking
|
||||
|
||||
---
|
||||
|
||||
## Complete Feature Development Flow
|
||||
## Streamlined Development Flow
|
||||
|
||||
```mermaid
|
||||
graph LR
|
||||
A[Feature PRD] --> B[Feature UX Design]
|
||||
B --> C[User Story UX Design]
|
||||
A --> D[BA User Story Breakdown]
|
||||
C --> E[TL Technical Breakdown]
|
||||
D --> E
|
||||
E --> F[Playwright Testing]
|
||||
C --> F
|
||||
E --> G[GitHub Issue Planning]
|
||||
F --> G
|
||||
G --> H[Automated project Setup]
|
||||
A[Epic PRD] --> B[Epic Architecture]
|
||||
B --> C[Feature PRD]
|
||||
C --> D[Feature Implementation Plan]
|
||||
D --> E[GitHub Project Setup]
|
||||
|
||||
subgraph "Core Planning Chain"
|
||||
G["Epic → Feature → Implementation"]
|
||||
H["Project Management"]
|
||||
end
|
||||
```
|
||||
|
||||
### Input/Output Chain
|
||||
|
||||
1. **Feature PRD** → User stories and requirements
|
||||
2. **User Story UX Design** → Micro-interaction specifications
|
||||
3. **Technical Breakdown** → Implementation tasks with UX context
|
||||
4. **Playwright Testing** → Comprehensive test strategy
|
||||
5. **GitHub Issue Planning** → Automated project management
|
||||
1. **Epic PRD** → Business requirements and scope definition
|
||||
2. **Epic Architecture** → High-level technical approach and system design
|
||||
3. **Feature PRD** → Detailed feature specifications and user requirements
|
||||
4. **Feature Implementation** → Technical planning and development approach
|
||||
5. **GitHub Project Setup** → Automated project management and tracking
|
||||
|
||||
---
|
||||
|
||||
## Step-by-Step Execution Guide
|
||||
|
||||
### 1. Epic Definition (Product)
|
||||
### 1. Epic Definition (Product Management)
|
||||
|
||||
- Use `epic-pm.prompt.md` to create an Epic PRD.
|
||||
- **Input:** High-level epic idea.
|
||||
- Use `plan-epic-pm.prompt.md` to create an Epic PRD
|
||||
- **Input:** High-level epic idea or business requirement
|
||||
- **Output:** `/docs/ways-of-work/plan/epic/{epic-name}.md`
|
||||
|
||||
### 2. Epic Architecture
|
||||
### 2. Epic Architecture (Technical Leadership)
|
||||
|
||||
- Use `epic-arch.prompt.md` with the Epic PRD to define high-level technical architecture.
|
||||
- **Input:** Epic PRD.
|
||||
- Use `plan-epic-arch.prompt.md` with the Epic PRD to define technical architecture
|
||||
- **Input:** Epic PRD from step 1
|
||||
- **Output:** `/docs/ways-of-work/plan/epic/{epic-name}-arch.md`
|
||||
|
||||
### 3. Feature Definition (Product)
|
||||
### 3. Feature Definition (Product Management)
|
||||
|
||||
- Use `feature-prd.prompt.md` for each feature in the epic to create a Feature PRD.
|
||||
- **Input:** Feature from Epic Architecture.
|
||||
- Use `plan-feature-prd.prompt.md` for each feature in the epic
|
||||
- **Input:** Epic PRD and Epic Architecture
|
||||
- **Output:** `/docs/ways-of-work/plan/{epic-name}/{feature-name}.md`
|
||||
|
||||
### 4. Feature Design (UI/UX)
|
||||
### 4. Feature Implementation Planning (Engineering)
|
||||
|
||||
- Use `feature-ux.prompt.md` with the Feature PRD to create a UI/UX design spec.
|
||||
- **Input:** Feature PRD.
|
||||
- **Output:** `/docs/ways-of-work/plan/{epic-name}/{feature-name}/design.md`
|
||||
|
||||
#### 4a. User Story Design (Micro-UX)
|
||||
|
||||
- Use `user-story-ux.prompt.md` for detailed interaction design at the user story level.
|
||||
- **Input:** User stories from Feature PRD.
|
||||
- **Output:** `/docs/ways-of-work/plan/{epic-name}/{feature-name}/user-story-{id}-design.md`
|
||||
|
||||
### 5. Feature Implementation Plan
|
||||
|
||||
- Use `feature-implementation.prompt.md` with the Feature PRD and Design Spec to create a technical plan.
|
||||
- **Input:** Feature PRD and Design Spec.
|
||||
- Use `plan-feature-implementation.prompt.md` to create technical implementation plan
|
||||
- **Input:** Feature PRD and Epic Architecture
|
||||
- **Output:** `/docs/ways-of-work/plan/{epic-name}/{feature-name}/implementation-plan.md`
|
||||
|
||||
### 6. Feature Testing Strategy (ISTQB & ISO 25010)
|
||||
### 5. GitHub Project Setup (Project Management)
|
||||
|
||||
- Use `feature-test.prompt.md` to generate a comprehensive test strategy.
|
||||
- **Input:** Epic PRD, Epic Architecture, Feature PRD, Feature UX Design, Implementation Plan.
|
||||
- **Output:** `/docs/ways-of-work/plan/{epic-name}/{feature-name}/test-strategy.md`
|
||||
|
||||
### 7. Business Analyst Breakdown
|
||||
|
||||
- Use `ba-user-story-breakdown.prompt.md` to break down features into user stories for AI agent execution.
|
||||
- **Input:** Feature PRD, Design Spec, Implementation Plan.
|
||||
- **Output:** `/docs/ways-of-work/plan/{epic-name}/{feature-name}/user-stories-breakdown.md`
|
||||
|
||||
### 8. Tech Lead Technical Breakdown
|
||||
|
||||
- Use `tl-technical-breakdown.prompt.md` to convert user stories into implementation tasks.
|
||||
- **Input:** User Stories Breakdown and all previous artifacts.
|
||||
- **Output:** `/docs/ways-of-work/plan/{epic-name}/{feature-name}/technical-breakdown.md`
|
||||
|
||||
### 9. Story-Level Playwright Testing
|
||||
|
||||
- Use `playwright-testing.prompt.md` to create detailed Playwright test implementations.
|
||||
- **Input:** Test Strategy, User Story UX Design, Technical Breakdown.
|
||||
- **Output:** `/docs/ways-of-work/plan/{epic-name}/{feature-name}/story-{id}-playwright-tests.md`
|
||||
|
||||
### 10. GitHub Issue Planning & Automation
|
||||
|
||||
- Use `github-issue-plan.prompt.md` to generate automated project management.
|
||||
- **Input:** All feature artifacts (PRD, UX, Technical, Test Strategy, Playwright Testing plans).
|
||||
- **Output:** `/docs/ways-of-work/plan/{epic-name}/{feature-name}/project-plan.md` and `/docs/ways-of-work/plan/{epic-name}/{feature-name}/github-issues-checklist.md`
|
||||
- Use `plan-github.prompt.md` to generate automated project management and issue tracking
|
||||
- **Input:** Epic PRD, Epic Architecture, Feature PRD, Implementation Plan
|
||||
- **Output:** `/docs/ways-of-work/plan/{epic-name}/{feature-name}/project-plan.md`
|
||||
|
||||
---
|
||||
|
||||
## Best Practices
|
||||
|
||||
- **Always attach required documents** as specified in each prompt.
|
||||
- **Use absolute file paths** for referencing outputs.
|
||||
- **Maintain file naming conventions** and version control all artifacts.
|
||||
- **Review outputs** before using as inputs for subsequent steps.
|
||||
- **Validate technical feasibility** and ensure UX consistency.
|
||||
- **Leverage MCP tools** for automation and traceability.
|
||||
- **Iterate and refine** using feedback loops.
|
||||
- **Sequential Execution**: Follow the step-by-step guide in order for optimal results
|
||||
- **Document Attachment**: Always attach required input documents as specified in each prompt
|
||||
- **File Path Consistency**: Use absolute file paths for referencing outputs
|
||||
- **Version Control**: Maintain version control for all planning artifacts
|
||||
- **Review and Validate**: Review outputs before using as inputs for subsequent steps
|
||||
- **Iterative Refinement**: Use feedback loops to improve planning quality
|
||||
|
||||
---
|
||||
|
||||
## Available Prompts
|
||||
|
||||
- **epic-pm.prompt.md** – Epic PRD
|
||||
- **epic-arch.prompt.md** – Epic Architecture
|
||||
- **feature-prd.prompt.md** – Feature PRD
|
||||
- **feature-ux.prompt.md** – Feature UI/UX Design
|
||||
- **story-ux.prompt.md** – User Story UX Design
|
||||
- **feature-implementation.prompt.md** – Implementation Plan
|
||||
- **feature-test.prompt.md** – Test Strategy
|
||||
- **story-ba-breakdown.prompt.md** – User Story Breakdown
|
||||
- **story-tl.prompt.md** – Technical Breakdown
|
||||
- **story-test.prompt.md** – Playwright Testing
|
||||
- **github-issue-plan.prompt.md** – GitHub Issue Planning
|
||||
- **plan-epic-pm.prompt.md** – Epic Product Requirements Document
|
||||
- **plan-epic-arch.prompt.md** – Epic Technical Architecture Specification
|
||||
- **plan-feature-prd.prompt.md** – Feature Product Requirements Document
|
||||
- **plan-feature-implementation.prompt.md** – Feature Technical Implementation Plan
|
||||
- **plan-test.prompt.md** – Comprehensive Test Strategy (ISTQB & ISO 25010)
|
||||
- **plan-github.prompt.md** – GitHub Project Management and Issue Planning
|
||||
|
||||
---
|
||||
|
||||
## AI Agent Integration & Automation
|
||||
|
||||
- **Multi-Agent Orchestration**: Copilot, Claude, MCP tools
|
||||
- **Executable Code Actions**: CodeAct patterns
|
||||
- **MCP Server Configuration**: Automated tool chain setup
|
||||
- **Context-Aware Handoffs**: Seamless transitions between planning, development, and testing
|
||||
- **Quality Gate Automation**: Autonomous validation with human oversight
|
||||
- **Comprehensive Testing**: Playwright MCP integration
|
||||
- **Project Management Automation**: GitHub Issues and Projects API
|
||||
- **Kanban Workflow Support**: Automated status transitions and dependency tracking
|
||||
- **Anti-Solutioneering Guidance**: Focus on outcomes over prescribed solutions
|
||||
- **Sequential Planning**: Copilot-driven workflow execution from epic to project management
|
||||
- **Document Chain Integration**: Each prompt builds on previous outputs for complete traceability
|
||||
- **Quality Gate Automation**: ISTQB framework integration with automated validation
|
||||
- **GitHub Integration**: Automated project setup and issue tracking from planning artifacts
|
||||
- **Multi-Modal Planning**: Business, technical, testing, and project management perspectives
|
||||
- **Artifact Management**: Structured file output with consistent naming and organization
|
||||
|
||||
---
|
||||
|
||||
@ -163,62 +115,47 @@ graph LR
|
||||
graph TD
|
||||
A[Epic Definition] --> B[Epic Architecture]
|
||||
B --> C[Feature PRD]
|
||||
C --> D[Feature UX Design]
|
||||
C --> E[Implementation Plan]
|
||||
|
||||
D --> F[User Story UX Design]
|
||||
E --> G[BA User Story Breakdown]
|
||||
G --> H[TL Technical Breakdown]
|
||||
|
||||
F --> H
|
||||
H --> I[Playwright Testing]
|
||||
F --> I
|
||||
|
||||
H --> J[GitHub Issue Planning]
|
||||
I --> J
|
||||
|
||||
J --> K[Automated Project Setup]
|
||||
K --> L[Sprint Execution]
|
||||
|
||||
subgraph "Key Workflow Connections"
|
||||
M["User Story UX → Technical Breakdown"]
|
||||
N["Technical Breakdown → Playwright Testing"]
|
||||
O["All Artifacts → GitHub Issue Planning"]
|
||||
C --> D[Feature Implementation Plan]
|
||||
D --> E[Test Strategy]
|
||||
E --> F[GitHub Project Setup]
|
||||
|
||||
subgraph "Key Planning Stages"
|
||||
G["Epic Level: Business & Technical Vision"]
|
||||
H["Feature Level: Detailed Requirements & Implementation"]
|
||||
I["Quality Level: Testing & Project Management"]
|
||||
end
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Cyclical Workflow Pattern
|
||||
## Simplified Workflow Pattern
|
||||
|
||||
- **Epic Level**: Each epic can contain multiple features, each requiring full workflow execution
|
||||
- **Feature Level**: Each feature contains multiple stories/enablers, each with detailed UX and technical breakdown
|
||||
- **Story Level**: Each story can generate multiple implementation tasks and test cases
|
||||
- **Testing Level**: Each story/enabler requires comprehensive test coverage across multiple test types
|
||||
- **Epic Level**: Define business capability and technical architecture
|
||||
- **Feature Level**: Detailed requirements and implementation planning
|
||||
- **Quality Level**: Comprehensive testing strategy and project management setup
|
||||
|
||||
The process **repeats and deepens** as you move through the hierarchy, ensuring complete coverage and traceability from high-level business goals down to specific implementation tasks and quality validation.
|
||||
The process provides **complete traceability** from high-level business goals down to specific implementation plans and quality validation, with automated project management integration.
|
||||
|
||||
---
|
||||
|
||||
## User Story Implementation
|
||||
## Usage Patterns
|
||||
|
||||
1. User Story UX → TL Technical → Playwright Testing → GitHub Issues
|
||||
### Complete Epic Planning
|
||||
|
||||
## Testing Focus
|
||||
1. Epic PRD → Epic Architecture → Feature PRD → Implementation → Testing → Project Setup
|
||||
|
||||
1. Review existing artifacts → Playwright Testing → Execute test automation
|
||||
### Feature-Focused Planning
|
||||
|
||||
## Project Management Setup
|
||||
1. Feature PRD → Implementation Plan → Test Strategy → GitHub Setup
|
||||
|
||||
1. Gather all feature artifacts → GitHub Issue Planning → Automated project creation
|
||||
### Quality-Focused Planning
|
||||
|
||||
1. Review existing artifacts → Test Strategy → Quality validation framework
|
||||
|
||||
### Project Management Setup
|
||||
|
||||
1. Gather all artifacts → GitHub Project Planning → Automated issue creation
|
||||
|
||||
---
|
||||
|
||||
## Checklist & Deferred Work Policy
|
||||
|
||||
- **Always create a checklist** when starting work on any Epic, Feature, or Issue. Name the file `_checklist-{issue-number}.md` if an issue number is available, otherwise use `_checklist-epic.md`, `_checklist-feat.md`, etc.
|
||||
- **Update the checklist** as work is completed, marking items off in real time.
|
||||
- **Move any deferred or explicitly skipped items** to a `_todo.md` file in the same directory (e.g., `_todo.md` for open/parked tasks).
|
||||
- **Checklist and todo files must be kept up to date** throughout the workflow for traceability and auditability.
|
||||
|
||||
This ensures all work is tracked, deferred items are not lost, and the workflow remains transparent and reviewable.
|
||||
This streamlined planning workflow provides complete coverage from business requirements through technical implementation and quality assurance, with integrated project management automation for efficient delivery tracking.
|
||||
|
||||
@ -34,62 +34,15 @@ The output should be a complete Epic Architecture Specification in Markdown form
|
||||
|
||||
#### 2. System Architecture Diagram
|
||||
|
||||
Create a comprehensive Mermaid diagram detailing the full system architecture for the epic:
|
||||
Create a comprehensive Mermaid diagram that illustrates the complete system architecture for this epic. The diagram should include:
|
||||
|
||||
```mermaid
|
||||
graph TB
|
||||
subgraph "User Layer"
|
||||
U[Users] --> WEB[Web Browser]
|
||||
U --> MOB[Mobile App]
|
||||
end
|
||||
- **User Layer**: Show how different user types (web browsers, mobile apps, admin interfaces) interact with the system
|
||||
- **Application Layer**: Depict load balancers, application instances, and authentication services (Stack Auth)
|
||||
- **Service Layer**: Include tRPC APIs, background services, workflow engines (n8n), and any epic-specific services
|
||||
- **Data Layer**: Show databases (PostgreSQL), vector databases (Qdrant), caching layers (Redis), and external API integrations
|
||||
- **Infrastructure Layer**: Represent Docker containerization and deployment architecture
|
||||
|
||||
subgraph "Application Layer"
|
||||
WEB --> LB[Load Balancer]
|
||||
MOB --> LB
|
||||
LB --> APP1[App Instance 1]
|
||||
LB --> APP2[App Instance 2]
|
||||
|
||||
APP1 --> AUTH[Stack Auth]
|
||||
APP2 --> AUTH
|
||||
end
|
||||
|
||||
subgraph "Service Layer"
|
||||
APP1 --> API[tRPC API]
|
||||
APP2 --> API
|
||||
API --> BG[Background Services]
|
||||
BG --> WORK[n8n Workflows]
|
||||
end
|
||||
|
||||
subgraph "Data Layer"
|
||||
API --> DB[(PostgreSQL)]
|
||||
API --> VECTOR[(Qdrant Vector DB)]
|
||||
BG --> CACHE[(Redis Cache)]
|
||||
WORK --> EXT[External APIs]
|
||||
end
|
||||
|
||||
subgraph "Infrastructure Layer"
|
||||
DB --> DOCKER[Docker Containers]
|
||||
VECTOR --> DOCKER
|
||||
CACHE --> DOCKER
|
||||
APP1 --> DOCKER
|
||||
APP2 --> DOCKER
|
||||
end
|
||||
|
||||
style U fill:#e1f5fe
|
||||
style WEB fill:#f3e5f5
|
||||
style MOB fill:#f3e5f5
|
||||
style APP1 fill:#e8f5e8
|
||||
style APP2 fill:#e8f5e8
|
||||
style DB fill:#fff3e0
|
||||
style VECTOR fill:#fff3e0
|
||||
```
|
||||
|
||||
**Architecture Flow Description:**
|
||||
|
||||
- **Color Coding**: User interactions (blue), Applications (purple), Services (green), Data (orange)
|
||||
- **Service Boundaries**: Clear separation between application zones and data persistence
|
||||
- **Data Flow**: Request routing from users through load balancer to application instances
|
||||
- **Integration Points**: Authentication, background processing, and external service connections
|
||||
Use clear subgraphs to organize these layers, apply consistent color coding for different component types, and show the data flow between components. Include both synchronous request paths and asynchronous processing flows where relevant to the epic.
|
||||
|
||||
#### 3. High-Level Features & Technical Enablers
|
||||
|
||||
|
||||
@ -1,301 +0,0 @@
|
||||
```prompt
|
||||
---
|
||||
mode: 'agent'
|
||||
description: 'Complete feature implementation prompt that builds the entire feature in VS Code using AI tools (GitHub Copilot, Claude CLI, Gemini CLI, etc.) with full context from all workflow artifacts.'
|
||||
---
|
||||
|
||||
# Feature Build Implementation Prompt
|
||||
|
||||
## Goal
|
||||
|
||||
Act as a senior full-stack engineer with expertise in the Epoch technology stack. Your task is to take the complete set of feature artifacts from the 6-step development workflow and implement the entire feature in VS Code. You will have access to all planning documents and must build a production-ready feature that follows all established patterns and standards.
|
||||
|
||||
## Context Integration
|
||||
|
||||
You will be provided with the complete artifact set from the development workflow:
|
||||
|
||||
### Planning Documents (Steps 1-2)
|
||||
- **Epic PRD**: `/docs/ways-of-work/plan/{epic-name}/epic.md`
|
||||
- **Epic Architecture**: `/docs/ways-of-work/plan/{epic-name}/arch.md`
|
||||
|
||||
### Feature Definition (Steps 3-6)
|
||||
- **Feature PRD**: `/docs/ways-of-work/plan/{epic-name}/{feature-name}/prd.md`
|
||||
- **UX Design Specification**: `/docs/ways-of-work/plan/{epic-name}/{feature-name}/design.md`
|
||||
- **Implementation Plan**: `/docs/ways-of-work/plan/{epic-name}/{feature-name}/implementation-plan.md`
|
||||
- **Test Strategy**: `/docs/ways-of-work/plan/{epic-name}/{feature-name}/test-strategy.md`
|
||||
|
||||
### Additional Context
|
||||
- **Project Plan**: `/docs/ways-of-work/plan/{epic-name}/{feature-name}/project-plan.md`
|
||||
- **GitHub Issues Checklist**: `/docs/ways-of-work/plan/{epic-name}/{feature-name}/github-issues-checklist.md`
|
||||
|
||||
## Technology Stack Requirements
|
||||
|
||||
### Core Technologies
|
||||
- **TypeScript**: Strict mode with comprehensive type safety
|
||||
- **Next.js**: App Router with latest patterns (not Pages Router)
|
||||
- **React**: Modern hooks and patterns with Server Components where appropriate
|
||||
- **Turborepo**: Monorepo structure with proper package organization
|
||||
- **tRPC**: Type-safe API communication between frontend and backend
|
||||
- **Stack Auth**: Authentication flows and user management
|
||||
- **Drizzle ORM**: Database interactions with type-safe queries
|
||||
- **PostgreSQL**: Primary database with proper schema design
|
||||
- **Qdrant**: Vector database for AI/ML features
|
||||
- **Docker**: Containerization for all services
|
||||
|
||||
### UI/UX Technologies
|
||||
- **shadcn/ui**: Component library for consistent UI patterns
|
||||
- **Tailwind CSS**: Utility-first styling with design system tokens
|
||||
- **Radix UI**: Headless components for accessibility
|
||||
- **Lucide React**: Icon library
|
||||
- **Framer Motion**: Animations and micro-interactions
|
||||
|
||||
### Testing Technologies
|
||||
- **Vitest**: Unit and integration testing
|
||||
- **Playwright**: End-to-end testing with browser automation
|
||||
- **Testing Library**: Component testing utilities
|
||||
- **MSW**: API mocking for testing
|
||||
|
||||
### Development Tools
|
||||
- **ESLint**: Code linting with project-specific rules
|
||||
- **Prettier**: Code formatting
|
||||
- **TypeScript**: Type checking
|
||||
- **Docker Compose**: Local development environment
|
||||
|
||||
## Implementation Requirements
|
||||
|
||||
### 1. Database Implementation
|
||||
|
||||
**Database Schema Creation:**
|
||||
- Create Drizzle schema files in `packages/db/src/schema/`
|
||||
- Include proper relationships, indexes, and constraints
|
||||
- Generate and run migrations
|
||||
- Implement seed data if required
|
||||
|
||||
**Example Structure:**
|
||||
```
|
||||
|
||||
packages/db/src/schema/
|
||||
├── {feature-name}.ts
|
||||
├── index.ts (export new schemas)
|
||||
└── relations.ts (if complex relationships)
|
||||
|
||||
```
|
||||
|
||||
### 2. API Implementation
|
||||
|
||||
**tRPC Router Creation:**
|
||||
- Create feature-specific routers in `apps/api/src/routers/`
|
||||
- Implement all CRUD operations with proper validation
|
||||
- Include authentication/authorization checks
|
||||
- Add comprehensive error handling
|
||||
|
||||
**Example Structure:**
|
||||
```
|
||||
|
||||
apps/api/src/routers/
|
||||
├── {feature-name}.ts
|
||||
└── index.ts (export new router)
|
||||
|
||||
```
|
||||
|
||||
### 3. Frontend Implementation
|
||||
|
||||
**Component Development:**
|
||||
- Create feature components in appropriate packages
|
||||
- Use shadcn/ui components as building blocks
|
||||
- Implement responsive design patterns
|
||||
- Add proper TypeScript interfaces
|
||||
|
||||
**Page Implementation:**
|
||||
- Create Next.js App Router pages in `apps/web/src/app/`
|
||||
- Implement proper loading states and error boundaries
|
||||
- Add metadata and SEO optimization
|
||||
- Include proper authentication guards
|
||||
|
||||
**Example Structure:**
|
||||
```
|
||||
|
||||
apps/web/src/app/
|
||||
├── {feature-name}/
|
||||
│ ├── page.tsx
|
||||
│ ├── loading.tsx
|
||||
│ ├── error.tsx
|
||||
│ └── components/
|
||||
└── api/trpc/[trpc]/route.ts (if API routes needed)
|
||||
|
||||
packages/ui/src/components/
|
||||
├── {feature-name}/
|
||||
│ ├── {component-name}.tsx
|
||||
│ ├── index.ts
|
||||
│ └── {component-name}.stories.tsx (Storybook)
|
||||
|
||||
```
|
||||
|
||||
### 4. State Management
|
||||
|
||||
**Client State:**
|
||||
- Implement Zustand stores for complex client state
|
||||
- Use React Query/TanStack Query for server state
|
||||
- Include proper TypeScript types for all state
|
||||
|
||||
**Server State:**
|
||||
- Leverage tRPC's built-in caching and synchronization
|
||||
- Implement optimistic updates where appropriate
|
||||
- Add proper invalidation strategies
|
||||
|
||||
### 5. Testing Implementation
|
||||
|
||||
**Unit Tests:**
|
||||
- Create Vitest tests for all utility functions and hooks
|
||||
- Test components in isolation with Testing Library
|
||||
- Achieve minimum 80% code coverage
|
||||
|
||||
**Integration Tests:**
|
||||
- Test API endpoints with proper mocking
|
||||
- Test component integration with real data flows
|
||||
- Include authentication and authorization testing
|
||||
|
||||
**E2E Tests:**
|
||||
- Implement Playwright tests based on test strategy
|
||||
- Cover critical user journeys end-to-end
|
||||
- Include accessibility testing with axe-core
|
||||
|
||||
**Example Test Structure:**
|
||||
```
|
||||
|
||||
tests/
|
||||
├── unit/
|
||||
│ ├── {feature-name}/
|
||||
│ └── **mocks**/
|
||||
├── integration/
|
||||
│ └── {feature-name}/
|
||||
└── e2e/
|
||||
└── {feature-name}/
|
||||
|
||||
````
|
||||
|
||||
### 6. Documentation
|
||||
|
||||
**Code Documentation:**
|
||||
- Add comprehensive JSDoc comments
|
||||
- Document complex business logic
|
||||
- Include usage examples for reusable components
|
||||
|
||||
**README Updates:**
|
||||
- Update relevant package READMEs
|
||||
- Add feature documentation to main README
|
||||
- Include setup and configuration instructions
|
||||
|
||||
## Quality Standards
|
||||
|
||||
### Code Quality
|
||||
- **Type Safety**: 100% TypeScript coverage with strict mode
|
||||
- **Linting**: Zero ESLint errors or warnings
|
||||
- **Formatting**: Consistent Prettier formatting
|
||||
- **Testing**: Minimum 80% test coverage
|
||||
- **Performance**: Lighthouse scores >90 for all metrics
|
||||
|
||||
### Architecture Standards
|
||||
- **Domain-Driven Design**: Proper separation of concerns
|
||||
- **SOLID Principles**: Clean, maintainable code structure
|
||||
- **Error Handling**: Comprehensive error boundaries and logging
|
||||
- **Security**: Proper input validation and sanitization
|
||||
- **Accessibility**: WCAG 2.1 AA compliance
|
||||
|
||||
### Deployment Standards
|
||||
- **Docker**: Proper containerization for all services
|
||||
- **Environment Config**: Proper environment variable management
|
||||
- **CI/CD Ready**: Code ready for automated deployment
|
||||
- **Monitoring**: Proper logging and error tracking integration
|
||||
|
||||
## Implementation Process
|
||||
|
||||
### Phase 1: Foundation Setup
|
||||
1. **Database**: Create schema, migrations, and seed data
|
||||
2. **API**: Implement tRPC routers with basic CRUD operations
|
||||
3. **Types**: Create shared TypeScript interfaces and types
|
||||
|
||||
### Phase 2: Core Implementation
|
||||
1. **Components**: Build UI components using shadcn/ui patterns
|
||||
2. **Pages**: Implement Next.js pages with proper routing
|
||||
3. **State**: Add client and server state management
|
||||
4. **Integration**: Connect frontend to API with tRPC
|
||||
|
||||
### Phase 3: Quality & Testing
|
||||
1. **Unit Tests**: Comprehensive component and utility testing
|
||||
2. **Integration Tests**: API and data flow testing
|
||||
3. **E2E Tests**: Critical user journey validation
|
||||
4. **Performance**: Optimization and Lighthouse auditing
|
||||
|
||||
### Phase 4: Documentation & Deployment
|
||||
1. **Documentation**: Code comments and README updates
|
||||
2. **Docker**: Service containerization and compose configuration
|
||||
3. **Validation**: Full feature testing and quality gates
|
||||
4. **Deployment**: Production-ready deployment configuration
|
||||
|
||||
## Validation Checklist
|
||||
|
||||
Before marking the feature complete, ensure:
|
||||
|
||||
- [ ] All requirements from the PRD are implemented
|
||||
- [ ] UX design specification is faithfully implemented
|
||||
- [ ] Implementation plan technical requirements are met
|
||||
- [ ] Test strategy is fully executed with passing tests
|
||||
- [ ] Code follows all project standards and patterns
|
||||
- [ ] TypeScript compilation passes with zero errors
|
||||
- [ ] All linting and formatting checks pass
|
||||
- [ ] Docker containers build and run successfully
|
||||
- [ ] Documentation is complete and accurate
|
||||
- [ ] Feature integrates properly with existing system
|
||||
- [ ] Performance meets established benchmarks
|
||||
- [ ] Accessibility requirements are met
|
||||
- [ ] Security requirements are implemented
|
||||
|
||||
## Context Template
|
||||
|
||||
To use this prompt effectively, provide:
|
||||
|
||||
```markdown
|
||||
## Feature Context
|
||||
|
||||
**Epic Name**: {epic-name}
|
||||
**Feature Name**: {feature-name}
|
||||
|
||||
### Artifact Documents
|
||||
|
||||
1. **Epic PRD**: [Attach epic.md content]
|
||||
2. **Epic Architecture**: [Attach arch.md content]
|
||||
3. **Feature PRD**: [Attach prd.md content]
|
||||
4. **UX Design**: [Attach design.md content]
|
||||
5. **Implementation Plan**: [Attach implementation-plan.md content]
|
||||
6. **Test Strategy**: [Attach test-strategy.md content]
|
||||
|
||||
### Additional Context
|
||||
|
||||
- **Project Plan**: [Attach project-plan.md if available]
|
||||
- **Existing Codebase**: [Current state of relevant packages/apps]
|
||||
- **Environment**: [Development environment specifics]
|
||||
- **Timeline**: [Implementation deadline or sprint information]
|
||||
|
||||
### Special Requirements
|
||||
|
||||
- [Any additional constraints or requirements not captured in artifacts]
|
||||
- [Integration points with existing features]
|
||||
- [Performance or scalability considerations]
|
||||
````
|
||||
|
||||
## Expected Output
|
||||
|
||||
Upon completion, the AI tool should have:
|
||||
|
||||
1. **Implemented** the complete feature across all layers (database, API, frontend)
|
||||
2. **Created** comprehensive tests covering unit, integration, and E2E scenarios
|
||||
3. **Updated** all relevant documentation and configuration files
|
||||
4. **Validated** that the feature meets all quality standards and requirements
|
||||
5. **Provided** a summary of what was built and how to run/test it
|
||||
|
||||
The feature should be production-ready and seamlessly integrated with the existing Epoch platform.
|
||||
|
||||
```
|
||||
|
||||
```
|
||||
@ -45,50 +45,17 @@ Feature goal described (3-5 sentences)
|
||||
|
||||
##### System Architecture Overview
|
||||
|
||||
Create a comprehensive system architecture diagram using Mermaid showing the feature's integration:
|
||||
Create a comprehensive system architecture diagram using Mermaid that shows how this feature integrates into the overall system. The diagram should include:
|
||||
|
||||
```mermaid
|
||||
graph TB
|
||||
subgraph "Frontend Layer"
|
||||
UI[User Interface]
|
||||
COMPONENTS[React Components]
|
||||
STATE[State Management]
|
||||
end
|
||||
- **Frontend Layer**: User interface components, state management, and client-side logic
|
||||
- **API Layer**: tRPC endpoints, authentication middleware, input validation, and request routing
|
||||
- **Business Logic Layer**: Service classes, business rules, workflow orchestration, and event handling
|
||||
- **Data Layer**: Database interactions, caching mechanisms, and external API integrations
|
||||
- **Infrastructure Layer**: Docker containers, background services, and deployment components
|
||||
|
||||
subgraph "API Layer"
|
||||
TRPC[tRPC Endpoints]
|
||||
MIDDLEWARE[Auth Middleware]
|
||||
VALIDATION[Input Validation]
|
||||
end
|
||||
Use subgraphs to organize these layers clearly. Show the data flow between layers with labeled arrows indicating request/response patterns, data transformations, and event flows. Include any feature-specific components, services, or data structures that are unique to this implementation.
|
||||
|
||||
subgraph "Business Logic"
|
||||
SERVICES[Business Services]
|
||||
WORKFLOWS[Background Workflows]
|
||||
EVENTS[Event Handlers]
|
||||
end
|
||||
|
||||
subgraph "Data Layer"
|
||||
DATABASE[(Database)]
|
||||
CACHE[(Cache)]
|
||||
EXTERNAL[(External APIs)]
|
||||
end
|
||||
|
||||
UI --> COMPONENTS
|
||||
COMPONENTS --> STATE
|
||||
STATE --> TRPC
|
||||
TRPC --> MIDDLEWARE
|
||||
MIDDLEWARE --> VALIDATION
|
||||
VALIDATION --> SERVICES
|
||||
SERVICES --> WORKFLOWS
|
||||
WORKFLOWS --> EVENTS
|
||||
SERVICES --> DATABASE
|
||||
SERVICES --> CACHE
|
||||
WORKFLOWS --> EXTERNAL
|
||||
|
||||
style UI fill:#e1f5fe
|
||||
style COMPONENTS fill:#f3e5f5
|
||||
style TRPC fill:#e8f5e8
|
||||
style DATABASE fill:#fff3e0
|
||||
- **Technology Stack Selection**: Document choice rationale for each layer
|
||||
```
|
||||
|
||||
- **Technology Stack Selection**: Document choice rationale for each layer
|
||||
@ -107,7 +74,7 @@ Create an entity-relationship diagram using Mermaid showing the feature's data m
|
||||
|
||||
##### API Design
|
||||
|
||||
- tRPC endpoints with full specifications
|
||||
- Endpoints with full specifications
|
||||
- Request/response formats with TypeScript types
|
||||
- Authentication and authorization with Stack Auth
|
||||
- Error handling strategies and status codes
|
||||
@ -145,7 +112,6 @@ Recipe Library Page
|
||||
```
|
||||
|
||||
- **State Flow Diagram**: Component state management using Mermaid
|
||||
- Next.js App Router component hierarchy
|
||||
- Reusable component library specifications
|
||||
- State management patterns with Zustand/React Query
|
||||
- TypeScript interfaces and types
|
||||
|
||||
@ -38,12 +38,11 @@ Before using this prompt, ensure you have the complete testing workflow artifact
|
||||
2. **Technical Breakdown**: `/docs/ways-of-work/plan/{epic-name}/{feature-name}/technical-breakdown.md`
|
||||
3. **Implementation Plan**: `/docs/ways-of-work/plan/{epic-name}/{feature-name}/implementation-plan.md`
|
||||
|
||||
### Quality Standards Context
|
||||
### Related Planning Prompts
|
||||
|
||||
- **ISTQB Framework**: Test process activities, design techniques, and test types
|
||||
- **ISO 25010 Quality Model**: Quality characteristics prioritization and validation approach
|
||||
- **Risk-Based Testing**: Risk assessment and mitigation strategies from test strategy
|
||||
- **Quality Gates**: Entry/exit criteria and quality validation checkpoints
|
||||
- **Test Planning**: Use `plan-test` prompt for comprehensive test strategy, quality assurance planning, and test issue creation
|
||||
- **Architecture Planning**: Use `plan-epic-arch` prompt for system architecture and technical design
|
||||
- **Feature Planning**: Use `plan-feature-prd` prompt for detailed feature requirements and specifications
|
||||
|
||||
## Output Format
|
||||
|
||||
@ -287,311 +286,6 @@ This enabler supports:
|
||||
{Story points or effort estimate}
|
||||
```
|
||||
|
||||
##### Test Strategy Issue Template
|
||||
|
||||
```markdown
|
||||
# Test Strategy: {Feature Name}
|
||||
|
||||
## Test Strategy Overview
|
||||
|
||||
{Summary of testing approach based on ISTQB and ISO 25010}
|
||||
|
||||
## ISTQB Framework Application
|
||||
|
||||
**Test Design Techniques Used:**
|
||||
|
||||
- [ ] Equivalence Partitioning
|
||||
- [ ] Boundary Value Analysis
|
||||
- [ ] Decision Table Testing
|
||||
- [ ] State Transition Testing
|
||||
- [ ] Experience-Based Testing
|
||||
|
||||
**Test Types Coverage:**
|
||||
|
||||
- [ ] Functional Testing
|
||||
- [ ] Non-Functional Testing
|
||||
- [ ] Structural Testing
|
||||
- [ ] Change-Related Testing (Regression)
|
||||
|
||||
## ISO 25010 Quality Characteristics
|
||||
|
||||
**Priority Assessment:**
|
||||
|
||||
- [ ] Functional Suitability: {Critical/High/Medium/Low}
|
||||
- [ ] Performance Efficiency: {Critical/High/Medium/Low}
|
||||
- [ ] Compatibility: {Critical/High/Medium/Low}
|
||||
- [ ] Usability: {Critical/High/Medium/Low}
|
||||
- [ ] Reliability: {Critical/High/Medium/Low}
|
||||
- [ ] Security: {Critical/High/Medium/Low}
|
||||
- [ ] Maintainability: {Critical/High/Medium/Low}
|
||||
- [ ] Portability: {Critical/High/Medium/Low}
|
||||
|
||||
## Risk-Based Testing Priorities
|
||||
|
||||
**Critical Risk Areas:**
|
||||
|
||||
- [ ] {High impact, high probability scenario}
|
||||
- [ ] {Business critical functionality}
|
||||
|
||||
**Quality Gates:**
|
||||
|
||||
- [ ] Entry criteria defined
|
||||
- [ ] Exit criteria established
|
||||
- [ ] Quality thresholds documented
|
||||
|
||||
## Test Implementation Tasks
|
||||
|
||||
- [ ] #{test-task-1} - Unit Test Implementation
|
||||
- [ ] #{test-task-2} - Integration Test Setup
|
||||
- [ ] #{test-task-3} - E2E Playwright Tests
|
||||
- [ ] #{test-task-4} - Performance Testing
|
||||
- [ ] #{test-task-5} - Accessibility Testing
|
||||
- [ ] #{test-task-6} - Security Testing
|
||||
|
||||
## Definition of Done
|
||||
|
||||
- [ ] Test strategy documented and approved
|
||||
- [ ] Risk assessment completed
|
||||
- [ ] Quality gates defined
|
||||
- [ ] Test implementation tasks created
|
||||
- [ ] CI/CD integration planned
|
||||
|
||||
## Labels
|
||||
|
||||
`testing`, `{test-type}`, `playwright/vitest`, `{component-name}`
|
||||
|
||||
## Feature
|
||||
|
||||
#{feature-issue-number}
|
||||
|
||||
## Dependencies
|
||||
|
||||
**Blocked by**: Feature requirements and design completion
|
||||
|
||||
## Estimate
|
||||
|
||||
{Strategic planning effort: 2-3 story points}
|
||||
```
|
||||
|
||||
##### Playwright Test Implementation Issue Template
|
||||
|
||||
```markdown
|
||||
# Playwright Tests: {Story/Component Name}
|
||||
|
||||
## Test Implementation Scope
|
||||
|
||||
{Specific user story or component being tested}
|
||||
|
||||
## Story/Enabler Under Test
|
||||
|
||||
**User Story**: #{story-issue-number} - {Story title}
|
||||
**Technical Task**: #{task-issue-number} - {Task title}
|
||||
|
||||
## ISTQB Test Case Design
|
||||
|
||||
**Test Design Technique**: {Selected ISTQB technique}
|
||||
**Test Type**: {Functional/Non-Functional/Structural/Change-Related}
|
||||
|
||||
## ISO 25010 Quality Validation
|
||||
|
||||
**Primary Quality Characteristics:**
|
||||
|
||||
- [ ] {Quality characteristic 1}
|
||||
- [ ] {Quality characteristic 2}
|
||||
|
||||
## Test Cases to Implement
|
||||
|
||||
**Functional Tests:**
|
||||
|
||||
- [ ] Happy path scenarios
|
||||
- [ ] Error handling validation
|
||||
- [ ] Boundary value testing
|
||||
- [ ] Input validation testing
|
||||
|
||||
**Non-Functional Tests:**
|
||||
|
||||
- [ ] Performance testing (response time < {threshold})
|
||||
- [ ] Accessibility testing (WCAG compliance)
|
||||
- [ ] Cross-browser compatibility
|
||||
- [ ] Mobile responsiveness
|
||||
|
||||
**Quality-Specific Tests:**
|
||||
|
||||
- [ ] Security validation (authentication/authorization)
|
||||
- [ ] Usability testing (user experience flows)
|
||||
- [ ] Reliability testing (error recovery)
|
||||
|
||||
## Playwright Implementation Tasks
|
||||
|
||||
- [ ] Page Object Model development
|
||||
- [ ] Test fixture setup
|
||||
- [ ] Test data management
|
||||
- [ ] Test case implementation
|
||||
- [ ] Visual regression tests
|
||||
- [ ] CI/CD integration
|
||||
|
||||
## Test Environment Requirements
|
||||
|
||||
- [ ] Test data preparation
|
||||
- [ ] Environment configuration
|
||||
- [ ] Browser/device matrix setup
|
||||
- [ ] API mocking setup (if needed)
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] All test cases pass
|
||||
- [ ] Code coverage targets met (>80%)
|
||||
- [ ] Performance thresholds validated
|
||||
- [ ] Accessibility standards verified
|
||||
- [ ] Cross-browser compatibility confirmed
|
||||
|
||||
## Definition of Done
|
||||
|
||||
- [ ] Test implementation completed
|
||||
- [ ] Tests integrated into CI/CD pipeline
|
||||
- [ ] Test results documented
|
||||
- [ ] Quality metrics captured
|
||||
- [ ] Code review approved
|
||||
|
||||
## Labels
|
||||
|
||||
`testing`, `playwright`, `e2e`, `quality-validation`, `{story-component}`
|
||||
|
||||
## Dependencies
|
||||
|
||||
**Blocked by**:
|
||||
|
||||
- #{story-issue-number} - Story implementation
|
||||
- #{test-strategy-issue} - Test strategy approval
|
||||
|
||||
## Test Strategy Reference
|
||||
|
||||
**Strategy Document**: `/docs/ways-of-work/plan/{epic-name}/{feature-name}/test-strategy.md`
|
||||
|
||||
## Estimate
|
||||
|
||||
{Test implementation effort: 2-5 story points}
|
||||
```
|
||||
|
||||
##### Quality Assurance Issue Template
|
||||
|
||||
```markdown
|
||||
# Quality Assurance: {Feature Name}
|
||||
|
||||
## Quality Validation Scope
|
||||
|
||||
{Overall quality validation for feature/epic}
|
||||
|
||||
## ISO 25010 Quality Assessment
|
||||
|
||||
**Quality Characteristics Validation:**
|
||||
|
||||
**Functional Suitability:**
|
||||
|
||||
- [ ] Functional completeness verified
|
||||
- [ ] Functional correctness validated
|
||||
- [ ] Functional appropriateness confirmed
|
||||
|
||||
**Performance Efficiency:**
|
||||
|
||||
- [ ] Time behavior validated (response times)
|
||||
- [ ] Resource utilization measured
|
||||
- [ ] Capacity limits tested
|
||||
|
||||
**Usability:**
|
||||
|
||||
- [ ] User interface aesthetics reviewed
|
||||
- [ ] Accessibility compliance verified
|
||||
- [ ] Learnability assessed
|
||||
- [ ] Operability validated
|
||||
|
||||
**Security:**
|
||||
|
||||
- [ ] Confidentiality measures tested
|
||||
- [ ] Integrity verification completed
|
||||
- [ ] Authentication/authorization validated
|
||||
- [ ] Input validation security tested
|
||||
|
||||
**Reliability:**
|
||||
|
||||
- [ ] Fault tolerance tested
|
||||
- [ ] Recovery procedures validated
|
||||
- [ ] System availability measured
|
||||
|
||||
**Compatibility:**
|
||||
|
||||
- [ ] Browser compatibility verified
|
||||
- [ ] Device compatibility tested
|
||||
- [ ] Integration compatibility confirmed
|
||||
|
||||
**Maintainability:**
|
||||
|
||||
- [ ] Code quality assessed
|
||||
- [ ] Modularity verified
|
||||
- [ ] Testability confirmed
|
||||
|
||||
**Portability:**
|
||||
|
||||
- [ ] Environment adaptability tested
|
||||
- [ ] Installation procedures verified
|
||||
|
||||
## Quality Gates Validation
|
||||
|
||||
**Entry Criteria:**
|
||||
|
||||
- [ ] All implementation tasks completed
|
||||
- [ ] Unit tests passing
|
||||
- [ ] Code review approved
|
||||
|
||||
**Exit Criteria:**
|
||||
|
||||
- [ ] All test types completed with >95% pass rate
|
||||
- [ ] No critical/high severity defects
|
||||
- [ ] Performance benchmarks met
|
||||
- [ ] Security validation passed
|
||||
|
||||
## Quality Metrics
|
||||
|
||||
- [ ] Test coverage: {target}%
|
||||
- [ ] Defect density: <{threshold} defects/KLOC
|
||||
- [ ] Performance: Response time <{threshold}ms
|
||||
- [ ] Accessibility: WCAG {level} compliance
|
||||
- [ ] Security: Zero critical vulnerabilities
|
||||
|
||||
## Quality Validation Tasks
|
||||
|
||||
- [ ] #{qa-task-1} - Functional testing validation
|
||||
- [ ] #{qa-task-2} - Non-functional testing review
|
||||
- [ ] #{qa-task-3} - Security assessment
|
||||
- [ ] #{qa-task-4} - Performance validation
|
||||
- [ ] #{qa-task-5} - Accessibility audit
|
||||
- [ ] #{qa-task-6} - Quality metrics analysis
|
||||
|
||||
## Definition of Done
|
||||
|
||||
- [ ] All quality characteristics validated
|
||||
- [ ] Quality gates criteria met
|
||||
- [ ] Quality metrics documented
|
||||
- [ ] Risk assessment updated
|
||||
- [ ] Quality sign-off obtained
|
||||
|
||||
## Labels
|
||||
|
||||
`quality-assurance`, `iso25010`, `quality-gates`, `sign-off`
|
||||
|
||||
## Dependencies
|
||||
|
||||
**Blocked by**: All feature implementation and testing tasks
|
||||
|
||||
## Feature
|
||||
|
||||
#{feature-issue-number}
|
||||
|
||||
## Estimate
|
||||
|
||||
{Quality validation effort: 3-5 story points}
|
||||
```
|
||||
|
||||
#### 4. Priority and Value Matrix
|
||||
|
||||
| Priority | Value | Criteria | Labels |
|
||||
@ -786,28 +480,6 @@ jobs:
|
||||
- [ ] **Dependencies mapped** between stories and enablers
|
||||
- [ ] **Acceptance criteria detailed** with testable requirements
|
||||
|
||||
#### Test Level Issues documented in `/docs/ways-of-work/plan/{epic-name}/{feature-name}/issues-checklist.md`
|
||||
|
||||
- [ ] **Test issues created** for each story/enabler
|
||||
- [ ] **Test types identified**: unit, integration, E2E, accessibility
|
||||
- [ ] **Test dependencies documented** (blocked by implementation)
|
||||
- [ ] **Test coverage targets set** (>80% code coverage)
|
||||
|
||||
#### Task Level Breakdown documented in `/docs/ways-of-work/plan/{epic-name}/{feature-name}/issues-checklist.md`
|
||||
|
||||
- [ ] **Implementation tasks created** for each story/enabler
|
||||
- [ ] **Task estimates provided** (hours or sub-story points)
|
||||
- [ ] **Task dependencies identified** and sequenced
|
||||
- [ ] **Task assignments made** based on team skills and capacity
|
||||
|
||||
#### Quality Assurance documented in `/docs/ways-of-work/plan/{epic-name}/{feature-name}/issues-checklist.md`
|
||||
|
||||
- [ ] **All issues follow templates** with required fields completed
|
||||
- [ ] **Labeling consistency maintained** across all work items
|
||||
- [ ] **Priority and value assigned** using defined criteria
|
||||
- [ ] **Dependencies validated** to avoid circular relationships
|
||||
- [ ] **Estimation accuracy reviewed** by technical leads
|
||||
|
||||
## Success Metrics
|
||||
|
||||
### Project Management KPIs
|
||||
@ -826,12 +498,12 @@ jobs:
|
||||
- **Documentation Completeness**: 100% of issues have required template fields
|
||||
- **Cross-Team Collaboration**: <2 business days for external dependency resolution
|
||||
|
||||
### Quality Metrics
|
||||
### Project Delivery Metrics
|
||||
|
||||
- **Definition of Done Compliance**: 100% of completed stories meet DoD criteria
|
||||
- **Acceptance Criteria Coverage**: 100% of acceptance criteria tested and validated
|
||||
- **Test Coverage Achievement**: >80% code coverage for all implemented features
|
||||
- **Performance Target Achievement**: 100% of performance requirements met
|
||||
- **User Acceptance Success**: >90% first-time acceptance rate for completed features
|
||||
- **Acceptance Criteria Coverage**: 100% of acceptance criteria validated
|
||||
- **Sprint Goal Achievement**: >90% of sprint goals successfully delivered
|
||||
- **Stakeholder Satisfaction**: >90% stakeholder approval for completed features
|
||||
- **Planning Accuracy**: <10% variance between estimated and actual delivery time
|
||||
|
||||
This comprehensive GitHub project management approach ensures complete traceability from epic-level planning down to individual implementation tasks, with automated tracking and clear accountability for all team members.
|
||||
|
||||
@ -1,288 +0,0 @@
|
||||
---
|
||||
mode: 'guide'
|
||||
description: 'Implementation guide for using Epoch role-based development prompts to build features from planning artifacts.'
|
||||
---
|
||||
|
||||
# Epoch Role-Based Implementation Guide
|
||||
|
||||
## Overview
|
||||
|
||||
This guide explains how to use the Epoch role-specific development prompts to transform planning artifacts (PRDs, implementation plans, GitHub issues) into working software. Each role prompt is designed to take planning outputs and create high-quality implementations with appropriate MCP tool integration.
|
||||
|
||||
## Implementation Workflow
|
||||
|
||||
### 1. Planning Phase (Already Complete)
|
||||
|
||||
Using the planning prompts in `/docs/ways-of-work/plan/`:
|
||||
|
||||
- ✅ Epic created: [#28 - Pantry Epic](https://github.com/craigbekker/epoch/issues/28)
|
||||
- ✅ Feature created: [#29 - Recipe Library Management](https://github.com/craigbekker/epoch/issues/29)
|
||||
- ✅ Technical enablers created: Database Schema (#30), tRPC API (#31), UI Components (#32), n8n Workflow (#33)
|
||||
- ✅ User story created: [#34 - Recipe Grid View](https://github.com/craigbekker/epoch/issues/34)
|
||||
|
||||
### 2. Implementation Phase (Using Role Prompts)
|
||||
|
||||
#### Phase 1: Foundation Infrastructure
|
||||
|
||||
**Database Engineer** → Use `/prompts/roles/database-engineer.prompt.md`
|
||||
|
||||
- **Input**: Issue #30 - Database Schema & Migrations
|
||||
- **Output**: PostgreSQL schema, Drizzle migrations, indexes
|
||||
- **MCP Tools**: Database MCP for query testing and validation
|
||||
- **Deliverables**:
|
||||
- `apps/web/drizzle/schema/recipes.ts`
|
||||
- Migration files in `apps/web/drizzle/`
|
||||
- Performance indexes and constraints
|
||||
|
||||
**Backend Developer** → Use `/prompts/roles/backend-developer.prompt.md`
|
||||
|
||||
- **Input**: Issue #31 - tRPC Recipe API Router
|
||||
- **Dependencies**: Database schema (#30)
|
||||
- **Output**: Type-safe tRPC endpoints
|
||||
- **MCP Tools**: Database MCP for testing, GitHub MCP for PR management
|
||||
- **Deliverables**:
|
||||
- `apps/web/src/server/api/routers/recipe.ts`
|
||||
- Input validation schemas
|
||||
- Error handling and authentication
|
||||
|
||||
#### Phase 2: User Interface Foundation
|
||||
|
||||
**Frontend Developer** → Use `/prompts/roles/frontend-developer.prompt.md`
|
||||
|
||||
- **Input**: Issue #32 - UI Foundation Components
|
||||
- **Output**: Reusable React components
|
||||
- **MCP Tools**: Playwright MCP for accessibility and interaction testing
|
||||
- **Deliverables**:
|
||||
- `packages/ui/components/recipes/RecipeCard.tsx`
|
||||
- `packages/ui/components/recipes/RecipeGrid.tsx`
|
||||
- Storybook stories and component tests
|
||||
|
||||
#### Phase 3: Feature Implementation
|
||||
|
||||
**Frontend Developer** → Use `/prompts/roles/frontend-developer.prompt.md`
|
||||
|
||||
- **Input**: Issue #34 - Recipe Grid View User Story
|
||||
- **Dependencies**: Database (#30), API (#31), Components (#32)
|
||||
- **Output**: Complete recipe library page
|
||||
- **MCP Tools**: Playwright MCP for comprehensive E2E testing
|
||||
- **Deliverables**:
|
||||
- `apps/web/src/app/recipes/page.tsx`
|
||||
- Complete responsive recipe grid
|
||||
- Loading states, error handling, empty states
|
||||
|
||||
#### Phase 4: Intelligent Automation
|
||||
|
||||
**Automation Engineer** → Use `/prompts/roles/automation-engineer.prompt.md`
|
||||
|
||||
- **Input**: Issue #33 - n8n Recipe Import Workflow
|
||||
- **Output**: Intelligent recipe import system
|
||||
- **MCP Tools**: GitHub MCP for webhook setup, Memory MCP for pattern storage
|
||||
- **Deliverables**:
|
||||
- n8n workflow for URL scraping
|
||||
- AI-powered recipe extraction
|
||||
- Vector embeddings for search
|
||||
|
||||
**AI Context Engineer** → Use `/prompts/roles/ai-context-engineer.prompt.md`
|
||||
|
||||
- **Input**: AI requirements from automation workflows
|
||||
- **Output**: Sophisticated prompt systems and context management
|
||||
- **MCP Tools**: Memory MCP for context storage, Sequential Thinking MCP for complex reasoning
|
||||
- **Deliverables**:
|
||||
- Recipe extraction prompts
|
||||
- Context management systems
|
||||
- Personalization engines
|
||||
|
||||
## Role Integration Patterns
|
||||
|
||||
### Cross-Role Dependencies
|
||||
|
||||
```mermaid
|
||||
graph TD
|
||||
A[Database Engineer] --> B[Backend Developer]
|
||||
A --> C[Frontend Developer]
|
||||
B --> C
|
||||
B --> D[Automation Engineer]
|
||||
C --> E[AI Context Engineer]
|
||||
D --> E
|
||||
|
||||
F[Planning Artifacts] --> A
|
||||
F --> B
|
||||
F --> C
|
||||
F --> D
|
||||
F --> E
|
||||
```
|
||||
|
||||
### Handoff Protocols
|
||||
|
||||
#### Database → Backend
|
||||
|
||||
- **Database Engineer** provides:
|
||||
|
||||
- Complete schema definitions
|
||||
- Migration scripts
|
||||
- Performance benchmarks
|
||||
- Query optimization recommendations
|
||||
|
||||
- **Backend Developer** receives:
|
||||
- Type-safe database access patterns
|
||||
- Optimized query examples
|
||||
- Performance constraints
|
||||
- Data access patterns
|
||||
|
||||
#### Backend → Frontend
|
||||
|
||||
- **Backend Developer** provides:
|
||||
|
||||
- Complete tRPC type definitions
|
||||
- API documentation with examples
|
||||
- Error handling patterns
|
||||
- Authentication requirements
|
||||
|
||||
- **Frontend Developer** receives:
|
||||
- End-to-end type safety
|
||||
- Clear API contracts
|
||||
- Error handling guidance
|
||||
- Performance expectations
|
||||
|
||||
#### Frontend → Automation
|
||||
|
||||
- **Frontend Developer** provides:
|
||||
|
||||
- User interaction patterns
|
||||
- Data requirements
|
||||
- Performance constraints
|
||||
- Integration points
|
||||
|
||||
- **Automation Engineer** receives:
|
||||
- User workflow understanding
|
||||
- Integration requirements
|
||||
- Performance targets
|
||||
- Data transformation needs
|
||||
|
||||
## MCP Tool Integration Strategy
|
||||
|
||||
### By Role
|
||||
|
||||
#### Database Engineer
|
||||
|
||||
- **Primary**: Database MCP for query execution and schema validation
|
||||
- **Secondary**: GitHub MCP for migration deployment coordination
|
||||
- **Usage Pattern**: Always validate queries and performance with Database MCP
|
||||
|
||||
#### Backend Developer
|
||||
|
||||
- **Primary**: Database MCP for testing data operations
|
||||
- **Secondary**: GitHub MCP for PR management and issue linking
|
||||
- **Usage Pattern**: Test all database operations and API endpoints
|
||||
|
||||
#### Frontend Developer
|
||||
|
||||
- **Primary**: Playwright MCP for comprehensive UI testing
|
||||
- **Secondary**: GitHub MCP for PR creation with screenshots
|
||||
- **Usage Pattern**: Always validate accessibility and user interactions
|
||||
|
||||
#### Automation Engineer
|
||||
|
||||
- **Primary**: GitHub MCP for webhook integration
|
||||
- **Secondary**: Memory MCP for storing workflow patterns
|
||||
- **Usage Pattern**: Validate all webhook endpoints and data flows
|
||||
|
||||
#### AI Context Engineer
|
||||
|
||||
- **Primary**: Memory MCP for context storage and retrieval
|
||||
- **Secondary**: Sequential Thinking MCP for complex reasoning
|
||||
- **Usage Pattern**: Store and retrieve context patterns for optimization
|
||||
|
||||
## Quality Standards
|
||||
|
||||
### Each Role Must Deliver
|
||||
|
||||
#### Database Engineer
|
||||
|
||||
- [ ] Schema passes all constraint tests
|
||||
- [ ] Migrations are reversible and tested
|
||||
- [ ] Query performance meets <100ms targets
|
||||
- [ ] Database MCP validation completed
|
||||
- [ ] Household data isolation verified
|
||||
|
||||
#### Backend Developer
|
||||
|
||||
- [ ] All endpoints are type-safe and validated
|
||||
- [ ] Authentication and authorization implemented
|
||||
- [ ] Error handling covers all edge cases
|
||||
- [ ] Performance targets met (<500ms API responses)
|
||||
- [ ] Database MCP query testing completed
|
||||
|
||||
#### Frontend Developer
|
||||
|
||||
- [ ] Components pass accessibility testing
|
||||
- [ ] Responsive design works on all devices
|
||||
- [ ] Playwright MCP validation completed
|
||||
- [ ] Performance targets met (90+ Lighthouse score)
|
||||
- [ ] User interactions are smooth and intuitive
|
||||
|
||||
#### Automation Engineer
|
||||
|
||||
- [ ] Workflows handle errors gracefully
|
||||
- [ ] Integration points are thoroughly tested
|
||||
- [ ] Performance optimization implemented
|
||||
- [ ] Monitoring and observability included
|
||||
- [ ] GitHub MCP webhook validation completed
|
||||
|
||||
#### AI Context Engineer
|
||||
|
||||
- [ ] Prompts are robust and reliable
|
||||
- [ ] Context management is efficient
|
||||
- [ ] Privacy requirements are met
|
||||
- [ ] Error handling and fallbacks implemented
|
||||
- [ ] Memory MCP context validation completed
|
||||
|
||||
## Implementation Commands
|
||||
|
||||
### Starting Implementation
|
||||
|
||||
For each role, use this pattern:
|
||||
|
||||
```bash
|
||||
# Example: Backend Developer implementing tRPC API
|
||||
copilot prompt --file=".github/prompts/roles/backend-developer.prompt.md" \
|
||||
--context="Issue #31: tRPC Recipe API Router" \
|
||||
--context="Database schema from #30" \
|
||||
--context="Feature requirements from #29"
|
||||
```
|
||||
|
||||
### MCP Validation Commands
|
||||
|
||||
Each role should validate their work:
|
||||
|
||||
```bash
|
||||
# Database Engineer
|
||||
dbcode-execute-query --query="SELECT * FROM recipes LIMIT 1"
|
||||
|
||||
# Frontend Developer
|
||||
mcp_playwright_browser_snapshot
|
||||
mcp_playwright_browser_take_screenshot
|
||||
|
||||
# Automation Engineer
|
||||
mcp_github_create_pull_request --title="Recipe Import Workflow"
|
||||
```
|
||||
|
||||
## Success Metrics
|
||||
|
||||
### Overall Feature Success
|
||||
|
||||
- [ ] All user acceptance criteria met
|
||||
- [ ] Performance benchmarks achieved
|
||||
- [ ] Security requirements validated
|
||||
- [ ] Accessibility standards met
|
||||
- [ ] Cross-browser compatibility confirmed
|
||||
|
||||
### Role-Specific Success
|
||||
|
||||
- [ ] Database: Query performance and data integrity
|
||||
- [ ] Backend: API performance and type safety
|
||||
- [ ] Frontend: User experience and accessibility
|
||||
- [ ] Automation: Workflow reliability and intelligence
|
||||
- [ ] AI Context: Prompt effectiveness and context retention
|
||||
|
||||
This implementation guide ensures that each role delivers high-quality work that integrates seamlessly with other roles, leveraging the appropriate MCP tools for validation and testing throughout the development process.
|
||||
365
collections/plan/prompts/plan-test.prompt.md
Normal file
365
collections/plan/prompts/plan-test.prompt.md
Normal file
@ -0,0 +1,365 @@
|
||||
---
|
||||
mode: 'agent'
|
||||
description: 'Test Planning and Quality Assurance prompt that generates comprehensive test strategies, task breakdowns, and quality validation plans for GitHub projects.'
|
||||
---
|
||||
|
||||
# Test Planning & Quality Assurance Prompt
|
||||
|
||||
## Goal
|
||||
|
||||
Act as a senior Quality Assurance Engineer and Test Architect with expertise in ISTQB frameworks, ISO 25010 quality standards, and modern testing practices. Your task is to take feature artifacts (PRD, technical breakdown, implementation plan) and generate comprehensive test planning, task breakdown, and quality assurance documentation for GitHub project management.
|
||||
|
||||
## Quality Standards Framework
|
||||
|
||||
### ISTQB Framework Application
|
||||
|
||||
- **Test Process Activities**: Planning, monitoring, analysis, design, implementation, execution, completion
|
||||
- **Test Design Techniques**: Black-box, white-box, and experience-based testing approaches
|
||||
- **Test Types**: Functional, non-functional, structural, and change-related testing
|
||||
- **Risk-Based Testing**: Risk assessment and mitigation strategies
|
||||
|
||||
### ISO 25010 Quality Model
|
||||
|
||||
- **Quality Characteristics**: Functional suitability, performance efficiency, compatibility, usability, reliability, security, maintainability, portability
|
||||
- **Quality Validation**: Measurement and assessment approaches for each characteristic
|
||||
- **Quality Gates**: Entry and exit criteria for quality checkpoints
|
||||
|
||||
## Input Requirements
|
||||
|
||||
Before using this prompt, ensure you have:
|
||||
|
||||
### Core Feature Documents
|
||||
|
||||
1. **Feature PRD**: `/docs/ways-of-work/plan/{epic-name}/{feature-name}.md`
|
||||
2. **Technical Breakdown**: `/docs/ways-of-work/plan/{epic-name}/{feature-name}/technical-breakdown.md`
|
||||
3. **Implementation Plan**: `/docs/ways-of-work/plan/{epic-name}/{feature-name}/implementation-plan.md`
|
||||
4. **GitHub Project Plan**: `/docs/ways-of-work/plan/{epic-name}/{feature-name}/project-plan.md`
|
||||
|
||||
## Output Format
|
||||
|
||||
Create comprehensive test planning documentation:
|
||||
|
||||
1. **Test Strategy**: `/docs/ways-of-work/plan/{epic-name}/{feature-name}/test-strategy.md`
|
||||
2. **Test Issues Checklist**: `/docs/ways-of-work/plan/{epic-name}/{feature-name}/test-issues-checklist.md`
|
||||
3. **Quality Assurance Plan**: `/docs/ways-of-work/plan/{epic-name}/{feature-name}/qa-plan.md`
|
||||
|
||||
### Test Strategy Structure
|
||||
|
||||
#### 1. Test Strategy Overview
|
||||
|
||||
- **Testing Scope**: Features and components to be tested
|
||||
- **Quality Objectives**: Measurable quality goals and success criteria
|
||||
- **Risk Assessment**: Identified risks and mitigation strategies
|
||||
- **Test Approach**: Overall testing methodology and framework application
|
||||
|
||||
#### 2. ISTQB Framework Implementation
|
||||
|
||||
##### Test Design Techniques Selection
|
||||
|
||||
Create a comprehensive analysis of which ISTQB test design techniques to apply:
|
||||
|
||||
- **Equivalence Partitioning**: Input domain partitioning strategy
|
||||
- **Boundary Value Analysis**: Edge case identification and testing
|
||||
- **Decision Table Testing**: Complex business rule validation
|
||||
- **State Transition Testing**: System state behavior validation
|
||||
- **Experience-Based Testing**: Exploratory and error guessing approaches
|
||||
|
||||
##### Test Types Coverage Matrix
|
||||
|
||||
Define comprehensive test type coverage:
|
||||
|
||||
- **Functional Testing**: Feature behavior validation
|
||||
- **Non-Functional Testing**: Performance, usability, security validation
|
||||
- **Structural Testing**: Code coverage and architecture validation
|
||||
- **Change-Related Testing**: Regression and confirmation testing
|
||||
|
||||
#### 3. ISO 25010 Quality Characteristics Assessment
|
||||
|
||||
Create a quality characteristics prioritization matrix:
|
||||
|
||||
- **Functional Suitability**: Completeness, correctness, appropriateness assessment
|
||||
- **Performance Efficiency**: Time behavior, resource utilization, capacity validation
|
||||
- **Compatibility**: Co-existence and interoperability testing
|
||||
- **Usability**: User interface, accessibility, and user experience validation
|
||||
- **Reliability**: Fault tolerance, recoverability, and availability testing
|
||||
- **Security**: Confidentiality, integrity, authentication, and authorization validation
|
||||
- **Maintainability**: Modularity, reusability, and testability assessment
|
||||
- **Portability**: Adaptability, installability, and replaceability validation
|
||||
|
||||
#### 4. Test Environment and Data Strategy
|
||||
|
||||
- **Test Environment Requirements**: Hardware, software, and network configurations
|
||||
- **Test Data Management**: Data preparation, privacy, and maintenance strategies
|
||||
- **Tool Selection**: Testing tools, frameworks, and automation platforms
|
||||
- **CI/CD Integration**: Continuous testing pipeline integration
|
||||
|
||||
### Test Issues Checklist
|
||||
|
||||
#### Test Level Issues Creation
|
||||
|
||||
- [ ] **Test Strategy Issue**: Overall testing approach and quality validation plan
|
||||
- [ ] **Unit Test Issues**: Component-level testing for each implementation task
|
||||
- [ ] **Integration Test Issues**: Interface and interaction testing between components
|
||||
- [ ] **End-to-End Test Issues**: Complete user workflow validation using Playwright
|
||||
- [ ] **Performance Test Issues**: Non-functional requirement validation
|
||||
- [ ] **Security Test Issues**: Security requirement and vulnerability testing
|
||||
- [ ] **Accessibility Test Issues**: WCAG compliance and inclusive design validation
|
||||
- [ ] **Regression Test Issues**: Change impact and existing functionality preservation
|
||||
|
||||
#### Test Types Identification and Prioritization
|
||||
|
||||
- [ ] **Functional Testing Priority**: Critical user paths and core business logic
|
||||
- [ ] **Non-Functional Testing Priority**: Performance, security, and usability requirements
|
||||
- [ ] **Structural Testing Priority**: Code coverage targets and architecture validation
|
||||
- [ ] **Change-Related Testing Priority**: Risk-based regression testing scope
|
||||
|
||||
#### Test Dependencies Documentation
|
||||
|
||||
- [ ] **Implementation Dependencies**: Tests blocked by specific development tasks
|
||||
- [ ] **Environment Dependencies**: Test environment and data requirements
|
||||
- [ ] **Tool Dependencies**: Testing framework and automation tool setup
|
||||
- [ ] **Cross-Team Dependencies**: Dependencies on external systems or teams
|
||||
|
||||
#### Test Coverage Targets and Metrics
|
||||
|
||||
- [ ] **Code Coverage Targets**: >80% line coverage, >90% branch coverage for critical paths
|
||||
- [ ] **Functional Coverage Targets**: 100% acceptance criteria validation
|
||||
- [ ] **Risk Coverage Targets**: 100% high-risk scenario validation
|
||||
- [ ] **Quality Characteristics Coverage**: Validation approach for each ISO 25010 characteristic
|
||||
|
||||
### Task Level Breakdown
|
||||
|
||||
#### Implementation Task Creation and Estimation
|
||||
|
||||
- [ ] **Test Implementation Tasks**: Detailed test case development and automation tasks
|
||||
- [ ] **Test Environment Setup Tasks**: Infrastructure and configuration tasks
|
||||
- [ ] **Test Data Preparation Tasks**: Data generation and management tasks
|
||||
- [ ] **Test Automation Framework Tasks**: Tool setup and framework development
|
||||
|
||||
#### Task Estimation Guidelines
|
||||
|
||||
- [ ] **Unit Test Tasks**: 0.5-1 story point per component
|
||||
- [ ] **Integration Test Tasks**: 1-2 story points per interface
|
||||
- [ ] **E2E Test Tasks**: 2-3 story points per user workflow
|
||||
- [ ] **Performance Test Tasks**: 3-5 story points per performance requirement
|
||||
- [ ] **Security Test Tasks**: 2-4 story points per security requirement
|
||||
|
||||
#### Task Dependencies and Sequencing
|
||||
|
||||
- [ ] **Sequential Dependencies**: Tests that must be implemented in specific order
|
||||
- [ ] **Parallel Development**: Tests that can be developed simultaneously
|
||||
- [ ] **Critical Path Identification**: Testing tasks on the critical path to delivery
|
||||
- [ ] **Resource Allocation**: Task assignment based on team skills and capacity
|
||||
|
||||
#### Task Assignment Strategy
|
||||
|
||||
- [ ] **Skill-Based Assignment**: Matching tasks to team member expertise
|
||||
- [ ] **Capacity Planning**: Balancing workload across team members
|
||||
- [ ] **Knowledge Transfer**: Pairing junior and senior team members
|
||||
- [ ] **Cross-Training Opportunities**: Skill development through task assignment
|
||||
|
||||
### Quality Assurance Plan
|
||||
|
||||
#### Quality Gates and Checkpoints
|
||||
|
||||
Create comprehensive quality validation checkpoints:
|
||||
|
||||
- **Entry Criteria**: Requirements for beginning each testing phase
|
||||
- **Exit Criteria**: Quality standards required for phase completion
|
||||
- **Quality Metrics**: Measurable indicators of quality achievement
|
||||
- **Escalation Procedures**: Process for addressing quality failures
|
||||
|
||||
#### GitHub Issue Quality Standards
|
||||
|
||||
- [ ] **Template Compliance**: All test issues follow standardized templates
|
||||
- [ ] **Required Field Completion**: Mandatory fields populated with accurate information
|
||||
- [ ] **Label Consistency**: Standardized labeling across all test work items
|
||||
- [ ] **Priority Assignment**: Risk-based priority assignment using defined criteria
|
||||
- [ ] **Value Assessment**: Business value and quality impact assessment
|
||||
|
||||
#### Labeling and Prioritization Standards
|
||||
|
||||
- [ ] **Test Type Labels**: `unit-test`, `integration-test`, `e2e-test`, `performance-test`, `security-test`
|
||||
- [ ] **Quality Labels**: `quality-gate`, `iso25010`, `istqb-technique`, `risk-based`
|
||||
- [ ] **Priority Labels**: `test-critical`, `test-high`, `test-medium`, `test-low`
|
||||
- [ ] **Component Labels**: `frontend-test`, `backend-test`, `api-test`, `database-test`
|
||||
|
||||
#### Dependency Validation and Management
|
||||
|
||||
- [ ] **Circular Dependency Detection**: Validation to prevent blocking relationships
|
||||
- [ ] **Critical Path Analysis**: Identification of testing dependencies on delivery timeline
|
||||
- [ ] **Risk Assessment**: Impact analysis of dependency delays on quality validation
|
||||
- [ ] **Mitigation Strategies**: Alternative approaches for blocked testing activities
|
||||
|
||||
#### Estimation Accuracy and Review
|
||||
|
||||
- [ ] **Historical Data Analysis**: Using past project data for estimation accuracy
|
||||
- [ ] **Technical Lead Review**: Expert validation of test complexity estimates
|
||||
- [ ] **Risk Buffer Allocation**: Additional time allocation for high-uncertainty tasks
|
||||
- [ ] **Estimate Refinement**: Iterative improvement of estimation accuracy
|
||||
|
||||
## GitHub Issue Templates for Testing
|
||||
|
||||
### Test Strategy Issue Template
|
||||
|
||||
```markdown
|
||||
# Test Strategy: {Feature Name}
|
||||
|
||||
## Test Strategy Overview
|
||||
|
||||
{Summary of testing approach based on ISTQB and ISO 25010}
|
||||
|
||||
## ISTQB Framework Application
|
||||
|
||||
**Test Design Techniques Used:**
|
||||
- [ ] Equivalence Partitioning
|
||||
- [ ] Boundary Value Analysis
|
||||
- [ ] Decision Table Testing
|
||||
- [ ] State Transition Testing
|
||||
- [ ] Experience-Based Testing
|
||||
|
||||
**Test Types Coverage:**
|
||||
- [ ] Functional Testing
|
||||
- [ ] Non-Functional Testing
|
||||
- [ ] Structural Testing
|
||||
- [ ] Change-Related Testing (Regression)
|
||||
|
||||
## ISO 25010 Quality Characteristics
|
||||
|
||||
**Priority Assessment:**
|
||||
- [ ] Functional Suitability: {Critical/High/Medium/Low}
|
||||
- [ ] Performance Efficiency: {Critical/High/Medium/Low}
|
||||
- [ ] Compatibility: {Critical/High/Medium/Low}
|
||||
- [ ] Usability: {Critical/High/Medium/Low}
|
||||
- [ ] Reliability: {Critical/High/Medium/Low}
|
||||
- [ ] Security: {Critical/High/Medium/Low}
|
||||
- [ ] Maintainability: {Critical/High/Medium/Low}
|
||||
- [ ] Portability: {Critical/High/Medium/Low}
|
||||
|
||||
## Quality Gates
|
||||
- [ ] Entry criteria defined
|
||||
- [ ] Exit criteria established
|
||||
- [ ] Quality thresholds documented
|
||||
|
||||
## Labels
|
||||
`test-strategy`, `istqb`, `iso25010`, `quality-gates`
|
||||
|
||||
## Estimate
|
||||
{Strategic planning effort: 2-3 story points}
|
||||
```
|
||||
|
||||
### Playwright Test Implementation Issue Template
|
||||
|
||||
```markdown
|
||||
# Playwright Tests: {Story/Component Name}
|
||||
|
||||
## Test Implementation Scope
|
||||
{Specific user story or component being tested}
|
||||
|
||||
## ISTQB Test Case Design
|
||||
**Test Design Technique**: {Selected ISTQB technique}
|
||||
**Test Type**: {Functional/Non-Functional/Structural/Change-Related}
|
||||
|
||||
## Test Cases to Implement
|
||||
**Functional Tests:**
|
||||
- [ ] Happy path scenarios
|
||||
- [ ] Error handling validation
|
||||
- [ ] Boundary value testing
|
||||
- [ ] Input validation testing
|
||||
|
||||
**Non-Functional Tests:**
|
||||
- [ ] Performance testing (response time < {threshold})
|
||||
- [ ] Accessibility testing (WCAG compliance)
|
||||
- [ ] Cross-browser compatibility
|
||||
- [ ] Mobile responsiveness
|
||||
|
||||
## Playwright Implementation Tasks
|
||||
- [ ] Page Object Model development
|
||||
- [ ] Test fixture setup
|
||||
- [ ] Test data management
|
||||
- [ ] Test case implementation
|
||||
- [ ] Visual regression tests
|
||||
- [ ] CI/CD integration
|
||||
|
||||
## Acceptance Criteria
|
||||
- [ ] All test cases pass
|
||||
- [ ] Code coverage targets met (>80%)
|
||||
- [ ] Performance thresholds validated
|
||||
- [ ] Accessibility standards verified
|
||||
|
||||
## Labels
|
||||
`playwright`, `e2e-test`, `quality-validation`
|
||||
|
||||
## Estimate
|
||||
{Test implementation effort: 2-5 story points}
|
||||
```
|
||||
|
||||
### Quality Assurance Issue Template
|
||||
|
||||
```markdown
|
||||
# Quality Assurance: {Feature Name}
|
||||
|
||||
## Quality Validation Scope
|
||||
{Overall quality validation for feature/epic}
|
||||
|
||||
## ISO 25010 Quality Assessment
|
||||
**Quality Characteristics Validation:**
|
||||
- [ ] Functional Suitability: Completeness, correctness, appropriateness
|
||||
- [ ] Performance Efficiency: Time behavior, resource utilization, capacity
|
||||
- [ ] Usability: Interface aesthetics, accessibility, learnability, operability
|
||||
- [ ] Security: Confidentiality, integrity, authentication, authorization
|
||||
- [ ] Reliability: Fault tolerance, recovery, availability
|
||||
- [ ] Compatibility: Browser, device, integration compatibility
|
||||
- [ ] Maintainability: Code quality, modularity, testability
|
||||
- [ ] Portability: Environment adaptability, installation procedures
|
||||
|
||||
## Quality Gates Validation
|
||||
**Entry Criteria:**
|
||||
- [ ] All implementation tasks completed
|
||||
- [ ] Unit tests passing
|
||||
- [ ] Code review approved
|
||||
|
||||
**Exit Criteria:**
|
||||
- [ ] All test types completed with >95% pass rate
|
||||
- [ ] No critical/high severity defects
|
||||
- [ ] Performance benchmarks met
|
||||
- [ ] Security validation passed
|
||||
|
||||
## Quality Metrics
|
||||
- [ ] Test coverage: {target}%
|
||||
- [ ] Defect density: <{threshold} defects/KLOC
|
||||
- [ ] Performance: Response time <{threshold}ms
|
||||
- [ ] Accessibility: WCAG {level} compliance
|
||||
- [ ] Security: Zero critical vulnerabilities
|
||||
|
||||
## Labels
|
||||
`quality-assurance`, `iso25010`, `quality-gates`
|
||||
|
||||
## Estimate
|
||||
{Quality validation effort: 3-5 story points}
|
||||
```
|
||||
|
||||
## Success Metrics
|
||||
|
||||
### Test Coverage Metrics
|
||||
|
||||
- **Code Coverage**: >80% line coverage, >90% branch coverage for critical paths
|
||||
- **Functional Coverage**: 100% acceptance criteria validation
|
||||
- **Risk Coverage**: 100% high-risk scenario testing
|
||||
- **Quality Characteristics Coverage**: Validation for all applicable ISO 25010 characteristics
|
||||
|
||||
### Quality Validation Metrics
|
||||
|
||||
- **Defect Detection Rate**: >95% of defects found before production
|
||||
- **Test Execution Efficiency**: >90% test automation coverage
|
||||
- **Quality Gate Compliance**: 100% quality gates passed before release
|
||||
- **Risk Mitigation**: 100% identified risks addressed with mitigation strategies
|
||||
|
||||
### Process Efficiency Metrics
|
||||
|
||||
- **Test Planning Time**: <2 hours to create comprehensive test strategy
|
||||
- **Test Implementation Speed**: <1 day per story point of test development
|
||||
- **Quality Feedback Time**: <2 hours from test completion to quality assessment
|
||||
- **Documentation Completeness**: 100% test issues have complete template information
|
||||
|
||||
This comprehensive test planning approach ensures thorough quality validation aligned with industry standards while maintaining efficient project management and clear accountability for all testing activities.
|
||||
Loading…
x
Reference in New Issue
Block a user