improvement-loop
Use after resolving a bug, failed task, or unexpected agent behavior to improve the pipeline skills, agents, hooks, or scripts that contributed to the problem. Also proactively suggest improvements when recurring patterns or inefficiencies are observed.
81
72%
Does it follow best practices?
Impact
93%
1.25xAverage score across 3 eval scenarios
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./.claude/skills/improvement-loop/SKILL.mdQuality
Discovery
67%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
The description has good completeness with explicit 'when' triggers covering both reactive (post-bug) and proactive (recurring patterns) scenarios. However, the actions described are vague ('improve') rather than concrete, and the trigger terms, while relevant, could overlap with debugging or CI/CD skills. Adding more specific actions and distinguishing keywords would strengthen it.
Suggestions
Replace vague 'improve' with concrete actions like 'refactor skill definitions', 'update hook configurations', 'add error handling to scripts', or 'document lessons learned'.
Add more distinctive trigger terms to reduce conflict risk, such as 'postmortem', 'retrospective', 'root cause analysis', or 'pipeline optimization'.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | The description names a domain (improving pipeline skills, agents, hooks, scripts) and some actions (resolve, improve, suggest improvements), but the actions are somewhat vague—'improve' is not a concrete action like 'refactor', 'update configuration', or 'add error handling'. | 2 / 3 |
Completeness | The description explicitly answers both 'what' (improve pipeline skills, agents, hooks, or scripts) and 'when' (after resolving a bug, failed task, or unexpected agent behavior; also when recurring patterns or inefficiencies are observed). The 'Use after...' and 'Also proactively suggest...' clauses serve as clear trigger guidance. | 3 / 3 |
Trigger Term Quality | Includes some relevant terms like 'bug', 'failed task', 'agent behavior', 'pipeline', 'hooks', 'scripts', and 'recurring patterns', but misses common user phrasings like 'postmortem', 'root cause', 'fix', 'debug', 'retrospective', or 'lesson learned'. | 2 / 3 |
Distinctiveness Conflict Risk | The scope is somewhat specific to post-incident improvement of pipeline components, but terms like 'bug', 'failed task', and 'improve scripts' could overlap with debugging skills, CI/CD skills, or general code improvement skills. | 2 / 3 |
Total | 9 / 12 Passed |
Implementation
77%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This is a strong meta-skill that clearly defines when and how to improve pipeline files. Its greatest strengths are the mandatory gate check preventing premature improvements, the concrete routing tables, and the anti-drift guardrails. The main weakness is verbosity — several concepts are repeated across sections (the 'fix first' principle appears in at least 4 places), and the dot graph diagrams consume tokens that simple lists could replace more efficiently.
Suggestions
Consolidate repeated 'fix first, improve later' messaging — it appears in the overview, gate section, red flags, key insight, and proactive detection. State it once prominently and reference it.
Replace the dot/graphviz diagrams with compact bullet-point decision trees — they convey the same logic in fewer tokens and are more directly parseable by Claude.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is well-structured but verbose in places. The dot graph diagrams add visual clarity but consume significant tokens for what could be expressed as simple bullet lists. Some sections like 'Red Flags' repeat points already made (e.g., 'improving while issue is unresolved' is stated multiple times). The batching section's example dialogue is useful but could be tighter. | 2 / 3 |
Actionability | The skill provides highly concrete, actionable guidance: specific git commit message formats, exact verification steps per change type, routing tables for which tool to use, and template messages for communicating with users. The five-step cycle is prescriptive and executable. | 3 / 3 |
Workflow Clarity | The workflow is exceptionally clear with an explicit mandatory gate check before improvement work begins, a well-sequenced five-step cycle, verification steps matched to change types, and explicit feedback loops (fix → verify → if errors fix again). The anti-drift section adds guardrails for the overall process. | 3 / 3 |
Progressive Disclosure | The content is entirely self-contained in one file with no references to external documentation, which is appropriate for the topic. However, at ~200+ lines, some sections (like the detailed routing table and batching guidance) could be split into referenced files. The structure within the file is good with clear headers, but it's on the edge of being a monolithic document. | 2 / 3 |
Total | 10 / 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
- aaddrick/claude-desktop-debian
- Commit
814cd52
- 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.