Official agent skill

Finalize PR

by microsoft in microsoft/bocpy

Finalize a feature branch for merge. An agent skill from microsoft/bocpy.

OfficialMITAuto-check passedDevelopment

Install Finalize PR

skills CLI
$ npx skills add microsoft/bocpy --skill finalize-pr -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install microsoft/bocpy finalize-pr --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/microsoft/bocpy.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.github/skills/finalize-pr .claude/skills/finalize-pr && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
finalize-pr
GitHub stars
200
Token cost
~3.5k tokens
SKILL.md length
1,530 words
Files
1
Skills in repo
9
Repo updated
First seen
Licence
MIT

At a glance

Finalize a feature branch for merge. An agent skill from microsoft/bocpy.

  • Works in 8 steps: Determine What Changed → Choose the New Version → Bump the Version → …
  • Finishing a feature branch
  • SKILL.md covers When to Use, Prerequisites, Procedure and Guardrails
  • Calls git, pip and pytest

What it does

Finalize PR is an agent skill from microsoft/bocpy, published by the product's own GitHub organization. Finalize a feature branch for merge. Use when finishing a feature branch, preparing for merge, releasing a new version, bumping the version, adding a changelog entry, or when asked to finalize, wrap up, or close out a PR. Covers version bump across all files, CHANGELOG entry, Sphinx + README updates, editor-lens pass over the diff, lint, and test verification. Replaces the older version-bump skill.

Its SKILL.md is about 3.5k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.

It sits in Development, covering Changelog and release notes, Technical documentation and Linting and formatting. The repository describes itself as: Behavior-Oriented Concurrency in Python. The licence is MIT.

When your agent uses it

  • Finishing a feature branch
  • Preparing for merge
  • Releasing a new version
  • Bumping the version

Example prompts

  • “/finalize-pr”

Requirements

  • Python 3

Workflow steps

8 steps, taken from the step headings in SKILL.md.

  1. Determine What Changed
  2. Choose the New Version
  3. Bump the Version
  4. Add a CHANGELOG Entry
  5. Update Documentation
  6. Editor-Lens Pass Over the Diff
  7. Lint and Test
  8. Summarize

What it can do on your machine

Read from SKILL.md and the folder at commit c8f3ceb. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Shell commands in SKILL.md call:

    • git
    • pip
    • pytest
    • apt

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md. Its commands use git and pip, which can reach the network depending on how they are called.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Finalize PR loads about 3.5k tokens when it runs. Until then it costs about 103 tokens; SKILL.md has 1,530 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~103
When it runs · the whole SKILL.md, loaded when a task matches
~3.5k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from microsoft/bocpy at commit c8f3ceb, republished under its MIT licence (© microsoft). 1,530 words, ~3,491 tokens.

