evaluate-existing-solutions

Compares libraries, services, and platform primitives against a bespoke baseline for build-versus-adopt decisions.

723|93|Updated Nov 14, 2021
One-click install
npx skills add https://github.com/citypaul/.dotfiles --skill evaluate-existing-solutions
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: evaluate-existing-solutions
Source: https://github.com/citypaul/.dotfiles/tree/main/claude/.claude/skills/evaluate-existing-solutions
Command: npx skills add https://github.com/citypaul/.dotfiles --skill evaluate-existing-solutions

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) and assets (resource) components.

What problem does it solve?

Teams often commit to custom-built mechanisms or adopt dependencies without structured due diligence, leading to unnecessary ownership costs, security exposure, or lock-in. This Skill enforces an evidence-backed decision process before committing to any material generic mechanism.

Core Features & Use Cases

  • Three Proportionate Depths: Lightweight preflight for local capability checks, due diligence for prescribed dependencies, and full comparison for consequential unresolved choices.
  • Evidence-Based Evaluation: Requires current primary sources (official docs, licenses, security advisories, changelogs) with recorded versions, dates, and URLs rather than popularity signals.
  • Structured Decision Artifact: Produces an adopt, adapt, combine, build, defer, or do-nothing proposal using a decision template with hard gates, qualitative trade-offs, exit paths, and re-evaluation triggers.
  • Use Case: Before building a custom feature-flag system, use this Skill to compare established open-source tools, managed services, and platform primitives against a genuine bespoke baseline, then record a proposed decision with ownership and exit strategy.

Quick Start

Use evaluate-existing-solutions to compare existing libraries and services against building our own solution for this scheduling mechanism before we commit.

Frequently Asked Questions about evaluate-existing-solutions

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

FAQPage Schema
How do I decide between building custom code and adopting a library?

Frame the job and hard constraints first, inspect existing repository and platform capabilities, then compare credible candidates against a genuine bespoke baseline on total lifecycle ownership. The outcome is classified as adopt, adapt, combine, build, defer, or do nothing.

What evidence should I gather when evaluating an open-source dependency?

Use primary sources: official documentation, exact release and changelog pages, the repository's LICENSE and SECURITY files, OSV or GHSA advisories, and reproducible benchmarks. Record the exact version, observation date, URL, and finding for each candidate.

When should I not run a full build-versus-buy comparison?

Skip the full comparison for trivial logic or glue code, routine use of an already-adopted tool, ordinary fixes, or domain-specific policy. Use lightweight preflight for small mechanisms and due diligence only when a dependency is already prescribed.

Can this skill install or test candidate packages automatically?

No. The skill researches and decides but does not install packages, run untrusted code, or implement the choice. Any proof-of-fit requires separate authorization and a disposable least-privilege sandbox with network and credential access denied by default.

How are popularity metrics like GitHub stars treated in evaluation?

Stars, download counts, and search rankings are discovery signals only and cannot select a candidate. Decisions must rest on primary technical evidence such as maintenance activity, security posture, license terms, and compatibility for the exact version.