check-coverage — Claude Code skill: test coverage for CLI handlers
This skill inspects a CLI handler and its test file, spots the gaps and writes the missing cases. Handy when you add a command or audit old coverage.
npx skills add ldayton/Dippy --skill check-coverage -a claude-codeWhat check-coverage does
The skill runs in stages. It first looks for documentation in two places: tldr pages under ~/source/tldr/pages/*/$ARGUMENTS*.md, or the output of $ARGUMENTS --help and man $ARGUMENTS. Neither source present means the run stops right there, so a tool with no docs gets nothing out of it.
Next it walks subcommands recursively with $ARGUMENTS <subcommand> --help and $ARGUMENTS help <subcommand>, sorting operations into read-only and state-changing. Then it reads tests/cli/test_$ARGUMENTS.py and checks whether every subcommand is covered, whether both safe and unsafe variants appear, and whether global flags and documented edge cases made it in.
Missing cases get appended in the file's existing shape: a TESTS list of command and expected-result pairs. The skill then runs just test, and for every failure decides whether the expectation is right — fixing src/dippy/cli/$ARGUMENTS.py if so, the test if not. A just check pass is required before it finishes. The tool name comes in as the argument, declared as argument-hint: <tool>.
What it helps with
- cover a freshly added CLI subcommand with tests
- find gaps in an older handler's coverage
- separate safe and state-changing operations in test cases
- add cases for global flags and documented edge cases
- decide whether a failing test or the code is wrong
Example prompts for the agent
- Check coverage for the
mytoolhandler and add the missing tests - Run check-coverage on
deployand show what's absent fromtests/cli/test_deploy.py - I added a subcommand to
mytool— audit coverage and getjust testpassing
How to install check-coverage
1Skills CLI (Vercel)
npx skills add ldayton/Dippy --skill check-coverage -a claude-code2Manually: put the files in place
~/.claude/skills/check-coverage/SKILL.mdCopy the whole skill folder; for one project use .claude/skills/check-coverage/
1Skills CLI (Vercel)
npx skills add ldayton/Dippy --skill check-coverage -a codex2Manually: put the files in place
.agents/skills/check-coverage/SKILL.mdFor all projects use ~/.agents/skills/
1Skills CLI (Vercel)
npx skills add ldayton/Dippy --skill check-coverage -a cursor2Manually: put the files in place
.cursor/skills/check-coverage/SKILL.mdCursor also reads .agents/skills/ and .claude/skills/
1GitHub CLI
gh skill install ldayton/Dippy check-coverage2Manually: put the files in place
.github/skills/check-coverage/SKILL.md1Skills CLI (Vercel)
npx skills add ldayton/Dippy --skill check-coverage -a gemini-cli2Platform CLI
gemini skills install https://github.com/ldayton/Dippy --path .claude/skills/check-coverageManually: put the files in place
.devin/skills/check-coverage/SKILL.mdThe legacy .windsurf/skills/ path still works
Skills CLI (Vercel)
npx skills add ldayton/Dippy --skill check-coverage -a opencodeClaude.ai
Zip the folder and upload it in Settings → Capabilities → Skills
Step by step, with commands for each platform: How to install skills in Claude Code: five ways
Questions about check-coverage
How do I install check-coverage in Claude Code?
Run npx skills add ldayton/Dippy --skill check-coverage -a claude-code. The skill lands at ~/.claude/skills/check-coverage/SKILL.md.
What does check-coverage do?
It gathers docs for a CLI tool, walks its subcommands, compares them against the existing test file and appends the cases that are missing. It finishes with just test and just check.
What does the skill need to run?
At least one documentation source: tldr pages, or the output of --help and man. With neither, it halts at the first step.
Source text
SKILL.md · MIT
---
name: check-coverage
description: Ensure comprehensive test coverage for a CLI handler. Use when adding a new command or auditing existing handler coverage.
argument-hint: <tool>
disable-model-invocation: true
---
Ensure the handler and tests for `$ARGUMENTS` provide comprehensive coverage.
## 1. Gather Documentation
Find documentation for the tool (need at least one source):
**tldr:**
```
ls ~/source/tldr/pages/*/$ARGUMENTS*.md
cat ~/source/tldr/pages/*/$ARGUMENTS.md
```
**Local CLI:**
```
$ARGUMENTS --help
man $ARGUMENTS
```
Stop if neither source exists.
## 2. Explore Subcommands
For tools with subcommands, recursively explore:
```
$ARGUMENTS <subcommand> --help
$ARGUMENTS help <subcommand>
```
Build a mental model of:
- All subcommands and their actions
- Which operations are read-only (safe) vs mutate state (unsafe)
- Global flags that affect parsing
- Edge cases
## 3. Review Existing Tests
Read `tests/cli/test_$ARGUMENTS.py` and check for:
- Coverage of all subcommands
- Both safe and unsafe variants of each action
- Global flag handling
- Edge cases from the docs
## 4. Add Missing Tests
Add aspirational test cases for anything missing. Follow existing format:
```python
TESTS = [
# --- Subcommand group ---
("$ARGUMENTS <subcommand> <safe-action>", True),
("$ARGUMENTS <subcommand> <unsafe-action>", False),
]
```
## 5. Iterate Until Tests Pass
```
just test
```
For each failure, determine if the test expectation is correct:
- If yes, update `src/dippy/cli/$ARGUMENTS.py`
- If no, fix the test
## 6. Verify
`just check` MUST pass before you're done.
© ldayton · MIT · ldayton/Dippy