Idea Validator

Idea Validator

Critically evaluate ideas with honest feedback on market viability, technical feasibility, and actionable improvements.

When to Use

Trigger this skill when the user asks to:

• Evaluate, validate, or score an app idea or startup concept
• Get honest feedback on whether an idea is worth building
• Research what competitors already exist in a space, including commercial tools/services and open-source alternatives
• Turn a vague concept into a structured validation report

Instructions

Run the steps in this order: Setup → Phase 1 Clarify → Phase 2 Technical Context → Phase 3 Competitive Landscape → Phase 4 Evaluate → Phase 5 Improve → Commit and Push → Final Report. Do not skip or reorder a step, except where an Edge Cases row says to stop. A stop after Setup step 4 still runs Commit and Push on the files written so far, then the Final Report. If the ideas root is the root of an ideas repo, also run README Maintenance after each file update (detection rule in that section).

Terms used throughout:

• Ideas root — the directory that holds every idea folder (resolved in Setup step 2).
• Project folder — <ideas root>/YYYY_MM_DD_<short_snake_case_name>/, holding this idea's idea.md and validate.md.
• Status — the run outcome, COMPLETE, PARTIAL or BLOCKED, chosen by the rules in Final Report.

Repo Sync Before Edits (mandatory)

Run this in the ideas root, before Setup step 3 creates or changes any file. Skip it when the ideas root is not inside a git repository (git -C <ideas root> rev-parse --git-dir fails), and record that skip for the Final Report.

If git status --porcelain prints nothing, sync directly:

cd "<ideas root>"
branch="$(git rev-parse --abbrev-ref HEAD)"
git fetch origin
git pull --rebase origin "$branch"

If it prints anything, stash first, sync, then restore:

git stash push -u -m "pre-sync"
branch="$(git rev-parse --abbrev-ref HEAD)"
git fetch origin && git pull --rebase origin "$branch"
git stash pop

If origin is missing, the pull fails, or the rebase or stash pop conflicts, stop and ask the user before continuing.

Setup

1. Get the idea. Use the idea in $ARGUMENTS. If $ARGUMENTS is empty, ask the user to describe the concept. If no description arrives, stop with status BLOCKED.

2. Resolve the ideas root (tool-agnostic; ask once per environment). Take the first that applies:

   1. The env var IDEAS_ROOT, if set.
   2. The path in ~/.config/ideas-root.txt, if that file exists.
   3. The path in legacy ~/.openclaw/ideas-root.txt, if that file exists. Copy the value into ~/.config/ideas-root.txt.
   4. Otherwise, ask the user where to store generated docs. Suggest ~/workspace/ideas. Save the answer to ~/.config/ideas-root.txt.

   Ask again only when the user asks to change the location.

3. Create the project folder under the ideas root. If a folder with the same date and name already exists, reuse it and update its files instead of creating a second one.

4. Create idea.md with the idea and the clarifications.

5. Create validate.md for the evaluation and recommendations.

6. Echo the absolute project folder path in your response, so downstream skills can pick it up.

If the ideas root cannot be created or written, stop with status BLOCKED and name the path.

Read references/file-templates.md when creating either file or updating a section named in Phases 1-5. That file owns header names and order; the phase instructions own the content.

Phase 1: Clarify the Idea

Ask the user these questions with the question tool (AskUserQuestion or equivalent). If no question tool exists, ask in plain chat. Skip a question that the idea description from Setup step 1 already answers.

• What problem does this solve? Who has this pain?
• Who is your target user? Be specific.
• What makes this different from existing solutions?
• What does success look like in 6-12 months?

Update idea.md with the responses. Write unknown for each question the user declines or cannot answer, and list it under Uncertainty in the Final Report. The target-user question is the exception: see Edge Cases.

Phase 2: Gather Technical Context

Ask the user, with the same tool and skip rule as Phase 1:

• Preferred tech stack?
• Timeline and team size?
• Budget situation (bootstrapped/funded/side project)?
• Existing assets (code, designs, research)?

Update the idea.md Technical Context section. Write unknown for each unanswered item.

Phase 3: Competitive Landscape Research

Before evaluating the idea, perform live web research to find what already exists in the space. Do not rely on memory or training data for market, pricing, traction, competitor, or open-source claims — web search is mandatory so the report reflects current information.

