-
Notifications
You must be signed in to change notification settings - Fork 21
Add a create-pr skill for pfe projects #49
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from all commits
87e3fd0
2831b65
66aef73
7a70eac
f4b8177
8540077
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,66 @@ | ||
| --- | ||
| name: create-pr | ||
| description: Create a pull request for the current session. Use when the user wants to open a PR with the session's changes. | ||
| # reference documentation: https://github.com/canonical/platform-engineering-docs/edit/main/docs/delivery-workflows/github/pull-requests/index.rst | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I am not sure of the efficiency or impact of placing reference documentation in the skill's description. I think it might be better if we reference in the body directly. WDYT?
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It's for us, not for the agent :) |
||
| --- | ||
|
|
||
| # Create Pull Request | ||
|
|
||
| Use the GitHub MCP server to create a pull request — do NOT use the `gh` CLI. | ||
|
|
||
| 1. Run the compile and hygiene tasks (fixing any errors) | ||
| 2. If there are any uncommitted changes, use the `/commit` skill to commit them | ||
| 3. Review all changes in the current session | ||
| 4. Write a clear, concise PR title with a short area prefix (e.g. "sessions: …", "editor: …") | ||
| 5. Write a description covering what changed, why, and anything reviewers should know | ||
| 6. Create the pull request following the guidelines from the next sections. | ||
|
|
||
| ## PR description | ||
|
|
||
| Unless the PR is trivial or self-explanatory (for example, fixing typos in the | ||
| documentation, a well known task that needs to be done across many repositories | ||
| such as enabling a new bot), the PR description should include: | ||
|
|
||
| - A high level overview of the change | ||
| - The reason the change is needed | ||
| - Any additional information requested in the pull request template. | ||
|
|
||
| Use the template available in `.github/pull_request_template.md>` if available. | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What do you think of adding an additional suggestion to include key agentic resource usage metrics if available?
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I would go for the template indeed, easier to test :) |
||
|
|
||
| ## PR branch name | ||
|
|
||
| PR branches should be named in a way that indicates the purpose of the branch. | ||
|
|
||
| Format: **type/scope-short-description[-optional-identifier]** (all lowercase, words separated by hyphens) | ||
|
|
||
| Where the type can be one of the following: | ||
|
|
||
| - `feat`: a new feature | ||
| - `fix`: a bug fix | ||
| - `docs`: documentation changes | ||
| - `chore`: a change that doesn't add a feature or fix a bug | ||
| (typically a maintenance change, such as updating dependencies or aligning with standards) | ||
| - `test`: adding or updating tests (if not related to a specific feature or bug fix, | ||
| in which case it should be tagged with the relevant type) | ||
| - `ci`: changes to our CI configuration or scripts (if not related to a specific feature or bug fix, | ||
| in which case it should be tagged with the relevant type) | ||
|
|
||
| Examples: | ||
|
|
||
| - `feat/tcp-wildcard-sni-support-isd-1234` | ||
| - `fix/non-working-tls-relation` | ||
| - `chore/terraform-align-module` | ||
|
|
||
| ## PR title | ||
|
|
||
| The PR title follows the same philosophy as the branch name. | ||
|
|
||
| Format: **type(scope):short description [optional-identifier]** (all lowercase, words separated by spaces) | ||
|
|
||
| Where the type is the same as described in the branch name section. | ||
|
|
||
| Examples: | ||
|
|
||
| - `feat(tcp): add wildcard SNI support (ISD-1234)` | ||
| - `fix(tls): non-working TLS relation` | ||
| - `chore(terraform): align module with standards` | ||
Uh oh!
There was an error while loading. Please reload this page.