prowler-pr_skill

Overview

This skill creates pull requests for Prowler following the project template, changelog rules, and conventional commit title conventions. It accelerates PR creation by inspecting diffs, determining affected components, and populating the required template sections. It also enforces component-specific changelog and checklist requirements to reduce review friction.

How this skill works

The skill analyzes changes with git diff main...HEAD and inspects commits to determine affected components (SDK, API, UI, MCP, Docs). It fills the PR template sections (Context, Description, Steps to review, Checklist, License) and validates title format against Conventional Commits. It checks relevant workflows and files (conventional-commit.yml, pr-check-changelog.yml, labeler.yml, CODEOWNERS) and prompts for changelog updates, screenshots, API artifacts, or permission notes when required.

When to use it

• When preparing a pull request that modifies checks, providers, or core components.
• When updating SDK, API, UI, or MCP code and you need to ensure CHANGELOG entries.
• When committing changes that must follow Conventional Commit titles for CI checks.
• When creating draft PRs for early feedback or large refactors.
• When reviewing PR-related workflows, label rules, or CODEOWNERS changes.

Best practices

• Run tests and linters locally before creating the PR (make lint and test suites).
• Use git diff main...HEAD to list all changes and decide which template sections apply.
• Follow Conventional Commits in the PR title (feat:, fix:, docs:, chore:, refactor:, test:).
• Update the component-specific CHANGELOG.md if the change affects SDK/API/UI/MCP.
• Include testing instructions, screenshots for UI changes, and any API performance evidence when applicable.

Example use cases

• Add a new cloud check: generate a feat: PR, update prowler/CHANGELOG.md, note provider permission changes.
• Fix API response formatting: create a fix: PR, include EXPLAIN ANALYZE and API spec updates in api/CHANGELOG.md.
• UI tweak for a dashboard element: create a docs:/feat: PR with Mobile/Tablet/Desktop screenshots and ui/CHANGELOG.md entry.
• Routine maintenance or dependency updates: create a chore: PR and confirm no changelog entry is needed.
• Large refactor or multi-commit feature: create a draft PR first to collect early feedback.