mcpbeat

Completion Check

parcadei/completion-check

Completion Check: Verify Infrastructure Is Wired

740 tokens
context cost
the whole folder, loaded on every use
1
files
instructions only
0
copies elsewhere
how many repositories repackaged it
3880
stars on the repo
on the repository, not the skill itself

Install

one command, takes just this skill from the repository
npx skills add https://github.com/parcadei/Continuous-Claude-v3 --skill completion-check

The instruction itself

7 sections, as written by the author

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

  • Trace the execution path - Follow from user intent to actual code execution:
   # Example: Verify Task tool spawns correctly
   grep -r "claude -p" src/
   grep -r "Task(" src/
  • Check hooks are registered, not just implemented:
   # Hook exists?
   ls -la .claude/hooks/my-hook.sh

   # Hook registered in settings?
   grep "my-hook" .claude/settings.json
  • Verify database connections - Ensure infrastructure uses the right backend:
   # Check connection strings
   grep -r "postgresql://" src/
   grep -r "sqlite:" src/  # Should NOT find if PostgreSQL expected
  • Test end-to-end - Run the feature and verify infrastructure is invoked:
   # 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
  • Search for orphaned implementations:
   # 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

How to use it

Copy the folder

Take parcadei/completion-check from the repository into ~/.claude/skills for personal use, or into .claude/skills inside a project.

Check the name does not clash

The agent identifies a skill by the name field in its header. Two skills with the same name cannot sit side by side — one of them will be ignored.