name: integration-checker\ndescription: \"Verify cross-component wiring and data flow.\"\nuser-invocable: false\ncommand: /integration-checker\nallowed-tools:
\nCheck that components are connected and receive real data. A function can pass unit tests yet never be called; an endpoint can exist without being registered.
\nThis skill reads and reports. Return fixes to the active implementation task or feature-lifecycle; do not create another approval round when fixes are already authorized.
Load references/wiring-checks.md for language detection, export exclusions, wiring states, data-flow failures, contract patterns, and the requirements map.
Read repository instructions. In a feature pipeline, use .feature/state/implement/ to scope changed and added files. Otherwise use the requested path or diff; a requested full audit covers all source files. If the implementation artifact is missing, use the diff and state the gap.
Detect every language in scope. Reuse existing integration evidence for unchanged connections; trace affected producers and consumers beyond the diff where needed.
\nGate: Scope and languages are known.
\nInventory public symbols using language-aware searches:
\n__all__, and __init__.py re-exports.Exclude dependencies, generated files, build output, fixtures, and repository metadata. Apply the reference's exceptions for public library APIs, plugin contracts, framework entrypoints, and other legitimate external consumers before calling a symbol orphaned.
\nFor each symbol, record file, name, kind, and line. Find imports and actual usage; an import alone does not establish wiring. Classify as ORPHANED, IMPORTED_NOT_USED, or WIRED using the reference. Report failures first; show successful connections only in verbose mode.
\nGate: Every in-scope symbol has a status or an explicit unresolved limitation.
\nTrace WIRED connections for real inputs and compatible contracts. Check hardcoded empty data, placeholders, dead parameters, mock remnants, shape/type mismatches, and event/message names using the reference.
\nStatic inspection establishes structure and likely compatibility, not runtime correctness. Use existing runtime evidence where available; distinguish observed failures from uncertain dynamic-language matches. Low-confidence contract findings warn rather than fail.
\nGate: Data-flow and contract findings include locations, evidence, and confidence.
\nReport component counts, wiring failures, data-flow issues, contract mismatches, and concrete fixes. In pipeline mode, use .feature/state/plan/ to map each requirement from entrypoint to implementation as WIRED, PARTIAL, or UNWIRED.
Compute integration score as 100 * WIRED / (WIRED + IMPORTED_NOT_USED + ORPHANED); report N/A when the denominator is zero.
| Verdict | \nCondition | \nNext action | \n
|---|---|---|
| PASS | \nNo wiring, flow, or contract issues | \nContinue validation | \n
| WARN | \nUnused imports or low-confidence contract findings only | \nResolve or explain warnings | \n
| FAIL | \nOrphaned components, data-flow defects, or high-confidence contract mismatches | \nReturn concrete fixes to implementation | \n
State incomplete coverage separately; missing source or unresolved scope cannot establish a PASS. Include circular imports as integration findings. For a large monorepo, narrow to affected connections unless the user requested a full audit; split a full audit into bounded scopes without silently omitting files.
\nGate: Findings, limitations, and next actions are clear. After fixes, recheck affected connections rather than repeating unchanged analysis.
\n