juicebox-incident-runbook
Juicebox incident response. Trigger: "juicebox incident", "juicebox outage".
42
43%
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 ./plugins/saas-packs/juicebox-pack/skills/juicebox-incident-runbook/SKILL.mdQuality
Discovery
22%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 description is severely underdeveloped. It names a product ('Juicebox') and a broad category ('incident response') but provides no concrete actions, no explanation of what the skill does, and no explicit 'Use when...' guidance. The two trigger terms are a start but far too limited for reliable skill selection.
Suggestions
Add specific concrete actions the skill performs, e.g., 'Diagnoses Juicebox service outages, checks system health dashboards, escalates to on-call engineers, and drafts incident postmortems.'
Add an explicit 'Use when...' clause, e.g., 'Use when Juicebox services are down, experiencing errors, or when the user reports a Juicebox production issue.'
Expand trigger terms to include natural variations users would say, such as 'Juicebox is down', 'Juicebox error', 'Juicebox alert', 'Juicebox production issue', 'Juicebox service degradation'.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | The description says 'Juicebox incident response' which is extremely vague. It names a domain ('incident response') but lists zero concrete actions—no mention of what the skill actually does (e.g., diagnose, escalate, notify, create postmortems, check logs). | 1 / 3 |
Completeness | The 'what' is essentially absent—'incident response' is too vague to understand what the skill actually does. While trigger terms are listed, there is no explicit 'Use when...' clause, and the what is so weak that completeness is severely lacking. | 1 / 3 |
Trigger Term Quality | It includes two trigger terms ('juicebox incident', 'juicebox outage') which are relevant but very limited. Missing common variations like 'Juicebox is down', 'Juicebox error', 'Juicebox alert', 'production issue', 'service degradation', etc. | 2 / 3 |
Distinctiveness Conflict Risk | The 'Juicebox' qualifier provides some distinctiveness, making it unlikely to conflict with generic incident response skills. However, the description is so vague that it could overlap with any Juicebox-related operational skill (monitoring, alerting, debugging, etc.). | 2 / 3 |
Total | 6 / 12 Passed |
Implementation
64%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This is a solid incident runbook with strong actionability — executable diagnostic commands, specific playbooks, and a ready-to-use communication template. Its main weaknesses are some redundancy between sections (error handling table vs. playbooks), unnecessary contextual explanation in the overview, and missing explicit validation checkpoints in the workflows. Tightening the content and adding verification gates would elevate it significantly.
Suggestions
Remove the explanatory sentence about what Juicebox does from the overview — the trigger context already establishes this, and Claude doesn't need it.
Add explicit validation checkpoints to playbooks, e.g., after deploying a new API key: '6. **Verify**: Run health check and test search before resuming pipelines.'
Consolidate the Error Handling table into the playbooks or remove it — it largely duplicates information already covered in the incident playbooks section.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The overview paragraph explains what Juicebox is and why incidents matter, which is unnecessary context for an incident runbook — Claude doesn't need to be told why outages are bad. The severity table and error handling table have some redundancy. However, the diagnostic commands and playbooks are reasonably tight. | 2 / 3 |
Actionability | Diagnostic steps are fully executable curl commands with proper headers and jq parsing. Playbooks provide specific, concrete steps including exact commands to run, endpoints to check, and clear decision points (e.g., 'If 401... If 403...'). The communication template is copy-paste ready. | 3 / 3 |
Workflow Clarity | Playbooks have clear sequential steps and the severity matrix provides good triage guidance. However, there are no explicit validation checkpoints — for example, after deploying a new API key there's no 'verify with health check before resuming pipelines' gate, and the post-incident checklist lacks a verification step to confirm the fix holds. For incident response involving potentially destructive actions like re-triggering analyses, feedback loops are missing. | 2 / 3 |
Progressive Disclosure | The skill references external resources (status page, API docs, juicebox-observability) which is good, but the content is fairly long and monolithic. The error handling table at the bottom largely duplicates information already covered in the playbooks. The post-incident checklist and communication template could reasonably be separate files to keep the runbook focused on immediate response. | 2 / 3 |
Total | 9 / 12 Passed |
Validation
81%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 9 / 11 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
allowed_tools_field | 'allowed-tools' contains unusual tool name(s) | Warning |
frontmatter_unknown_keys | Unknown frontmatter key(s) found; consider removing or moving to metadata | Warning |
Total | 9 / 11 Passed | |
- Commit
a04d1a2
- 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.