Skip to content

feat: require customer impact section in PRs#1154

Open
sarinali wants to merge 1 commit intotrycua:mainfrom
sarinali:feat/require-customer-impact-pr
Open

feat: require customer impact section in PRs#1154
sarinali wants to merge 1 commit intotrycua:mainfrom
sarinali:feat/require-customer-impact-pr

Conversation

@sarinali
Copy link
Copy Markdown
Contributor

@sarinali sarinali commented Mar 11, 2026

Summary

  • Adds a PR template with Customer Impact and Visibility (External/Internal) sections
  • Adds a CI check (ci-check-customer-impact) that fails if the impact section is empty or no visibility checkbox is checked
  • Ensures every PR documents user-facing impact, whether it's a new feature, bug fix, or internal-only change

Customer Impact

  • Internal — not customer-facing (infra, CI, refactor, tooling, docs, tests)

This adds process tooling to improve how we document changes. No direct user-facing behavior change.

Test plan

  • Open a test PR with empty Customer Impact section → CI should fail
  • Open a test PR with filled section but no checkbox → CI should fail
  • Open a test PR with filled section and checkbox → CI should pass
  • Verify PR template auto-populates when creating a new PR

🤖 Generated with Claude Code

Summary by CodeRabbit

  • Chores
    • Introduced a standardized pull request template to improve documentation consistency.
    • Added automated validation to ensure customer impact information is properly documented in pull requests.

Adds a PR template with Customer Impact and Visibility sections, plus a
GitHub Action that blocks merging if the impact description is missing or
no visibility checkbox (External/Internal) is checked.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
@vercel
Copy link
Copy Markdown
Contributor

vercel Bot commented Mar 11, 2026

@sarinali is attempting to deploy a commit to the Cua Team on Vercel.

A member of the Team first needs to authorize it.

@coderabbitai
Copy link
Copy Markdown
Contributor

coderabbitai Bot commented Mar 11, 2026

📝 Walkthrough

Walkthrough

Two new files establish a standardized PR process: a template defining required sections including Customer Impact with visibility checkboxes, and a GitHub Actions workflow that validates the template's Customer Impact section is completed with at least one visibility option selected.

Changes

Cohort / File(s) Summary
Pull Request Template
.github/PULL_REQUEST_TEMPLATE.md
Introduces a structured PR template with sections for changes, rationale, customer impact visibility (External/Internal checkboxes), and test plan.
Customer Impact Validation Workflow
.github/workflows/ci-check-customer-impact.yml
Adds GitHub Actions workflow that validates PR descriptions contain a non-empty Customer Impact section and at least one visibility checkbox is selected; fails the check if validation conditions are unmet.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~12 minutes

Poem

🐰 A template hops into place,
With checkboxes neat and clean,
A workflow bounds through cyberspace,
Ensuring impact is seen! ✨
PRs now skip with purpose bright!

