Plugin check: Run node "${CLAUDE_PLUGIN_ROOT}/scripts/check-version.js" — if it outputs a message, show it to the user before proceeding.

Manage Web Application Firewall

Configure the firewall for a Power Pages production site. The firewall is only available on production sites and in supported regions — the scripts detect and report eligibility issues. After rule changes, edge propagation takes up to one hour.

Initial request: $ARGUMENTS

Gotchas

• Website record id vs portal id. .powerpages-site/website.yml stores the website record id, not the portal id. Every script takes --portalId. Resolve once via website.js --websiteId during prerequisites.
• Never resolve by name. Site names can duplicate; only the website record id is safe.
• Async operations. enable.js and disable.js poll until the status reaches the target value (or timeout). delete-rules.js returns immediately (202) — verify via get-rules.js.
• Concurrent-operation guard. B003 means another enable/disable is in flight. Poll status until it settles, then retry.
• False-positive managed rule: disable via a rule override (EnabledState: "Disabled" inside RuleGroupOverrides — managed rule fields use PascalCase).
• First-match-wins. Rules evaluate in priority order. A geo-allow-then-default-deny pattern requires an explicit default-deny rule AFTER the allow.
• Custom rule priority range: 11–65000. Values 1–10 are reserved for platform-managed rules.
• set-rules.js is additive / update-only. Send only rules being created or modified. The service merges them; existing rules not in the payload are untouched.
• Use delete-rules.js to remove rules. set-rules.js cannot remove. Always use delete-rules.js --names.
• WAF state semantics — Created is the only "enabled" state. get-status.js returns value: "Created" when the firewall is enabled and actively filtering (counter-intuitive — the API does NOT use "Enabled"). Any other value (Disabled, None, Enabling, Disabling, Failed) means no active policy exists. MUST call get-status.js first and only invoke get-rules.js when value is Created — otherwise the rules endpoint returns a 500 and the whole firewall section gets skipped in the report.

Workflow

1. Prerequisites — Locate project, confirm sign-in, identify site, check eligibility
2. Check firewall state — Capture status and rules
3. Choose an action — Context-aware recommendation or question
4. Apply the change — Run the matching script, verify
5. Summarize and next steps — Present result, record usage, offer follow-ups

Task Tracking

Create tasks in three groups. Mark each in_progress when starting, completed when done.

1. Prerequisites

1.1 Locate the project, detect review mode

Use Glob to find **/powerpages.config.json. If $ARGUMENTS contains --review <out-dir>, remember the output directory — Steps 3–4 are skipped and Step 5 writes JSON only.

1.2 Resolve site identifiers

Read .powerpages-site/website.yml → extract id field → that is <WEBSITE_ID>.

If missing, the site has not been deployed. Tell the user and recommend /deploy-site. Stop. Do not resolve by name or URL.

Resolve to portalId:

node "${CLAUDE_PLUGIN_ROOT}/scripts/website.js" --websiteId "<WEBSITE_ID>"

Capture Id (portalId), Type, Name, WebsiteUrl. If exit code 2 → sign-in required (pac auth create or az login). If null → site not found in this environment. Stop in either case.

1.3 Eligibility

Check the Type field and the script responses for eligibility. The scripts return specific error codes for ineligible sites (non-production, unsupported region, restricted feature). Read references/commands.md § "Common error catalogue" and § "Regional availability" for the full list.

If the site is ineligible, tell the user in plain language what the limitation is and stop.

2. Check firewall state

2.1 Get status (always run first)

node "${CLAUDE_PLUGIN_ROOT}/skills/manage-firewall/scripts/get-status.js" --portalId "<PORTAL_ID>"

The response shape is { "status": "ok", "value": "<state>" }.

• Created — WAF is enabled and filtering. Proceed to 2.2 to fetch rules.
• Any other value (Disabled, None, Enabling, Disabling, Failed, etc.) — WAF is not enabled. MUST NOT call get-rules.js — the rules endpoint will return a 500 because no active policy exists to read. Skip 2.2 and treat the rules payload as empty: { "status": "ok", "body": { "CustomRules": [], "ManagedRules": [] } }.

If the status response is "status": "unsupported", tell the user the firewall is not available and stop.

2.2 Get rules (only when WAF is enabled)

node "${CLAUDE_PLUGIN_ROOT}/skills/manage-firewall/scripts/get-rules.js" --portalId "<PORTAL_ID>"

Both scripts output the full response as JSON to stdout. If get-rules.js returns "status": "unsupported", tell the user the firewall is not available and stop.

3. Choose an action

Skip in review mode.

MUST use plain language only with the user. Never use words like WAF, OWASP, ModSec, ruleset, geo-block, rate-limit, ASN, SocketAddr, or rule priority.

Each AskUserQuestion call is a separate call. Wait for the user's answer before asking the next.

Default approach

Analyze the site's current state (firewall status, existing custom rules, managed rules, region eligibility) and recommend the single most relevant action. Present the recommendation with a plain-language explanation of why. The user can accept, choose a different action, or ask to just view the current state.

• Firewall off → recommend enabling it.
• Firewall on, no custom rules → recommend adding a rule if there is a clear gap (e.g., no rate limiting). Otherwise, summarize the state and ask if the user wants to add a rule.
• Firewall on, rules exist → summarize what is configured and ask what the user wants to do.

If the site's state does not warrant a specific recommendation, do not force one — ask what the user wants to do.

MUST NOT proactively offer actions that reduce security (disabling the firewall, removing managed rules, weakening existing rules). If the user needs those, they will ask.

Option rules

When presenting options via AskUserQuestion:

• Keep label to 1–5 words. Include description on every option.
• Include preview only when the option represents a concrete change (create, update, or delete a rule) — use it to show the configuration that will be applied so the user can review before approving. Do not add preview to navigation or informational choices.
• Only show options that are actionable given the current state. Omit options for features the site cannot use (check references/commands.md § "Regional availability").
• Mark "(Recommended)" only when there is a genuine, context-based reason. If nothing stands out, do not mark any.
• When offering to add a rule type that already exists on the site, acknowledge it in the description — include the count and summarize what is configured so the user can decide whether to add or update.
• For path-based rules, reference actual page paths from the project structure when known. Fall back to generic language only when no project context is available.

Rule type follow-up

When the user picks "Add a rule", ask a follow-up for the rule type. The same option rules apply. Translate the answer into set-rules.js parameters — keep the user out of priority-numbering and rule-naming details. Read `refer