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
See ai/todos/active/TODO-YYYYMMDD_feature.md
Co-Authored-By: Claude <[email protected]>
Rules:
* prefix (not -)pwiz-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.
## Summary
* bullet point 1
* bullet point 2
Fixes #XXXX
## Test plan
- [x] TestName - description
Co-Authored-By: Claude <[email protected]>
Rules:
Co-Authored-By: Claude <[email protected]> at the end (not emoji "Generated with" lines)* prefix in Summary- [x] checkboxesSkyline/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.