Integration Checker Skill

Core Principle

Purpose

Operator Context

Hardcoded Behaviors (Always Apply)

• CLAUDE.md Compliance: Read and follow repository CLAUDE.md before execution
• Read-Only Analysis: This skill reads and reports. It does NOT fix wiring issues. Fixes route back to feature-implement or the user.
• Language Detection First: Detect project language(s) before applying verification techniques. Different languages have different import/export patterns.
• Three-State Classification: Every export gets exactly one status: WIRED, IMPORTED_NOT_USED, or ORPHANED. No ambiguous states.
• Structural Not Semantic: Contract checking verifies shape and naming compatibility, not whether data is logically correct. WHY: semantic correctness requires runtime information we don't have.

Default Behaviors (ON unless disabled)

• Concise Reporting: Report facts. Show the wiring map, not prose about the wiring map.
• Feature Pipeline Integration: When invoked within the feature pipeline, read implementation artifact from

  .feature/state/implement/

  for context on what was built.
• Exclusion Patterns: Skip

  node_modules/

  ,

  vendor/

  ,

  .git/

  ,

  __pycache__/

  ,

  dist/

  ,

  build/

  , test fixtures, and generated files. WHY: these contain intentionally unused exports (library code, vendored deps) that would flood the report with false positives.
• Severity Ordering: Report ORPHANED (failure) before IMPORTED_NOT_USED (warning) before WIRED (pass). Users need to see failures first.

Optional Behaviors (OFF unless enabled)

• Requirements Map: When a task plan exists (

  .feature/state/plan/

  ), produce per-requirement wiring status. Only available in feature pipeline context.
• Verbose Mode: Show WIRED components in addition to failures and warnings. Default only shows issues.

What This Skill CAN Do

• Build export/import maps for Go, Python, TypeScript, and JavaScript projects
• Classify exports as WIRED, IMPORTED_NOT_USED, or ORPHANED
• Detect hardcoded empty data, placeholder values, and dead parameters flowing through wired connections
• Verify output shape compatibility between connected components
• Produce per-requirement wiring status when a task plan exists
• Operate standalone or as part of the feature pipeline

What This Skill CANNOT Do

• Fix wiring issues (route to feature-implement or the user)
• Verify runtime behavior or semantic correctness
• Analyze dynamically-loaded modules, reflection-based wiring, or plugin architectures with certainty
• Replace integration tests (this is static analysis, not execution)
• Reason: This skill is static structural analysis. Runtime verification and fix application require different capabilities.

Instructions

Phase 0: PRIME

• Pipeline: Check for

  .feature/state/implement/

  artifact. If present, load it to understand what was built and scope the check to changed/added files.
• Standalone: Scope to the current working directory or user-specified path. Analyze all source files.

go.mod

*.go

pyproject.toml

setup.py

*.py

tsconfig.json

*.ts

*.tsx

package.json

*.js

*.jsx

import "path/to/pkg"

pkg.Name

init()

__all__

__init__.py

from module import name

import module

__init__.py

export

export default

index.ts

import { name } from './module'

module.exports

export

export default

require()

import

Phase 1: EXPORT/IMPORT MAP

• Go: Find all capitalized function, type, const, and var declarations at package level. Include method receivers on exported types.
• Python: Find all module-level function/class/variable definitions. Check

  __all__

  if present (it restricts the public API). Check

  __init__.py

  for re-exports.
• TypeScript/JavaScript: Find all

  export

  declarations,

  export default

  , and barrel file re-exports.

{file, name, kind (function/type/const/var), line}

1. Import: The symbol is imported (appears in an import statement referencing the exporting module)
2. Usage: The imported symbol is actually used (called, referenced, assigned, passed as argument) beyond the import statement itself

• main()

  functions and entry points
• Interface implementations that satisfy an interface (Go)
• Test helpers exported for use by

  _test.go

  files in other packages
• Symbols listed in public API documentation or

  __all__

  in library packages
• CLI command handlers wired via registration (e.g., cobra commands, click groups)
• Exports in files matching exclusion patterns (vendor, node_modules, etc.)

## Export/Import Map

