Agent skill · aliyun
alibabacloud-waf-rule-effectiveness-check
Diagnose why a configured Alibaba Cloud WAF 3.0 custom protection rule (custom ACL, CC / rate limiting, scan protection, IP blacklist) is not working: name the first broken link in the chain and hand back the console fix path. Read-only checks of configuration state only; never sends test traffic. Use it when a customer says a rule has no effect at all, a rule matches in the logs but nothing is blocked, an attack that should have been blocked got through, a rule worked yesterday but not today, or a CC or rate-limiting rule does not trigger or bans far too widely. Not for: explaining why one specific request was blocked or looking it up by trace_id, whitelist rule effectiveness itself, live attack sample validation, built-in rule toggles, config export, or reports. Triggers: "规则不生效", "规则配了但不生效", "自定义规则不生效", "预期拦未拦", "该拦的没拦住", "漏拦截", "规则命中但没拦", "规则昨天还好今天失效", "CC不触发", "误封面过大", "规则为什么没生效", "WAF rule not effective", "rule not taking effect", "rule hit but not blocked
What it needs
About 12k tokens when loaded.
What this skill does
WAF Custom Rule Effectiveness Check Answers one precise question: is this custom rule currently in effect for this protection object, and if not, which link is broken. Statically checks the configuration chain; sends no test traffic. WAF 3.0 only (waf-openapi 2021-10-01). Use when the customer reports "I configured the rule but it does not work / it should have been blocked but was not / CC does not trigger or the ban scope is too wide". Scope: user-defined rules with DefenseOrigin = custom (customacl / cc / rate limiting / scan / blacklist). ❗ Hard Constraints (highest priority in this document) Interaction stance — confirm first, query second. Asking the customer for a required input that is missing or ambiguous, and then waiting for the answer, is correct behaviour in this skill — never a failure to act. Guessing an input, or querying around the gap, is the failure. 1. Never take the customer's "I configured it" at face value — saying it was configured does not mean the rule exists, is enabled, and is bound. Verify all platform-side state with read-only APIs (Phase 1→3). 2. When the disposal action is observe/monitor mode, that IS the root cause — do not demote it to a "side note", and do not switch to hunting for binding / timing / config-rollout explanations instead. Having observe-mode evidence in hand yet picking a self-consistent but wrong explanation is rationalized convergence and is explicitly forbidden (see Phase 3, element ④). 3. A failed or empty query is NOT proof of absence — mark it "not retrieved" and state how that limits the conclusion. Never infer "the rule / binding does not exist" and close the case on that basis. 4. No region or no matchedhost → call nothing at all. Both are prerequisites for every query in this skill. When either is missing, ask the customer and WAIT for the answer: not one API call, not even describe-instance, and never guess a region from the domain name. …
How to use it
Reference it in AdaL, Claude Code, Cursor or any coding agent — nothing to install:
@skills aliyun/alibabacloud-waf-rule-effectiveness-check