Skip to content

Commit e1c7c7a

Browse files
authored
Add 18 new prompts files (github#56)
* Add prompts for .NET best practices, design pattern review, and GitHub Copilot suggestions - Introduced a comprehensive prompt for ensuring .NET/C# code adheres to best practices, covering documentation, design patterns, dependency injection, resource management, async patterns, testing standards, configuration, AI integration, error handling, performance, security, and code quality. - Added a prompt for reviewing C#/.NET code for design pattern implementation, providing a checklist for required patterns, architecture, best practices, SOLID principles, performance, maintainability, testability, security, documentation, code clarity, and clean code. - Created prompts for suggesting relevant GitHub Copilot chatmodes and prompts based on the current repository context, including a structured process for fetching available chatmodes/prompts, scanning local files, and presenting options with rationale. - Developed a prompt for updating Azure Verified Modules (AVM) in Bicep files, detailing the process for scanning, checking for updates, validating, and handling breaking changes. - Implemented a prompt for updating implementation plans with new requirements, ensuring machine-readable output and adherence to a strict template. - Added a prompt for updating the llms.txt file to reflect changes in documentation or specifications, focusing on compliance with the llmstxt specification. - Created a prompt for updating markdown file indices with files from specified folders, including options for table structures and update strategies. - Developed a prompt for updating object-oriented component documentation, following industry best practices and ensuring alignment with current implementations. - Added a prompt for updating specification files, emphasizing clarity, structure, and compliance with established documentation standards. * CHANGE: Update implementation plan prompt formatting - Renamed prompt title for clarity. - Added spacing for improved readability. - Enhanced structure to ensure compliance with template validation rules. * CHANGE: Fix typo in .NET best practices prompt - Corrected "soltion" to "solution" in the prompt description.
1 parent 4daef65 commit e1c7c7a

19 files changed

Lines changed: 1926 additions & 0 deletions

README.md

Lines changed: 18 additions & 0 deletions
Large diffs are not rendered by default.
Lines changed: 97 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,97 @@
1+
---
2+
mode: 'agent'
3+
description: 'Create an Architectural Decision Record (ADR) document for AI-optimized decision documentation.'
4+
tools: ['changes', 'codebase', 'editFiles', 'extensions', 'fetch', 'githubRepo', 'openSimpleBrowser', 'problems', 'runTasks', 'search', 'searchResults', 'terminalLastCommand', 'terminalSelection', 'testFailure', 'usages', 'vscodeAPI']
5+
---
6+
# Create Architectural Decision Record
7+
8+
Create an ADR document for `${input:DecisionTitle}` using structured formatting optimized for AI consumption and human readability.
9+
10+
## Inputs
11+
12+
- **Context**: `${input:Context}`
13+
- **Decision**: `${input:Decision}`
14+
- **Alternatives**: `${input:Alternatives}`
15+
- **Stakeholders**: `${input:Stakeholders}`
16+
17+
## Input Validation
18+
If any of the required inputs are not provided or cannot be determined from the conversation history, ask the user to provide the missing information before proceeding with ADR generation.
19+
20+
## Requirements
21+
22+
- Use precise, unambiguous language
23+
- Follow standardized ADR format with front matter
24+
- Include both positive and negative consequences
25+
- Document alternatives with rejection rationale
26+
- Structure for machine parsing and human reference
27+
- Use coded bullet points (3-4 letter codes + 3-digit numbers) for multi-item sections
28+
29+
The ADR must be saved in the `/docs/adr/` directory using the naming convention: `adr-NNNN-[title-slug].md`, where NNNN is the next sequential 4-digit number (e.g., `adr-0001-database-selection.md`).
30+
31+
## Required Documentation Structure
32+
33+
The documentation file must follow the template below, ensuring that all sections are filled out appropriately. The front matter for the markdown should be structured correctly as per the example following:
34+
35+
```md
36+
---
37+
title: "ADR-NNNN: [Decision Title]"
38+
status: "Proposed"
39+
date: "YYYY-MM-DD"
40+
authors: "[Stakeholder Names/Roles]"
41+
tags: ["architecture", "decision"]
42+
supersedes: ""
43+
superseded_by: ""
44+
---
45+
46+
# ADR-NNNN: [Decision Title]
47+
48+
## Status
49+
50+
**Proposed** | Accepted | Rejected | Superseded | Deprecated
51+
52+
## Context
53+
54+
[Problem statement, technical constraints, business requirements, and environmental factors requiring this decision.]
55+
56+
## Decision
57+
58+
[Chosen solution with clear rationale for selection.]
59+
60+
## Consequences
61+
62+
### Positive
63+
64+
- **POS-001**: [Beneficial outcomes and advantages]
65+
- **POS-002**: [Performance, maintainability, scalability improvements]
66+
- **POS-003**: [Alignment with architectural principles]
67+
68+
### Negative
69+
70+
- **NEG-001**: [Trade-offs, limitations, drawbacks]
71+
- **NEG-002**: [Technical debt or complexity introduced]
72+
- **NEG-003**: [Risks and future challenges]
73+
74+
## Alternatives Considered
75+
76+
### [Alternative 1 Name]
77+
78+
- **ALT-001**: **Description**: [Brief technical description]
79+
- **ALT-002**: **Rejection Reason**: [Why this option was not selected]
80+
81+
### [Alternative 2 Name]
82+
83+
- **ALT-003**: **Description**: [Brief technical description]
84+
- **ALT-004**: **Rejection Reason**: [Why this option was not selected]
85+
86+
## Implementation Notes
87+
88+
- **IMP-001**: [Key implementation considerations]
89+
- **IMP-002**: [Migration or rollout strategy if applicable]
90+
- **IMP-003**: [Monitoring and success criteria]
91+
92+
## References
93+
94+
- **REF-001**: [Related ADRs]
95+
- **REF-002**: [External documentation]
96+
- **REF-003**: [Standards or frameworks referenced]
97+
```
Lines changed: 28 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,28 @@
1+
---
2+
mode: 'agent'
3+
description: 'Create GitHub Issue for feature request from specification file using feature_request.yml template.'
4+
tools: ['codebase', 'search', 'github', 'create_issue', 'search_issues', 'update_issue']
5+
---
6+
# Create GitHub Issue from Specification
7+
8+
Create GitHub Issue for the specification at `${file}`.
9+
10+
## Process
11+
12+
1. Analyze specification file to extract requirements
13+
2. Check existing issues using `search_issues`
14+
3. Create new issue using `create_issue` or update existing with `update_issue`
15+
4. Use `feature_request.yml` template (fallback to default)
16+
17+
## Requirements
18+
19+
- Single issue for the complete specification
20+
- Clear title identifying the specification
21+
- Include only changes required by the specification
22+
- Verify against existing issues before creation
23+
24+
## Issue Content
25+
26+
- Title: Feature name from specification
27+
- Description: Problem statement, proposed solution, and context
28+
- Labels: feature, enhancement (as appropriate)
Lines changed: 28 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,28 @@
1+
---
2+
mode: 'agent'
3+
description: 'Create GitHub Issues from implementation plan phases using feature_request.yml or chore_request.yml templates.'
4+
tools: ['codebase', 'search', 'github', 'create_issue', 'search_issues', 'update_issue']
5+
---
6+
# Create GitHub Issue from Implementation Plan
7+
8+
Create GitHub Issues for the implementation plan at `${file}`.
9+
10+
## Process
11+
12+
1. Analyze plan file to identify phases
13+
2. Check existing issues using `search_issues`
14+
3. Create new issue per phase using `create_issue` or update existing with `update_issue`
15+
4. Use `feature_request.yml` or `chore_request.yml` templates (fallback to default)
16+
17+
## Requirements
18+
19+
- One issue per implementation phase
20+
- Clear, structured titles and descriptions
21+
- Include only changes required by the plan
22+
- Verify against existing issues before creation
23+
24+
## Issue Content
25+
26+
- Title: Phase name from implementation plan
27+
- Description: Phase details, requirements, and context
28+
- Labels: Appropriate for issue type (feature/chore)
Lines changed: 35 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,35 @@
1+
---
2+
mode: 'agent'
3+
description: 'Create GitHub Issues for unimplemented requirements from specification files using feature_request.yml template.'
4+
tools: ['codebase', 'search', 'github', 'create_issue', 'search_issues', 'update_issue']
5+
---
6+
# Create GitHub Issues for Unmet Specification Requirements
7+
8+
Create GitHub Issues for unimplemented requirements in the specification at `${file}`.
9+
10+
## Process
11+
12+
1. Analyze specification file to extract all requirements
13+
2. Check codebase implementation status for each requirement
14+
3. Search existing issues using `search_issues` to avoid duplicates
15+
4. Create new issue per unimplemented requirement using `create_issue`
16+
5. Use `feature_request.yml` template (fallback to default)
17+
18+
## Requirements
19+
20+
- One issue per unimplemented requirement from specification
21+
- Clear requirement ID and description mapping
22+
- Include implementation guidance and acceptance criteria
23+
- Verify against existing issues before creation
24+
25+
## Issue Content
26+
27+
- Title: Requirement ID and brief description
28+
- Description: Detailed requirement, implementation method, and context
29+
- Labels: feature, enhancement (as appropriate)
30+
31+
## Implementation Check
32+
33+
- Search codebase for related code patterns
34+
- Check related specification files in `/spec/` directory
35+
- Verify requirement isn't partially implemented
Lines changed: 146 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,146 @@
1+
---
2+
mode: 'agent'
3+
description: 'Create a new implementation plan file for new features, refactoring existing code or upgrading packages, design, architecture or infrastructure.'
4+
tools: ['changes', 'codebase', 'editFiles', 'extensions', 'fetch', 'githubRepo', 'openSimpleBrowser', 'problems', 'runTasks', 'search', 'searchResults', 'terminalLastCommand', 'terminalSelection', 'testFailure', 'usages', 'vscodeAPI']
5+
---
6+
# Create Implementation Plan
7+
8+
## Primary Directive
9+
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.
10+
11+
## Execution Context
12+
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.
13+
14+
## Core Requirements
15+
16+
- Generate implementation plans that are fully executable by AI agents or humans
17+
- Use deterministic language with zero ambiguity
18+
- Structure all content for automated parsing and execution
19+
- Ensure complete self-containment with no external dependencies for understanding
20+
21+
## Plan Structure Requirements
22+
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.
23+
24+
## Phase Architecture
25+
26+
- Each phase must have measurable completion criteria
27+
- Tasks within phases must be executable in parallel unless dependencies are specified
28+
- All task descriptions must include specific file paths, function names, and exact implementation details
29+
- No task should require human interpretation or decision-making
30+
31+
## AI-Optimized Implementation Standards
32+
33+
- Use explicit, unambiguous language with zero interpretation required
34+
- Structure all content as machine-parseable formats (tables, lists, structured data)
35+
- Include specific file paths, line numbers, and exact code references where applicable
36+
- Define all variables, constants, and configuration values explicitly
37+
- Provide complete context within each task description
38+
- Use standardized prefixes for all identifiers (REQ-, TASK-, etc.)
39+
- Include validation criteria that can be automatically verified
40+
41+
## Output File Specifications
42+
43+
- Save implementation plan files in `/plan/` directory
44+
- Use naming convention: `[purpose]-[component]-[version].md`
45+
- Purpose prefixes: `upgrade|refactor|feature|data|infrastructure|process|architecture|design`
46+
- Example: `upgrade-system-command-4.md`, `feature-auth-module-1.md`
47+
- File must be valid Markdown with proper front matter structure
48+
49+
## Mandatory Template Structure
50+
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.
51+
52+
## Template Validation Rules
53+
54+
- All front matter fields must be present and properly formatted
55+
- All section headers must match exactly (case-sensitive)
56+
- All identifier prefixes must follow the specified format
57+
- Tables must include all required columns
58+
- No placeholder text may remain in the final output
59+
60+
```md
61+
---
62+
goal: [Concise Title Describing the Package Implementation Plan's Goal]
63+
version: [Optional: e.g., 1.0, Date]
64+
date_created: [YYYY-MM-DD]
65+
last_updated: [Optional: YYYY-MM-DD]
66+
owner: [Optional: Team/Individual responsible for this spec]
67+
tags: [Optional: List of relevant tags or categories, e.g., `feature`, `upgrade`, `chore`, `architecture`, `migration`, `bug` etc]
68+
---
69+
70+
# Introduction
71+
72+
[A short concise introduction to the plan and the goal it is intended to achieve.]
73+
74+
## 1. Requirements & Constraints
75+
76+
[Explicitly list all requirements & constraints that affect the plan and constrain how it is implemented. Use bullet points or tables for clarity.]
77+
78+
- **REQ-001**: Requirement 1
79+
- **SEC-001**: Security Requirement 1
80+
- **[3 LETTERS]-001**: Other Requirement 1
81+
- **CON-001**: Constraint 1
82+
- **GUD-001**: Guideline 1
83+
- **PAT-001**: Pattern to follow 1
84+
85+
## 2. Implementation Steps
86+
87+
### Implementation Phase 1
88+
89+
- GOAL-001: [Describe the goal of this phase, e.g., "Implement feature X", "Refactor module Y", etc.]
90+
91+
| Task | Description | Completed | Date |
92+
|------|-------------|-----------|------|
93+
| TASK-001 | Description of task 1 || 2025-04-25 |
94+
| TASK-002 | Description of task 2 | | |
95+
| TASK-003 | Description of task 3 | | |
96+
97+
### Implementation Phase 2
98+
99+
- GOAL-002: [Describe the goal of this phase, e.g., "Implement feature X", "Refactor module Y", etc.]
100+
101+
| Task | Description | Completed | Date |
102+
|------|-------------|-----------|------|
103+
| TASK-004 | Description of task 4 | | |
104+
| TASK-005 | Description of task 5 | | |
105+
| TASK-006 | Description of task 6 | | |
106+
107+
## 3. Alternatives
108+
109+
[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.]
110+
111+
- **ALT-001**: Alternative approach 1
112+
- **ALT-002**: Alternative approach 2
113+
114+
## 4. Dependencies
115+
116+
[List any dependencies that need to be addressed, such as libraries, frameworks, or other components that the plan relies on.]
117+
118+
- **DEP-001**: Dependency 1
119+
- **DEP-002**: Dependency 2
120+
121+
## 5. Files
122+
123+
[List the files that will be affected by the feature or refactoring task.]
124+
125+
- **FILE-001**: Description of file 1
126+
- **FILE-002**: Description of file 2
127+
128+
## 6. Testing
129+
130+
[List the tests that need to be implemented to verify the feature or refactoring task.]
131+
132+
- **TEST-001**: Description of test 1
133+
- **TEST-002**: Description of test 2
134+
135+
## 7. Risks & Assumptions
136+
137+
[List any risks or assumptions related to the implementation of the plan.]
138+
139+
- **RISK-001**: Risk 1
140+
- **ASSUMPTION-001**: Assumption 1
141+
142+
## 8. Related Specifications / Further Reading
143+
144+
[Link to related spec 1]
145+
[Link to relevant external documentation]
146+
```

0 commit comments

Comments
 (0)