mirror of
https://github.com/github/awesome-copilot.git
synced 2026-02-23 03:45:13 +00:00
chore: publish from staged [skip ci]
This commit is contained in:
github-actions[bot]
66
plugins/project-planning/commands/breakdown-epic-arch.md
Normal file
66
plugins/project-planning/commands/breakdown-epic-arch.md
Normal file
@@ -0,0 +1,66 @@
|
||||
---
|
||||
agent: 'agent'
|
||||
description: 'Prompt for creating the high-level technical architecture for an Epic, based on a Product Requirements Document.'
|
||||
---
|
||||
|
||||
# Epic Architecture Specification Prompt
|
||||
|
||||
## Goal
|
||||
|
||||
Act as a Senior Software Architect. Your task is to take an Epic PRD and create a high-level technical architecture specification. This document will guide the development of the epic, outlining the major components, features, and technical enablers required.
|
||||
|
||||
## Context Considerations
|
||||
|
||||
- The Epic PRD from the Product Manager.
|
||||
- **Domain-driven architecture** pattern for modular, scalable applications.
|
||||
- **Self-hosted and SaaS deployment** requirements.
|
||||
- **Docker containerization** for all services.
|
||||
- **TypeScript/Next.js** stack with App Router.
|
||||
- **Turborepo monorepo** patterns.
|
||||
- **tRPC** for type-safe APIs.
|
||||
- **Stack Auth** for authentication.
|
||||
|
||||
**Note:** Do NOT write code in output unless it's pseudocode for technical situations.
|
||||
|
||||
## Output Format
|
||||
|
||||
The output should be a complete Epic Architecture Specification in Markdown format, saved to `/docs/ways-of-work/plan/{epic-name}/arch.md`.
|
||||
|
||||
### Specification Structure
|
||||
|
||||
#### 1. Epic Architecture Overview
|
||||
|
||||
- A brief summary of the technical approach for the epic.
|
||||
|
||||
#### 2. System Architecture Diagram
|
||||
|
||||
Create a comprehensive Mermaid diagram that illustrates the complete system architecture for this epic. The diagram should include:
|
||||
|
||||
- **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
|
||||
|
||||
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
|
||||
|
||||
- A list of the high-level features to be built.
|
||||
- A list of technical enablers (e.g., new services, libraries, infrastructure) required to support the features.
|
||||
|
||||
#### 4. Technology Stack
|
||||
|
||||
- A list of the key technologies, frameworks, and libraries to be used.
|
||||
|
||||
#### 5. Technical Value
|
||||
|
||||
- Estimate the technical value (e.g., High, Medium, Low) with a brief justification.
|
||||
|
||||
#### 6. T-Shirt Size Estimate
|
||||
|
||||
- Provide a high-level t-shirt size estimate for the epic (e.g., S, M, L, XL).
|
||||
|
||||
## Context Template
|
||||
|
||||
- **Epic PRD:** [The content of the Epic PRD markdown file]
|
||||
58
plugins/project-planning/commands/breakdown-epic-pm.md
Normal file
58
plugins/project-planning/commands/breakdown-epic-pm.md
Normal file
@@ -0,0 +1,58 @@
|
||||
---
|
||||
agent: 'agent'
|
||||
description: '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.'
|
||||
---
|
||||
|
||||
# Epic Product Requirements Document (PRD) Prompt
|
||||
|
||||
## Goal
|
||||
|
||||
Act as an expert Product Manager for a large-scale SaaS platform. Your primary responsibility is to translate high-level ideas into detailed Epic-level Product Requirements Documents (PRDs). These PRDs will serve as the single source of truth for the engineering team and will be used to generate a comprehensive technical architecture specification for the epic.
|
||||
|
||||
Review the user's request for a new epic and generate a thorough PRD. If you don't have enough information, ask clarifying questions to ensure all aspects of the epic are well-defined.
|
||||
|
||||
## Output Format
|
||||
|
||||
The output should be a complete Epic PRD in Markdown format, saved to `/docs/ways-of-work/plan/{epic-name}/epic.md`.
|
||||
|
||||
### PRD Structure
|
||||
|
||||
#### 1. Epic Name
|
||||
|
||||
- A clear, concise, and descriptive name for the epic.
|
||||
|
||||
#### 2. Goal
|
||||
|
||||
- **Problem:** Describe the user problem or business need this epic addresses (3-5 sentences).
|
||||
- **Solution:** Explain how this epic solves the problem at a high level.
|
||||
- **Impact:** What are the expected outcomes or metrics to be improved (e.g., user engagement, conversion rate, revenue)?
|
||||
|
||||
#### 3. User Personas
|
||||
|
||||
- Describe the target user(s) for this epic.
|
||||
|
||||
#### 4. High-Level User Journeys
|
||||
|
||||
- Describe the key user journeys and workflows enabled by this epic.
|
||||
|
||||
#### 5. Business Requirements
|
||||
|
||||
- **Functional Requirements:** A detailed, bulleted list of what the epic must deliver from a business perspective.
|
||||
- **Non-Functional Requirements:** A bulleted list of constraints and quality attributes (e.g., performance, security, accessibility, data privacy).
|
||||
|
||||
#### 6. Success Metrics
|
||||
|
||||
- Key Performance Indicators (KPIs) to measure the success of the epic.
|
||||
|
||||
#### 7. Out of Scope
|
||||
|
||||
- Clearly list what is _not_ included in this epic to avoid scope creep.
|
||||
|
||||
#### 8. Business Value
|
||||
|
||||
- Estimate the business value (e.g., High, Medium, Low) with a brief justification.
|
||||
|
||||
## Context Template
|
||||
|
||||
- **Epic Idea:** [A high-level description of the epic from the user]
|
||||
- **Target Users:** [Optional: Any initial thoughts on who this is for]
|
||||
@@ -0,0 +1,128 @@
|
||||
---
|
||||
agent: 'agent'
|
||||
description: 'Prompt for creating detailed feature implementation plans, following Epoch monorepo structure.'
|
||||
---
|
||||
|
||||
# Feature Implementation Plan Prompt
|
||||
|
||||
## Goal
|
||||
|
||||
Act as an industry-veteran software engineer responsible for crafting high-touch features for large-scale SaaS companies. Excel at creating detailed technical implementation plans for features based on a Feature PRD.
|
||||
Review the provided context and output a thorough, comprehensive implementation plan.
|
||||
**Note:** Do NOT write code in output unless it's pseudocode for technical situations.
|
||||
|
||||
## Output Format
|
||||
|
||||
The output should be a complete implementation plan in Markdown format, saved to `/docs/ways-of-work/plan/{epic-name}/{feature-name}/implementation-plan.md`.
|
||||
|
||||
### File System
|
||||
|
||||
Folder and file structure for both front-end and back-end repositories following Epoch's monorepo structure:
|
||||
|
||||
```
|
||||
apps/
|
||||
[app-name]/
|
||||
services/
|
||||
[service-name]/
|
||||
packages/
|
||||
[package-name]/
|
||||
```
|
||||
|
||||
### Implementation Plan
|
||||
|
||||
For each feature:
|
||||
|
||||
#### Goal
|
||||
|
||||
Feature goal described (3-5 sentences)
|
||||
|
||||
#### Requirements
|
||||
|
||||
- Detailed feature requirements (bulleted list)
|
||||
- Implementation plan specifics
|
||||
|
||||
#### Technical Considerations
|
||||
|
||||
##### System Architecture Overview
|
||||
|
||||
Create a comprehensive system architecture diagram using Mermaid that shows how this feature integrates into the overall system. The diagram should include:
|
||||
|
||||
- **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
|
||||
|
||||
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.
|
||||
|
||||
- **Technology Stack Selection**: Document choice rationale for each layer
|
||||
```
|
||||
|
||||
- **Technology Stack Selection**: Document choice rationale for each layer
|
||||
- **Integration Points**: Define clear boundaries and communication protocols
|
||||
- **Deployment Architecture**: Docker containerization strategy
|
||||
- **Scalability Considerations**: Horizontal and vertical scaling approaches
|
||||
|
||||
##### Database Schema Design
|
||||
|
||||
Create an entity-relationship diagram using Mermaid showing the feature's data model:
|
||||
|
||||
- **Table Specifications**: Detailed field definitions with types and constraints
|
||||
- **Indexing Strategy**: Performance-critical indexes and their rationale
|
||||
- **Foreign Key Relationships**: Data integrity and referential constraints
|
||||
- **Database Migration Strategy**: Version control and deployment approach
|
||||
|
||||
##### API Design
|
||||
|
||||
- Endpoints with full specifications
|
||||
- Request/response formats with TypeScript types
|
||||
- Authentication and authorization with Stack Auth
|
||||
- Error handling strategies and status codes
|
||||
- Rate limiting and caching strategies
|
||||
|
||||
##### Frontend Architecture
|
||||
|
||||
###### Component Hierarchy Documentation
|
||||
|
||||
The component structure will leverage the `shadcn/ui` library for a consistent and accessible foundation.
|
||||
|
||||
**Layout Structure:**
|
||||
|
||||
```
|
||||
Recipe Library Page
|
||||
├── Header Section (shadcn: Card)
|
||||
│ ├── Title (shadcn: Typography `h1`)
|
||||
│ ├── Add Recipe Button (shadcn: Button with DropdownMenu)
|
||||
│ │ ├── Manual Entry (DropdownMenuItem)
|
||||
│ │ ├── Import from URL (DropdownMenuItem)
|
||||
│ │ └── Import from PDF (DropdownMenuItem)
|
||||
│ └── Search Input (shadcn: Input with icon)
|
||||
├── Main Content Area (flex container)
|
||||
│ ├── Filter Sidebar (aside)
|
||||
│ │ ├── Filter Title (shadcn: Typography `h4`)
|
||||
│ │ ├── Category Filters (shadcn: Checkbox group)
|
||||
│ │ ├── Cuisine Filters (shadcn: Checkbox group)
|
||||
│ │ └── Difficulty Filters (shadcn: RadioGroup)
|
||||
│ └── Recipe Grid (main)
|
||||
│ └── Recipe Card (shadcn: Card)
|
||||
│ ├── Recipe Image (img)
|
||||
│ ├── Recipe Title (shadcn: Typography `h3`)
|
||||
│ ├── Recipe Tags (shadcn: Badge)
|
||||
│ └── Quick Actions (shadcn: Button - View, Edit)
|
||||
```
|
||||
|
||||
- **State Flow Diagram**: Component state management using Mermaid
|
||||
- Reusable component library specifications
|
||||
- State management patterns with Zustand/React Query
|
||||
- TypeScript interfaces and types
|
||||
|
||||
##### Security Performance
|
||||
|
||||
- Authentication/authorization requirements
|
||||
- Data validation and sanitization
|
||||
- Performance optimization strategies
|
||||
- Caching mechanisms
|
||||
|
||||
## Context Template
|
||||
|
||||
- **Feature PRD:** [The content of the Feature PRD markdown file]
|
||||
61
plugins/project-planning/commands/breakdown-feature-prd.md
Normal file
61
plugins/project-planning/commands/breakdown-feature-prd.md
Normal file
@@ -0,0 +1,61 @@
|
||||
---
|
||||
agent: 'agent'
|
||||
description: 'Prompt for creating Product Requirements Documents (PRDs) for new features, based on an Epic.'
|
||||
---
|
||||
|
||||
# Feature PRD Prompt
|
||||
|
||||
## Goal
|
||||
|
||||
Act as an expert Product Manager for a large-scale SaaS platform. Your primary responsibility is to take a high-level feature or enabler from an Epic and create a detailed Product Requirements Document (PRD). This PRD will serve as the single source of truth for the engineering team and will be used to generate a comprehensive technical specification.
|
||||
|
||||
Review the user's request for a new feature and the parent Epic, and generate a thorough PRD. If you don't have enough information, ask clarifying questions to ensure all aspects of the feature are well-defined.
|
||||
|
||||
## Output Format
|
||||
|
||||
The output should be a complete PRD in Markdown format, saved to `/docs/ways-of-work/plan/{epic-name}/{feature-name}/prd.md`.
|
||||
|
||||
### PRD Structure
|
||||
|
||||
#### 1. Feature Name
|
||||
|
||||
- A clear, concise, and descriptive name for the feature.
|
||||
|
||||
#### 2. Epic
|
||||
|
||||
- Link to the parent Epic PRD and Architecture documents.
|
||||
|
||||
#### 3. Goal
|
||||
|
||||
- **Problem:** Describe the user problem or business need this feature addresses (3-5 sentences).
|
||||
- **Solution:** Explain how this feature solves the problem.
|
||||
- **Impact:** What are the expected outcomes or metrics to be improved (e.g., user engagement, conversion rate, etc.)?
|
||||
|
||||
#### 4. User Personas
|
||||
|
||||
- Describe the target user(s) for this feature.
|
||||
|
||||
#### 5. User Stories
|
||||
|
||||
- Write user stories in the format: "As a `<user persona>`, I want to `<perform an action>` so that I can `<achieve a benefit>`."
|
||||
- Cover the primary paths and edge cases.
|
||||
|
||||
#### 6. Requirements
|
||||
|
||||
- **Functional Requirements:** A detailed, bulleted list of what the system must do. Be specific and unambiguous.
|
||||
- **Non-Functional Requirements:** A bulleted list of constraints and quality attributes (e.g., performance, security, accessibility, data privacy).
|
||||
|
||||
#### 7. Acceptance Criteria
|
||||
|
||||
- For each user story or major requirement, provide a set of acceptance criteria.
|
||||
- Use a clear format, such as a checklist or Given/When/Then. This will be used to validate that the feature is complete and correct.
|
||||
|
||||
#### 8. Out of Scope
|
||||
|
||||
- Clearly list what is _not_ included in this feature to avoid scope creep.
|
||||
|
||||
## Context Template
|
||||
|
||||
- **Epic:** [Link to the parent Epic documents]
|
||||
- **Feature Idea:** [A high-level description of the feature request from the user]
|
||||
- **Target Users:** [Optional: Any initial thoughts on who this is for]
|
||||
@@ -0,0 +1,28 @@
|
||||
---
|
||||
agent: 'agent'
|
||||
description: 'Create GitHub Issues from implementation plan phases using feature_request.yml or chore_request.yml templates.'
|
||||
tools: ['search/codebase', 'search', 'github', 'create_issue', 'search_issues', 'update_issue']
|
||||
---
|
||||
# Create GitHub Issue from Implementation Plan
|
||||
|
||||
Create GitHub Issues for the implementation plan at `${file}`.
|
||||
|
||||
## Process
|
||||
|
||||
1. Analyze plan file to identify phases
|
||||
2. Check existing issues using `search_issues`
|
||||
3. Create new issue per phase using `create_issue` or update existing with `update_issue`
|
||||
4. Use `feature_request.yml` or `chore_request.yml` templates (fallback to default)
|
||||
|
||||
## Requirements
|
||||
|
||||
- One issue per implementation phase
|
||||
- Clear, structured titles and descriptions
|
||||
- Include only changes required by the plan
|
||||
- Verify against existing issues before creation
|
||||
|
||||
## Issue Content
|
||||
|
||||
- Title: Phase name from implementation plan
|
||||
- Description: Phase details, requirements, and context
|
||||
- Labels: Appropriate for issue type (feature/chore)
|
||||
157
plugins/project-planning/commands/create-implementation-plan.md
Normal file
157
plugins/project-planning/commands/create-implementation-plan.md
Normal file
@@ -0,0 +1,157 @@
|
||||
---
|
||||
agent: 'agent'
|
||||
description: 'Create a new implementation plan file for new features, refactoring existing code or upgrading packages, design, architecture or infrastructure.'
|
||||
tools: ['changes', 'search/codebase', 'edit/editFiles', 'extensions', 'web/fetch', 'githubRepo', 'openSimpleBrowser', 'problems', 'runTasks', 'search', 'search/searchResults', 'runCommands/terminalLastCommand', 'runCommands/terminalSelection', 'testFailure', 'usages', 'vscodeAPI']
|
||||
---
|
||||
# Create Implementation Plan
|
||||
|
||||
## Primary Directive
|
||||
|
||||
Your goal is to create a new implementation plan file for `${input:PlanPurpose}`. Your output must be machine-readable, deterministic, and structured for autonomous execution by other AI systems or humans.
|
||||
|
||||
## Execution Context
|
||||
|
||||
This prompt is designed for AI-to-AI communication and automated processing. All instructions must be interpreted literally and executed systematically without human interpretation or clarification.
|
||||
|
||||
## Core Requirements
|
||||
|
||||
- Generate implementation plans that are fully executable by AI agents or humans
|
||||
- Use deterministic language with zero ambiguity
|
||||
- Structure all content for automated parsing and execution
|
||||
- Ensure complete self-containment with no external dependencies for understanding
|
||||
|
||||
## Plan Structure Requirements
|
||||
|
||||
Plans must consist of discrete, atomic phases containing executable tasks. Each phase must be independently processable by AI agents or humans without cross-phase dependencies unless explicitly declared.
|
||||
|
||||
## Phase Architecture
|
||||
|
||||
- Each phase must have measurable completion criteria
|
||||
- Tasks within phases must be executable in parallel unless dependencies are specified
|
||||
- All task descriptions must include specific file paths, function names, and exact implementation details
|
||||
- No task should require human interpretation or decision-making
|
||||
|
||||
## AI-Optimized Implementation Standards
|
||||
|
||||
- Use explicit, unambiguous language with zero interpretation required
|
||||
- Structure all content as machine-parseable formats (tables, lists, structured data)
|
||||
- Include specific file paths, line numbers, and exact code references where applicable
|
||||
- Define all variables, constants, and configuration values explicitly
|
||||
- Provide complete context within each task description
|
||||
- Use standardized prefixes for all identifiers (REQ-, TASK-, etc.)
|
||||
- Include validation criteria that can be automatically verified
|
||||
|
||||
## Output File Specifications
|
||||
|
||||
- Save implementation plan files in `/plan/` directory
|
||||
- Use naming convention: `[purpose]-[component]-[version].md`
|
||||
- Purpose prefixes: `upgrade|refactor|feature|data|infrastructure|process|architecture|design`
|
||||
- Example: `upgrade-system-command-4.md`, `feature-auth-module-1.md`
|
||||
- File must be valid Markdown with proper front matter structure
|
||||
|
||||
## Mandatory Template Structure
|
||||
|
||||
All implementation plans must strictly adhere to the following template. Each section is required and must be populated with specific, actionable content. AI agents must validate template compliance before execution.
|
||||
|
||||
## Template Validation Rules
|
||||
|
||||
- All front matter fields must be present and properly formatted
|
||||
- All section headers must match exactly (case-sensitive)
|
||||
- All identifier prefixes must follow the specified format
|
||||
- Tables must include all required columns
|
||||
- No placeholder text may remain in the final output
|
||||
|
||||
## Status
|
||||
|
||||
The status of the implementation plan must be clearly defined in the front matter and must reflect the current state of the plan. The status can be one of the following (status_color in brackets): `Completed` (bright green badge), `In progress` (yellow badge), `Planned` (blue badge), `Deprecated` (red badge), or `On Hold` (orange badge). It should also be displayed as a badge in the introduction section.
|
||||
|
||||
```md
|
||||
---
|
||||
goal: [Concise Title Describing the Package Implementation Plan's Goal]
|
||||
version: [Optional: e.g., 1.0, Date]
|
||||
date_created: [YYYY-MM-DD]
|
||||
last_updated: [Optional: YYYY-MM-DD]
|
||||
owner: [Optional: Team/Individual responsible for this spec]
|
||||
status: 'Completed'|'In progress'|'Planned'|'Deprecated'|'On Hold'
|
||||
tags: [Optional: List of relevant tags or categories, e.g., `feature`, `upgrade`, `chore`, `architecture`, `migration`, `bug` etc]
|
||||
---
|
||||
|
||||
# Introduction
|
||||
|
||||
|
||||
|
||||
[A short concise introduction to the plan and the goal it is intended to achieve.]
|
||||
|
||||
## 1. Requirements & Constraints
|
||||
|
||||
[Explicitly list all requirements & constraints that affect the plan and constrain how it is implemented. Use bullet points or tables for clarity.]
|
||||
|
||||
- **REQ-001**: Requirement 1
|
||||
- **SEC-001**: Security Requirement 1
|
||||
- **[3 LETTERS]-001**: Other Requirement 1
|
||||
- **CON-001**: Constraint 1
|
||||
- **GUD-001**: Guideline 1
|
||||
- **PAT-001**: Pattern to follow 1
|
||||
|
||||
## 2. Implementation Steps
|
||||
|
||||
### Implementation Phase 1
|
||||
|
||||
- GOAL-001: [Describe the goal of this phase, e.g., "Implement feature X", "Refactor module Y", etc.]
|
||||
|
||||
| Task | Description | Completed | Date |
|
||||
|------|-------------|-----------|------|
|
||||
| TASK-001 | Description of task 1 | ✅ | 2025-04-25 |
|
||||
| TASK-002 | Description of task 2 | | |
|
||||
| TASK-003 | Description of task 3 | | |
|
||||
|
||||
### Implementation Phase 2
|
||||
|
||||
- GOAL-002: [Describe the goal of this phase, e.g., "Implement feature X", "Refactor module Y", etc.]
|
||||
|
||||
| Task | Description | Completed | Date |
|
||||
|------|-------------|-----------|------|
|
||||
| TASK-004 | Description of task 4 | | |
|
||||
| TASK-005 | Description of task 5 | | |
|
||||
| TASK-006 | Description of task 6 | | |
|
||||
|
||||
## 3. Alternatives
|
||||
|
||||
[A bullet point list of any alternative approaches that were considered and why they were not chosen. This helps to provide context and rationale for the chosen approach.]
|
||||
|
||||
- **ALT-001**: Alternative approach 1
|
||||
- **ALT-002**: Alternative approach 2
|
||||
|
||||
## 4. Dependencies
|
||||
|
||||
[List any dependencies that need to be addressed, such as libraries, frameworks, or other components that the plan relies on.]
|
||||
|
||||
- **DEP-001**: Dependency 1
|
||||
- **DEP-002**: Dependency 2
|
||||
|
||||
## 5. Files
|
||||
|
||||
[List the files that will be affected by the feature or refactoring task.]
|
||||
|
||||
- **FILE-001**: Description of file 1
|
||||
- **FILE-002**: Description of file 2
|
||||
|
||||
## 6. Testing
|
||||
|
||||
[List the tests that need to be implemented to verify the feature or refactoring task.]
|
||||
|
||||
- **TEST-001**: Description of test 1
|
||||
- **TEST-002**: Description of test 2
|
||||
|
||||
## 7. Risks & Assumptions
|
||||
|
||||
[List any risks or assumptions related to the implementation of the plan.]
|
||||
|
||||
- **RISK-001**: Risk 1
|
||||
- **ASSUMPTION-001**: Assumption 1
|
||||
|
||||
## 8. Related Specifications / Further Reading
|
||||
|
||||
[Link to related spec 1]
|
||||
[Link to relevant external documentation]
|
||||
```
|
||||
231
plugins/project-planning/commands/create-technical-spike.md
Normal file
231
plugins/project-planning/commands/create-technical-spike.md
Normal file
@@ -0,0 +1,231 @@
|
||||
---
|
||||
agent: 'agent'
|
||||
description: 'Create time-boxed technical spike documents for researching and resolving critical development decisions before implementation.'
|
||||
tools: ['runCommands', 'runTasks', 'edit', 'search', 'extensions', 'usages', 'vscodeAPI', 'think', 'problems', 'changes', 'testFailure', 'openSimpleBrowser', 'web/fetch', 'githubRepo', 'todos', 'Microsoft Docs', 'search']
|
||||
---
|
||||
|
||||
# Create Technical Spike Document
|
||||
|
||||
Create time-boxed technical spike documents for researching critical questions that must be answered before development can proceed. Each spike focuses on a specific technical decision with clear deliverables and timelines.
|
||||
|
||||
## Document Structure
|
||||
|
||||
Create individual files in `${input:FolderPath|docs/spikes}` directory. Name each file using the pattern: `[category]-[short-description]-spike.md` (e.g., `api-copilot-integration-spike.md`, `performance-realtime-audio-spike.md`).
|
||||
|
||||
```md
|
||||
---
|
||||
title: "${input:SpikeTitle}"
|
||||
category: "${input:Category|Technical}"
|
||||
status: "🔴 Not Started"
|
||||
priority: "${input:Priority|High}"
|
||||
timebox: "${input:Timebox|1 week}"
|
||||
created: [YYYY-MM-DD]
|
||||
updated: [YYYY-MM-DD]
|
||||
owner: "${input:Owner}"
|
||||
tags: ["technical-spike", "${input:Category|technical}", "research"]
|
||||
---
|
||||
|
||||
# ${input:SpikeTitle}
|
||||
|
||||
## Summary
|
||||
|
||||
**Spike Objective:** [Clear, specific question or decision that needs resolution]
|
||||
|
||||
**Why This Matters:** [Impact on development/architecture decisions]
|
||||
|
||||
**Timebox:** [How much time allocated to this spike]
|
||||
|
||||
**Decision Deadline:** [When this must be resolved to avoid blocking development]
|
||||
|
||||
## Research Question(s)
|
||||
|
||||
**Primary Question:** [Main technical question that needs answering]
|
||||
|
||||
**Secondary Questions:**
|
||||
|
||||
- [Related question 1]
|
||||
- [Related question 2]
|
||||
- [Related question 3]
|
||||
|
||||
## Investigation Plan
|
||||
|
||||
### Research Tasks
|
||||
|
||||
- [ ] [Specific research task 1]
|
||||
- [ ] [Specific research task 2]
|
||||
- [ ] [Specific research task 3]
|
||||
- [ ] [Create proof of concept/prototype]
|
||||
- [ ] [Document findings and recommendations]
|
||||
|
||||
### Success Criteria
|
||||
|
||||
**This spike is complete when:**
|
||||
|
||||
- [ ] [Specific criteria 1]
|
||||
- [ ] [Specific criteria 2]
|
||||
- [ ] [Clear recommendation documented]
|
||||
- [ ] [Proof of concept completed (if applicable)]
|
||||
|
||||
## Technical Context
|
||||
|
||||
**Related Components:** [List system components affected by this decision]
|
||||
|
||||
**Dependencies:** [What other spikes or decisions depend on resolving this]
|
||||
|
||||
**Constraints:** [Known limitations or requirements that affect the solution]
|
||||
|
||||
## Research Findings
|
||||
|
||||
### Investigation Results
|
||||
|
||||
[Document research findings, test results, and evidence gathered]
|
||||
|
||||
### Prototype/Testing Notes
|
||||
|
||||
[Results from any prototypes, spikes, or technical experiments]
|
||||
|
||||
### External Resources
|
||||
|
||||
- [Link to relevant documentation]
|
||||
- [Link to API references]
|
||||
- [Link to community discussions]
|
||||
- [Link to examples/tutorials]
|
||||
|
||||
## Decision
|
||||
|
||||
### Recommendation
|
||||
|
||||
[Clear recommendation based on research findings]
|
||||
|
||||
### Rationale
|
||||
|
||||
[Why this approach was chosen over alternatives]
|
||||
|
||||
### Implementation Notes
|
||||
|
||||
[Key considerations for implementation]
|
||||
|
||||
### Follow-up Actions
|
||||
|
||||
- [ ] [Action item 1]
|
||||
- [ ] [Action item 2]
|
||||
- [ ] [Update architecture documents]
|
||||
- [ ] [Create implementation tasks]
|
||||
|
||||
## Status History
|
||||
|
||||
| Date | Status | Notes |
|
||||
| ------ | -------------- | -------------------------- |
|
||||
| [Date] | 🔴 Not Started | Spike created and scoped |
|
||||
| [Date] | 🟡 In Progress | Research commenced |
|
||||
| [Date] | 🟢 Complete | [Resolution summary] |
|
||||
|
||||
---
|
||||
|
||||
_Last updated: [Date] by [Name]_
|
||||
```
|
||||
|
||||
## Categories for Technical Spikes
|
||||
|
||||
### API Integration
|
||||
|
||||
- Third-party API capabilities and limitations
|
||||
- Integration patterns and authentication
|
||||
- Rate limits and performance characteristics
|
||||
|
||||
### Architecture & Design
|
||||
|
||||
- System architecture decisions
|
||||
- Design pattern applicability
|
||||
- Component interaction models
|
||||
|
||||
### Performance & Scalability
|
||||
|
||||
- Performance requirements and constraints
|
||||
- Scalability bottlenecks and solutions
|
||||
- Resource utilization patterns
|
||||
|
||||
### Platform & Infrastructure
|
||||
|
||||
- Platform capabilities and limitations
|
||||
- Infrastructure requirements
|
||||
- Deployment and hosting considerations
|
||||
|
||||
### Security & Compliance
|
||||
|
||||
- Security requirements and implementations
|
||||
- Compliance constraints
|
||||
- Authentication and authorization approaches
|
||||
|
||||
### User Experience
|
||||
|
||||
- User interaction patterns
|
||||
- Accessibility requirements
|
||||
- Interface design decisions
|
||||
|
||||
## File Naming Conventions
|
||||
|
||||
Use descriptive, kebab-case names that indicate the category and specific unknown:
|
||||
|
||||
**API/Integration Examples:**
|
||||
|
||||
- `api-copilot-chat-integration-spike.md`
|
||||
- `api-azure-speech-realtime-spike.md`
|
||||
- `api-vscode-extension-capabilities-spike.md`
|
||||
|
||||
**Performance Examples:**
|
||||
|
||||
- `performance-audio-processing-latency-spike.md`
|
||||
- `performance-extension-host-limitations-spike.md`
|
||||
- `performance-webrtc-reliability-spike.md`
|
||||
|
||||
**Architecture Examples:**
|
||||
|
||||
- `architecture-voice-pipeline-design-spike.md`
|
||||
- `architecture-state-management-spike.md`
|
||||
- `architecture-error-handling-strategy-spike.md`
|
||||
|
||||
## Best Practices for AI Agents
|
||||
|
||||
1. **One Question Per Spike:** Each document focuses on a single technical decision or research question
|
||||
|
||||
2. **Time-Boxed Research:** Define specific time limits and deliverables for each spike
|
||||
|
||||
3. **Evidence-Based Decisions:** Require concrete evidence (tests, prototypes, documentation) before marking as complete
|
||||
|
||||
4. **Clear Recommendations:** Document specific recommendations and rationale for implementation
|
||||
|
||||
5. **Dependency Tracking:** Identify how spikes relate to each other and impact project decisions
|
||||
|
||||
6. **Outcome-Focused:** Every spike must result in an actionable decision or recommendation
|
||||
|
||||
## Research Strategy
|
||||
|
||||
### Phase 1: Information Gathering
|
||||
|
||||
1. **Search existing documentation** using search/fetch tools
|
||||
2. **Analyze codebase** for existing patterns and constraints
|
||||
3. **Research external resources** (APIs, libraries, examples)
|
||||
|
||||
### Phase 2: Validation & Testing
|
||||
|
||||
1. **Create focused prototypes** to test specific hypotheses
|
||||
2. **Run targeted experiments** to validate assumptions
|
||||
3. **Document test results** with supporting evidence
|
||||
|
||||
### Phase 3: Decision & Documentation
|
||||
|
||||
1. **Synthesize findings** into clear recommendations
|
||||
2. **Document implementation guidance** for development team
|
||||
3. **Create follow-up tasks** for implementation
|
||||
|
||||
## Tools Usage
|
||||
|
||||
- **search/searchResults:** Research existing solutions and documentation
|
||||
- **fetch/githubRepo:** Analyze external APIs, libraries, and examples
|
||||
- **codebase:** Understand existing system constraints and patterns
|
||||
- **runTasks:** Execute prototypes and validation tests
|
||||
- **editFiles:** Update research progress and findings
|
||||
- **vscodeAPI:** Test VS Code extension capabilities and limitations
|
||||
|
||||
Focus on time-boxed research that resolves critical technical decisions and unblocks development progress.
|
||||
157
plugins/project-planning/commands/update-implementation-plan.md
Normal file
157
plugins/project-planning/commands/update-implementation-plan.md
Normal file
@@ -0,0 +1,157 @@
|
||||
---
|
||||
agent: 'agent'
|
||||
description: 'Update an existing implementation plan file with new or update requirements to provide new features, refactoring existing code or upgrading packages, design, architecture or infrastructure.'
|
||||
tools: ['changes', 'search/codebase', 'edit/editFiles', 'extensions', 'web/fetch', 'githubRepo', 'openSimpleBrowser', 'problems', 'runTasks', 'search', 'search/searchResults', 'runCommands/terminalLastCommand', 'runCommands/terminalSelection', 'testFailure', 'usages', 'vscodeAPI']
|
||||
---
|
||||
# Update Implementation Plan
|
||||
|
||||
## Primary Directive
|
||||
|
||||
You are an AI agent tasked with updating the implementation plan file `${file}` based on new or updated requirements. Your output must be machine-readable, deterministic, and structured for autonomous execution by other AI systems or humans.
|
||||
|
||||
## Execution Context
|
||||
|
||||
This prompt is designed for AI-to-AI communication and automated processing. All instructions must be interpreted literally and executed systematically without human interpretation or clarification.
|
||||
|
||||
## Core Requirements
|
||||
|
||||
- Generate implementation plans that are fully executable by AI agents or humans
|
||||
- Use deterministic language with zero ambiguity
|
||||
- Structure all content for automated parsing and execution
|
||||
- Ensure complete self-containment with no external dependencies for understanding
|
||||
|
||||
## Plan Structure Requirements
|
||||
|
||||
Plans must consist of discrete, atomic phases containing executable tasks. Each phase must be independently processable by AI agents or humans without cross-phase dependencies unless explicitly declared.
|
||||
|
||||
## Phase Architecture
|
||||
|
||||
- Each phase must have measurable completion criteria
|
||||
- Tasks within phases must be executable in parallel unless dependencies are specified
|
||||
- All task descriptions must include specific file paths, function names, and exact implementation details
|
||||
- No task should require human interpretation or decision-making
|
||||
|
||||
## AI-Optimized Implementation Standards
|
||||
|
||||
- Use explicit, unambiguous language with zero interpretation required
|
||||
- Structure all content as machine-parseable formats (tables, lists, structured data)
|
||||
- Include specific file paths, line numbers, and exact code references where applicable
|
||||
- Define all variables, constants, and configuration values explicitly
|
||||
- Provide complete context within each task description
|
||||
- Use standardized prefixes for all identifiers (REQ-, TASK-, etc.)
|
||||
- Include validation criteria that can be automatically verified
|
||||
|
||||
## Output File Specifications
|
||||
|
||||
- Save implementation plan files in `/plan/` directory
|
||||
- Use naming convention: `[purpose]-[component]-[version].md`
|
||||
- Purpose prefixes: `upgrade|refactor|feature|data|infrastructure|process|architecture|design`
|
||||
- Example: `upgrade-system-command-4.md`, `feature-auth-module-1.md`
|
||||
- File must be valid Markdown with proper front matter structure
|
||||
|
||||
## Mandatory Template Structure
|
||||
|
||||
All implementation plans must strictly adhere to the following template. Each section is required and must be populated with specific, actionable content. AI agents must validate template compliance before execution.
|
||||
|
||||
## Template Validation Rules
|
||||
|
||||
- All front matter fields must be present and properly formatted
|
||||
- All section headers must match exactly (case-sensitive)
|
||||
- All identifier prefixes must follow the specified format
|
||||
- Tables must include all required columns
|
||||
- No placeholder text may remain in the final output
|
||||
|
||||
## Status
|
||||
|
||||
The status of the implementation plan must be clearly defined in the front matter and must reflect the current state of the plan. The status can be one of the following (status_color in brackets): `Completed` (bright green badge), `In progress` (yellow badge), `Planned` (blue badge), `Deprecated` (red badge), or `On Hold` (orange badge). It should also be displayed as a badge in the introduction section.
|
||||
|
||||
```md
|
||||
---
|
||||
goal: [Concise Title Describing the Package Implementation Plan's Goal]
|
||||
version: [Optional: e.g., 1.0, Date]
|
||||
date_created: [YYYY-MM-DD]
|
||||
last_updated: [Optional: YYYY-MM-DD]
|
||||
owner: [Optional: Team/Individual responsible for this spec]
|
||||
status: 'Completed'|'In progress'|'Planned'|'Deprecated'|'On Hold'
|
||||
tags: [Optional: List of relevant tags or categories, e.g., `feature`, `upgrade`, `chore`, `architecture`, `migration`, `bug` etc]
|
||||
---
|
||||
|
||||
# Introduction
|
||||
|
||||
|
||||
|
||||
[A short concise introduction to the plan and the goal it is intended to achieve.]
|
||||
|
||||
## 1. Requirements & Constraints
|
||||
|
||||
[Explicitly list all requirements & constraints that affect the plan and constrain how it is implemented. Use bullet points or tables for clarity.]
|
||||
|
||||
- **REQ-001**: Requirement 1
|
||||
- **SEC-001**: Security Requirement 1
|
||||
- **[3 LETTERS]-001**: Other Requirement 1
|
||||
- **CON-001**: Constraint 1
|
||||
- **GUD-001**: Guideline 1
|
||||
- **PAT-001**: Pattern to follow 1
|
||||
|
||||
## 2. Implementation Steps
|
||||
|
||||
### Implementation Phase 1
|
||||
|
||||
- GOAL-001: [Describe the goal of this phase, e.g., "Implement feature X", "Refactor module Y", etc.]
|
||||
|
||||
| Task | Description | Completed | Date |
|
||||
|------|-------------|-----------|------|
|
||||
| TASK-001 | Description of task 1 | ✅ | 2025-04-25 |
|
||||
| TASK-002 | Description of task 2 | | |
|
||||
| TASK-003 | Description of task 3 | | |
|
||||
|
||||
### Implementation Phase 2
|
||||
|
||||
- GOAL-002: [Describe the goal of this phase, e.g., "Implement feature X", "Refactor module Y", etc.]
|
||||
|
||||
| Task | Description | Completed | Date |
|
||||
|------|-------------|-----------|------|
|
||||
| TASK-004 | Description of task 4 | | |
|
||||
| TASK-005 | Description of task 5 | | |
|
||||
| TASK-006 | Description of task 6 | | |
|
||||
|
||||
## 3. Alternatives
|
||||
|
||||
[A bullet point list of any alternative approaches that were considered and why they were not chosen. This helps to provide context and rationale for the chosen approach.]
|
||||
|
||||
- **ALT-001**: Alternative approach 1
|
||||
- **ALT-002**: Alternative approach 2
|
||||
|
||||
## 4. Dependencies
|
||||
|
||||
[List any dependencies that need to be addressed, such as libraries, frameworks, or other components that the plan relies on.]
|
||||
|
||||
- **DEP-001**: Dependency 1
|
||||
- **DEP-002**: Dependency 2
|
||||
|
||||
## 5. Files
|
||||
|
||||
[List the files that will be affected by the feature or refactoring task.]
|
||||
|
||||
- **FILE-001**: Description of file 1
|
||||
- **FILE-002**: Description of file 2
|
||||
|
||||
## 6. Testing
|
||||
|
||||
[List the tests that need to be implemented to verify the feature or refactoring task.]
|
||||
|
||||
- **TEST-001**: Description of test 1
|
||||
- **TEST-002**: Description of test 2
|
||||
|
||||
## 7. Risks & Assumptions
|
||||
|
||||
[List any risks or assumptions related to the implementation of the plan.]
|
||||
|
||||
- **RISK-001**: Risk 1
|
||||
- **ASSUMPTION-001**: Assumption 1
|
||||
|
||||
## 8. Related Specifications / Further Reading
|
||||
|
||||
[Link to related spec 1]
|
||||
[Link to relevant external documentation]
|
||||
```
|
||||
Reference in New Issue
Block a user