本文へ移動
cccskills
無料GitHub で公開

ln-11-opportunity-evaluator

Evaluates new product opportunities through demand, channels and economics before committing to build.

インストール方法を見る

含まれるファイル(1)

  • SKILL.md12.6 KB

SKILL.md(原文)

インストールする前に、エージェントに与えられる指示の中身を確認できます。

Opportunity Evaluator

Goal: Evaluate product opportunities before implementation commitment. Start from observable demand and a reachable acquisition path, eliminate weak candidates early, and recommend one low-cost validation step without manufacturing market precision.

Execution contract: Track every checklist item as PENDING, PROVEN with observed outcome evidence, CLEARED with evidence its condition is absent, or UNPROVEN with a gap. Reading, delegation, tool failure, zero exit status, and self-reported success are not proof. Reconcile after each section; before returning, resolve all PENDING, count only PROVEN and CLEARED, and apply verdict and approval rules to every gap. Preserve intent, scope, mode, and existing authorization. Complete authorized work before required external approval; ask only consequential unresolved choices. If nobody can answer, report the exact question and apply the skill's gap verdict without waiting or guessing. Cite any blocking instruction and unresolved boundary; never invent approval gates. Scale depth to material risk; preserve mandatory checks, dependencies, and safety order while choosing verification methods. Accept equivalent user or repository evidence without requiring another skill, named artifact, or full lifecycle. Preserve source requirement and decision IDs. Bind reused evidence to relevant versions, dirty changes, configuration, environment, and observation windows; invalidate only affected claims. Choose the primary workflow by outcome and explicit selection. Consume neighboring contracts and valid evidence without duplicating ownership or restarting audits. Split distinct deliverables by scope, not mandatory skill invocation. Broad independent assessments use audit workflows; focused domain reviews remain read-only. On continuation, reconcile task, authorization, state, and gaps. Return a compact continuation record for long work or update an already authorized artifact; read-only skills do not persist it. Distinguish artifact readiness, verified behavior, and external-action authority. Before retrieval, define the evidence question; read selectively without skipping applicable instructions. Use tools for mechanical processing; summarize bounded results, errors, coverage, and source paths, keeping full output outside context. Before technical decisions, establish applicability and actual versions; verify version-dependent assumptions against official documentation or specifications. Search and read primary pages for current external recommendations; snippets are not evidence. Version-matched bundled documentation or valid prior evidence suffices. Record decision, version, source, and limitations. Mark unavailable evidence UNVERIFIED; block only essential dependent work. Prefer native mechanisms, justify added tools or abstractions with evidence, and reuse the existing rule owner.

Tool Routing

NeedPreferred toolUse it whenFallback
Product and constraintsUser context plus existing product, analytics, customer, and strategy documentsEstablishing audience, assets, channels, economics, and non-goalsState assumptions and request only consequential missing intent
Current demand and acquisitionWeb research, trend or marketplace data, communities, reviews, ads, directories, and primary customer evidenceEvery external market claim that affects elimination or recommendationMark the signal unavailable; never infer a number from search-result count
Competition and pricingCompetitor product pages, pricing, release history, distribution channels, reviews, and public filings where relevantEstablishing substitutes, willingness-to-pay signals, and credible differentiationUse qualitative evidence with explicit confidence
Feasibility and validation costExisting capabilities, public APIs, regulations, platform rules, and current official documentationComparing the cheapest credible experiment and major blockersLabel estimates and name the evidence still required

Keep the evaluation read-only. Do not create project files, roadmaps, Epics, Stories, implementation plans, campaigns, listings, advertisements, or customer outreach.

Evidence Classes

ClassMeaning
MEASUREDDirect analytics, transactions, experiments, or instrumented observations with known method and date
REPORTEDA primary source reports a value or behavior, but the underlying measurement is not independently available
ESTIMATEDA stated model based on explicit inputs and assumptions
INFERREDA qualitative conclusion from observable proxies
UNKNOWNEvidence is unavailable, stale, incomparable, or too weak to support a decision

