Menu
ALWAYS load before git commit, push, or PR - team-specific commit format differs from standard conventions.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
| name | version-control |
| description | ALWAYS load before git commit, push, or PR - team-specific commit format differs from standard conventions. |
Before any Git or GitHub operation, read the relevant documentation:
NEVER commit code that has not been built and tested. This is a hard gate.
Before staging and committing, verify:
If the LLM has not built/tested the code itself, ask the developer: "Has this been built and tested since the last change?" Do not skip this step even for small fixes - even a small change can introduce a build error or break a test.
<Title in past tense>
* bullet point 1
* bullet point 2
Reported by <First>.
See ai/todos/active/TODO-YYYYMMDD_feature.md
Co-Authored-By: Claude <noreply@anthropic.com>
Rules:
* prefix (not -)Reported by <First>. (or Requested by <First>.) when the change came from a user report/request — see "Crediting reporters" belowpwiz-ai repository (ai/): Omit TODO reference for documentation-only changes
Nearly all PRs get squash-merged, so multiple commits on a branch are fine.
NEVER amend after a PR has been reviewed. When addressing review feedback (from humans or Copilot), always create a NEW commit. This preserves the review history and makes it easy to see what changed in response to feedback. A commit message like "Addressed Copilot review suggestions" or "Fixed issues from code review" is appropriate.
When amending is acceptable:
When amending is NOT acceptable:
The commits will be squashed on merge anyway, so there is no cost to having multiple commits.
Changes under ai/ commit directly to pwiz-ai master (no PR, no feature branch).
There is no squash-merge to clean up history later, so the master history must stay
linear — never create a merge commit on pwiz-ai master.
When git push is rejected because the remote advanced (another machine pushed first),
rebase your local commits onto the new remote tip — do not git pull (merge).
pwiz-ai changes are almost always small and most machines keep pwiz-ai fairly
up-to-date, so a rejected push is typically only a commit or two out of sync and
rebases cleanly:
cd /c/proj/ai
git pull --rebase origin master # replay your commits on top of remote; no merge commit
git push origin master
Note this overrides the machine's global pull.rebase false setting (which is correct
for pwiz feature branches) by passing --rebase explicitly for pwiz-ai work.
If the rebase hits a conflict (rare for ai/), resolve it, git rebase --continue,
then push. Do not fall back to a merge to avoid the conflict.
## Summary
* bullet point 1
* bullet point 2
Reported by <First>.
Fixes #XXXX
## Test plan
- [x] TestName - description
Co-Authored-By: Claude <noreply@anthropic.com>
Rules:
Co-Authored-By: Claude <noreply@anthropic.com> at the end (not emoji "Generated with" lines)* prefix in Summary- [x] checkboxesWhen a change came from a report or request from outside the development team,
credit the originator by first
name only in both the commit message and the PR description: Reported by <First>. / Requested by <First>. on its own line (it feeds the release notes).
Do NOT add the line for the PR's own author, or for a developer of the project being changed — a developer asking for work on code they develop is ordinary planning, not an outside request. This is role-scoped: the same person can be an outside requester on one project and a developer on another (e.g. Mike requests features for Skyline, but is a primary Osprey developer — no credit line on Osprey changes). When in doubt, leave it out.
Full rules — placement, looking the name up from a support thread, the Brendan exception — in ai/docs/version-control-guide.md ("Crediting Reporters and Requesters").
/code-review <level> is the AI review gate. It replaced the retired
/pw-self-review (2026-07-25), which existed only because an early session
claimed it could not give an unbiased review of its own code. /code-review
is the native, maintained answer to that, and it gains capability upstream
without us maintaining prose.
Run it on the branch BEFORE gh pr create. It diffs master...HEAD, so
it needs no PR to exist. Reviewing first is cheaper for three reasons:
For Osprey there is no counter-argument: the expensive Perf/Regression config is manual/overnight and does NOT start on PR open, so opening early overlaps nothing. (For a Skyline PR that does auto-start something long, weigh that overlap against the wasted Copilot pass.)
/code-review <level> on the branch, before the PR exists. Fold the
fixes into the commits that will open the PR.
TestEncodeMatchesRustByteLayout pins each field to a
distinct offset with a distinct literal and does fail. Reproduce or
refute each finding against the code. Pushing back with the reason is
a legitimate outcome; auto-applying is not.max for code changes. The effort levels
(low / medium / high / xhigh / max) all run locally on the
Max subscription with NO extra billing, so use the highest effort the
change warrants. max is the ceiling. Drop to a lower level only for
genuinely trivial diffs - comment, doc, or rename-only changes - where
the wall time is the only thing being spent. For reference, xhigh on
#4460 took ~10.5 min and ~138k tokens./pw-respond <PR#> to address and resolve its threads.Do NOT use /code-review ultra (aka the deprecated /ultrareview) on
this project. It is a different animal from the effort levels above: a
billed multi-agent cloud review, and pwiz is too large for it.
Brendan's attempts repeatedly ran ~30 minutes, timed out, and returned
nothing useful while still incurring cost. max is both free under the
subscription and actually completes here, so there is no case for ultra on
pwiz.
The AI reviews do not stack. Copilot plus /code-review is already two
independent passes; do not add a third by rote.
Request human review only after the findings are settled and TeamCity is green.
Skyline/work/YYYYMMDD_feature_name
When in FEATURE COMPLETE or patch mode, bug fix PRs should be cherry-picked to the release branch:
ai/docs/release-cycle-guide.mdCherry pick to releaseCurrent release branch: Skyline/skyline_26_1 (check release-cycle-guide.md for updates)
Use /pw-pcommit or /pw-pcommitfull for guided commits.
See ai/docs/version-control-guide.md for complete specification.
ALWAYS load when working in pwiz_tools/Osprey (C# port), on maccoss/osprey (Rust), or debugging Osprey-Rust parity issues.
ALWAYS load when working on LabKey Server modules (MacCossLabModules, targetedms), in a LabKey enlistment directory, or on GitHub issues/PRs in LabKey repositories.
ALWAYS load when working in pwiz_tools/Skyline, on GitHub issues labeled 'skyline', or TODOs referencing Skyline code.
Invoke when starting an autonomous overnight session ("this is a nighttime autonomous session"). Sets a deep-investigation posture - premium on progress and high-definition findings, expects 5-8 hours of work without check-ins.
ALWAYS load when investigating bugs, failures, or unexpected behavior - ensures root cause analysis before attempting fixes.
Load when investigating handle leaks, memory leaks, or GC-LEAK failures. Covers handle counting, dotMemory profiling, and GC leak tracker workflows.