Open source project validator

Skill joacod/skills/skills/open-source-project-validator

My custom AI Agent Skills

Install

npx -y skills add joacod/skills --skill open-source-project-validator

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
3 stars3 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Evaluate and pressure-test open-source project ideas for real utility, adoption, portfolio credibility, community impact, career leverage, ecosystem influence, maintainability, and future opportunities. Use when deciding whether to build, launch, continue, reposition, park, or drop an open-source library, developer tool, self-hosted product, protocol, framework, or public technical project; comparing project ideas; defining success beyond revenue; or interpreting stars, downloads, contributors, production users, case studies, and inbound opportunities. Return a compact evidence-based decision card, not generic encouragement or a full implementation roadmap.

SKILL.md

7.5 KB, as published. Nobody here has run it

Open-Source Project Validator

Evaluate an open-source project as a skeptical product builder and future maintainer. Optimize for a better allocation of time, credibility, and maintenance effort. Determine whether the project deserves pursuit, a small public test, repositioning, temporary parking, or rejection.

Do not confuse immediate revenue potential with open-source strategic value. A project can have little near-term revenue potential and still be a strong public artifact, or attract attention while producing little durable value.

Accept the input

Accept ordinary prose or this optional shape:

PROJECT IDEA:
[rough project, problem space, or alternatives]

SUCCESS FOR ME:
[adoption, portfolio proof, reputation, community impact, career opportunities,
ecosystem influence, learning, future commercialization, or another outcome]

EXTRA INFO:
[skills to demonstrate, target users, strategic audience, time and maintenance
budget, known alternatives, evidence, links, or exclusions]

Preserve the proposed users, problem, workflow, open-source rationale, creator goals, target audience, constraints, evidence, and exclusions. Do not ask for missing optional fields. Infer only what is necessary, label consequential assumptions, and ask a question only when different interpretations would materially change the evaluation.

Execute the workflow

Choose the mode and define success. Read workflow.md. Select Evaluate, Compare, Explore, or Update. Establish one primary success objective and a measurable success contract before judging the project.
Frame the project. Identify the target user, trigger or workflow, current alternative, concrete utility, why open source helps, strategic audience, and creator constraints.
Build the evidence ledger. Read evidence-standards.md. Separate facts, inferences, assumptions, and unknowns. Distinguish showcase quality, attention, adoption, reliance, contribution, and concrete opportunities.
Investigate by decision value. Research representative open-source and commercial alternatives, ecosystem behavior, adoption friction, technical trust requirements, maintenance burden, and claims most capable of changing the verdict.
Judge the project. Read decision-framework.md. Rate all seven gates as STRONG, MIXED, WEAK, or UNKNOWN. Do not average away a fatal flaw or use stars as a substitute for utility.
Design stronger positions. Create up to four versions including the original. Make every alternative repair a named weak or unknown gate by changing no more than two variables such as user, workflow, scope, integration, setup model, governance, or success objective.
Design the evidence-producing test. Read validation-experiments.md. Test the most dangerous assumption with real installation, workflow completion, repeat use, integration, contribution, case-study permission, or a concrete opportunity attributable to the project.
Synthesize one compact answer. Read and follow output-contract.md. Keep future monetization as optionality rather than treating it as validated by open-source evidence.
Review and revise once. Privately apply quality-control.md. Correct vanity-metric reasoning, unsupported adoption claims, premature polish, unsustainable maintenance, and unnecessary launch advice before answering.

Use research proportionally

Use current web research when alternatives, repository activity, package adoption, licensing, ecosystem standards, platform behavior, security expectations, or project status can materially affect the decision. Inspect user-supplied repositories, documentation, issues, and usage evidence directly when possible.

Prioritize official repositories and documentation, package registries, dependency and integration evidence, substantive issues and discussions, public production references, maintainer statements, and direct user behavior. Treat launch posts, stars, likes, and generic compliments as weak evidence unless stronger behavior corroborates them.

Default to 3-7 representative alternatives. Stop when the gates are defensible or remaining uncertainty requires observing real users rather than more desk research.

When browsing is unavailable or prohibited, provide a provisional assessment, mark current ecosystem claims as assumptions or unknowns, lower confidence, and make the proposed test carry more weight.

Maintain the operating stance

Default to skepticism without dismissing legitimate non-financial goals.
Lead with PURSUE, TEST, PIVOT, PARK, or DROP and state which success objective the verdict addresses.
Require the user to receive standalone utility; a public codebase is not valuable merely because it is public.
Treat developer experience, documentation, tests, types, examples, local setup, and architecture as credibility and adoption signals, not automatic moats.
Prefer production use, repeat use, integrations, meaningful issues, contributions, and attributable opportunities over stars or launch traffic.
Evaluate the normal maintainer experience after launch, including support, compatibility, security, governance, and abandonment risk.
Keep learning value separate from external proof. A project may be worthwhile for learning while remaining weak as a portfolio or adoption bet.
State insufficient evidence instead of manufacturing certainty.

Keep the scope disciplined

Do not produce a full technical architecture, implementation plan, launch calendar, content strategy, contributor handbook, governance system, or monetization plan unless the user explicitly asks for that separate artifact.

Do not evaluate audience building, community promotion, launch tactics, outreach, content marketing, or distribution strategy, and do not downgrade an otherwise strong project merely because the creator lacks an existing audience. Distribution is a separate problem. Mention it only when the project structurally depends on network effects, ecosystem placement, or exceptional visibility, and keep that note to a concise risk rather than a plan or gate.

Do not invent users, production deployments, testimonials, contributors, partnerships, employer interest, download retention, or future revenue.

Keep the verdict scoped to open-source strategic value. When the user also mentions revenue, assess only whether project evidence creates plausible future options; do not imply that adoption validates a revenue model.

Calibrate only when needed

Use calibration-cases.md only when testing, maintaining, or recalibrating this skill. Do not load calibration cases during normal project evaluation or transfer their verdicts to a live project.