Download SKILL.mdSave it as .claude/skills/finalize-pr/SKILL.md (or your agent's skills folder).
name
finalize-pr
description
Finalize a feature branch for merge. Use when finishing a feature branch, preparing for merge, releasing a new version, bumping the version, adding a changelog entry, or when asked to finalize, wrap up, or close out a PR. Covers version bump across all files, CHANGELOG entry, Sphinx + README updates, editor-lens pass over the diff, lint, and test verification. Replaces the older version-bump skill.
argument-hint
Optional: target version (e.g. '0.7.0'); otherwise inferred from scope of changes

Finalize PR

Prepares a feature branch for merge by bumping the version, writing a changelog entry, updating documentation, scrubbing comment debt, and verifying the change with lint + the full test suite. The user reviews and commits — this skill never commits.

When to Use

  • A feature branch is ready to merge and needs the final release polish
  • Bumping the bocpy version (replaces the older version-bump skill)
  • Adding a CHANGELOG entry
  • Pre-merge documentation sweep

For a multi-perspective pre-merge review of the code itself, run branch-review first. This skill assumes the code is settled and the test suite is green.

Prerequisites

Before invoking this skill:

  • All code changes are complete
  • The test suite passes locally in the venv you intend to use
  • A branch-review pass (or equivalent) has been run if the change is non-trivial — see .github/copilot-instructions.md
  • You know which venv this work targets (.env312, .env313d, .env313t, .env314, .env315, .env315t). Ask the user if unsure; default is .env314.

Procedure

Execute these steps in order. Pause for user review between steps — this is a wrap-up workflow, not an autonomous one.

Step 1 — Determine What Changed

Gather context about the branch:

  1. Read the current version from pyproject.toml ([project] version).
  2. Run git log --oneline main..HEAD to see commits on the branch.
  3. Run git diff main --stat to see changed files.
  4. Read the current CHANGELOG.md to see the most recent entry format and any existing ## Unreleased section.
  5. If a session plan file exists under .copilot/plans/ for this branch, read it to understand the scope of work.

Summarize the work performed (what was added, what was changed, what was removed, any breaking changes) and confirm with the user before proceeding. The summary drives every later step.

Step 2 — Choose the New Version

bocpy follows semantic versioning. Propose the version bump based on the Step 1 summary:

BumpWhen
Patch (0.6.0 → 0.6.1)Bug fixes, internal refactors, test additions, doc-only changes, no public API change
Minor (0.6.0 → 0.7.0)New public API (new @when semantics, new bocpy.* symbols, new C ABI surface), new examples, new tunables. No breaking changes
Major (0.6.0 → 1.0.0)Breaking changes to the Python API, the C ABI (<bocpy/bocpy.h> / <bocpy/xidata.h>), or Cown / @when semantics

The public C ABI is version-gated via the BOCPY_ABI macro and the bocpy~=MAJOR.MINOR pin in templates/c_abi_consumer/pyproject.toml. Any incompatible change to <bocpy/bocpy.h> or <bocpy/xidata.h> requires a minor bump at minimum and an explicit BOCPY_ABI bump in the header.

Confirm the proposed version with the user before editing any files.

Step 3 — Bump the Version

Update all five files in lock-step. Skipping any one of these leaves the release inconsistent.

3.1 pyproject.toml
toml
[project]
name = "bocpy"
version = "<NEW_VERSION>"
3.2 sphinx/source/conf.py
python
release = '<NEW_VERSION>'
3.3 CITATION.cff

Update both fields:

yaml
version: <NEW_VERSION>
date-released: <TODAY YYYY-MM-DD>
3.4 templates/c_abi_consumer/pyproject.toml

Update both bocpy entries to a compatible-release bound on the new MAJOR.MINOR:

toml
[build-system]
requires = ["setuptools", "wheel", "bocpy~=<MAJOR.MINOR>"]

[project]
dependencies = ["bocpy~=<MAJOR.MINOR>"]

The template is the canonical downstream example; its pin signals which public C ABI it was authored against. Keep it in lock-step with the root [project].version.

3.5 CHANGELOG.md

Handled in Step 4 — version is part of the changelog entry header.

Step 4 — Add a CHANGELOG Entry

Open CHANGELOG.md. If a ## Unreleased section already exists, re-title it; otherwise prepend a new entry at the top of the file (below any header).

Format

Match the prevailing format in the file. Recent entries follow this shape:

markdown
## YYYY-MM-DD - Version X.Y.Z
One-paragraph summary of the headline change.

**New Features**

- **Feature name** — what it is, why it matters, where it lives.
- ...

**Bug Fixes**

- **Short title** — root cause + fix, in past tense.
- ...

**Improvements**

- ...

**Breaking Changes**

- **What broke** — why, and the recommended migration path.

**Documentation**

- New :doc:`xxx` page, expanded :doc:`api`, ...

**Tests**

- ...

**Internal**

- ...
Rules
  • Date is today's date (UTC).
  • Use the same bold-noun-phrase + em-dash style as recent entries.
  • Reference Sphinx pages with :doc: directives (rendered on the Sphinx site, which embeds the changelog).
  • Group by category in the order shown above. Omit any category with no entries.
  • Breaking Changes must be its own section, never folded into another. Each entry must say what to do instead.
  • Mention any new console entry points (bocpy-*) by name.
  • Mention any new files in templates/c_abi_consumer/ only if they change the consumer-facing template.
Step 5 — Update Documentation

Walk through the docs and update anything the branch made stale. Do not rewrite prose that is still accurate.

5.1 README.md (root)

Check and update:

  • Public API table / feature list — add new @when, Cown, send/receive, noticeboard, or messaging symbols.
  • Quick-start / examples list — add any new entry-point example (bocpy-* console script).
  • Compatibility matrix — update if Python-version support changed (look at pyproject.toml classifiers).
  • Sub-interpreter / scheduler description — update only if the architecture changed meaningfully on this branch.

The file is PyPI's project description (after the <!-- pypi-skip-start -->...<!-- pypi-skip-end --> filter in setup.py); keep it presentable.

5.2 sphinx/source/
FileUpdate if...
index.rstArchitecture overview changed, or a new top-level subsystem was added
api.rstNew public Python symbol added or removed (Sphinx autodoc picks the docstring up from __init__.pyi, but the toctree entry must exist)
c_abi.rstAnything in <bocpy/bocpy.h> or <bocpy/xidata.h> changed, or BOCPY_ABI was bumped
messaging.rstsend / receive / set_tags / drain / TIMEOUT semantics changed
noticeboard.rstnotice_* / noticeboard() / REMOVED / snapshot semantics changed
sbom.rstSBOM generation, the audit extra, or wheel-embedding format changed

Sphinx autodoc reads docstrings from src/bocpy/__init__.pyi and src/bocpy/_core.pyi. If you added a new public symbol, the stub docstring is the canonical source — update it there, not in behaviors.py (or both, where applicable).

5.3 templates/c_abi_consumer/README.md

Update only if the consumer-facing API surface changed (new helpers in bocpy.get_include() / bocpy.get_sources(), new headers, new required compile flags).

Show full SKILL.md (711 more words)Show less
Step 6 — Editor-Lens Pass Over the Diff

Comment debt accumulates while a PR is in flight: review-process scaffolding (chunk numbers, finding IDs like H1 / M5 / L2, plan back-references, sketch IDs, "Round-2 adv#6"), wordy paraphrases of the code, dated status notes, and "previously / now" archaeology. None of this serves a future reader. Scrub it as part of finalize.

This step is run via the review-loop skill against the PR diff (not the whole repo) using the editor-lens agent.

  1. Identify the changed in-scope source files:

    bash
    mkdir -p .copilot/finalize
    git diff --name-only main -- \
        'src/bocpy/**/*.c' 'src/bocpy/**/*.h' \
        'src/bocpy/**/*.py' 'src/bocpy/**/*.pyi' \
        'examples/**/*.py' \
        'test/**/*.py' \
        'templates/c_abi_consumer/src/**/*.c' \
        'templates/c_abi_consumer/src/**/*.h' \
        'templates/c_abi_consumer/src/**/*.py' \
        'scripts/**/*.py' \
      | tee .copilot/finalize/editor-lens-targets.txt

    git diff (no ..HEAD) covers both committed and uncommitted changes — important during finalize, when you may still be editing.

  2. Invoke review-loop with editor-lens as the reviewer and the file list as the target. The lens follows the keep / rewrite / cut policy in .github/agents/editor-lens.agent.md. Iterate until the loop comes back clean.

  3. Apply approved cuts and rewrites. Anything the lens flags under "Questions for the user" must be resolved before proceeding — do not silently delete.

The editor-lens scope explicitly excludes sphinx/source/, README.md, CHANGELOG.md, the top-level policy docs, and everything under .github/ and .copilot/. Those have different rules and are managed by other steps in this skill (or are off-limits entirely).

Why this lives in finalize, not pre-commit: during PR work the review tags and scaffold comments are useful — they let the author and reviewer cross-reference findings. They become noise only after the review documents are deleted. Finalize is the right place to scrub.

Step 7 — Lint and Test

Activate the chosen venv (default .env314 — confirm with the user) and run the full local mirror of the PR gate. Pipe long-running output to .copilot/finalize/<name>.log so the chat stays readable.

bash
source .env314/bin/activate
7.1 Lint

Mirrors the .github/workflows/pr_gate.yml linting job. The --filename flag opts the walker into .pyi stubs (it would otherwise skip them silently):

bash
flake8 --filename='*.py,*.pyi' src/bocpy test examples scripts \
  2>&1 | tee .copilot/finalize/flake8.log

Must exit zero.

7.2 Clang-format

Mirrors the cpp-format job. Run for both C trees touched by the branch:

bash
clang-format-18 --dry-run -Werror \
    src/bocpy/*.c src/bocpy/*.h src/bocpy/include/bocpy/*.h \
  2>&1 | tee .copilot/finalize/clang-format-src.log

clang-format-18 --dry-run -Werror \
    templates/c_abi_consumer/src/**/*.{c,h} \
  2>&1 | tee .copilot/finalize/clang-format-template.log

Both must exit zero. If clang-format-18 is not installed, install it (apt install clang-format-18) or skip with explicit user approval; the CI version is pinned to 18.

7.3 Reinstall bocpy in the venv

A version bump touches pyproject.toml and (often) C sources. Force a fresh editable install so the test suite sees the new build. Use the BOCPY_BUILD_INTERNAL_TESTS=1 opt-in so the _internal_test_* extensions are built and the test_internal_* / test_compat_atomics.py modules run instead of skipping:

bash
BOCPY_BUILD_INTERNAL_TESTS=1 pip install -e .[test] --no-build-isolation \
  2>&1 | tee .copilot/finalize/install.log
7.4 Full test suite
bash
pytest -vv 2>&1 | tee .copilot/finalize/pytest.log | tail -40

Must exit zero. If pre-existing skips are present (e.g. version-gated tests), confirm they match the baseline recorded in the session plan; new skips warrant investigation.

7.5 Downstream consumer (if touched)

If the branch changed anything under src/bocpy/include/bocpy/, src/bocpy/boc_*.{c,h}, templates/c_abi_consumer/, or the bocpy.get_include() / bocpy.get_sources() helpers, also run:

bash
pip install --no-build-isolation ./templates/c_abi_consumer \
  2>&1 | tee .copilot/finalize/consumer-install.log

pytest -vv templates/c_abi_consumer/test \
  2>&1 | tee .copilot/finalize/consumer-pytest.log | tail -20

Both must exit zero.

7.6 Cross-version spot check (optional)

If the branch touched anything version-gated (xidata.h, PY_VERSION_HEX ladders, free-threaded code paths, #if Py_GIL_DISABLED branches), re-run 7.3 + 7.4 in at least one additional venv covering the affected versions (e.g. .env312, .env313t, .env315t). Confirm with the user which extra venvs to exercise.

Step 8 — Summarize

Present a single summary to the user with:

  • Version: old → new
  • Files changed by this skill: pyproject.toml, sphinx/source/conf.py, CITATION.cff, templates/c_abi_consumer/pyproject.toml, CHANGELOG.md, any Sphinx pages updated, any README sections updated, and the list of source files edited by the editor-lens pass.
  • Verification: flake8, clang-format, pytest, downstream consumer (if run), cross-version (if run) — all pass / fail with log paths under .copilot/finalize/.
  • Open questions: anything editor-lens flagged as ambiguous and any pre-existing test skips that warrant attention.

Do not commit. All git operations belong to the user.

Guardrails

  • Never commit, push, tag, or create a release. The user owns every git operation.
  • Never skip a file listed in Step 3. All five (pyproject.toml, conf.py, CITATION.cff, the template pyproject.toml, and CHANGELOG.md) must move in lock-step.
  • Never silently widen scope. If the editor-lens pass surfaces a bug, stop and raise it as a finding; do not fix it in the finalize pass.
  • Never edit prose under sphinx/source/ to mask a missing public symbol. If the docs reference a symbol that does not exist, the bug is in the code or in __init__.pyi, not the docs.
  • Always confirm the venv at Step 7 before running pip install. Installing into the wrong venv silently rebuilds the wrong interpreter's wheel.

© microsoft, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in .github/skills/finalize-pr of microsoft/bocpy.

Open the folder on GitHubat commit c8f3ceb

Compare with similar skills

Finalize PR next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Finalize PR compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Finalize PR this skillmicrosoft/bocpy200—~3.5kAutomated safety check: PassMIT
Swig Conventionsswig/swig6.3k—~2.7kAutomated safety check: PassCustom licence
Simple Englishmoeru-ai/airi50k2 repos~4.6kAutomated safety check: PassMIT
WooCommerce Markdown Guidelineswoocommerce/woocommerce11k1 repos~1.7kAutomated safety check: PassCustom licence
Cut Releasemicrosoft/apm4k—~2.5kAutomated safety check: PassMIT
Ccb GitHubSeemSeam/claude_codex_bridge3.5k—~4.9kAutomated safety check: PassCustom licence

Similar skills

  • SWIG source and contribution conventions: clang-format / code formatting, C/C++ comment style (quotes, widths, function header blocks), parser.y new-code rules, alphabetical ordering of makefile…

    6.3k GitHub stars~2.7k tokensUpdated today
    DevelopmentAuto-check passed
  • Simple English

    moeru-ai/airi

    Write or rewrite technical text with the rules of ASD-STE100 Simplified Technical English so it is clear, unambiguous, and free of AI slop.

    50k GitHub starsUsed in 2 repos~4.6k tokens
    DevelopmentAuto-check passed
  • WooCommerce Markdown Guidelines

    woocommerce/woocommerce

    Rules for writing and editing markdown in the WooCommerce repository, with the project's markdownlint settings for headings, lists and code blocks.

    11k GitHub starsUsed in 1 repo~1.7k tokens
    DevelopmentAuto-check passed
  • Cut Release

    microsoft/apm

    Official

    A skill your agent uses to cut an APM release from the current worktree: assess whether the cycle since the last tag warrants a patch or minor bump (semver discipline against the…

    4k GitHub stars~2.5k tokensUpdated yesterday
    DevelopmentAuto-check passed
  • Ccb GitHub

    SeemSeam/claude_codex_bridge

    Maintain this CCB project's GitHub-facing release and npm publication surface.

    3.5k GitHub stars~4.9k tokensUpdated yesterday
    DevelopmentAuto-check passed
  • Comprehensive documentation guide for Golang projects, covering godoc comments, README, CONTRIBUTING, CHANGELOG, Go Playground, Example tests, API docs, and llms.txt.

    240 GitHub starsUsed in 3 repos~3.5k tokens
    DevelopmentAuto-check passed

More from microsoft/bocpy

All 9 skills in this repo
  • Branch Review

    microsoft/bocpy

    Official

    Multi-perspective code review for a branch before merging. An agent skill from microsoft/bocpy.

    200 GitHub stars~3.2k tokensUpdated 9 days ago
    Auto-check passed
  • Official

    Write a C extension whose custom types can live inside a bocpy Cown and travel between worker sub-interpreters.

    200 GitHub stars~5.1k tokensUpdated 9 days ago
    Auto-check passed
  • Official

    Follow bocpy commenting and documentation conventions. An agent skill from microsoft/bocpy.

    200 GitHub stars~3.3k tokensUpdated 9 days ago
    Auto-check passed
  • Multi Perspective Plan

    microsoft/bocpy

    Official

    Multi-perspective planning with rebuttal rounds and adversarial review loop.

    200 GitHub stars~2.8k tokensUpdated 9 days ago
    Auto-check passed
  • Testing Message Queue

    microsoft/bocpy

    Official

    Write tests for the bocpy message queue — the lock-free tag-based MPSC ring buffer.

    200 GitHub stars~2.3k tokensUpdated 9 days ago
    Auto-check passed
  • Thinking In Boc

    microsoft/bocpy

    Official

    Think in Behavior-Oriented Concurrency, not threads-and-locks.

    200 GitHub stars~2.6k tokensUpdated 9 days ago
    Auto-check passed

Categories

Questions about Finalize PR

What does Finalize PR do?

Finalize a feature branch for merge. An agent skill from microsoft/bocpy. Finalize PR is an agent skill from microsoft/bocpy, published by the product's own GitHub organization. Finalize a feature branch for merge.

When should I use Finalize PR?

Finalize PR fits situations like: finishing a feature branch; preparing for merge; releasing a new version; bumping the version.

How do I install Finalize PR in Claude Code?

Run `npx skills add microsoft/bocpy --skill finalize-pr -a claude-code`. Or copy the skill folder (.github/skills/finalize-pr in microsoft/bocpy) into .claude/skills/finalize-pr in your project. Claude Code loads it when a task matches its description.

How do I install Finalize PR in Codex?

Run `npx skills add microsoft/bocpy --skill finalize-pr -a codex`. Or copy the skill folder (.github/skills/finalize-pr in microsoft/bocpy) into .agents/skills/finalize-pr in your project. Codex loads it when a task matches its description.

Can I use Finalize PR in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add microsoft/bocpy --skill finalize-pr -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/finalize-pr, .gemini/skills/finalize-pr, .github/skills/finalize-pr and .opencode/skills/finalize-pr in your project.

What does Finalize PR need to run?

Going by SKILL.md and its folder, Finalize PR needs the command-line tools its instructions call (git, pip, pytest and apt). Our summary lists: Python 3.

Does Finalize PR access the network?

SKILL.md contains no URLs. Its commands use git and pip, which can reach the network depending on how they are called. This is read from the text; nothing was executed.

Is Finalize PR safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Finalize PR use?

Finalize PR is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Finalize PR use?

About 3.5k tokens (SKILL.md is roughly 14k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Finalize PR?

Skills that share tags, products or a category with Finalize PR: Swig Conventions (swig/swig, 6.3k stars), Simple English (moeru-ai/airi, 50k stars), WooCommerce Markdown Guidelines (woocommerce/woocommerce, 11k stars) and Cut Release (microsoft/apm, 4k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Finalize PR?

microsoft (a GitHub organization, an official publisher) maintains it in microsoft/bocpy, which has 200 GitHub stars. The repository holds 9 skills in this directory. The repository was last updated on September 28, 2026.

Source: microsoft/bocpy on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.