completion-check — Claude Code skill: infrastructure checks
Checks whether infrastructure is wired into the execution path, including registered hooks, the expected backend, and an end-to-end run.
npx skills add parcadei/Continuous-Claude-v3 --skill completion-check -a claude-codeWhat completion-check does
completion-check is a checklist for infrastructure that has been written but may not be connected to the application. It traces the path from user intent to code execution, checks whether hooks are registered in .claude/settings.json, and verifies which backend the application uses.
The skill covers an end-to-end run with debug logging, searches for defined but unused functions, and looks for parallel implementations. Its examples use grep, ls, uv run python, cat, and ast-grep; the database checks distinguish PostgreSQL from SQLite. That makes the backend check concrete: a PostgreSQL architecture should not silently end up using SQLite.
The skill is marked as unavailable for direct invocation. It can be installed for Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI, and OpenCode.
What it helps with
- trace execution from the entry point to infrastructure
- verify hooks are registered in
.claude/settings.json - confirm that PostgreSQL is the active backend
- find dead code and parallel implementations
- run an end-to-end check that proves infrastructure was invoked
Example prompts for the agent
- Check whether the new infrastructure is wired from the user request through to code execution.
- Trace the
Task()path and verify whether it invokesclaude -pinstead of a parallel implementation. - Inspect
.claude/settings.json, the database backend, and the end-to-end run, then report unfinished checklist items.
How to install completion-check
1Skills CLI (Vercel)
npx skills add parcadei/Continuous-Claude-v3 --skill completion-check -a claude-code2Manually: put the files in place
~/.claude/skills/completion-check/SKILL.mdCopy the whole skill folder; for one project use .claude/skills/completion-check/
1Skills CLI (Vercel)
npx skills add parcadei/Continuous-Claude-v3 --skill completion-check -a codex2Manually: put the files in place
.agents/skills/completion-check/SKILL.mdFor all projects use ~/.agents/skills/
1Skills CLI (Vercel)
npx skills add parcadei/Continuous-Claude-v3 --skill completion-check -a cursor2Manually: put the files in place
.cursor/skills/completion-check/SKILL.mdCursor also reads .agents/skills/ and .claude/skills/
1GitHub CLI
gh skill install parcadei/Continuous-Claude-v3 completion-check2Manually: put the files in place
.github/skills/completion-check/SKILL.md1Skills CLI (Vercel)
npx skills add parcadei/Continuous-Claude-v3 --skill completion-check -a gemini-cli2Platform CLI
gemini skills install https://github.com/parcadei/Continuous-Claude-v3 --path .claude/skills/completion-checkManually: put the files in place
.devin/skills/completion-check/SKILL.mdThe legacy .windsurf/skills/ path still works
Skills CLI (Vercel)
npx skills add parcadei/Continuous-Claude-v3 --skill completion-check -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 completion-check
How do I install completion-check in Claude Code?
Run npx skills add parcadei/Continuous-Claude-v3 --skill completion-check -a claude-code, then run the same command once more. Open ~/.claude/skills/completion-check/SKILL.md after that.
What does completion-check do?
The skill checks whether written infrastructure is actually connected and called. It covers the execution path, hook registration, backend selection, end-to-end execution, and dead code.
What database check does the skill perform?
It checks connection strings and verifies that PostgreSQL is used when it is the intended architecture backend, rather than SQLite.
Source text
SKILL.md · MIT
---
name: completion-check
description: "Completion Check: Verify Infrastructure Is Wired"
user-invocable: false
---
# Completion Check: Verify Infrastructure Is Wired
When building infrastructure, verify it's actually connected to the system before marking as complete.
## Pattern
Infrastructure is not done when the code is written - it's done when it's wired into the system and actively used. Dead code (built but never called) is wasted effort.
## DO
1. **Trace the execution path** - Follow from user intent to actual code execution:
```bash
# Example: Verify Task tool spawns correctly
grep -r "claude -p" src/
grep -r "Task(" src/
```
2. **Check hooks are registered**, not just implemented:
```bash
# Hook exists?
ls -la .claude/hooks/my-hook.sh
# Hook registered in settings?
grep "my-hook" .claude/settings.json
```
3. **Verify database connections** - Ensure infrastructure uses the right backend:
```bash
# Check connection strings
grep -r "postgresql://" src/
grep -r "sqlite:" src/ # Should NOT find if PostgreSQL expected
```
4. **Test end-to-end** - Run the feature and verify infrastructure is invoked:
```bash
# Add debug logging
echo "DEBUG: DAG spawn invoked" >> /tmp/debug.log
# Trigger feature
uv run python -m my_feature
# Verify infrastructure was called
cat /tmp/debug.log
```
5. **Search for orphaned implementations**:
```bash
# Find functions defined but never called
ast-grep --pattern 'async function $NAME() { $$$ }' | \
xargs -I {} grep -r "{}" src/
```
## DON'T
- Mark infrastructure "complete" without testing execution path
- Assume code is wired just because it exists
- Build parallel systems (Task tool vs claude -p spawn)
- Use wrong backends (SQLite when PostgreSQL is architected)
- Skip end-to-end testing ("it compiles" ≠ "it runs")
## Completion Checklist
Before declaring infrastructure complete:
- [ ] Traced execution path from entry point to infrastructure
- [ ] Verified hooks are registered in .claude/settings.json
- [ ] Confirmed correct database/backend in use
- [ ] Ran end-to-end test showing infrastructure invoked
- [ ] Searched for dead code or parallel implementations
- [ ] Checked configuration files match implementation
## Example: DAG Task Graph
**Wrong approach:**
```
✓ Built BeadsTaskGraph class
✓ Implemented DAG dependencies
✓ Added spawn logic
✗ Never wired - Task tool still runs instead
✗ Used SQLite instead of PostgreSQL
```
**Right approach:**
```
✓ Built BeadsTaskGraph class
✓ Wired into Task tool execution path
✓ Verified claude -p spawn is called
✓ Confirmed PostgreSQL backend in use
✓ Tested: user calls Task() → DAG spawns → beads execute
✓ No parallel implementations found
```
## Source Sessions
- This session: Architecture gap discovery - DAG built but not wired, Task tool runs instead of spawn, SQLite used instead of PostgreSQL
© parcadei · MIT · parcadei/Continuous-Claude-v3