### ORPHANED (Failure)
| File | Export | Kind | Imported By |
|------|--------|------|-------------|
| api/handlers.go | HandleUserDelete | func | (none) |
| utils/format.py | format_currency | func | (none) |

### IMPORTED_NOT_USED (Warning)
| File | Export | Kind | Imported By | Used? |
|------|--------|------|-------------|-------|
| api/handlers.go | HandleUserUpdate | func | routes/api.go | No |

### WIRED (Pass) — [N] components
(Shown only in verbose mode)

Phase 2: DATA FLOW AND CONTRACT CHECK

Data Flow Tracing

• Empty arrays/slices passed to functions that iterate over them:

  processItems([])

  ,

  handleUsers([]User{})

• Empty strings passed where meaningful content is expected
• Zero values for IDs, counts, or sizes that should be populated

• nil

  /

  None

  /

  null

  /

  undefined

  passed where a real object is expected

• TODO/FIXME/HACK comments adjacent to data assignment
• Lorem ipsum, "test", "example", "placeholder" string literals in non-test code
• Zeroed structs or objects with no fields populated:

  User{}

  ,

  {}

• Function declares a parameter but never reads it (not just

  _

  convention)
• Parameter is read only to immediately discard:

  _ = param

• return []

  ,

  return nil

  ,

  return {}

  in non-test code paths where real data is expected
• Hardcoded return values that bypass actual logic

{file, line, kind (empty-data|placeholder|dead-param|mock-remnant), description}

Cross-Component Contract Checking

• A returns

  {id, name, email}

  but B expects

  {userId, displayName, emailAddress}

  -- field naming mismatch
• A returns a flat object but B destructures expecting nested structure
• A returns a single item but B expects an array (or vice versa)

• A returns a string ID but B expects a numeric ID
• A returns an optional/nullable value but B accesses it without null check

• Emitter sends event type

  "user.created"

  but handler listens for

  "userCreated"

• Message producer sends one schema, consumer expects different fields

{producer_file, consumer_file, mismatch_kind, description}

• High confidence: Explicit type annotations match/mismatch, struct/interface definitions
• Medium confidence: Inferred from usage patterns, variable names, JSDoc/docstrings
• Low confidence: Dynamic access patterns, computed property names, reflection

Phase 3: REPORT

.feature/state/plan/

## Requirements Integration Map

| Requirement | Status | Integration Path |
|-------------|--------|-----------------|
| User can delete account | WIRED | DELETE /api/users/:id -> routes/api.go -> handlers.HandleUserDelete -> db.DeleteUser |
| Email notification on delete | PARTIAL | handlers.HandleUserDelete -> [GAP] -> email.SendNotification (exists but not called from handler) |
| Audit log on delete | UNWIRED | audit.LogEvent exists, but no call from any delete path |

# Integration Check Report

## Summary
- Components checked: [N]
- WIRED: [N]
- IMPORTED_NOT_USED: [N]
- ORPHANED: [N]
- Data flow issues: [N]
- Contract mismatches: [N]
- Integration score: [WIRED / (WIRED + IMPORTED_NOT_USED + ORPHANED) * 100]%

## Verdict: PASS / WARN / FAIL

PASS: No ORPHANED components, no data flow issues, no contract mismatches
WARN: No ORPHANED, but has IMPORTED_NOT_USED or low-confidence contract findings
FAIL: Has ORPHANED components, data flow issues, or high-confidence contract mismatches

## Export/Import Map
[From Phase 1 — only issues, unless verbose mode]

## Data Flow Issues
[From Phase 2 — data flow findings]

## Contract Mismatches
[From Phase 2 — contract findings with confidence level]

## Requirements Integration Map
[From Step 1 — if in pipeline mode]

## Recommended Actions
1. [Specific action for each ORPHANED component]
2. [Specific action for each IMPORTED_NOT_USED]
3. [Specific action for each data flow issue]
4. [Specific action for each contract mismatch]

Error Handling

git diff --name-only

Anti-Patterns

Anti-Rationalization

References

• Feature State Conventions
• Gate Enforcement
• Anti-Rationalization Core
• ADR-078: Integration Checker