playbooks

home / skills / willsigmon / sigstack / service-consolidator

service-consolidator skill

/plugins/app-dev/skills/service-consolidator

This skill consolidates duplicate service implementations by finding, comparing, selecting a winner, updating the DI container, and removing unused usages.

npx playbooks add skill willsigmon/sigstack --skill service-consolidator

Review the files below or copy the command above to add this skill to your agents.

Files (1)
SKILL.md
765 B
---
name: Service Consolidator
description: Find and consolidate duplicate service implementations in Leavn app - analyze variants, choose winner, update call sites, delete duplicates
allowed-tools: Read, Edit, Grep, Glob, Bash
---

# Service Consolidator

Consolidate duplicate services:

1. **Find duplicates**: Search for services with similar names (Enhanced, Live, Base)
2. **Compare implementations**: Feature completeness, code quality, usage
3. **Choose winner**: Modern patterns (@Observable, async/await, protocol-based)
4. **Update DIContainer**: Use correct implementation
5. **Find all usages**: Grep for class name
6. **Delete unused**: Remove files + update imports

Use when: Multiple similar services exist, Enhanced variants, consolidation needed

Overview

This skill helps consolidate duplicate service implementations in the Leavn app by identifying similar service variants, selecting the best implementation, and updating callers and the dependency container. It streamlines maintenance by reducing redundant code paths and ensuring a single, modern implementation is used across the codebase. The workflow focuses on safety: analyze, pick a winner, update DI and usages, then safely remove duplicates.

How this skill works

The skill scans the TypeScript codebase for services with similar names and common suffixes like Enhanced, Live, or Base. It compares implementations for feature coverage, modern patterns (Observables, async/await, protocol-based interfaces), and code quality. After selecting a winner, it updates the DIContainer binding, finds and replaces all call sites to reference the chosen class, and removes redundant files and imports.

When to use it

  • When multiple services implement the same responsibility with variant names (e.g., Service, ServiceEnhanced, ServiceLive).
  • When maintaining feature parity across variants is causing bugs or developer confusion.
  • Before major refactors to reduce surface area and simplify testing.
  • When onboarding new engineers who must choose which implementation to use.
  • When migrating to modern patterns (Observables, async/await, interface-driven design).

Best practices

  • Run a comprehensive test suite before and after consolidation to catch regressions.
  • Document the winner’s API and why it was chosen (feature coverage, performance, patterns).
  • Prefer implementations that follow protocol/interface contracts to minimize breakage.
  • Update the DIContainer once and use automated search-and-replace for call site updates.
  • Keep backward-compatible shims briefly if external consumers exist, then remove once safe.

Example use cases

  • Consolidate PaymentService, PaymentServiceEnhanced, and PaymentServiceLive into a single modern implementation.
  • Replace older callback-based services with an async/await or Observable-based winner across the app.
  • Unify multiple data-fetching implementations that differ only in logging or minor behavior.
  • Remove duplicate mock/test services and point tests to a single, well-tested mock implementation.

FAQ

How do I choose the winning implementation?

Compare feature coverage, test coverage, adherence to modern patterns, and ease of maintenance. Prefer the implementation that best matches project conventions and has the fewest breaking changes required.

What if the winner lacks some niche behavior?

Add the missing behavior to the winner or create a small adapter. Avoid keeping full duplicate implementations; prefer protocol-based extension points.

How do I ensure no usages are missed?

Use both static search (grep/IDE) for class and file names and run the test suite and integration tests. Consider build-time type checks to reveal unresolved imports.