typescript-react-dup-unifier

Detects near-duplicate TypeScript/React abstractions and recommends evidence-based unification decisions.

2|Updated May 6, 2026
One-click install
npx skills add https://github.com/bpcakes/jig-skills --skill typescript-react-dup-unifier-bpcakes
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: typescript-react-dup-unifier
Source: https://github.com/bpcakes/jig-skills/tree/main/plugins/jig-typescript/skills/typescript-react-dup-unifier
Command: npx skills add https://github.com/bpcakes/jig-skills --skill typescript-react-dup-unifier-bpcakes

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill requires typescript, and includes scripts (resource) and references (resource) components.

What problem does it solve? Teams accumulate parallel components, hooks, forms, and data-access code that look similar but have drifted in naming, lifecycle, and behavior. This Skill determines whether such duplicates should be merged, share a core, align only their contracts, or remain intentionally separate—without creating a fragile god abstraction. ## Core Features & Use Cases - AST-based candidate scanner: A bundled Node.js script parses TypeScript/TSX files with the TypeScript compiler API and ranks structurally similar components, hooks, reducers, schemas, and types. - Five-way decision framework: Classifies each candidate as unify-now, shared-core, standardize-contract, intentional-duplicate, or false-positive using an evidence rubric and hard stops for lifecycle, accessibility, and ownership conflicts. - Structured report contract: Produces a report with source anchors, usage evidence, shared invariants, migration plans, and validation commands; optionally applies the refactor in apply mode. - Use Case: Ask whether two search hooks in a React app should share a core; the Skill scans the repo, compares cache and cancellation semantics, and recommends a typed shared query core with thin wrappers—or explains why they must stay separate. ## Quick Start Ask the agent to analyze whether the similar hooks and components in this TypeScript/React repository should be unified, and report findings without editing code.

Frequently Asked Questions about typescript-react-dup-unifier

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I find duplicate React components and hooks in a TypeScript codebase?

Run the bundled scanner with node scripts/typescript-react-dup-unifier.mjs against the repository root. It parses TS/TSX files with the TypeScript compiler API and emits ranked JSON or Markdown candidates based on AST shape, behavior signals, and React-specific features.

How to decide whether two similar React hooks should be merged?

Compare their shared invariant, change triggers, lifecycle semantics, cache and cancellation behavior, and ownership using the decision rubric. Merge only when the variation surface is small and typed; otherwise extract a shared core or keep them as intentional duplicates.

Does the scanner require installing TypeScript or other npm packages?

No. The scanner loads the repository's existing typescript dependency or an already-installed global TypeScript package. It never installs packages or accesses the network, and has no bundled runtime dependencies.

Can the scanner be used in CI to block duplicate code?

Yes. Run it with --fail-above 0.90 and --json output; it exits with status 2 when any candidate reaches the threshold. Treat results as a review queue, since the score is a heuristic, not proof of mergeability.

What are the limitations of AST-based duplicate detection?

The scanner builds no full type-aware call graph, does not resolve re-exports or dynamic imports, and cannot inspect runtime behavior or git history. Its output is a ranked review queue that requires source, usage, and lifecycle review before any consolidation decision.

When should duplicated code be kept instead of unified?

Keep duplicates when they have different domain owners, release cadences, accessibility behavior, state ownership, or server/client boundaries, or when the variation surface is open-ended. Record these as intentional duplicates so they are not repeatedly flagged.