docs(workflow): require PRs to mirror their closing issue's triage labels (closes #237)#238
docs(workflow): require PRs to mirror their closing issue's triage labels (closes #237)#238cristim wants to merge 2 commits intofeat/multicloud-web-frontendfrom
Conversation
…bels (closes #237) Adds three mandatory workflow sections to CLAUDE.md: - Post-push CI watcher: arm a background watcher after every push so CI failures are caught and fixed within the same turn rather than sitting overnight. This rule already existed in the system-prompt CLAUDE.md but was absent from the base branch. - CodeRabbit loop: iterate CR passes to silence before declaring a PR done. Same gap — the rule existed locally but not on feat/multicloud-web-frontend. - PR labeling: every PR must carry the same triage labels as the issue it closes (priority/*, severity/*, urgency/*, impact/*, effort/*, type/*, triaged). Unlabeled PRs are invisible to priority-ordered queries. The section codifies the gh invocation, multi-close merge logic, and a closing checkpoint with the same shape as the CI-watcher rule. All three sections are inserted between ## Build & Test and ## Security Rules, matching the layout already present in the working-tree checkout.
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
📝 WalkthroughWalkthroughDocumentation added to ChangesWorkflow Procedure Documentation
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Suggested labels
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
|
@coderabbitai review |
✅ Actions performedReview triggered.
|
) A fork that pushes a PR, pings CodeRabbit, then exits leaves CR threads unresolved — exactly what happened to PRs #228, #229, #230, etc., where CR posted Actionable findings + Nitpicks that were never triaged. This adds a paragraph to the CR-loop section explicitly addressing the delegation case: subagent prompts MUST include the full loop with the exit criteria spelled out. Stops the failure mode where the rule is correctly stated for humans but doesn't get mirrored into fork prompts.
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
CLAUDE.md (1)
150-153: ⚡ Quick winAvoid manual
PR_NUMentry in a mandatory path.Using a hand-copied PR number is brittle and easy to misapply to the wrong PR. Prefer deriving it directly from the current branch context.
Safer PR number resolution
-PR_NUM=<the number gh just printed> +PR_NUM=$(gh pr view --repo LeanerCloud/CUDly --json number --jq '.number') ISSUE_NUM=<the issue this PR closes>🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@CLAUDE.md` around lines 150 - 153, Replace the brittle manual PR_NUM assignment after `gh pr create` with automatic resolution: capture the created PR number programmatically (e.g., parse `gh pr create` output or call `gh pr view` for the current branch) and set PR_NUM from that value; reference the variables PR_NUM and ISSUE_NUM and the command `gh pr create` in your changes so the script derives PR_NUM from the current branch/PR context rather than requiring manual entry.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@CLAUDE.md`:
- Around line 154-160: The script currently unconditionally runs gh pr edit
"$PR_NUM" --add-label "$LABELS", which fails when LABELS is empty; change it to
guard the call by checking the LABELS variable first (the LABELS assignment and
the gh pr edit "$PR_NUM" --add-label "$LABELS" invocation), e.g., only call gh
pr edit with --add-label when LABELS is non-empty and otherwise surface the
triage gap deterministically (for example add a specific fallback label like
"triage-needed" or post a comment) so the workflow does not break on empty label
payloads.
---
Nitpick comments:
In `@CLAUDE.md`:
- Around line 150-153: Replace the brittle manual PR_NUM assignment after `gh pr
create` with automatic resolution: capture the created PR number
programmatically (e.g., parse `gh pr create` output or call `gh pr view` for the
current branch) and set PR_NUM from that value; reference the variables PR_NUM
and ISSUE_NUM and the command `gh pr create` in your changes so the script
derives PR_NUM from the current branch/PR context rather than requiring manual
entry.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
| LABELS=$(gh issue view "$ISSUE_NUM" --repo LeanerCloud/CUDly --json labels \ | ||
| --jq '[.labels[].name | select(test("^(priority|severity|urgency|impact|effort|type)/")) ] | ||
| + (if [.labels[].name] | any(. == "triaged") then ["triaged"] else [] end) | ||
| | join(",")') | ||
|
|
||
| gh pr edit "$PR_NUM" --repo LeanerCloud/CUDly --add-label "$LABELS" | ||
|
|
There was a problem hiding this comment.
Handle empty $LABELS before calling gh pr edit --add-label.
If the closing issue has none of the selected label classes, this command can fail on an empty label payload and break the mandatory flow. Add a guard so the workflow stays deterministic and still surfaces the triage gap.
Proposed hardening
LABELS=$(gh issue view "$ISSUE_NUM" --repo LeanerCloud/CUDly --json labels \
--jq '[.labels[].name | select(test("^(priority|severity|urgency|impact|effort|type)/")) ]
+ (if [.labels[].name] | any(. == "triaged") then ["triaged"] else [] end)
| join(",")')
-gh pr edit "$PR_NUM" --repo LeanerCloud/CUDly --add-label "$LABELS"
+if [ -n "$LABELS" ]; then
+ gh pr edit "$PR_NUM" --repo LeanerCloud/CUDly --add-label "$LABELS"
+else
+ echo "No matching triage labels found on issue #$ISSUE_NUM; surface this in PR body/comment for human triage."
+fi📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| LABELS=$(gh issue view "$ISSUE_NUM" --repo LeanerCloud/CUDly --json labels \ | |
| --jq '[.labels[].name | select(test("^(priority|severity|urgency|impact|effort|type)/")) ] | |
| + (if [.labels[].name] | any(. == "triaged") then ["triaged"] else [] end) | |
| | join(",")') | |
| gh pr edit "$PR_NUM" --repo LeanerCloud/CUDly --add-label "$LABELS" | |
| LABELS=$(gh issue view "$ISSUE_NUM" --repo LeanerCloud/CUDly --json labels \ | |
| (if [.labels[].name] | any(. == "triaged") then ["triaged"] else [] end) | |
| | join(",")') | |
| if [ -n "$LABELS" ]; then | |
| gh pr edit "$PR_NUM" --repo LeanerCloud/CUDly --add-label "$LABELS" | |
| else | |
| echo "No matching triage labels found on issue #$ISSUE_NUM; surface this in PR body/comment for human triage." | |
| fi |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@CLAUDE.md` around lines 154 - 160, The script currently unconditionally runs
gh pr edit "$PR_NUM" --add-label "$LABELS", which fails when LABELS is empty;
change it to guard the call by checking the LABELS variable first (the LABELS
assignment and the gh pr edit "$PR_NUM" --add-label "$LABELS" invocation), e.g.,
only call gh pr edit with --add-label when LABELS is non-empty and otherwise
surface the triage gap deterministically (for example add a specific fallback
label like "triage-needed" or post a comment) so the workflow does not break on
empty label payloads.
|
Added a follow-up commit ( |
|
Tip For best results, initiate chat on the files or code changes.
[review] |
Summary
feat/multicloud-web-frontendbase branch.git pushso CI failures surface within the same turn.priority/*,severity/*,urgency/*,impact/*,effort/*,type/*,triaged) onto every new PR viagh pr edit --add-label, before pinging CodeRabbit. Unlabeled PRs are invisible to priority-orderedis:open label:priority/p*queries.The silent failure that motivated this PR: 10 PRs shipped in two recent batches, all merged-eligible after CR sign-off, none labeled — making them invisible to triage ordering.
Dogfooding
This PR itself is labeled with the issue's triage labels per the new rule (
type/docs,priority/p3,severity/low,urgency/eventually,impact/internal,effort/xs,triaged).Test plan
CLAUDE.mdcontains## PR labeling — mirror closing-issue labels (MANDATORY)between## CodeRabbit loopand## Security Rulesghinvocation with jq filter for all label classesSummary by CodeRabbit
Release Notes
No user-facing changes in this release. This update consists of internal documentation improvements to development procedures and workflows.