Cicd

CI/CD Lane (formerly pr-review)

Complete pull request lifecycle for the culture project. Follow every step in order. The skill was renamed from pr-review to cicd in culture 8.8.1 and rebased on agex pr in culture 11.1.0; existing prompts that say "use pr-review" still resolve here through the trigger phrases above.

agex pr (in agentculture/agex-cli) is the upstream for the five core PR-lifecycle verbs — lint, open, read, reply, delta. Culture used to vendor parallel scripts for each (create-pr-and-wait.sh, pr-batch.sh, pr-comments.sh, wait-and-check.sh, poll-readiness.sh); in 11.1.0 those were dropped in favor of delegating to agex. What's left in this skill is the culture-specific gating layer:

• status — SonarCloud quality gate, OPEN issues, hotspots, deploy preview URL, unresolved-inline-thread tally.
• await — composes agex pr read --wait with status and gates on Sonar ERROR / unresolved threads. The single command to run after pushing a fix when you want "wake me when this PR is triage-able."

Both extensions are filed upstream (agex-cli#41); when they land they migrate out of this skill.

Prerequisites

Hard requirements: agex (already a culture runtime dep — agex-cli>=0.13 in pyproject.toml), gh (GitHub CLI), jq, bash, python3 (stdlib only), curl (used by pr-status.sh).

If agex is not on PATH (e.g. running outside a culture venv):

uv tool install agex-cli   # or: pip install --user agex-cli

Step 1 — Branch

If you are on main, create a feature branch first:

git checkout -b <branch-name>

Branch naming conventions:

Step 1b — Check for existing PRs on the branch

Before adding new work to an existing branch, check if there's already an open PR:

gh pr view --json number,title,state --jq '{number,title,state}'

If the command fails with "no pull requests found", there is no open PR — proceed normally. Only act on the result if it returns valid JSON with state: "OPEN".

If an open PR exists and your new changes are unrelated to that PR's scope, stop and ask the user:

"There's an open PR (#N: 'title') on this branch. The new changes are unrelated to that PR. Would you like to merge the existing PR first before starting the new work?"

Wait for the user's answer before proceeding. If the user says yes, let them merge (never merge yourself). If they say continue, add the changes to the existing PR.

If the new changes ARE related to the existing PR, proceed normally — commit and push to the same branch.

Step 2 — Make changes, commit, push

1. Edit code

2. Run tests via the run-tests skill (parallel by default)

3. Bump the version (required before PR — version-check CI gate enforces this):

   echo '{"fixed":["..."]}' | python3 .claude/skills/version-bump/scripts/bump.py patch

4. Stage and commit:

   git add <files>
   git commit -m "$(cat <<'EOF'
   Commit message here.
   
   Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
   EOF
   )"

5. Push the branch (no --push flag on workflow.sh open anymore — see the Migration note at the end):

   git push -u origin <branch-name>

Step 3 — Create PR (and wait for an initial briefing in one shot)

Use workflow.sh open — it forwards to agex pr open --delayed-read, which creates the PR then polls 180s for an initial briefing (CI checks, SonarCloud gate + new issues, all comments, next-step footer). Automated reviewers (qodo, copilot, sonarcloud) need that window to post; checking sooner returns zero comments.

bash .claude/skills/cicd/scripts/workflow.sh open \
    --title "Short title" \
    --body-file /tmp/pr-body.md

Or pipe the body via heredoc on stdin:

bash .claude/skills/cicd/scripts/workflow.sh open --title "Short title" <<'EOF'
## Summary
- Bullet points describing changes

## Test plan
- [ ] Test items
EOF

agex pr open writes the body via --body-file to a tempfile under the hood, so large self-contained briefs don't hit the OS argv length limit. The auto-signature - <nick> (Claude) is appended by agex from the repo-root culture.yaml (first agent's suffix) — don't sign manually in the body.

If you must do it by hand (PR was opened earlier and you only need to fetch feedback now):

bash .claude/skills/cicd/scripts/workflow.sh read <PR_NUMBER>

Do not check for comments before the 3-minute mark on a brand-new PR. Empty comment lists in the first 1–2 minutes don't mean reviewers are done — they mean reviewers haven't started yet.

Step 4 — Wait another window if needed

If the initial briefing came back empty or thin, or you suspect a slow reviewer (or you just pushed a follow-up commit and want a fresh review pass), use workflow.sh read --wait for a deliberate poll:

bash .claude/skills/cicd/scripts/workflow.sh read <PR_NUMBER> --wait 180

This polls agex pr read up to 180 seconds, exiting when required reviewers have posted (or the cap hits). It is not open-ended polling — it's "give the reviewers one more deliberate window before deciding they're done." For the SonarCloud-gated variant that exits non-zero on unresolved threads, use workflow.sh await <PR> instead.

If two windows are also empty, fall back to one-shot reads spaced a minute apart:

bash .claude/skills/cicd/scripts/workflow.sh read <PR_NUMBER>
# if still empty:
sleep 60
bash .claude/skills/cicd/scripts/workflow.sh read <PR_NUMBER>

Three consecutive reads returning zero comments means reviewers are done / not configured; proceed to triage (or skip directly to merge if there's truly nothing to address).

Long waits — background polling

agex pr read --wait N polls in-session for up to N seconds. The Anthropic prompt cache has a 5-minute TTL; sleeping past it burns context every cache miss. Two ways to drive the wait:

• Synchronous — workflow.sh await <PR> after workflow.sh open. Fine when readiness is expected within ~5 minutes.
• Asynchronous — for longer waits, run agex pr read --wait NNN inside a background subagent (Agent tool, run_in_background: true) so the main session only pays the cache cost when readiness fires. The subagent's only job is to invoke agex pr read --wait and echo its headline back. The parent triages with workflow.sh await when the notification arrives.

Step 6 — Triage each comment

For every review comment, decide FIX or PUSHBACK with reasoning.

Default to FIX for: portability complaints (always valid for culture — recurring bug class), test or doc requests, style nits aligned with project conventions, exception-type mismatches (e.g. breaking reconnect loops), Sonar findings.

Default to PUSHBACK for: architecture opinions that conflict with the project CLAUDE.md (notably the all-backends rule and the citation pattern), greenfield false-positives.

Alignment-delta rule

If the PR touches CLAUDE.md, culture.yaml, or anything under .claude/skills/, run workflow.sh delta before declaring FIX or PUSHBACK on each comment. Note any sibling that needs a follow-up PR and mention it in your reply.