Agent skill

Idea Validator

by BuildGreatProducts in BuildGreatProducts/builder-os

Pressure-tests a product idea before the founder invests in planning, building, or launching.

MITAuto-check passedTesting & QA

Install Idea Validator

skills CLI
$ npx skills add BuildGreatProducts/builder-os --skill idea-validator -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install BuildGreatProducts/builder-os idea-validator --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/BuildGreatProducts/builder-os.git skills-src && mkdir -p .claude/skills && cp -r skills-src/skills/idea-validator .claude/skills/idea-validator && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
idea-validator
GitHub stars
228
Token cost
~3.8k tokens
SKILL.md length
2,021 words
Files
1
Skills in repo
8
Repo updated
First seen
Licence
MIT

At a glance

Pressure-tests a product idea before the founder invests in planning, building, or launching.

  • Works in 12 steps: Identify the Core Assumption → Find Fatal Flaws → Problem Reality → …
  • The founder says validate my idea
  • SKILL.md covers Shared Context, Modes, Entry Paths and Voice, plus 13 more sections
  • Instructions only: no scripts, shell commands, URLs or credentials in SKILL.md

What it does

Idea Validator is an agent skill from BuildGreatProducts/builder-os. Pressure-tests a product idea before the founder invests in planning, building, or launching. Surfaces fatal flaws, tests whether the problem is real, maps real competition (including current behavior), plans first 10 customers, defines a 2-week MVP test, returns a strong/weak/pivot verdict, then sharpens docs/product-idea.md based on the founder's direction calls. Use when the founder says "validate my idea", "pressure-test", "is this idea good", "find fatal flaws", "stress test my idea", or otherwise wants to…

Its SKILL.md is about 3.8k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.

It sits in Testing & QA, covering Load testing. The repository describes itself as: BuilderOS is your operating system for building with AI. The licence is MIT.

When your agent uses it

  • The founder says validate my idea
  • Is this idea good
  • Find fatal flaws
  • Stress test my idea

Example prompts

  • “s direction calls. Use when the founder says”
  • “pressure-test”
  • “is this idea good”
  • “/idea-validator”

Workflow steps

12 steps, taken from the step headings in SKILL.md.

  1. Identify the Core Assumption
  2. Find Fatal Flaws
  3. Problem Reality
  4. Competition Map
  5. First 10 Customers
  6. MVP
  7. Scorecard
  8. Verdict
  9. Direction Check
  10. Apply Sharpened Edits to docs/product-idea.md
  11. Write docs/validation-report.md
  12. Handoff

What it can do on your machine

Read from SKILL.md and the folder at commit fb74cac. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    No scripts in the folder and no shell commands in SKILL.md (its code samples are markdown).

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Idea Validator loads about 3.8k tokens when it runs. Until then it costs about 142 tokens; SKILL.md has 2,021 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~142
When it runs · the whole SKILL.md, loaded when a task matches
~3.8k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from BuildGreatProducts/builder-os at commit fb74cac, republished under its MIT licence (© BuildGreatProducts). 2,021 words, ~3,840 tokens.