Do not turn REPORTED, ESTIMATED, or INFERRED evidence into a measured market size, search volume, conversion rate, revenue, or willingness-to-pay claim. Date every external source and distinguish the event date from the publication date when they differ. Treat the creator thesis, intended experience, taste, and conviction as owner preferences and strategic-fit inputs, never as demand, acquisition, or willingness-to-pay evidence.

Checklist

1. Frame the Decision

  • Resolve the existing product or capability, target users, creator thesis, intended experience, decision horizon, available assets, geographic or regulatory scope, constraints, and explicit non-goals.
  • Accept user-supplied candidates or generate a bounded set of materially distinct opportunities from product context and current signals; do not create cosmetic variants of one idea.
  • Define what would justify deeper validation: identifiable user and problem, observable demand, reachable channel, credible value exchange, differentiating wedge, and affordable experiment.
  • Separate discovery of a new direction from prioritization of already committed work or implementation planning.
  • Record assumptions that can reverse the recommendation, separate researchable facts from owner preference, and ask one concise question only when different interpretations materially change the candidates or experiment.

2. Collect One Evidence Bundle per Candidate

  • Identify who experiences the problem, how they solve it today, what triggers active search or purchase, and what evidence shows the pain is recurring or costly.
  • Find a reachable acquisition channel and its mechanism: query, marketplace category, integration ecosystem, community, partner, outbound audience, or another observable path.
  • Inspect direct competitors, substitutes, do-nothing behavior, pricing, positioning, distribution, review complaints, and evidence of continued investment or abandonment.
  • Examine economic signals without inventing unit economics: price anchors, budget owner, purchase frequency, switching cost, delivery cost, platform fees, and support burden.
  • Identify implementation, data, dependency, regulation, trust, distribution, and operational blockers that affect the cost of a validation experiment.
  • Capture source/date, evidence class, scope, confidence, contradictions, and decision impact. Trace reused statistics and syndicated reports to their origin; correlated copies are one signal, not independent corroboration.
  • Stop researching a candidate once the evidence is sufficient to eliminate it or additional sources cannot change its status.

3. Apply Evidence-First Elimination

  • Eliminate a candidate when evidence contradicts a necessary viability condition or shows no feasible validation path within the stated constraints. Missing public data alone defers the candidate to UNKNOWN under the rule below.
  • Treat competitor presence as a lead on demand and constraints; verify usage or purchase signals rather than assuming a listing proves demand. Require a concrete wedge against substitutes and doing nothing.
  • Do not use universal thresholds for search volume, competitor count, ARPU, market size, or MVP duration.
  • Preserve candidates with weak public data as UNKNOWN rather than labeling them invalid when a cheap primary experiment can resolve the uncertainty.
  • Record the decisive evidence and falsification condition for every eliminated candidate so rejection is reproducible.
  • Only after external viability, ask whether the owner is willing and able to pursue the audience, channel, operating model, and validation effort; do not infer personal interest.

4. Compare Survivors and Choose the Next Experiment

  • Compare survivors on evidence strength, problem severity, channel reachability, differentiation, economics, validation cost, strategic fit with the creator thesis and intended experience, and reversibility without collapsing them into a fake composite score.
  • Preserve meaningful disagreements and sensitivity: show which assumption would cause another candidate to become preferable.
  • Select one primary recommendation only when its evidence is materially stronger for the stated goal; otherwise return INCONCLUSIVE.
  • Define the cheapest credible validation experiment that tests the weakest decisive assumption through observed behavior rather than stated purchase intent alone.
  • Specify experiment audience, channel, offer or prototype, success and failure evidence, budget or time boundary, safety constraints, and stop rule without pretending to know the result.
  • Prefer reversible tests such as concierge delivery, prototype usage, pricing or preorder intent with appropriate disclosure, channel response, or integration demand before implementation commitment.

