prowler-pr

PR Creation Process

1. Analyze changes: git diff main...HEAD to understand ALL commits
2. Determine affected components: SDK, API, UI, MCP, Docs
3. Fill template sections based on changes
4. Create PR with gh pr create

PR Template Structure

### Context

{Why this change? Link issues with `Fix #XXXX`}

### Description

{Summary of changes and dependencies}

### Steps to review

{How to test/verify the changes}

Checklist

• This feature/issue is listed in here or roadmap.prowler.com
• Is it assigned to me, if not, request it via the issue/feature in here or Prowler Community Slack

• Are there new checks included in this PR? Yes / No
  • If so, do we need to update permissions for the provider?
• Review if the code is being covered by tests.
• Review if code is being documented following https://github.com/google/styleguide/blob/gh-pages/pyguide.md#38-comments-and-docstrings
• Review if backport is needed.
• Review if is needed to change the Readme.md
• Ensure a changelog fragment is added under /changelog.d/, if applicable.

SDK/CLI

• Are there new checks included in this PR? Yes / No
  • If so, do we need to update permissions for the provider? Please review this carefully.

UI (if applicable)

• All issue/task requirements work as expected on the UI
• Screenshots/Video - Mobile (X < 640px)
• Screenshots/Video - Tablet (640px > X < 1024px)
• Screenshots/Video - Desktop (X > 1024px)
• Ensure a changelog fragment is added under ui/changelog.d/

API (if applicable)

• All issue/task requirements work as expected on the API
• Endpoint response output (if applicable)
• EXPLAIN ANALYZE output for new/modified queries or indexes (if applicable)
• Performance test results (if applicable)
• Any other relevant evidence of the implementation (if applicable)
• Verify if API specs need to be regenerated.
• Check if version updates are required.
• Ensure a changelog fragment is added under api/changelog.d/

License

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

## Component-Specific Rules

| Component | Changelog fragment | Extra Checks |
|-----------|--------------------|--------------|
| SDK | `prowler/changelog.d/` | New checks → permissions update? |
| API | `api/changelog.d/` | API specs, version bump, endpoint output, EXPLAIN ANALYZE, performance |
| UI | `ui/changelog.d/` | Screenshots for Mobile/Tablet/Desktop |
| MCP | `mcp_server/changelog.d/` | N/A |

## Commands

```bash
# Check current branch status
git status
git log main..HEAD --oneline

# View full diff
git diff main...HEAD

# Create PR with heredoc for body
gh pr create --title "feat: description" --body "$(cat <<'EOF'
### Context
...
EOF
)"

# Create draft PR
gh pr create --draft --title "feat: description"

Title Conventions

Follow conventional commits:

• feat: New feature
• fix: Bug fix
• docs: Documentation
• chore: Maintenance
• refactor: Code restructure
• test: Tests

Before Creating PR

1. ✅ All tests pass locally
2. ✅ Linting passes (make lint or component-specific)
3. ✅ Changelog fragment added (if applicable)
4. ✅ Branch is up to date with main
5. ✅ Commits are clean and descriptive

Before Re-Requesting Review (REQUIRED)

Resolve or respond to every open inline review thread before re-requesting review:

1. Agreed + fixed: Commit the change. Reply with the commit hash so the reviewer can verify quickly:

   Fixed in abc1234.

2. Agreed but deferred: Explain why it's out of scope for this PR and where it's tracked.
3. Disagreed: Reply with clear technical reasoning. Do not leave threads silently open.
4. Re-request review only after all threads are in a clean state — either resolved or explicitly responded to.

Rule of thumb: A reviewer should never have to wonder "did they see my comment?" when they re-open the PR.

Resources

• Documentation: See references/ for links to local developer guide