completion-check
Confirms infrastructure components are correctly registered and connected to the system, preventing dead code.
Install
mkdir -p .claude/skills/completion-check && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/4644" && unzip -o skill.zip -d .claude/skills/completion-check && rm skill.zipInstalls to .claude/skills/completion-check
Activation
This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.
Completion Check: Verify Infrastructure Is WiredKey capabilities
- →Trace execution paths
- →Verify hook registration
- →Validate database connections
- →Identify orphaned code
How it works
It traces the path from user intent to execution and checks for proper registration and backend connectivity.
Inputs & outputs
When to use completion-check
- →Verify database connection strings
- →Check hook registration in settings
- →Identify dead or unused infrastructure code
- →Test end-to-end execution path
About this skill
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
When not to use it
- →When infrastructure is not yet implemented
Limitations
- →Requires manual trigger of features
- →Cannot verify non-existent infrastructure
How it compares
It mandates end-to-end testing of infrastructure wiring rather than assuming functionality based on code existence.
Compared to similar skills
completion-check side by side with the closest alternatives in the catalog.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| completion-check (this skill) | 1 | 7mo | Review | Intermediate |
| n8n-expression-syntax | 6 | 4mo | No flags | Beginner |
| python-repl | 6 | 4mo | Review | Beginner |
| n8n-validation-expert | 6 | 4mo | No flags | Intermediate |
Try saying
Example prompts that trigger this skill in your AI assistant.
More by parcadei
View all by parcadei →You might also like
n8n-expression-syntax
czlonkowski
Validate n8n expression syntax and fix common errors. Use when writing n8n expressions, using {{}} syntax, accessing $json/$node variables, troubleshooting expression errors, or working with webhook data in workflows.
python-repl
gptme
Interactive Python REPL automation with common helpers and best practices
n8n-validation-expert
czlonkowski
Interpret validation errors and guide fixing them. Use when encountering validation errors, validation warnings, false positives, operator structure issues, or need help understanding validation results. Also use when asking about validation profiles, error types, or the validation loop process.
powershell-windows
davila7
PowerShell Windows patterns. Critical pitfalls, operator syntax, error handling.
bats
OleksandrKucherenko
Bash Automated Testing System (BATS) for TDD-style testing of shell scripts. Use when: (1) Writing unit or integration tests for Bash scripts, (2) Testing CLI tools or shell functions, (3) Setting up test infrastructure with setup/teardown hooks, (4) Mocking external commands (curl, git, docker), (5) Generating JUnit reports for CI/CD, (6) Debugging test failures or flaky tests, (7) Implementing test-driven development for shell scripts.
browser-daemon
noiv
Persistent browser automation via Playwright daemon. Keep a browser window open and send it commands (navigate, execute JS, inspect console). Perfect for interactive debugging, development, and testing web applications. Use when you need to interact with a browser repeatedly without opening/closing it.