Parses API Gateway access logs (AWS API Gateway, Kong, Nginx) to detect BOLA/IDOR attacks, rate limit bypass, credential scanning, and injection attempts. Uses pandas for statistical analysis of request patterns and anomaly detection. Use when investigating API abuse or building API-specific threat detection rules.
59
68%
Does it follow best practices?
Impact
—
No eval scenarios have been run
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./skills/analyzing-api-gateway-access-logs/SKILL.mdQuality
Discovery
100%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
This is an excellent skill description that clearly communicates specific capabilities, includes rich trigger terms from the API security domain, and explicitly states both what the skill does and when to use it. The description is concise yet comprehensive, naming specific platforms, attack types, and tools, making it highly distinguishable from other security or log analysis skills.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Lists multiple specific concrete actions: parses API Gateway access logs from named platforms (AWS API Gateway, Kong, Nginx), detects specific attack types (BOLA/IDOR, rate limit bypass, credential scanning, injection attempts), and uses pandas for statistical analysis and anomaly detection. | 3 / 3 |
Completeness | Clearly answers both 'what' (parses API Gateway logs to detect specific attack types using pandas for statistical analysis) and 'when' (explicitly states 'Use when investigating API abuse or building API-specific threat detection rules'). | 3 / 3 |
Trigger Term Quality | Excellent coverage of natural terms a user would say: 'API Gateway', 'access logs', 'BOLA', 'IDOR', 'rate limit bypass', 'credential scanning', 'injection', 'API abuse', 'threat detection', plus specific platform names (AWS API Gateway, Kong, Nginx). These are terms security engineers would naturally use. | 3 / 3 |
Distinctiveness Conflict Risk | Highly distinctive with a clear niche: API Gateway log analysis for specific security threats. The combination of named platforms, specific attack types (BOLA/IDOR), and the API-specific focus makes it very unlikely to conflict with general log analysis or broader security skills. | 3 / 3 |
Total | 12 / 12 Passed |
Implementation
37%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
The skill provides a reasonable starting point with executable BOLA and credential scanning detection code, but it falls short by leaving three of its five listed detection patterns without concrete implementation. The boilerplate 'When to Use' and 'Prerequisites' sections add little value, and the lack of a sequenced investigation workflow with validation steps limits its practical utility for SOC analysts.
Suggestions
Add executable code examples for the remaining detection patterns (rate limit bypass, injection detection, unusual HTTP methods) instead of just listing them.
Structure the content as a sequenced investigation workflow: e.g., 1) Load and validate logs, 2) Run each detection pattern, 3) Correlate findings, 4) Generate report — with explicit validation checkpoints.
Remove or drastically shorten the generic 'When to Use' and 'Prerequisites' sections; replace with a one-line scope statement and a pip install command for dependencies.
Add concrete thresholds and decision criteria (e.g., what constitutes a suspicious count, when to escalate) to make the guidance more actionable.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The 'When to Use' and 'Prerequisites' sections contain generic filler that Claude already knows (e.g., 'Familiarity with security operations concepts,' 'Appropriate authorization for any testing activities'). The core detection content is reasonably lean, but the surrounding boilerplate wastes tokens. | 2 / 3 |
Actionability | The BOLA detection and 401 surge examples are executable Python, which is good. However, patterns 2, 4, and 5 from the key detection list are described abstractly with no code or concrete commands. Rate limit bypass via header manipulation and injection detection are mentioned but never shown. | 2 / 3 |
Workflow Clarity | There is no clear multi-step workflow for investigating API abuse. The skill presents isolated code snippets without sequencing them into an investigation process, and there are no validation checkpoints, thresholds for escalation, or feedback loops for refining detection. | 1 / 3 |
Progressive Disclosure | The content is organized into sections (When to Use, Prerequisites, Instructions, Examples), which provides some structure. However, there are no references to supporting files for the detection patterns that lack code, and the inline content is thin enough that it doesn't need splitting but thick enough in its boilerplate sections to feel poorly balanced. | 2 / 3 |
Total | 7 / 12 Passed |
Validation
90%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 10 / 11 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
frontmatter_unknown_keys | Unknown frontmatter key(s) found; consider removing or moving to metadata | Warning |
Total | 10 / 11 Passed | |
0f429d0
Table of Contents
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.