Skip to main content
skill CX Codex

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.

Install into Claude Code · Skills CLI (Vercel) All methods and platforms ↓
npx skills add parcadei/Continuous-Claude-v3 --skill completion-check -a claude-code
Open on GitHub

What 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 invokes claude -p instead 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-code

2Manually: put the files in place

~/.claude/skills/completion-check/SKILL.md

Copy the whole skill folder; for one project use .claude/skills/completion-check/

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

Similar skills

All skills for DevOps and infrastructure →

From the same set77

Project sponsors

Companies that keep this analytics open
Gold sponsor

Impressions, clicks and code copies — open statistics. We keep the numbers public for the same reason NeBlask itself is public. Become a sponsor