feat: add copilot instructions and release notes guidelines; update .gitignore and VSCode settings

This commit is contained in:
Nick Alteen 2025-07-11 13:36:46 -04:00
parent 6f4f96e326
commit 8f6413f2d9
5 changed files with 127 additions and 1 deletions

69
.github/copilot-instructions.md vendored Normal file
View File

@ -0,0 +1,69 @@
# Copilot Instructions
This GitHub Action is written as a Docker container that invokes an entrypoint
script. The entrypoint script is responsible for invoking the main logic of the
action.
## Repository Structure
| Path | Description |
| -------------------- | ----------------------------------- |
| `.devcontainer/` | Development Container Configuration |
| `.github/` | GitHub Configuration |
| `.markdown-lint.yml` | Markdown Linter Configuration |
| `.prettierrc.yml` | Prettier Formatter Configuration |
| `.yaml-lint.yml` | YAML Linter Configuration |
| `action.yml` | GitHub Action Metadata |
| `CODEOWNERS` | Code Owners File |
| `Dockerfile` | Dockerfile for the Action |
| `entrypoint.sh` | Entrypoint Script |
| `LICENSE` | License File |
| `README.md` | Project Documentation |
## General Coding Guidelines
- Follow standard shell scripting conventions and best practices
- Changes should maintain consistency with existing patterns and style
- Document changes clearly and thoroughly, including updates to existing
comments when appropriate
- Do not include basic, unnecessary comments that simply restate what the code
is doing (focus on explaining _why_, not _what_)
- Use consistent error handling patterns throughout the codebase
- Keep functions focused and manageable
- Use descriptive variable and function names that clearly convey their purpose
- When suggesting code changes, always opt for the most maintainable approach.
Try your best to keep the code clean and follow "Don't Repeat Yourself" (DRY)
principles
- Avoid unnecessary complexity and always consider the long-term maintainability
of the code
### Versioning
GitHub Actions are versioned using branch and tag names. The version should
follow [Semantic Versioning](https://semver.org/) principles.
## Pull Request Guidelines
When creating a pull request (PR), please ensure that:
- Keep changes focused and minimal (avoid large changes, or consider breaking
them into separate, smaller PRs)
- Formatting checks pass
- Linting checks pass
- If necessary, the `README.md` file is updated to reflect any changes in
functionality or usage
The body of the PR should include:
- A summary of the changes
- A special note of any changes to dependencies
- A link to any relevant issues or discussions
- Any additional context that may be helpful for reviewers
## Code Review Guidelines
When performing a code review, please follow these guidelines:
- If there are changes that modify the functionality/usage of the action,
validate that there are changes in the `README.md` file that document the new
or modified functionality

View File

@ -0,0 +1,34 @@
# Create Release Notes
You are an expert technical writer tasked with creating release notes for
updates to this repository. Your specific task is to generate release notes that
are clear, concise, and useful for developers and users of the project.
## Guidelines
Ensure you adhere to the following guidelines when creating release notes:
- Use a clear and consistent format for the release notes
- Include a summary of the changes made in the release
- Highlight any new features, improvements, or bug fixes
- If applicable, include instructions for upgrading or migrating to the new
version
- Use technical language that is appropriate for the audience, but avoid jargon
that may not be understood by all users
- Ensure that the release notes are easy to read and navigate
- Include relevant issue or PR numbers where applicable
- Use proper Markdown formatting
- Use code blocks for commands, configuration examples, or code changes
- Use note and warning callouts for important information
## Versioning
GitHub Actions are versioned using branch and tag names. The version should
reflect the changes made in the codebase and follow
[Semantic Versioning](https://semver.org/) principles. Depending on the nature
of the changes, please make sure to adjust the release notes accordingly:
- For **major** changes, include a detailed description of the breaking changes
and how users can adapt to them
- For **minor** changes, highlight new features and improvements
- For **patch** changes, focus on bug fixes and minor improvements

1
.gitignore vendored
View File

@ -21,5 +21,4 @@ Thumbs.db
# IDE files
.idea
.vscode
*.code-workspace

9
.vscode/mcp.json vendored Normal file
View File

@ -0,0 +1,9 @@
{
"servers": {
"github": {
"url": "https://api.githubcopilot.com/mcp/",
"type": "http"
}
},
"inputs": []
}

15
.vscode/settings.json vendored Normal file
View File

@ -0,0 +1,15 @@
{
"github.copilot.chat.reviewSelection.instructions": [
{
"text": "Review the code changes carefully before accepting them."
}
],
"github.copilot.chat.commitMessageGeneration.instructions": [
{
"text": "Use conventional commit message format."
}
],
"github.copilot.chat.pullRequestDescriptionGeneration.instructions": [
{ "text": "Always include a list of key changes." }
]
}