SECURITY REVIEW
Not yet assessed
Review the original instructions and requested permissions before installing.
No security review is available for this catalog entry yet.
Guide branch naming, commit messages, and pull request titles.
Guidance for branch naming, commit messages, and PR titles.
Review the original instructions and requested permissions before installing.
No security review is available for this catalog entry yet.
How clearly the skill guides your agent, how complete its workflow is, and how you can check the outcome.
No quality assessment is available for this catalog entry yet.
Original instructions from the publisher’s SKILL.md
# Pull Request Conventions ## Branch discipline - **Never commit to `main` directly.** Create a branch: `<user>/<short-description>` (e.g. `mmansour/optimize-handler-allocs`). - One logical change per commit. Write imperative messages: *"Add …"* not *"Added …"*. ## PR title format PR titles must use a [Conventional Commits](https://www.conventionalcommits.org/) prefix: | Prefix | When to use | Example | |--------|-------------|---------| | `feat:` | New feature or capability | `feat: add HTTP/2 support to hyper example` | | `fix:` | Bug fix | `fix: render missing signals as empty` | | `perf:` | Speed or memory improvement, measured | `perf: reduce allocations on hot paths` | | `chore:` | Maintenance, refactoring, CI, docs, dependencies | `chore: move shared files to examples/app` | The prefix is **lowercase**, followed by a colon and a space, then a short imperative description. A `perf:` PR must report before/after numbers in its description - see the **perf** skill for how to measure. ## Linking PRs to issues When a PR is meant to close a GitHub issue, include the keyword `Closes` followed by the issue number in the PR description body (not the title): ``` Closes #42 ``` For multiple issues, use one per line: ``` Closes #42 Closes #43 ``` > **Note:** Issue-linking keywords only work when the PR targets the repository's default branch. See [GitHub docs: linking a pull request to an issue](https://docs.github.com/en/issues/tracking-your-work-with-issues/using-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword) for the full reference. ## PR description Remove the Co-author-by line from the PR description. If you want to credit a co-author, add them as a reviewer instead. And check all the changes from its merge-base to get a detailed summary for the commit. ## Framework change PRs For PRs touching core framework code (handler, parser, protocol, router, CLI runtime, FFI), apply the **code-review** skill checklist before opening the PR. It covers correctness, concurrency, performance, design, and style checks that complement the automated quality gate.