Prowler pr

Skill prowler-cloud/prowler/skills/prowler-pr

Creates Pull Requests for Prowler following the project template and conventions. Trigger: When working on pull request requirements or creation (PR template sections, PR title Conventional Commits check, changelog gate/no-changelog label), or when inspecting PR-related GitHub workflows like conventional-commit.yml, pr-check-changelog.yml, pr-conflict-checker.yml, labeler.yml, or CODEOWNERS.From its SKILL.md

Install

npx -y skills add prowler-cloud/prowler --skill prowler-pr

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

What its file declares

Copied from the file, not written here

The file declares its own license as Apache-2.0. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.

SKILL.md

5.3 KB, as published. Nobody here has run it

PR Creation Process

Analyze changes: git diff main...HEAD to understand ALL commits
Determine affected components: SDK, API, UI, MCP, Docs
Fill template sections based on changes
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

<details>

<summary><b>Community Checklist</b></summary>

- [ ] This feature/issue is listed in [here](https://github.com/prowler-cloud/prowler/issues?q=sort%3Aupdated-desc+is%3Aissue+is%3Aopen) or roadmap.prowler.com
- [ ] Is it assigned to me, if not, request it via the issue/feature in [here](https://github.com/prowler-cloud/prowler/issues?q=sort%3Aupdated-desc+is%3Aissue+is%3Aopen) or [Prowler Community Slack](goto.prowler.com/slack)

</details>

- 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 <component>/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

# 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

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

Before Re-Requesting Review (REQUIRED)

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

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

Fixed in abc1234.
Agreed but deferred: Explain why it's out of scope for this PR and where it's tracked.
Disagreed: Reply with clear technical reasoning. Do not leave threads silently open.
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