Intelligent code cleanup with mainline detection, stale artifact discovery, and safe execution. Supports targeted cleanup and confirmation.
38
36%
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 ./.codex/skills/clean/SKILL.mdQuality
Discovery
32%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 provides a moderate level of specificity around code cleanup capabilities but relies on somewhat abstract terminology rather than concrete actions users would recognize. The biggest weakness is the complete absence of explicit trigger guidance ('Use when...'), which makes it harder for Claude to know when to select this skill. The terms used are more technical jargon than natural user language.
Suggestions
Add an explicit 'Use when...' clause, e.g., 'Use when the user asks to clean up code, remove dead code, find unused files, or delete stale artifacts from a repository.'
Replace abstract terms like 'stale artifact discovery' and 'safe execution' with concrete actions, e.g., 'Finds and removes unused files, dead code, orphaned imports, and outdated build artifacts.'
Include natural trigger terms users would say, such as 'dead code', 'unused files', 'clean up repo', 'remove old code', 'unused imports', or 'orphaned files'.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (code cleanup) and some actions (mainline detection, stale artifact discovery, safe execution, targeted cleanup, confirmation), but these are somewhat abstract and not fully concrete — e.g., 'stale artifact discovery' and 'safe execution' are vague about what specifically is being cleaned up or executed. | 2 / 3 |
Completeness | Describes what the skill does at a high level but completely lacks a 'Use when...' clause or any explicit trigger guidance for when Claude should select this skill. Per the rubric, a missing 'Use when...' clause caps completeness at 2, and the 'what' is also somewhat weak, so this scores a 1. | 1 / 3 |
Trigger Term Quality | Includes some relevant terms like 'code cleanup', 'stale artifact', and 'mainline detection', but misses common natural user phrases like 'dead code', 'unused files', 'remove old code', 'clean up repo', or 'delete unused imports'. The terms used lean more technical/jargon than what users would naturally say. | 2 / 3 |
Distinctiveness Conflict Risk | The combination of 'mainline detection' and 'stale artifact discovery' provides some distinctiveness, but 'code cleanup' is broad enough to overlap with linting, formatting, refactoring, or general code quality skills. | 2 / 3 |
Total | 7 / 12 Passed |
Implementation
39%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This skill has excellent workflow design with clear phases, validation checkpoints, staged deletion, and user confirmation gates, but suffers from severe verbosity and poor content organization. The entire multi-hundred-line implementation is inlined in a single file with no progressive disclosure, mixed Chinese/English comments add noise, and the code uses undefined runtime APIs making it not truly executable. The skill would benefit enormously from extracting implementation into separate files and keeping SKILL.md as a concise overview.
Suggestions
Extract the implementation code for each phase into separate files (e.g., phase1-mainline.js, phase2-discovery.js) and reference them from SKILL.md, keeping only the workflow overview and key decision points inline.
Remove mixed-language comments (Chinese explanations) and redundant explanatory text — Claude doesn't need to be told what `git rev-parse --show-toplevel` does.
Define or document the runtime environment (what provides bash(), spawn_agent(), Write(), Read(), request_user_input) so the code becomes actionable rather than pseudo-executable.
Remove the 'Iteration Flow' section which duplicates information already conveyed by the phase descriptions and argument documentation above it.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is extremely verbose at ~300+ lines with extensive inline code that could be modularized. It includes unnecessary explanations (e.g., explaining what project root detection does in Chinese), redundant sections (the iteration flow repeats what's already shown), and mixed languages (Chinese comments interspersed with English) adding noise. The full implementation code is inlined rather than referenced from separate files. | 1 / 3 |
Actionability | The code blocks are detailed and mostly concrete, but they use pseudo-API functions (spawn_agent, wait_agent, followup_task, close_agent, Write, Read, functions.request_user_input) without defining what runtime these belong to. The JavaScript is not standard Node.js (uses undefined 'bash()' function) making it not truly executable as-is. The variable `projectRoot` is used before it's defined in the initialization block. | 2 / 3 |
Workflow Clarity | The workflow is exceptionally well-structured with clear phases (0-4), explicit validation checkpoints (path validation, manifest schema validation, user confirmation gate), a staged deletion approach before permanent deletion, dry-run support, and a 4-step timeout cascade for the subagent. Error handling is documented in a summary table with clear actions for each failure mode. | 3 / 3 |
Progressive Disclosure | All implementation details are inlined in a single monolithic file with no bundle files or external references. The full code for all four phases, plus initialization, is dumped into SKILL.md. The session folder structure, risk levels, security features, and error handling tables could all be separate reference files. For a skill this complex, the lack of any content splitting is a significant organizational failure. | 1 / 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 | |
5ff5e86
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.