skilly. Buy ad slot
All skills
Devops · Writing / AGENT SKILL

pr

microsoft/webui
0 installs 92 GitHub stars
0

Guide branch naming, commit messages, and pull request titles.
Guidance for branch naming, commit messages, and PR titles.

BEFORE YOU INSTALL

Understand the trade-offs.

SECURITY REVIEW

Not yet assessed

Review the original instructions and requested permissions before installing.

No security review is available for this catalog entry yet.

SKILL QUALITY

Not yet assessed

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.

The full skill.

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.