PR Raise

When the user is ready to open a pull request from a feature branch. Raises the PR with compass pr create and immediately posts an @claude comment to trigger an interactive code review.

By the time this skill runs, the work is done from the developer's side — review is a post-done validation activity, not a continuation of implementation. That means task/story bookkeeping (see agile-close-task) happens before this skill, not after review approves. A PR should never need a bookkeeping-only commit once CI has gone green post-review — that wastes a full CI cycle for a change with no code content. See Work a task through to merged PR for why the lifecycle is ordered this way.

1. MANDATORY — classify the change and run only the matching checks locally first, and do not skip this even under time pressure. CI runs no PR gate (the pr.yml workflow was deleted), so this step is the only thing that catches a broken build before review, and the PR description is the only record that it happened.

   Classify the diff against its branch point:

   git diff origin/main...HEAD --name-only
   

   Bucket every changed file with the rule table. A mixed change runs the union of its classes' checks:

   Class	Paths	Checks to run
   docs	doc/*, assets/*, .claude/*, *.md, *.org, projects/*/modeling/* (org/puml/png), external/* (vendored)	Site build (+ codegen drift when projects/*/modeling/* changed)
   code (C++)	projects/ores.* C++ sources and headers, *.cmake, CMakeLists.txt	Full build + ctest; roundtrip; drift checks; CDash experimental
   ci	.github/*, projects/ores.codegen/library/templates/*	Site build; roundtrip; drift checks
   python tooling	projects/ores.compass/*, projects/ores.codegen/* (non-template)	Compass test suite; drift checks
   anything else	any path matching no bucket above	Code class checks (full build + ctest; roundtrip; drift checks)

   The catch-all defaults an unmatched path to the code class — a change that matches no bucket still gets the full build.

   The projects/*/modeling/* paths under docs carry a codegen-drift exception: the retired pr.yml codegen-drift job ran unconditionally, because a model-only edit classifies as docs and would otherwise skip the check that catches forgotten regeneration. A change touching the modeling paths also runs the codegen drift checks (compass build --direct codegen_templates then check_component_drift.py).

   The checks:

   • Site build: ./compass.sh build --direct site.

   • Full build and tests (code class only; run both via compass, never raw cmake --build or ctest — it takes the host-wide build lock so a concurrent build in another worktree can't corrupt this one; see How do I build the system?):

     ./compass.sh build --preset <preset>
     ./compass.sh test run --preset <preset>
     

   • Roundtrip: python3 scripts/ore_domain_roundtrip_check.py.
   • cmake-sources drift: python3 projects/ores.codegen/scripts/regenerate_cmake_component_files.py --all --check (when a source file was added or removed, regenerate with --all instead; see codegen-sync-cmake-sources).
   • codegen drift: ./compass.sh build --direct codegen_templates then python3 projects/ores.codegen/scripts/check_component_drift.py --components refdata,reporting,marketdata.
   • Compass test suite: projects/ores.compass/venv/bin/pytest projects/ores.compass/tests -q.
   • CDash experimental (code class; visibility only): ./compass.sh test run --preset <preset> --cdash Experimental.

   Do not raise the PR until the checks for the class are clean. Note the class(es), the checks run, and the results (e.g. "doc-only; local site build clean" or "code; build clean (<preset>); ctest 142/142 passed") — they go into the PR description in step 2.

2. Close task/story bookkeeping now, if not already done. The task should already be DONE with its * Result written and the parent story/sprint rows synced (per agile-close-task) — do this before raising the PR, not after review. If it's not done yet, do it now, as part of the same commit set the PR will contain from the start.

3. Raise the PR, including the change class and the verification from step 1 as an explicit --change bullet so it's visible in the PR description (reviewers and future readers can see it happened without asking):

   ./compass.sh pr create --title "[component] Description" \
     --summary "What changes, why." \
     --change "First change" --change "Second change" \
     --change "Verification: <class>; <checks run and results>"
   

   Compass validates the title, builds the body, pushes the branch, opens the PR, records it on the task, and stamps the journal. Note the PR number it prints.

4. Trigger Claude review by posting a PR comment:

   gh pr comment <N> --body "@claude please review this pull request"
   

   This starts an interactive review session. Claude will post a progress-tracking comment and then inline findings once it is done.

• How do I create a PR? — compass pr create details, title conventions, body structure.

• GitHub recipes — full GitHub recipe index.
• Agile close task — close bookkeeping before raising the PR, not after review.
• Work a task through to merged PR — the full lifecycle this fits into.