Help us improve
Share bugs, ideas, or general feedback.
From prowler
Makes cloud accounts compliant with security/industry frameworks via iterative Prowler Cloud setup, reporting, and remediation. Handles provider configuration, framework selection, and step-by-step compliance checking.
npx claudepluginhub prowler-cloud/prowler --plugin prowlerHow this skill is triggered — by the user, by Claude, or both
Slash command
/prowler:framework-compliance-triageThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Iterative, interactive flow that takes a cloud account through setup, reporting, and remediation until it complies with the chosen security or industry framework.
Analyzes compliance gaps for frameworks like PCI DSS, SOC 2, CIS AWS: ranks failing controls by impact, quick wins, account/business unit breakdowns, remediation plans. Use for compliance status or failure queries.
Audits Terraform, Kubernetes, and cloud configs against CIS, SOC 2, HIPAA using Checkov, tfsec, OPA. Generates compliance reports, remediation patches, and CI/CD gating steps.
Runs AWS CLI checks against CIS AWS Foundations, PCI-DSS, HIPAA, and SOC 2 benchmarks for IAM, logging, networking, and more. Use for audits and compliance monitoring.
Share bugs, ideas, or general feedback.
Iterative, interactive flow that takes a cloud account through setup, reporting, and remediation until it complies with the chosen security or industry framework.
This skill uses checkpoints to mark moments where you must stop, post a clear question or summary to the user, and wait for the reply before continuing. Each checkpoint is rendered like this:
Checkpoint —
What to present, and what to wait for.
Treat every checkpoint as a hard stop:
Checkpoint — Provider and framework selection
If the user has not already specified both the provider and the framework, ask explicitly and wait for the answer. If they have specified them in their opening message, skip this checkpoint.
Confirm both are supported by the Prowler Hub MCP:
prowler_hub_list_providers.prowler_hub_list_compliances, passing the provider id as the only element of the provider input list.If the framework is not supported, tell the user, suggest they request it or contribute it themselves, and end the flow. Otherwise continue.
Verify the Prowler MCP connection by calling prowler_app_search_providers — a successful response returns the list of providers. If the call fails, walk the user through troubleshooting: internet connectivity, Prowler Cloud credentials, and permissions on the Prowler Cloud account.
For getting accurate information about configurations use prowler_docs_search to pull relevant instructions from the Prowler documentation.
Call prowler_app_search_providers to check whether the target provider (AWS account, Azure Subscription, GitHub Account...) exists in the user's Prowler Cloud account. Handle the result based on what's found:
prowler_docs_search.prowler_docs_search.Checkpoint — Account selection (conditional: more than one account of the chosen provider is configured)
List the accounts with helpful detail (account name, uid, last scan date) and ask which one to use. Wait for the answer. If only one account exists, skip this checkpoint and use it.
The flow needs at least one completed scan with a compliance report available.
Look for a completed scan first: call prowler_app_list_scans with the selected provider_id and state: ["completed"], then call prowler_app_get_compliance_overview with each scan_id to find one whose compliance report is available. If one is found, continue to the next section.
If no completed scan has a report, call prowler_app_list_scans again with state: ["available", "executing"] to detect a scan in progress.
Checkpoint — Scan-in-progress decision (conditional: an in-progress scan was detected)
Tell the user a scan is already running and ask whether to wait for it to complete or start a fresh one. Wait for the answer.
If no scan is running (or the user chose to start a fresh one), trigger a new scan with prowler_app_trigger_scan and the provider_id. The link https://cloud.prowler.com/scans?filter%5Bprovider_uid__in%5D={provider_id} lets the user monitor progress.
When a scan is in progress (either pre-existing and elected to wait, or just triggered), stop the flow and ask the user to return when it's completed — restart this section to re-check the results.
Every iteration of the remediation loop reads and writes a single markdown file per provider account and framework, stored at ${CLAUDE_PROJECT_DIR}/.prowler/compliance-<compliance_id>-<provider_uid>.md. Sanitize <provider_uid> to [a-zA-Z0-9_-] by replacing anything else with -. Create .prowler/ if missing.
Across iterations, edit only: status tags on failed requirements and their findings, the per-requirement Fix plan / Fix applied sub-bullets added during sections 3.3–3.4, the Global remediation approach block, and the Activity log (append-only, newest on top). Requirement descriptions, finding IDs, and the entire Manual review requirements section are read-only after first render.
Status taxonomy for failed requirements and their findings:
[FAIL] — failing in the latest scan.[IN PROGRESS] — picked up by section 3.3.[FIXED-UNVERIFIED] — remediation applied; not yet confirmed.[PASS] — passing in the latest scan (set when a rescan in section 3.5 confirms the fix).[SKIPPED] — user explicitly deferred.A fresh report is rendered like this (substituting values from the prowler_app_get_compliance_framework_state_details Prowler MCP tool response):
# Compliance report: <compliance_id>
**Provider account**: <display name + uid>
**Scan ID**: <scan_id>
**Generated**: <ISO timestamp>
**Last update**: <ISO timestamp>
**Status**: <passed>/<total> passing (<pct>%) · <failed> failing · <manual_review> manual review
## Global remediation approach
<!-- Filled by section 3.1. -->
- **Primary tool**: _Terraform | Azure CLI | AWS CLI | web console | mixed_
- **Mode**: _Claude autonomous | Claude-assisted_
- **Notes**:
## Activity log
- <ISO timestamp> — Report initialized from scan `<scan_id>`.
## Failed requirements
### <code> — [FAIL]
**Description**: <text>
**Findings** (<n>):
- [FAIL] `<finding_id>`
## Manual review requirements
- **<code>** — [PENDING]: <description>
Resolve the report path for the current compliance_id and provider account.
If the file does not exist, call prowler_app_get_compliance_framework_state_details for the target scan, render the template above, and write the file with one initialization entry in the activity log.
If the file exists, read it and compare its Scan ID to the target scan from section 1.3. When the scan matches, reuse the file and summarize remaining [FAIL] and [IN PROGRESS] items in chat.
Checkpoint — Report refresh (conditional: the file's
Scan IDdiffers from the current target scan)Tell the user the report on disk was generated from a different scan and ask whether to refresh it from the new scan. Wait for the answer.
On confirmation, regenerate the failed-requirements section from the new prowler_app_get_compliance_framework_state_details response, carry forward the Global remediation approach block and the full activity log, and append an activity-log entry noting the scan change.
Once the file is current, surface the top failing requirements in chat: sort by finding count descending, show the top 5 with their codes and counts, and point to the file path for the full list.
Two modes are available:
If the user phrases their request as "just do it" or similar, treat that as autonomous with the batch-plan confirmation still required — the confirmation is a property of the skill, not the user's verbosity preference.
Checkpoint — Global remediation approach
Ask the user which tool to use for fixes (Terraform, gh / az / aws CLI, web console, mixed...) and which mode to operate in. Wait for the answer before continuing. This checkpoint is non-negotiable: never assume a default tool, and never assume autonomous mode.
Once answered, write the values into the Global remediation approach block of the report file.
Checkpoint — Overwriting an existing approach (conditional: the block is already populated from a previous session)
Show the previous values and the new ones, and ask the user to confirm before overwriting. Wait for the answer.
In assisted mode, skip this section — the per-requirement gate in §3.3 confirms each fix as it comes up. Only run §3.2 in autonomous mode, where the loop will otherwise apply fixes without further input.
Before touching anything, post a single chat summary covering every [FAIL] requirement:
[SKIPPED] with the reason.Checkpoint — Batch fix plan approval (conditional: autonomous mode)
Post the grouped plan and wait for explicit confirmation. Do not start any fix before the user replies.
Once approved, the loop proceeds through the batch without further prompts unless something deviates from the approved plan.
Pick the first [FAIL] requirement at the top of the failed-requirements section. Move its status and every finding under it to [IN PROGRESS], and add a **Fix plan**: sub-bullet describing what will be done.
Call prowler_app_get_finding_details for each finding_id to retrieve the failing resource and the Prowler Hub's remediation guidance for that check using the tool prowler_hub_get_check_details with the check_id from the finding details. Summarize the guidance in chat, and append it to the **Fix plan** note for each finding.
If a finding does not apply to the target resource (Organization-only check on a User account, paid-tier feature, missing resource type, etc.), set the requirement status to [SKIPPED] with the reason, log it in the activity log, and move on without attempting the fix — even if it was missed during §3.2.
Checkpoint — Per-requirement approval (conditional: assisted mode)
Post the per-requirement plan in chat — resource, command, side effects, reversibility — and wait for confirmation before moving to §3.4. In autonomous mode, post the plan for transparency but proceed unless it deviates from the batch plan agreed in §3.2.
Read the remediation guidance returned in §3.3, identify the root cause, and apply the fix using the tool defined in the Global remediation approach block. After applying, verify via the same tool that applied the fix or via a provider API call when applicable. If the re-read shows the change did not land, leave the status at [IN PROGRESS], surface the error to the user, and stop the loop for this requirement.
When the change is in place, append a **Fix applied**: <tool, summary, refs> sub-bullet to the requirement, move each fixed finding to [FIXED-UNVERIFIED], and add one activity-log entry describing the change. If no programmatic verification was possible (e.g. web console action), note in the activity log that confirmation depends on the rescan in §3.5.
Move to the next [FAIL] requirement and repeat from section 3.3.
Checkpoint — Rescan trigger (conditional: no
[FAIL]requirements remain; all are[FIXED-UNVERIFIED]or[SKIPPED])Summarize what was applied, list any
[SKIPPED]items with reasons, and ask whether to trigger a fresh scan withprowler_app_trigger_scanto verify the fixes end-to-end. Wait for the answer.
On confirmation, trigger the rescan. When it completes, restart section 2.1 with the carry-forward path — requirements no longer in the new FAIL list move to [PASS], anything still failing reverts to [FAIL] with the previous fix attempt visible in the activity log.