5. Validate and Report

  • Reconcile consequential external claims with the collected primary-source evidence; refresh only stale, contradicted, or decision-critical unsupported claims, and label weaker evidence explicitly.
  • Separate facts, estimates, inferences, owner preferences, and unresolved unknowns in the final result.
  • Keep the recommended opportunity, falsification condition, and experiment evidence distinct from an approved product requirement or commitment to build.
  • Use RECOMMEND <candidate> only when the candidate has a credible demand signal, reachable channel, differentiating path, plausible value exchange, and executable validation experiment.
  • Use INCONCLUSIVE when candidates remain plausible but evidence cannot select among them or a cheap experiment is required; use DO_NOT_PURSUE only when evidence eliminates every candidate within scope.
  • Use BLOCKED when the decision lacks product context, candidate scope, lawful research access, or a safe validation boundary.
  • Reconcile recommended, eliminated, and deferred candidates against their evidence; report the proposed next experiment without creating files or executing it.

Self-Check

  • Reconcile before returning. Check item-level evidence, requirement coverage, contradictions, scope, verdict, and applicable cleanup. Correct the report or authorized artifacts. Reuse valid evidence; do not automatically rescan the repository or rerun successful commands. Repeat checks only for relevant changes, failures, or unresolved evidence. Disclose remaining gaps.

Output Contract

Report in the user's language, in this order; label all five fields and state each fact once. Use controlled plain language: one fact per sentence, usually under 20 words, active voice, and one term per concept, with no synonyms for verdicts, IDs, or states. Small results may use one line per field; omit empty tables and do not copy linked artifacts:

  1. Result: The exact skill-specific verdict token first, then the supported outcome.
  2. Scope: Reviewed/changed scope, exclusions, baseline, and material assumptions.
  3. Evidence: Skill-specific fields below; distinguish facts, inferences, and unverified claims. Link artifacts; use tables when useful.
  4. Verification: Checks/results, unavailable evidence, and applicable cleanup/external state.
  5. Completion: Checklist: X/Y complete; Incomplete: None or each UNPROVEN item's reason, outcome impact, and exact next action; residual risks and required decisions.

Skill-specific evidence: Product, audience, candidates, constraints, and creator thesis separated from market evidence. Compare demand, channel, substitutes/wedge, economics, validation cost, source/date/class, and confidence. For eliminated or deferred candidates give decisive evidence or unknown and falsification/resolution condition. State the recommendation or inconclusive rationale and the proposed experiment contract, budget, stop rule, and decision-changing evidence; do not execute outreach or experiments.

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

同じリポジトリのスキル

概要と使いどころ

Defines product requirements, business rules and acceptance criteria for a committed intent; edits product docs only.

日本語の概要は準備中です。原文の説明を表示しています。

levnikolaevich/claude-code-skills5762026年10月12日 更新

Designs user flows, interaction states and mockups for a defined product scope; does not implement UI code.

日本語の概要は準備中です。原文の説明を表示しています。

levnikolaevich/claude-code-skills5762026年10月12日 更新

Defines measurable architecture drivers and constraints before system design; edits architecture docs only.

日本語の概要は準備中です。原文の説明を表示しています。

levnikolaevich/claude-code-skills5762026年10月12日 更新

Documents current architecture from implementation evidence; does not propose a target or audit fitness.

日本語の概要は準備中です。原文の説明を表示しています。

levnikolaevich/claude-code-skills5762026年10月12日 更新

Designs target system boundaries, contracts and tradeoffs from requirements; does not plan tasks or implement.

日本語の概要は準備中です。原文の説明を表示しています。

levnikolaevich/claude-code-skills5762026年10月12日 更新

Records one architecture decision with alternatives, consequences and status; does not design the whole system.

日本語の概要は準備中です。原文の説明を表示しています。

levnikolaevich/claude-code-skills5762026年10月12日 更新

levnikolaevich のスキルをすべて見る

このスキルの問題を報告する