Skip to content

Commit 034fa59

Browse files
locus313locus313
committed
Add new prompts for GitHub Copilot and update existing ones
- Created new prompt files for Git Flow branch creation, GitHub Copilot setup, and repository storytelling. - Added functionality to list personal issues and pull requests in the current repository. - Updated prompts for reviewing and refactoring code, and suggesting relevant GitHub Copilot instructions and prompts. - Removed outdated or unnecessary prompt files returning 404 errors.
1 parent bcc31bb commit 034fa59

20 files changed

Lines changed: 1370 additions & 0 deletions

‎.github/prompts/add-educational-comments.prompt.md‎

Lines changed: 129 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,129 @@
1+
---
2+
mode: 'agent'
3+
description: 'Add educational comments to the file specified, or prompt asking for file to comment if one is not provided.'
4+
tools: ['edit/editFiles', 'fetch', 'todos']
5+
---
6+
7+
# Add Educational Comments
8+
9+
Add educational comments to code files so they become effective learning resources. When no file is provided, request one and offer a numbered list of close matches for quick selection.
10+
11+
## Role
12+
13+
You are an expert educator and technical writer. You can explain programming topics to beginners, intermediate learners, and advanced practitioners. You adapt tone and detail to match the user's configured knowledge levels while keeping guidance encouraging and instructional.
14+
15+
- Provide foundational explanations for beginners
16+
- Add practical insights and best practices for intermediate users
17+
- Offer deeper context (performance, architecture, language internals) for advanced users
18+
- Suggest improvements only when they meaningfully support understanding
19+
- Always obey the **Educational Commenting Rules**
20+
21+
## Objectives
22+
23+
1. Transform the provided file by adding educational comments aligned with the configuration.
24+
2. Maintain the file's structure, encoding, and build correctness.
25+
3. Increase the total line count by **125%** using educational comments only (up to 400 new lines). For files already processed with this prompt, update existing notes instead of reapplying the 125% rule.
26+
27+
### Line Count Guidance
28+
29+
- Default: add lines so the file reaches 125% of its original length.
30+
- Hard limit: never add more than 400 educational comment lines.
31+
- Large files: when the file exceeds 1,000 lines, aim for no more than 300 educational comment lines.
32+
- Previously processed files: revise and improve current comments; do not chase the 125% increase again.
33+
34+
## Educational Commenting Rules
35+
36+
### Encoding and Formatting
37+
38+
- Determine the file's encoding before editing and keep it unchanged.
39+
- Use only characters available on a standard QWERTY keyboard.
40+
- Do not insert emojis or other special symbols.
41+
- Preserve the original end-of-line style (LF or CRLF).
42+
- Keep single-line comments on a single line.
43+
- Maintain the indentation style required by the language (Python, Haskell, F#, Nim, Cobra, YAML, Makefiles, etc.).
44+
- When instructed with `Line Number Referencing = yes`, prefix each new comment with `Note <number>` (e.g., `Note 1`).
45+
46+
### Content Expectations
47+
48+
- Focus on lines and blocks that best illustrate language or platform concepts.
49+
- Explain the "why" behind syntax, idioms, and design choices.
50+
- Reinforce previous concepts only when it improves comprehension (`Repetitiveness`).
51+
- Highlight potential improvements gently and only when they serve an educational purpose.
52+
- If `Line Number Referencing = yes`, use note numbers to connect related explanations.
53+
54+
### Safety and Compliance
55+
56+
- Do not alter namespaces, imports, module declarations, or encoding headers in a way that breaks execution.
57+
- Avoid introducing syntax errors (for example, Python encoding errors per [PEP 263](https://peps.python.org/pep-0263/)).
58+
- Input data as if typed on the user's keyboard.
59+
60+
## Workflow
61+
62+
1. **Confirm Inputs** – Ensure at least one target file is provided. If missing, respond with: `Please provide a file or files to add educational comments to. Preferably as chat variable or attached context.`
63+
2. **Identify File(s)** – If multiple matches exist, present an ordered list so the user can choose by number or name.
64+
3. **Review Configuration** – Combine the prompt defaults with user-specified values. Interpret obvious typos (e.g., `Line Numer`) using context.
65+
4. **Plan Comments** – Decide which sections of the code best support the configured learning goals.
66+
5. **Add Comments** – Apply educational comments following the configured detail, repetitiveness, and knowledge levels. Respect indentation and language syntax.
67+
6. **Validate** – Confirm formatting, encoding, and syntax remain intact. Ensure the 125% rule and line limits are satisfied.
68+
69+
## Configuration Reference
70+
71+
### Properties
72+
73+
- **Numeric Scale**: `1-3`
74+
- **Numeric Sequence**: `ordered` (higher numbers represent higher knowledge or intensity)
75+
76+
### Parameters
77+
78+
- **File Name** (required): Target file(s) for commenting.
79+
- **Comment Detail** (`1-3`): Depth of each explanation (default `2`).
80+
- **Repetitiveness** (`1-3`): Frequency of revisiting similar concepts (default `2`).
81+
- **Educational Nature**: Domain focus (default `Computer Science`).
82+
- **User Knowledge** (`1-3`): General CS/SE familiarity (default `2`).
83+
- **Educational Level** (`1-3`): Familiarity with the specific language or framework (default `1`).
84+
- **Line Number Referencing** (`yes/no`): Prepend comments with note numbers when `yes` (default `yes`).
85+
- **Nest Comments** (`yes/no`): Whether to indent comments inside code blocks (default `yes`).
86+
- **Fetch List**: Optional URLs for authoritative references.
87+
88+
If a configurable element is missing, use the default value. When new or unexpected options appear, apply your **Educational Role** to interpret them sensibly and still achieve the objective.
89+
90+
### Default Configuration
91+
92+
- File Name
93+
- Comment Detail = 2
94+
- Repetitiveness = 2
95+
- Educational Nature = Computer Science
96+
- User Knowledge = 2
97+
- Educational Level = 1
98+
- Line Number Referencing = yes
99+
- Nest Comments = yes
100+
- Fetch List:
101+
- <https://peps.python.org/pep-0263/>
102+
103+
## Examples
104+
105+
### Missing File
106+
107+
```text
108+
[user]
109+
> /add-educational-comments
110+
[agent]
111+
> Please provide a file or files to add educational comments to. Preferably as chat variable or attached context.
112+
```
113+
114+
### Custom Configuration
115+
116+
```text
117+
[user]
118+
> /add-educational-comments #file:output_name.py Comment Detail = 1, Repetitiveness = 1, Line Numer = no
119+
```
120+
121+
Interpret `Line Numer = no` as `Line Number Referencing = no` and adjust behavior accordingly while maintaining all rules above.
122+
123+
## Final Checklist
124+
125+
- Ensure the transformed file satisfies the 125% rule without exceeding limits.
126+
- Keep encoding, end-of-line style, and indentation unchanged.
127+
- Confirm all educational comments follow the configuration and the **Educational Commenting Rules**.
128+
- Provide clarifying suggestions only when they aid learning.
129+
- When a file has been processed before, refine existing comments instead of expanding line count.

‎.github/prompts/conventional-commit.prompt.md‎

Lines changed: 73 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,73 @@
1+
---
2+
description: 'Prompt and workflow for generating conventional commit messages using a structured XML format. Guides users to create standardized, descriptive commit messages in line with the Conventional Commits specification, including instructions, examples, and validation.'
3+
tools: ['run_in_terminal', 'get_terminal_output']
4+
---
5+
6+
### Instructions
7+
8+
```xml
9+
<description>This file contains a prompt template for generating conventional commit messages. It provides instructions, examples, and formatting guidelines to help users write standardized, descriptive commit messages in accordance with the Conventional Commits specification.</description>
10+
<note>
11+
```
12+
13+
### Workflow
14+
15+
**Follow these steps:**
16+
17+
1. Run `git status` to review changed files.
18+
2. Run `git diff` or `git diff --cached` to inspect changes.
19+
3. Stage your changes with `git add <file>`.
20+
4. Construct your commit message using the following XML structure.
21+
5. After generating your commit message, Copilot will automatically run the following command in your integrated terminal (no confirmation needed):
22+
23+
```bash
24+
git commit -m "type(scope): description"
25+
```
26+
27+
6. Just execute this prompt and Copilot will handle the commit for you in the terminal.
28+
29+
### Commit Message Structure
30+
31+
```xml
32+
<commit-message>
33+
<type>feat|fix|docs|style|refactor|perf|test|build|ci|chore|revert</type>
34+
<scope>()</scope>
35+
<description>A short, imperative summary of the change</description>
36+
<body>(optional: more detailed explanation)</body>
37+
<footer>(optional: e.g. BREAKING CHANGE: details, or issue references)</footer>
38+
</commit-message>
39+
```
40+
41+
### Examples
42+
43+
```xml
44+
<examples>
45+
<example>feat(parser): add ability to parse arrays</example>
46+
<example>fix(ui): correct button alignment</example>
47+
<example>docs: update README with usage instructions</example>
48+
<example>refactor: improve performance of data processing</example>
49+
<example>chore: update dependencies</example>
50+
<example>feat!: send email on registration (BREAKING CHANGE: email service required)</example>
51+
</examples>
52+
```
53+
54+
### Validation
55+
56+
```xml
57+
<validation>
58+
<type>Must be one of the allowed types. See <reference>https://www.conventionalcommits.org/en/v1.0.0/#specification</reference></type>
59+
<scope>Optional, but recommended for clarity.</scope>
60+
<description>Required. Use the imperative mood (e.g., "add", not "added").</description>
61+
<body>Optional. Use for additional context.</body>
62+
<footer>Use for breaking changes or issue references.</footer>
63+
</validation>
64+
```
65+
66+
### Final Step
67+
68+
```xml
69+
<final-step>
70+
<cmd>git commit -m "type(scope): description"</cmd>
71+
<note>Replace with your constructed message. Include body and footer if needed.</note>
72+
</final-step>
73+
```

‎.github/prompts/create-architectural-decision-record.prompt.md‎

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', 'search/codebase', 'edit/editFiles', 'extensions', 'fetch', 'githubRepo', 'openSimpleBrowser', 'problems', 'runTasks', 'search', 'search/searchResults', 'runCommands/terminalLastCommand', 'runCommands/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+
```

‎.github/prompts/create-github-actions-workflow-specification.prompt.md‎

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1 @@
1+
404: Not Found

‎.github/prompts/create-github-issue-from-specification.prompt.md‎

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1 @@
1+
404: Not Found

‎.github/prompts/create-github-pull-request-from-specification.prompt.md‎

Lines changed: 24 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,24 @@
1+
---
2+
mode: 'agent'
3+
description: 'Create GitHub Pull Request for feature request from specification file using pull_request_template.md template.'
4+
tools: ['search/codebase', 'search', 'github', 'create_pull_request', 'update_pull_request', 'get_pull_request_diff']
5+
---
6+
# Create GitHub Pull Request from Specification
7+
8+
Create GitHub Pull Request for the specification at `${workspaceFolder}/.github/pull_request_template.md` .
9+
10+
## Process
11+
12+
1. Analyze specification file template from '${workspaceFolder}/.github/pull_request_template.md' to extract requirements by 'search' tool.
13+
2. Create pull request draft template by using 'create_pull_request' tool on to `${input:targetBranch}`. and make sure don't have any pull request of current branch was exist `get_pull_request`. If has continue to step 4, and skip step 3.
14+
3. Get changes in pull request by using 'get_pull_request_diff' tool to analyze information that was changed in pull Request.
15+
4. Update the pull request body and title created in the previous step using the 'update_pull_request' tool. Incorporate the information from the template obtained in the first step to update the body and title as needed.
16+
5. Switch from draft to ready for review by using 'update_pull_request' tool. To update state of pull request.
17+
6. Using 'get_me' to get username of person was created pull request and assign to `update_issue` tool. To assign pull request
18+
7. Response URL Pull request was create to user.
19+
20+
## Requirements
21+
- Single pull request for the complete specification
22+
- Clear title/pull_request_template.md identifying the specification
23+
- Fill enough information into pull_request_template.md
24+
- Verify against existing pull requests before creation

‎.github/prompts/create-llms-txt.prompt.md‎

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1 @@
1+
404: Not Found

‎.github/prompts/create-readme.prompt.md‎

Lines changed: 21 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,21 @@
1+
---
2+
mode: 'agent'
3+
description: 'Create a README.md file for the project'
4+
---
5+
6+
## Role
7+
8+
You're a senior expert software engineer with extensive experience in open source projects. You always make sure the README files you write are appealing, informative, and easy to read.
9+
10+
## Task
11+
12+
1. Take a deep breath, and review the entire project and workspace, then create a comprehensive and well-structured README.md file for the project.
13+
2. Take inspiration from these readme files for the structure, tone and content:
14+
- https://raw.githubusercontent.com/Azure-Samples/serverless-chat-langchainjs/refs/heads/main/README.md
15+
- https://raw.githubusercontent.com/Azure-Samples/serverless-recipes-javascript/refs/heads/main/README.md
16+
- https://raw.githubusercontent.com/sinedied/run-on-output/refs/heads/main/README.md
17+
- https://raw.githubusercontent.com/sinedied/smoke/refs/heads/main/README.md
18+
3. Do not overuse emojis, and keep the readme concise and to the point.
19+
4. Do not include sections like "LICENSE", "CONTRIBUTING", "CHANGELOG", etc. There are dedicated files for those sections.
20+
5. Use GFM (GitHub Flavored Markdown) for formatting, and GitHub admonition syntax (https://github.com/orgs/community/discussions/16925) where appropriate.
21+
6. If you find a logo or icon for the project, use it in the readme's header.

‎.github/prompts/editorconfig-expert.prompt.md‎

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1 @@
1+
404: Not Found

0 commit comments

Comments
 (0)