🚥 Pre-merge checks | ✅ 3
✅ Passed checks (3 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title 'feat: require customer impact section in PRs' directly and clearly summarizes the main change: implementing a requirement for customer impact documentation in pull requests.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Post copyable unit tests in a comment

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

Copy link
Copy Markdown
Contributor

@coderabbitai coderabbitai Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 2

🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.

Inline comments:
In @.github/workflows/ci-check-customer-impact.yml:
- Around line 18-22: The current extraction leaves the "### Visibility" scaffold
and its checklist in impactContent so stripped still appears non-empty; update
the cleaning step (the code that assigns stripped, which currently does
impactContent.replace(/<!--[\s\S]*?-->/g, '').trim()) to also remove the
Visibility section and any checklist lines: after stripping HTML comments, run a
regex to remove a "### Visibility" heading plus its following checkbox lines
(e.g. /###\s*Visibility[\s\S]*?(?=\n###|\n##|\n*$)/i) and/or remove standalone
checklist lines like /^\s*-\s*\[[ xX]\]\s*.*$/gm, then trim—so impactContent ->
stripped no longer counts the visibility scaffold as customer-impact text.
- Around line 24-27: The current visibility check (externalChecked,
internalChecked, hasVisibility) allows both boxes to be checked; change the
validation to require exactly one selection by replacing hasVisibility with a
check using XOR semantics (e.g., const exactlyOneVisibility = externalChecked
!== internalChecked) and treat any other case (neither or both true) as a
validation failure that fails the CI job and emits a clear error message
instructing the user to "Check one: External OR Internal" (reference
externalChecked, internalChecked, and the new exactlyOneVisibility variable).

ℹ️ Review info
⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 429f6fa0-2176-4056-8379-caf8538d50c9

📥 Commits

Reviewing files that changed from the base of the PR and between af26da0 and c5a8e1f.

📒 Files selected for processing (2)
  • .github/PULL_REQUEST_TEMPLATE.md
  • .github/workflows/ci-check-customer-impact.yml

Comment on lines +18 to +22
const impactMatch = body.match(/## Customer Impact\s*\n([\s\S]*?)(?=\n## |\n*$)/);
const impactContent = impactMatch ? impactMatch[1].trim() : '';

// Strip HTML comments
const stripped = impactContent.replace(/<!--[\s\S]*?-->/g, '').trim();
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

Don't count the visibility scaffold as customer-impact text.

Line 22 only removes HTML comments. The ### Visibility heading and checkbox labels are still left in stripped, so an untouched template — or a PR with only - [x] Internal and no explanation — will bypass the empty-impact check at Line 31.

Suggested fix
-            const stripped = impactContent.replace(/<!--[\s\S]*?-->/g, '').trim();
+            const stripped = impactContent
+              .replace(/<!--[\s\S]*?-->/g, '')
+              .replace(/^### Visibility\s*$/gim, '')
+              .replace(/^- \[[ xX]\] (External|Internal)\b.*$/gim, '')
+              .trim();
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In @.github/workflows/ci-check-customer-impact.yml around lines 18 - 22, The
current extraction leaves the "### Visibility" scaffold and its checklist in
impactContent so stripped still appears non-empty; update the cleaning step (the
code that assigns stripped, which currently does
impactContent.replace(/<!--[\s\S]*?-->/g, '').trim()) to also remove the
Visibility section and any checklist lines: after stripping HTML comments, run a
regex to remove a "### Visibility" heading plus its following checkbox lines
(e.g. /###\s*Visibility[\s\S]*?(?=\n###|\n##|\n*$)/i) and/or remove standalone
checklist lines like /^\s*-\s*\[[ xX]\]\s*.*$/gm, then trim—so impactContent ->
stripped no longer counts the visibility scaffold as customer-impact text.

Comment on lines +24 to +27
// Check that at least one visibility checkbox is checked
const externalChecked = /- \[x\] External/i.test(impactContent);
const internalChecked = /- \[x\] Internal/i.test(impactContent);
const hasVisibility = externalChecked || internalChecked;
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟡 Minor

Enforce exactly one visibility choice.

This currently accepts both checkboxes, which contradicts the template's "Check one" instruction and leaves the PR in an ambiguous state for release-note/customer-impact classification.

Suggested fix
             const externalChecked = /- \[x\] External/i.test(impactContent);
             const internalChecked = /- \[x\] Internal/i.test(impactContent);
-            const hasVisibility = externalChecked || internalChecked;
+            const checkedCount = Number(externalChecked) + Number(internalChecked);

             const errors = [];
@@
-            if (!hasVisibility) {
+            if (checkedCount === 0) {
               errors.push(
                 '❌ Missing visibility label.\n' +
                 'Check one of the boxes in the Visibility section:\n' +
                 '- [x] External — visible to customers\n' +
                 '- [x] Internal — not customer-facing'
               );
             }
+
+            if (checkedCount > 1) {
+              errors.push(
+                '❌ Ambiguous visibility label.\n' +
+                'Check exactly one box in the Visibility section.'
+              );
+            }
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In @.github/workflows/ci-check-customer-impact.yml around lines 24 - 27, The
current visibility check (externalChecked, internalChecked, hasVisibility)
allows both boxes to be checked; change the validation to require exactly one
selection by replacing hasVisibility with a check using XOR semantics (e.g.,
const exactlyOneVisibility = externalChecked !== internalChecked) and treat any
other case (neither or both true) as a validation failure that fails the CI job
and emits a clear error message instructing the user to "Check one: External OR
Internal" (reference externalChecked, internalChecked, and the new
exactlyOneVisibility variable).

@sarinali sarinali requested a review from f-trycua March 11, 2026 03:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant