network-inspection
Use when debugging API calls, checking network requests, inspecting HTTP traffic, finding failed requests, analyzing response data, or investigating API errors. Provides detailed request/response analysis.
79
76%
Does it follow best practices?
Impact
Pending
No eval scenarios have been run
Risky
Do not use without reviewing
Optimize this skill with Tessl
npx tessl skill review --optimize ./plugins/product-design/skills/network-inspection/SKILL.mdQuality
Discovery
89%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 a well-structured description with excellent trigger term coverage and clear 'Use when' guidance. The main weakness is that the 'what' portion is somewhat vague - it mentions 'detailed request/response analysis' but doesn't enumerate specific capabilities like inspecting headers, viewing payloads, filtering by status codes, or timing analysis.
Suggestions
Expand the capabilities section with specific actions like 'inspect headers, view request/response bodies, filter by status code, analyze timing data'
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (API calls, HTTP traffic, network requests) and mentions 'detailed request/response analysis' but doesn't list specific concrete actions like 'capture headers', 'filter by status code', or 'export HAR files'. | 2 / 3 |
Completeness | Explicitly answers both what ('Provides detailed request/response analysis') and when ('Use when debugging API calls, checking network requests, inspecting HTTP traffic, finding failed requests, analyzing response data, or investigating API errors'). | 3 / 3 |
Trigger Term Quality | Excellent coverage of natural terms users would say: 'debugging API calls', 'network requests', 'HTTP traffic', 'failed requests', 'response data', 'API errors' - these are all phrases users naturally use when needing this skill. | 3 / 3 |
Distinctiveness Conflict Risk | Clear niche focused specifically on HTTP/API debugging with distinct triggers like 'HTTP traffic', 'API errors', 'network requests' - unlikely to conflict with general coding or document skills. | 3 / 3 |
Total | 11 / 12 Passed |
Implementation
62%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This skill provides comprehensive network debugging guidance with well-structured reference tables and a clear workflow. However, it's verbose with information Claude already knows (HTTP status codes, common headers) and lacks fully executable tool examples. The debugging report template is valuable, but the core tool usage instructions need more concrete, copy-paste ready examples.
Suggestions
Remove or drastically condense the HTTP status code reference tables - Claude knows what 404 and 500 mean; keep only the 'Debugging Action' column as a quick reference
Add complete, executable tool call examples with realistic parameters and expected response structures, not just tool names with placeholders
Move reference tables (status codes, headers, timing thresholds) to a separate REFERENCE.md file, keeping the main skill focused on the debugging workflow
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The HTTP status code reference tables explain concepts Claude already knows well (what 200, 404, 500 mean). The tables are well-organized but add significant token overhead for information that's common knowledge. The debugging-specific columns add some value but could be more condensed. | 2 / 3 |
Actionability | Tool names are provided but without complete parameter examples or expected outputs. The workflow steps are clear but lack executable code - just tool names with placeholder parameters like 'request-id-here'. The debugging report template is useful but the actual tool usage examples are incomplete. | 2 / 3 |
Workflow Clarity | The 4-step workflow is clearly sequenced with logical prioritization (5xx first, then 4xx, then slow, then successful). The analysis checklist for each request component is explicit. The integration with console debugging provides good cross-referencing for comprehensive debugging. | 3 / 3 |
Progressive Disclosure | Content is reasonably organized with clear sections, but everything is in one monolithic file. The extensive reference tables (status codes, headers, timing thresholds) could be split into separate reference files, keeping the main skill focused on the workflow and tool usage. | 2 / 3 |
Total | 9 / 12 Passed |
Validation
100%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 11 / 11 Passed
Validation for skill structure
No warnings or errors.
- Repository
- jpoutrin/product-forge
- Commit
0ebe7ae
- Reviewed
Table of Contents
Is this your skill?
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.