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.
1---2name: open-source-project-validator3description: 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.4---56# Open-Source Project Validator78Evaluate 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.910Do 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.1112## Accept the input1314Accept ordinary prose or this optional shape:1516```text17PROJECT IDEA:18[rough project, problem space, or alternatives]1920SUCCESS FOR ME:21[adoption, portfolio proof, reputation, community impact, career opportunities,22ecosystem influence, learning, future commercialization, or another outcome]2324EXTRA INFO:25[skills to demonstrate, target users, strategic audience, time and maintenance26budget, known alternatives, evidence, links, or exclusions]27```2829Preserve 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.3031## Execute the workflow32331. **Choose the mode and define success.** Read [workflow.md](references/workflow.md). Select `Evaluate`, `Compare`, `Explore`, or `Update`. Establish one primary success objective and a measurable success contract before judging the project.342. **Frame the project.** Identify the target user, trigger or workflow, current alternative, concrete utility, why open source helps, strategic audience, and creator constraints.353. **Build the evidence ledger.** Read [evidence-standards.md](references/evidence-standards.md). Separate facts, inferences, assumptions, and unknowns. Distinguish showcase quality, attention, adoption, reliance, contribution, and concrete opportunities.364. **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.375. **Judge the project.** Read [decision-framework.md](references/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.386. **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.397. **Design the evidence-producing test.** Read [validation-experiments.md](references/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.408. **Synthesize one compact answer.** Read and follow [output-contract.md](references/output-contract.md). Keep future monetization as optionality rather than treating it as validated by open-source evidence.419. **Review and revise once.** Privately apply [quality-control.md](references/quality-control.md). Correct vanity-metric reasoning, unsupported adoption claims, premature polish, unsustainable maintenance, and unnecessary launch advice before answering.4243## Use research proportionally4445Use 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.4647Prioritize 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.4849Default to 3-7 representative alternatives. Stop when the gates are defensible or remaining uncertainty requires observing real users rather than more desk research.5051When 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.5253## Maintain the operating stance5455- Default to skepticism without dismissing legitimate non-financial goals.56- Lead with `PURSUE`, `TEST`, `PIVOT`, `PARK`, or `DROP` and state which success objective the verdict addresses.57- Require the user to receive standalone utility; a public codebase is not valuable merely because it is public.58- Treat developer experience, documentation, tests, types, examples, local setup, and architecture as credibility and adoption signals, not automatic moats.59- Prefer production use, repeat use, integrations, meaningful issues, contributions, and attributable opportunities over stars or launch traffic.60- Evaluate the normal maintainer experience after launch, including support, compatibility, security, governance, and abandonment risk.61- Keep learning value separate from external proof. A project may be worthwhile for learning while remaining weak as a portfolio or adoption bet.62- State `insufficient evidence` instead of manufacturing certainty.6364## Keep the scope disciplined6566Do 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.6768Do 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.6970Do not invent users, production deployments, testimonials, contributors, partnerships, employer interest, download retention, or future revenue.7172Keep 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.7374## Calibrate only when needed7576Use [calibration-cases.md](references/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.
joacod