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

saas-idea-validator

Evaluates a software or startup idea against problem, market, competition, monetization, defensibility, and execution, and returns a verdict rather than encouragement. Use this when an idea needs pressure-testing before anyone builds, when deciding whether something is worth pursuing, when assessing competition or willingness to pay, or when a validated idea needs a first-customers and MVP plan. Default to scrutiny; the useful answer is usually the unwelcome one.

インストール方法を見る

含まれるファイル(1)

  • SKILL.md4.4 KB

SKILL.md(原文)

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

SaaS idea validator

Most ideas fail for reasons visible before any code is written. Finding them costs an hour; not finding them costs a year.

Interrogate in this order

Problem. Who has it, how often, and what does it cost them today? An idea survives this only if you can name a specific person and what they currently do instead. "Businesses struggle with X" is not a problem statement — it is a category.

The strongest signal is a workaround: someone has built a spreadsheet, hired a contractor, or strung tools together to survive this. Paid workarounds are validated demand.

Market. Who exactly, and how many, and can you reach them? A large market you cannot address cheaply is smaller than a narrow one you can. Ask specifically: where do these people already gather, and what would it cost to reach a hundred of them this month?

Competition. Established competitors are usually good news — they prove budget exists. The dangerous answers are "nobody is doing this" (usually because it does not work or nobody pays) and "everybody is doing this" with no differentiation.

Name the actual alternative, including doing nothing and using a spreadsheet, which win far more often than competitors do.

Monetization. Who pays, how much, and out of which budget? Products die between "useful" and "someone has a line item for it." If the buyer and the user are different people, that is a different and harder business.

Defensibility. What stops a competitor copying this in a quarter? Features are not a moat. Data, switching costs, network effects, distribution, and regulatory position are.

Execution. Can this team build and sell it? Distribution is more often the binding constraint than engineering, and it is more often the one nobody has thought about.

The verdict

Give one. "It depends" is an evasion.

  • Pursue — what to validate first, and the cheapest test.
  • Pursue if — the specific condition that must hold, and how to check it.
  • Reframe — the adjacent idea that is stronger, and why.
  • Do not pursue — the reason, stated once, without softening.

Red flags

Any one of these should lower the verdict materially, and several together are usually fatal:

  • The problem is described in terms of the solution, and the founder cannot state it without mentioning their product.
  • Nobody currently pays anything to solve it, including in labor.
  • The stated advantage is "better UX" or "AI-powered" with nothing structural underneath.
  • The buyer is "everyone," or the segment widened when challenged.
  • Revenue depends on a platform whose terms could change unilaterally.
  • The founder has not spoken to ten prospective customers, and has a reason why not.

The investor lens

Whether or not you are raising, the question is clarifying: could this plausibly become large, and what would have to be true?

  • What does this look like at scale — same motion at ten times the volume, or a different business?
  • Where does growth come from once the obvious channel saturates? Most plans have exactly one channel and no answer.
  • What is the wedge and what is the expansion? A narrow entry point is a strength only if there is somewhere to go from it.
  • Why has nobody done this? Usually there is a reason. Find it before assuming you spotted something others missed.

When it survives

The first job is not building. It is finding ten people with the problem who will say what they do today and what they would pay. If ten cannot be found in a fortnight, the reachability answer above was wrong.

Then the smallest thing that delivers the value once, manually if necessary. A concierge version that works beats an automated version that might.

Never

  • Score an idea favorably because the person is invested in it.
  • Accept "there's no competition" without checking what people do instead.
  • Recommend building before anyone has said they would pay.

レビュー

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

同じリポジトリのスキル

概要と使いどころ

Designs and audits who can reach what — authentication, authorization models, privileged access, service credentials, and joiner-mover-leaver process. Use this to design a permissions model, run an access review, reduce standing privilege, handle offboarding, set up SSO or MFA, manage service and machine credentials, or diagnose why permissions have sprawled.

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

cbrock84/headcount2,0332026年9月18日 更新

Concentrates marketing and sales effort on a named set of accounts rather than on volume — qualifying whether the model fits your economics at all, building the account list and the buying group inside each, tiering effort against account value, coordinating so the account experiences one campaign rather than several, and measuring account progression instead of leads. Use this to decide whether to run an account-based program, build one, or work out why an existing one produces activity and no pipeline.

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

cbrock84/headcount2,0332026年9月18日 更新

Gets new users from signup to first real value — signup flow, onboarding, time-to-value, and the early experience that determines whether someone becomes a user or a lapsed account. Use this to design or fix signup and onboarding, diagnose why signups do not convert to active use, reduce time-to-value, or decide what a new user must accomplish first.

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

cbrock84/headcount2,0332026年9月18日 更新

Designs orchestrator-and-subagent hierarchies for a repository — splitting agents by exclusive write surface, pairing every producer with an independent auditor, and enforcing the split with a script that runs in CI. Use this whenever the user wants to set up, expand, audit, or fix a multi-agent or subagent structure for a codebase; asks how to divide work between agents; wants agent charters, roles, or a surface map written; or is hitting agents that collide on the same files, review their own work, or drift from their remit. Also use when sizing a roster or deciding whether a new agent is justified.

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

cbrock84/headcount2,0332026年9月18日 更新

Governs models and AI systems in production — intended use, evaluation, monitoring, human oversight, documentation, and the decision to deploy or retire. Use this before deploying a model or AI feature, when defining evaluation criteria, when a model's behavior has drifted, when assessing AI risk or regulatory exposure, or when deciding whether an AI system is fit for a consequential decision.

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

cbrock84/headcount2,0332026年9月18日 更新

Produces executive-level research — market sizing, competitor mapping, trend analysis, and strategic intelligence — grounded in cited sources with the confidence in each claim made explicit. Use this to analyze a market or industry, map competitors, evaluate a market-entry or build-versus-buy decision, produce a research brief, or assemble evidence for a decision. Also use when comparing options that need a structured, evidence-based verdict rather than an opinion.

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

cbrock84/headcount2,0332026年9月18日 更新

cbrock84 のスキルをすべて見る

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