evaluate-existing-solutions

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

Updated May 18, 2024
One-click install
npx skills add https://github.com/joshhornby/dotfiles --skill evaluate-existing-solutions-joshhornby
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: evaluate-existing-solutions
Source: https://github.com/joshhornby/dotfiles/tree/main/.claude/skills/evaluate-existing-solutions
Command: npx skills add https://github.com/joshhornby/dotfiles --skill evaluate-existing-solutions-joshhornby

SYSTEM DOCUMENTATION & REQUIREMENTS

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

What problem does it solve? Teams often commit to new dependencies or build custom machinery without structured due diligence, leading to unnecessary ownership costs, lock-in, or reinvented wheels. This Skill enforces an evidence-backed decision process before adopting or building any material generic mechanism. ## Core Features & Use Cases - Three proportionate depths: lightweight preflight before proposing bespoke machinery, due diligence on a prescribed dependency, or a full market comparison for consequential choices. - Hard gates and qualitative trade-offs: eliminate candidates on hard constraints first, then compare finalists on total lifecycle ownership using the evaluation-dimensions reference. - Decision artifact: produces a structured adopt, adapt, combine, build, defer, or do-nothing proposal using the included decision template, with evidence ledger, exit path, and re-evaluation triggers. - Use Case: Before adding a validation library to a project, use this Skill to check the framework's built-in primitives, verify the candidate's maintenance and license status from primary sources, and record a proposed decision for the owner to accept. ## Quick Start Use evaluate-existing-solutions to decide whether we should adopt a library or build our own mechanism for this feature.

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 adopting a library and building custom code?

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 an adopt, adapt, combine, build, defer, or do-nothing proposal.

What evidence should I gather before adding a new dependency?

Verify the exact version, maintenance status, security advisories, license text, and compatibility from primary sources such as official documentation, registries, and the repository's LICENSE and SECURITY files. Record the observation date and URL for each finding.

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

Skip the full comparison for trivial logic, one-off glue code, routine fixes with no new mechanism, or routine use of a tool the project already owns. A lightweight preflight of local and platform capabilities is sufficient in those cases.

Can this skill install or test a candidate package for me?

No, it researches and decides but does not install packages, run untrusted code, or implement the choice without separate authority. A proof-of-fit requires explicit authorization and a least-privilege disposable sandbox.

How are hard gates different from trade-off comparison?

Hard gates are pass/fail constraints such as license, security, platform compatibility, or deadlines that eliminate candidates before any trade-off discussion. Survivors are then compared qualitatively across dimensions like maturity, operations, and lock-in, never with a weighted numeric score.