| name | pr |
| description | The full pipeline from "code is ready" to "ready to merge" — pre-push verification, three-way self-review, opening the PR, watching CI and review threads. Read BEFORE committing, opening a PR, or checking on an open one. |
PR Pipeline
The development flow is: branch off main → write code (discussing requirements with the maintainer) → self-review and fix → open the PR → watch CI and reviews until everything is handled → report that it is ready. The maintainer merges — never merge yourself.
Branch
- Always branch from freshly fetched
origin/main — git fetch origin && git checkout -b <type>/<short-topic> origin/main — never from the local main. <type> uses the conventional-commit types, e.g. fix/queue-cancel, refactor/codec-macros.
Pre-push verification (every push, not just the first)
Never push anything unverified — "it compiles" is not verified, and CI is not a debugger.
pixi run format.- Both test suites pass locally (the test skill): unit tests via
pixi run test (builds the debug preset and runs ctest, which handles the snapshot dir), and pixi run integration-test. Every failure on the branch is yours to fix now — even if it looks pre-existing (main is green), and never by skipping, disabling, or weakening the test.
Self-review (before opening)
Commit all work first — the review diff only sees commits, so a dirty worktree means the reviewers inspect an incomplete patch (git status must be clean). Then launch 3 parallel subagents to review the full diff (git diff origin/main...HEAD — never against the local main, which goes stale) independently, and fix everything they report before opening:
