dry-consolidation
Find and extract duplicated code into shared abstractions. Use when seeing repeated utilities, copy-pasted components, duplicated hooks, or boilerplate repeated across files.
What this skill does
# DRY Consolidation Systematic extraction of duplicated code into shared, tested abstractions. ## When to Use This Skill | Use this skill when... | Use these instead when... | |------------------------|--------------------------| | Multiple files have identical/near-identical code blocks | Single file needs cleanup → `/code:refactor` | | Copy-pasted utility functions across components | Looking for anti-patterns without fixing → `/code:antipatterns` | | Repeated UI patterns (dialogs, pagination, error states) | Functional refactoring of a file or directory → `/code:refactor` | | Duplicated hooks or state management boilerplate | Structural code search only → `ast-grep-search` | | Import blocks are bloated from repeated inline patterns | Linting/formatting issues → `/lint:check` | ## Context - Target path: !`echo "$1"` - Project type: !`find . -maxdepth 1 \( -name "package.json" -o -name "Cargo.toml" -o -name "pyproject.toml" -o -name "go.mod" \)` - Source directories: !`find . -maxdepth 1 -type d \( -name "src" -o -name "lib" -o -name "app" -o -name "components" -o -name "packages" \)` - Test framework: !`find . -maxdepth 2 \( -name "vitest.config.*" -o -name "jest.config.*" -o -name "pytest.ini" -o -name "conftest.py" \)` - Existing shared utilities: !`find . \( -path "*/lib/*" -o -path "*/utils/*" -o -path "*/shared/*" -o -path "*/common/*" -o -path "*/hooks/*" \) -type f -print -quit` ## Parameters - `$1`: Path or directory to scan (defaults to `src/`) - `--scope`: Focus on a specific extraction type: `utilities`, `components`, `hooks`, or `all` (default: `all`) - `--dry-run`: Analyze and report duplications without making changes ## Execution Execute this 7-step consolidation workflow. Use TodoWrite to track each extraction as a separate task. ### Step 1: Scan for duplicated patterns Scan the target path for duplicated patterns. Search for these duplication signals: **Identical function bodies:** ``` Grep for function/method signatures that appear in multiple files. Look for identical multi-line blocks (3+ lines) across files. ``` **Repeated inline patterns:** - Utility functions defined identically in multiple files (string truncation, date formatting, validation) - Identical error handling blocks (try/catch patterns, error state JSX) - Copy-pasted UI fragments (pagination controls, confirmation dialogs, loading states) - Repeated hook/state management patterns (delete confirmation + mutation + handler) - Duplicated import blocks that signal repeated inline implementations **Search strategy:** 1. Use Grep to find repeated function names, variable patterns, and import clusters 2. Use Glob to identify files with similar structure (e.g., all `*List.tsx`, all `*Detail.tsx`) 3. Read candidate files to confirm duplication and measure scope ### Step 2: Classify duplications Group discovered duplications into extraction categories: | Category | Extract Into | Location Convention | |----------|-------------|---------------------| | **Utilities** | Pure functions | `src/lib/utils/` or `src/utils/` | | **Components** | Shared UI components | `src/components/ui/` or `src/components/shared/` | | **Hooks** | Custom React/Vue hooks | `src/hooks/` or `src/composables/` | | **Types** | Shared type definitions | `src/types/` or alongside the abstraction | Follow the project's existing conventions for shared code location. If no convention exists, propose one based on the framework. ### Step 3: Plan extractions For each duplication cluster, plan the extraction: 1. **Name the abstraction** — Use a clear, descriptive name that reflects the shared behavior 2. **Define the interface** — Determine parameters needed to cover all usage variations 3. **Choose the location** — Follow project conventions for shared code placement 4. **List all consumers** — Identify every file that will be updated 5. **Assess risk** — Note any subtle differences between duplicated instances that need parameterization Present the plan to the user before proceeding (unless `--dry-run` was not specified and the scope is clear). **Plan format:** ``` ## Extraction Plan ### 1. [Abstraction Name] → [target file path] - Type: utility | component | hook - Replaces: [N] identical blocks across [M] files - Consumers: [list of files] - Parameters: [any variations that need to be parameterized] - Estimated lines saved: [N] ``` ### Step 4: Extract shared abstractions Execute each planned extraction: 1. **Create the shared abstraction** with proper typing and documentation 2. **Replace each instance** in consumer files with an import + usage of the new abstraction 3. **Handle variations** — parameterize differences between instances rather than creating multiple abstractions 4. **Update imports** — add the new import, remove imports that were only needed for the inline version **Extraction order:** Start with utilities (no dependencies), then components, then hooks (may depend on utilities/components). Mark each extraction as completed in the todo list before moving to the next. ### Step 5: Write tests Write tests for each extracted abstraction: | Abstraction Type | Test Approach | |-----------------|---------------| | Utility function | Unit tests covering all input variations, edge cases | | UI component | Render tests, prop variations, accessibility | | Custom hook | Hook testing with mock dependencies, state transitions | | Type definitions | Type-level tests if applicable (tsd, expect-type) | Place test files adjacent to the abstraction or in the project's test directory, following existing conventions. ### Step 6: Clean up dead code After all extractions are complete: 1. **Remove unused imports** from all updated consumer files 2. **Remove dead code** — inline helper functions that are now replaced 3. **Verify no orphaned references** — search for any remaining references to removed code ### Step 7: Verify all checks pass Run the full verification suite: **TypeScript/JavaScript projects:** ```bash npx tsc --noEmit # Type checking npm run lint # Linting (or biome/eslint directly) npm run test # Full test suite ``` **Python projects:** ```bash ty check . # Type checking ruff check . # Linting pytest # Test suite ``` **Rust projects:** ```bash cargo check # Type checking cargo clippy # Linting cargo test # Test suite ``` All three must pass. If any fail, fix the issues before reporting completion. ### Output Summary After all phases complete, report: ``` ## DRY Consolidation Summary ### Extractions - [Abstraction Name] (type) — replaced N blocks in M files - ... ### New Files Created - path/to/new/file.ts — [description] - ... ### Tests Added - N tests across M test files ### Net Effect - ~N lines of duplicated code consolidated - N reusable abstractions created - All verified: typecheck + lint + N passing tests ``` ## Agentic Optimizations | Context | Approach | |---------|----------| | Quick scan | Use `--dry-run` to see duplication report without changes | | Focused extraction | Use `--scope utilities` to extract only utility functions | | Large codebase | Scope to specific directory: `/code:dry-consolidation src/components/` | | Post-extraction verify | `npx tsc --noEmit 2>&1 | head -30` for quick type error check | | Test run (fast) | `npm test -- --bail=1 --reporter=dot` for quick pass/fail | ## See Also - `/code:refactor` — Functional refactoring of a file or directory (pure functions, immutability, composition) - `/code:antipatterns` — Detection-only analysis for code smells - `ast-grep-search` — Structural code search for finding patterns ## Related Skills - If dead code detected during consolidation → `/code:dead-code` - If complexity is high after consolidation → `/code:complexity`
Related in Writing & Docs
jax-development
IncludedUse this skill when the user is writing, debugging, profiling, refactoring, reviewing, benchmarking, parallelising, exporting, or explaining JAX code, or when they mention JAX, jax.numpy, jit, grad, value_and_grad, vmap, scan, lax, random keys, pytrees, jax.Array, sharding, Mesh, PartitionSpec, NamedSharding, pmap, shard_map, Pallas, XLA, StableHLO, checkify, profiler, or the JAX repo. It helps turn NumPy or PyTorch-style code into pure functional JAX, fix tracer/control-flow/shape/PRNG bugs, remove recompiles and host-device syncs, choose transforms and sharding strategies, inspect jaxpr/lowering/IR, and benchmark compiled code correctly.
nature-article-writer
IncludedDrafts, rewrites, diagnostically critiques, and style-calibrates primary research manuscripts for Nature and Nature Portfolio journals. Use when the user wants a Nature-style title, summary paragraph or abstract, introduction, results, discussion, methods, figure legends, presubmission enquiry, cover letter, reviewer response, or when a scientific draft sounds generic, jargon-heavy, structurally weak, or AI-ish and needs precise, broad-reader-friendly prose without inventing data, analyses, or references. Best for primary research articles and letters rather than reviews or press releases unless explicitly adapting one.
deckrd
IncludedDocument-driven framework that derives requirements, specifications, implementation plans, and executable tasks from goals through structured AI dialogue. Use when user says "write requirements", "create spec", "plan implementation", "derive tasks", "structure this feature", "break down into tasks", or "document this module". Also use for reverse engineering existing code into docs (/deckrd rev). Do NOT use for direct code writing — use /deckrd-coder after tasks are generated. Do NOT use when the user only wants to run or fix existing code without planning.
clinical-decision-support
IncludedGenerate professional clinical decision support (CDS) documents for pharmaceutical and clinical research settings, including patient cohort analyses (biomarker-stratified with outcomes) and treatment recommendation reports (evidence-based guidelines with decision algorithms). Supports GRADE evidence grading, statistical analysis (hazard ratios, survival curves, waterfall plots), biomarker integration, and regulatory compliance. Outputs publication-ready LaTeX/PDF format optimized for drug development, clinical research, and evidence synthesis.
handling-sf-data
IncludedSalesforce data operations with 130-point scoring. Use this skill to create, update, delete, bulk import/export, generate test data, and clean up org records using sf CLI and anonymous Apex. TRIGGER when: user creates test data, performs bulk import/export, uses sf data CLI commands, needs data factory patterns for Apex tests, or needs to seed/clean records in a Salesforce org. DO NOT TRIGGER when: SOQL query writing only (use querying-soql), Apex test execution (use running-apex-tests), or metadata deployment (use deploying-metadata).
accelint-ac-to-playwright
IncludedConvert and validate acceptance criteria for Playwright test automation. Use when user asks to (1) review/evaluate/check if AC are ready for automation, (2) assess if AC can be converted as-is, (3) validate AC quality for Playwright, (4) turn AC into tests, (5) generate tests from acceptance criteria, (6) convert .md bullets or .feature Gherkin files to Playwright specs, (7) create test automation from requirements. Handles both bullet-style markdown and Gherkin syntax with JSON test plan generation and validation.