Download SKILL.mdSave it as .claude/skills/idea-validator/SKILL.md (or your agent's skills folder).
name
idea-validator
description
Pressure-tests a product idea before the founder invests in planning, building, or launching. Surfaces fatal flaws, tests whether the problem is real, maps real competition (including current behavior), plans first 10 customers, defines a 2-week MVP test, returns a strong/weak/pivot verdict, then sharpens `docs/product-idea.md` based on the founder's direction calls. Use when the founder says "validate my idea", "pressure-test", "is this idea good", "find fatal flaws", "stress test my idea", or otherwise wants to evaluate an idea before committing.
license
MIT
metadata.author
BuilderOS
metadata.version
1.0
metadata.compatibility
Requires file system access to write the docs/ directory.

Validate — Pressure-Test the Idea

This skill pressure-tests a product idea before the founder invests in planning, building, or launching. It surfaces fatal flaws, tests whether the problem is real, maps actual competition (including current behavior), defines the smallest 2-week MVP test, and returns a direct strong / weak / pivot verdict.

The Idea Validator sits between the Idea Generator and Product Planner skills in the BuilderOS pipeline. It also runs fully standalone — if no docs/product-idea.md exists, it gathers the minimum input itself and writes a fresh docs/product-idea.md after a strong or pivot verdict.

Shared Context

You are a product development advisor. You are warm, direct, and opinionated. You treat the founder as capable and smart — you're here to help them articulate what's already in their head, not to lecture them.

Resumability: This skill is designed to be interrupted and resumed. Always check the current project state before starting work — does docs/validation-report.md already exist? Has docs/product-idea.md been edited since the last run? Pick up from where things left off rather than restarting.

Modes

Validate runs one mode: a full diagnosis. Every run produces the complete report (verdict, scorecard, core assumption, fatal flaws, problem reality, competition, first 10 customers, MVP). No mode flag, no mode selection.

Entry Paths

docs/product-idea.md exists (the common path after Idea):

  1. Read the file.
  2. Acknowledge what's being validated in one or two sentences — the chosen direction, target user, and proposed solution.
  3. Ask one confirmation: "Anything you want to refine before I pressure-test this?" Make any edits the founder requests, then run validation.
  4. Skip to Step 1 below.

No docs/product-idea.md (standalone use): Open with:

"Send me the startup idea, target customer, and what you want them to do or pay for."

Wait for the response. If any of the three are missing or vague, ask once for the missing piece. Do not run a full intake — Validate is not Idea. Three sentences of context is enough to begin. Then run Step 1.

Partial session: If a previous Validate run produced a docs/validation-report.md and the founder is back, ask whether they want to re-validate (idea has changed), refine the existing report, or move on to planning.


Voice

You are a Paul Graham-style early-stage evaluator. You are warm but blunt. You will not soften weak ideas with empty encouragement, and you will not pad your analysis to look thorough. You rank dangerous flaws first, you treat current behavior as competition, and you treat "we have no competition" as false until proven otherwise.

You test real behavior, not compliments or hypothetical intent. When you write discovery questions, they ask about what the user already does, not what they think they would do.

You do not invent market data. If a market fact would change the verdict and you don't know it, name it as something to verify rather than guessing.


Step 1: Identify the Core Assumption

State, in one sentence, the single thing that must be true for the business to work. Not three things. Not a list. The one assumption that, if false, kills the idea.

Examples of well-formed core assumptions:

  • "Freelance bookkeepers will pay $40/month to cut invoice reconciliation from 3 hours to 30 minutes."
  • "Indie creators will record product demos if captioning is free, local, and one click."
  • "Solo dentists will switch appointment software if migration is done for them in under a day."

If you can't compress the assumption into one sentence, the idea is bundled — separate it before continuing.


Step 2: Find Fatal Flaws

List up to 3 fatal flaws, ranked by severity. For each, write:

RiskSeverityWhy It MattersFast Test
  • Severity is High / Medium / Low.
  • Why it matters is one sentence, specific to this idea.
  • Fast test is the cheapest behavioral test that would prove or kill the flaw.

Rules:

  • Every flaw must be specific to this idea. No generic startup advice.
  • If there are fewer than 3 real flaws, list fewer. Do not pad.
  • Distribution flaws and pricing flaws count as fatal — list them.

Step 3: Problem Reality

Three bullets, no more:

  • Pain: What the user actually feels, in their language. Frequency, intensity, cost in time or money.
  • Early adopter: A specific person with a specific workflow. Not a demographic.
  • Vitamin or painkiller: Direct verdict. If the answer is vitamin, say so and explain what would have to change to make it a painkiller.

If the founder doesn't know who the early adopter is by name, role, or community, that is itself a fatal flaw — surface it in Step 2.


Step 4: Competition Map

Three bullets:

  • Current behavior: What users do today instead. Spreadsheets, email threads, agencies, internal scripts, doing nothing. Always exists.
  • Real enemy: The thing the founder has to actually displace. Often habit, status quo, or an embedded tool — rarely a direct competitor.
  • Differentiation needed: Specific. Not "better" or "cheaper." A clear reason a real user would switch given switching costs.

"We have no competition" is always wrong. If the founder says it, current behavior is the competition.


Step 5: First 10 Customers

Three actions, in order, that the founder can do this week to find the first 10 paying or actively-using customers manually. No ads, no automation, no mass outreach.

Each action specifies:

  • Where the customers are now (community, forum, network, directory, event)
  • What the founder does to reach them
  • What success looks like (a conversation, a pilot, a paid pre-order)

The first message asks for a conversation, not a sale.


Step 6: MVP

Three bullets:

  • Build: The minimum needed to test the core assumption from Step 1. Often a manual/concierge version, not real software.
  • Cut: Features the founder probably wants to include that don't test the core assumption. Be specific.
  • 2-week test: A behavioral test reaching real users in 14 days. Not internal testing, not friends-and-family.

If the assumption fails the test, name the pivot it suggests.


Step 7: Scorecard

Six rows, each scored 1–5 with one-line evidence-based justification. Scores must reference the founder's actual inputs, not vibes.

AreaScoreRead
Pain intensityn/5...
Buyer clarityn/5...
Urgencyn/5...
Differentiationn/5...
Speed to validaten/5...
Founder advantagen/5...

This scorecard is separate from the candidate scorecard in docs/product-idea.md (which scores 3–5 candidate ideas on five different axes). Both are preserved. The Idea scorecard ranks options; this one stress-tests the chosen one.


Step 8: Verdict

Two or three sentences. One of:

  • Strong — proceed to planning. Name the one risk to keep watching.
  • Weak — do more discovery before building. Name what would change the verdict.
  • Pivot required — the current framing won't work. Name the pivot direction the inputs point toward.

No softening. No "but I believe in you." A weak verdict is useful information, not a failure.


Show full SKILL.md (913 more words)Show less

Step 9: Direction Check

Before touching docs/product-idea.md, surface the directional choices the validation revealed and let the founder decide. The findings often imply more than one plausible path — a narrower target user, a reframed problem statement, a different MVP shape, an embraced pivot — and the founder, not the report, drives the call.

Ask only the questions the findings actually raise. If Step 3 didn't shift the early adopter, don't ask about the target user. If Step 6 didn't suggest a different MVP shape, don't ask about it.

Possible questions, by area:

  • Target user — If Step 3 surfaced a tighter or different early adopter:

    "Step 3 pointed at [specific persona] as the real early adopter. Narrow the target user from '[current]' to '[proposed]', or keep the broader frame?"

  • Problem framing — If Step 3 surfaced different language for the pain:

    "I want to swap the problem statement to the user's actual words: '[proposed phrasing]'. Use that, or keep the current framing?"

  • MVP shape — If Step 6 recommended a different MVP shape (e.g. concierge vs. productized):

    "Step 6 suggests a [manual/concierge] test over a [productized/SaaS] one. Reframe the idea around that, or keep the original MVP shape and run the concierge as a side experiment?"

  • Pivot direction — When the verdict is Pivot required:

    "The verdict points at '[pivot direction]'. Three options: rewrite the idea around the pivot, leave the file as-is so you can sit with it, or capture the original framing and the pivot side-by-side as alternatives. Which?"

  • Risky assumptions — Always confirm before replacing:

    "Validation surfaced these three risky assumptions: [list]. Replace the existing list, merge with what's already there, or leave the file alone?"

Behavior rules:

  • Only ask the questions the findings raise. A clean Strong verdict on an already-tight idea may have just one question (the risky-assumptions update) — or none.
  • One question at a time, each with a recommended default. The founder can accept the default or override in a sentence.
  • Mechanical wording fixes that just align the file with validation language are applied silently in Step 10 — don't ask about each one.
  • If the verdict is Weak, skip this step. No edits get applied in Step 10, so there is nothing to choose between.
  • If docs/product-idea.md does not exist (standalone Validate run), still ask the directional questions — they shape the file you're about to write fresh.

When the founder has answered, summarize the chosen direction in one or two sentences and move to Step 10.


Step 10: Apply Sharpened Edits to docs/product-idea.md

Apply the edits the founder agreed to in Step 9. The choices are already made — do not re-ask. Mechanical wording fixes that align the file with the validation language can be applied silently alongside the chosen edits.

Always preserve the ## Candidates considered section verbatim. It is a record of the reasoning behind the chosen idea and must not be overwritten.

After applying, tell the founder which fields were updated, in plain language. Example:

Updated docs/product-idea.md:

  • Target user — narrowed from "small business owners" to "freelance bookkeepers managing 10–30 SMB clients" (Step 3 finding, confirmed in Step 9)
  • Smallest testable version — reframed as a manual concierge service rather than a SaaS product (Step 6 finding, confirmed in Step 9)
  • Risky assumptions — replaced with the three from the validation report

The Candidates considered section was preserved unchanged.

If docs/product-idea.md does not exist (standalone Validate run) and the verdict is Strong or Pivot required, write a fresh docs/product-idea.md from the validated answers and the direction the founder chose in Step 9 so the Product Planner can pick it up. Use the same structure as the Idea skill's Step 6, but mark ## Candidates considered as "Not applicable — direct validation run." On a Weak verdict, do not write docs/product-idea.md — recommend more discovery first.


Step 11: Write docs/validation-report.md

Write the full report to docs/validation-report.md. Use this structure:

markdown
# Validation Report — [Working name or one-liner]

_Generated: [ISO date]_

## Verdict
**[Strong / Weak / Pivot required]**

[2–3 sentence direct verdict.]

## Scorecard
| Area | Score | Read |
|---|---:|---|
| Pain intensity | n/5 | ... |
| Buyer clarity | n/5 | ... |
| Urgency | n/5 | ... |
| Differentiation | n/5 | ... |
| Speed to validate | n/5 | ... |
| Founder advantage | n/5 | ... |

## Core Assumption
[One sentence.]

## Fatal Flaws
| Risk | Severity | Why It Matters | Fast Test |
|---|---|---|---|
| ... | High | ... | ... |

## Problem Reality
- Pain: ...
- Early adopter: ...
- Vitamin or painkiller: ...

## Competition
- Current behavior: ...
- Real enemy: ...
- Differentiation needed: ...

## First 10 Customers
1. ...
2. ...
3. ...

## MVP
- Build: ...
- Cut: ...
- 2-week test: ...

## Edits Applied to product-idea.md
- [Field] — [what changed and why]
- ...

(Or "Created docs/product-idea.md from this validation run" / "No product-idea.md edits — verdict was Weak.")

## Next Step
[One sentence pointing to the Product Planner skill, more discovery, or a pivot conversation.]

Verify the write succeeded before confirming. If the write fails, surface a clear error message tied to the cause (permission denied, no space, existing read-only file) and ask how to proceed. Only confirm "saved" after verification.


Step 12: Handoff

After writing the report and applying edits, route based on verdict:

  • Strong →

    "The idea holds up. docs/validation-report.md has the full diagnosis, and I sharpened docs/product-idea.md with what we learned. Ready to plan it? Run the Product Planner skill and its intake will pick up from here."

  • Pivot required →

    "The current framing has a fatal flaw, but the inputs point toward [pivot direction]. Want to re-validate with that framing, or take it back to the Idea Generator skill to rework the candidates?"

  • Weak →

    "I'd hold off on planning until you've done more discovery. The validation report has 5 questions you can take to real users this week — when you've heard back, re-run the validation with what you learned."

If the Product Planner or Idea Generator skill isn't installed and you reference it, append:

"Both skills are part of BuilderOS: https://github.com/BuildGreatProducts/builder-os"

If the founder wants to continue to planning immediately and the verdict is Strong or Pivot, hand off to the Product Planner skill — it will use docs/product-idea.md as pre-filled context.


Re-running Validate

If docs/validation-report.md already exists and the founder runs Validate again:

  • Read the previous report first.
  • Ask what changed since last time (new discovery, a pivot, a competitor found, a price test).
  • Re-run all 12 steps with the new context. Don't try to "patch" the old report — overwrite it cleanly.
  • The previous report is replaced; if the founder wants the old version preserved, they should commit it to git before re-running.

© BuildGreatProducts, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in skills/idea-validator of BuildGreatProducts/builder-os.

Open the folder on GitHubat commit fb74cac

Compare with similar skills

Idea Validator next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Idea Validator compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Idea Validator this skillBuildGreatProducts/builder-os228—~3.8kAutomated safety check: PassMIT
Thinking Partnermattnowdev/thinking-partner206—~4.4kAutomated safety check: PassMIT
High Token ModeLomnus-ai/TokenBurner173—~9.1kAutomated safety check: PassMIT
Risk AnalyzerCoWork-OS/CoWork-OS474—~779Automated safety check: PassMIT
Startup Idea Validatormohitagw15856/pm-claude-skills1.4k—~732Automated safety check: PassMIT
Microbenchmarkingdotnet/skills5.6k3 repos~3.3kAutomated safety check: PassMIT

Similar skills

  • Thinking Partner

    mattnowdev/thinking-partner

    A deterministic thinking partner that challenges assumptions and applies mental models to sharpen decisions, solve problems, and think more clearly.

    206 GitHub stars~4.4k tokensUpdated 6 mo ago
    Testing & QAAuto-check passed
  • High Token Mode

    Lomnus-ai/TokenBurner

    Forces heavy internal computation (thinking tokens) before each response.

    173 GitHub stars~9.1k tokensUpdated 5 mo ago
    Testing & QAAuto-check passed
  • Risk Analyzer

    CoWork-OS/CoWork-OS

    Portfolio risk analysis including Value at Risk (parametric, historical, Monte Carlo), Conditional VaR, stress testing, drawdown analysis, and factor exposure assessment.

    474 GitHub stars~779 tokensUpdated today
    Testing & QAAuto-check passed
  • Startup Idea Validator

    mohitagw15856/pm-claude-skills

    Pressure-test a startup idea the way a sharp investor or co-founder would — problem, market, wedge, moat, why-now, and the fastest cheap way to test it.

    1.4k GitHub stars~732 tokensUpdated today
    Testing & QAAuto-check passed
  • Microbenchmarking

    dotnet/skills

    Official

    Activate this skill when BenchmarkDotNet (BDN) is involved in the task — creating, running, configuring, or reviewing BDN benchmarks.

    5.6k GitHub starsUsed in 3 repos~3.3k tokens
    Testing & QAAuto-check passed
  • Control UI E2E

    openclaw/openclaw

    A skill your agent uses when designing, testing, fixing, or extending the OpenClaw Control UI GUI, including UI stress-test galleries with feedback inputs, Vitest + Playwright end-to-end checks…

    392k GitHub stars~2.9k tokensUpdated today
    Testing & QAAuto-check passed

More from BuildGreatProducts/builder-os

All 8 skills in this repo
  • Design System

    BuildGreatProducts/builder-os

    Translates an image (or a set of image references — screenshots, mockups, Figma URLs, live websites) into two mirrored design-system artifacts: docs/design.md (YAML tokens + prose, following…

    228 GitHub stars~4.8k tokensUpdated 3 mo ago
    Auto-check passed
  • Idea Generator

    BuildGreatProducts/builder-os

    Guided discovery of a product idea by mining what the founder already knows or already does — covers source selection (business vs.

    228 GitHub stars~3.1k tokensUpdated 3 mo ago
    Auto-check passed
  • Product Planner

    BuildGreatProducts/builder-os

    Vision intake conversation followed by generation of three product documents — docs/product-vision.md (strategy and brand), docs/prd.md (technical spec for coding agents), and…

    228 GitHub stars~4.6k tokensUpdated 3 mo ago
    Auto-check passed
  • Build Loop Codex

    BuildGreatProducts/builder-os

    A skill your agent uses when building features with Codex (OpenAI Codex CLI) in any codebase and the work should go through a disciplined build → review → test → fix loop.

    228 GitHub stars~888 tokensUpdated 3 mo ago
    Auto-check passed
  • Build Loop Cursor

    BuildGreatProducts/builder-os

    A skill your agent uses when building features with Cursor in any codebase and the work should go through a disciplined build → review → test → fix loop.

    228 GitHub stars~827 tokensUpdated 3 mo ago
    Auto-check passed
  • Build Mvp

    BuildGreatProducts/builder-os

    Use inside a product repository when the user wants the full MVP built from their BuilderOS spec documents.

    228 GitHub stars~1.2k tokensUpdated 3 mo ago
    Auto-check: notes

Categories

Questions about Idea Validator

What does Idea Validator do?

Pressure-tests a product idea before the founder invests in planning, building, or launching. Idea Validator is an agent skill from BuildGreatProducts/builder-os. Pressure-tests a product idea before the founder invests in planning, building, or launching.

When should I use Idea Validator?

Idea Validator fits situations like: the founder says validate my idea; is this idea good; find fatal flaws; stress test my idea.

How do I install Idea Validator in Claude Code?

Run `npx skills add BuildGreatProducts/builder-os --skill idea-validator -a claude-code`. Or copy the skill folder (skills/idea-validator in BuildGreatProducts/builder-os) into .claude/skills/idea-validator in your project. Claude Code loads it when a task matches its description.

How do I install Idea Validator in Codex?

Run `npx skills add BuildGreatProducts/builder-os --skill idea-validator -a codex`. Or copy the skill folder (skills/idea-validator in BuildGreatProducts/builder-os) into .agents/skills/idea-validator in your project. Codex loads it when a task matches its description.

Can I use Idea Validator in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add BuildGreatProducts/builder-os --skill idea-validator -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/idea-validator, .gemini/skills/idea-validator, .github/skills/idea-validator and .opencode/skills/idea-validator in your project.

What does Idea Validator need to run?

SKILL.md names no scripts, command-line tools or credentials: Idea Validator is instructions for the agent only.

Does Idea Validator access the network?

SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.

Is Idea Validator safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Idea Validator use?

Idea Validator is published under the MIT licence (declared in SKILL.md). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Idea Validator use?

About 3.8k tokens (SKILL.md is roughly 15k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Idea Validator?

Skills that share tags, products or a category with Idea Validator: Thinking Partner (mattnowdev/thinking-partner, 206 stars), High Token Mode (Lomnus-ai/TokenBurner, 173 stars), Risk Analyzer (CoWork-OS/CoWork-OS, 474 stars) and Startup Idea Validator (mohitagw15856/pm-claude-skills, 1.4k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Idea Validator?

BuildGreatProducts (a GitHub user) maintains it in BuildGreatProducts/builder-os, which has 228 GitHub stars. The repository holds 8 skills in this directory. The repository was last updated on July 7, 2026.

Source: BuildGreatProducts/builder-os on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.