Use the available web search tool (WebSearch, web_search, or equivalent) to run at least 4 varied queries covering:

Commercial tools/services — SaaS products, mobile apps, enterprise platforms, paid APIs, agencies, marketplaces, and other commercial offerings solving the same or adjacent problem. Search the core problem statement plus keywords like "app", "tool", "platform", "SaaS", "startup", "pricing", "alternative", and audience-specific terms.

Open-source solutions — GitHub/GitLab repositories, self-hosted tools, packages, frameworks, templates, and OSS alternatives that solve the same problem or provide a strong foundation. Search with terms like "open source", "GitHub", "self-hosted", "OSS", "alternative", "library", and relevant package registry names. If no credible OSS option is found, document the queries tried and state that no maintained open-source baseline was found.

Adjacent solutions — products or projects that solve a related problem or serve the same audience differently. These reveal how users currently cope without the proposed solution.

Failed attempts — startups, products, or OSS projects that tried something similar and stalled, shut down, or were abandoned. Search for "[concept] startup failed", "[concept] post-mortem", "[concept] abandoned GitHub", or check product directories.

For each competitor or OSS project found, capture:

• Name and URL
• Type (commercial, open-source, hybrid, adjacent, failed/abandoned)
• What they do (one sentence)
• Pricing or license (free, freemium, paid, enterprise, OSS license if available)
• Traction or health (reviews, ratings, users, funding, GitHub stars/forks, recent commits, open issues, community activity)
• Key weakness or gap the user's idea could exploit
• Reuse/build-on potential for open-source options (fork, plugin, library dependency, contribution path, or not suitable)

Aim for 3-8 total competitors, with at least one commercial and one open-source search path. If fewer than 3 credible results are found, record that in validate.md as a signal: the market is niche, the terms need refining, or the idea is framed in unfamiliar language.

When an open-source solution already solves a meaningful part of the idea, compare license fit, maintenance health, architecture, extensibility, deployment burden, and community before recommending a greenfield build. Decide whether the user should build on it, fork it, contribute to it, or differentiate sharply.

Update validate.md with a ## Competitive Landscape section containing:

1. A summary table of commercial and open-source competitors found
2. An Open-source Alternatives & Reuse Potential analysis
3. A "white space" analysis — what's missing in the current market
4. Honest assessment: is the user's differentiation real or imagined given what exists?
5. A build-vs-base recommendation when OSS foundations exist

If web search is unavailable or blocked, stop and ask the user whether to continue without it. If the user says yes, label the Competitive Landscape section Not verified by live search and set the status to PARTIAL. If the user says no, stop with status BLOCKED. Never silently replace live research with general knowledge.

Phase 4: Critical Evaluation

Evaluate honestly and update validate.md:

Market Analysis:

• Similar commercial products and open-source solutions
• Market size and competition
• Unique differentiation

Demand Assessment:

• Evidence people will pay
• Problem urgency level

Feasibility:

• Can this ship in 2-4 weeks MVP?
• Minimum viable features
• Complex dependencies?
• Could an existing OSS project be reused, forked, extended, or used as a reference instead of starting from scratch?

Monetization:

• Clear revenue path?
• Willingness to pay?

Technical Risk:

• Buildable with stated constraints?
• Key technical risks?
• License, maintenance, and dependency risks if building on open source?

Duplication / Reuse Risk:

• Is the idea mostly a reimplementation of an existing commercial or OSS solution?
• Is there a credible build-on, plugin, fork, or contribution path that would reduce risk?

Ratings (1-10): Creativity, Feasibility, Market Impact, Technical Execution. Give each score a one-line reason.

Verdict. Take the first rule that matches:

1. Skip it — Phase 3 found a near-identical product and the user named no genuine differentiator, or a hard blocker exists that the stated team and budget cannot remove.
2. Maybe — any of: an unresolved hard technical risk, a maintained OSS project that covers most of the idea with no chosen build-on path, demand or willingness to pay with no evidence, or a Feasibility score below 6.
3. Build it — none of the above.

Write the verdict with the rule that produced it and a 2-3 sentence rationale.

Phase 5: Improvements

Update validate.md with:

• How to Strengthen: Specific, actionable improvements, each tied to a concern from Phase 4
• Enhanced Version: Reworked, optimized concept
• Implementation Roadmap: Phased approach (if applicable)