TexasBedouin/vibe-check: a pre-code planning skill for Claude Code, Codex and Antigravity
By a 12-year product manager who builds 0-to-1: takes a beginner from a vague idea to a buildable plan, then guides the build (GitHub basics, clean-code habits, a verify-and-iterate loop, a checkup for the mess). For Claude Code, Codex, and Antigravity. grill-me is for engineers, vibe-check is for everyone else.
At a glance
- What is it?
- vibe-check is an MIT-licensed skill that turns a vague app idea into a buildable blueprint before any code is written. It is aimed at first-time builders, and its hardest limits are the ones its own README admits: it plans, it does not build, and the plan is only as good as the research the agent can reach.
- Who is it for?
- Adopt vibe-check if you have an app idea and no engineering background, and you want the problem, the flows and the stack settled before an agent starts writing files. Skip it if you already know what you are building and only need implementation help, or if your idea cannot be researched from public sources, because the discovery steps lean on Reddit pain-mining and competitor analysis.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 63 days ago.
- What is it written in?
- Mainly HTML, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 17, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap vibe-check targets: planning happens before the first prompt
Most coding skills assume the hard decision is already made. The README states the premise plainly: "Every coding skill out there is great... if you already know what you're building." vibe-check is positioned on the other side of that line. It is a skill, not an application, and its job is to interrogate an idea before an agent writes anything.
The intended user is explicit. The README lists people who have an app idea but have never built software, vibe coders who can get something running on their own screen but cannot see the whole picture, and anyone who wants a structured plan before touching code. The repository's own framing puts it against grill-me, an adjacent project for engineers: grill-me is for engineers, vibe-check is for everyone else.
That audience choice drives the design. Explanations are meant to be plain-language, decisions are surfaced rather than assumed, and the output is a document a non-engineer can read. If you are a working developer who already scopes projects, the value proposition shrinks considerably.
How the skill works: research, scoring, then a blueprint the agent can follow
The mechanism is a guided sequence, not a single prompt. According to the README, the skill walks through discovery, experience mapping, decision surfacing, stack recommendation, and plan production, with build checkpoints along the way.
Discovery is the part with the most concrete machinery. The README names three techniques: Reddit pain-mining, competitor gap analysis, and ODI opportunity scoring. Those feed two artefacts, an Opportunity Map of scored, evidence-tagged needs and a Competitor Matrix showing where the gap sits. The v2.6.1 release note is worth reading alongside this: it says the Reddit fetch ladder now reads reddit.com directly. That is a small but telling detail, because it implies earlier versions depended on intermediaries and that fetching real user complaints is treated as load-bearing rather than decorative.
From there the session fills in an Experience Blueprint, converges on a direction from Crazy 8 sketches, sorts capabilities into V1, V2 and Later lanes on a Story Map, and draws happy, failure and edge-case flows. The stack recommendation comes with plain-language reasons for each piece, and the final plan is structured as the coding tool's onboarding manual plus an interactive PRD the human opens in a browser. Build checkpoints stop the agent after each phase to explain what was built and what comes next. Checkup Mode is the maintenance counterpart, described as a gentle pass over a messy codebase that tidies it safely.
The three on-ramps matter for cost. You can run the full journey, validation only, or planning only if you already have research. Planning only is the cheapest path and the one most likely to be overlooked.
Installing vibe-check with Claude Code and running a first session
The README gives the skills CLI as the easiest route. It installs across agents, so the same command works whether you are on Claude Code, Codex or Antigravity.
npx skills add TexasBedouin/vibe-checkIf you prefer to keep the skill inside a single project, the README offers a clone into the Claude skills directory instead.
git clone https://github.com/TexasBedouin/vibe-check .claude/skills/vibe-checkOnce installed, the README's example prompt is a plain sentence. You should see the agent pick up the skill and start asking about the problem rather than the feature list.
Use the vibe-check skill to help me plan my app.The README also gives on-ramp prompts for the shorter paths, including "Is my idea worth building? Reality-check it with vibe-check." and "I already validated my idea. Use vibe-check to plan the build." Updates are equally plain: `npx skills update` for the CLI install, or `git pull` inside `.claude/skills/vibe-check` for the clone.
For any other AI tool, the README says to copy the contents of `SKILL.md` into the tool's system prompt or project instructions. There is no package manifest, no server and no runtime. The repository is HTML, Markdown and assets, so installation is file placement and nothing else.
Where vibe-check stops: it plans, and the research can be thin
The skill does not write your application. It produces a plan document, an interactive PRD, diagrams and a stack recommendation, and then hands the build to your coding agent. If you expected the skill to scaffold a repository, it will not, and the README never claims otherwise.
Discovery quality is the second boundary. Reddit pain-mining and competitor gap analysis depend on what the agent can actually retrieve. The v2.6.1 note about reading reddit.com directly suggests retrieval has been a moving target, and any idea whose evidence lives behind a login, inside a private community or in a niche no one writes about publicly will produce a weaker Opportunity Map. The scoring framework will still run, but it will be scoring thin evidence.
There is also a commercial boundary worth naming. The README links paid services from the author, including idea validation, a rescue audit for AI-built apps, and a validated MVP blueprint. The method is free under MIT and the README says so, but the page doubles as a funnel. That is not disqualifying, and the author is transparent about it, but a reader should treat the free path and the paid path as genuinely separate offers rather than one continuous product.
Finally, the skill is opinionated about growth. It expects a growth loop to be designed before code, preferably viral and organic, built into the core flow. For internal tools, utilities and single-user projects, that step is wasted effort, and the README does not carve out an exemption for them.
How vibe-check differs from grill-me and from spec-driven tools
The nearest comparison in the repository is grill-me, which the README describes as the engineer-facing counterpart. The split is audience and timing. grill-me interrogates a builder who already has the vocabulary to answer hard questions about architecture and scope. vibe-check assumes the user cannot answer those questions yet, so it teaches the vocabulary as it goes, which is why the README spends space on local versus GitHub versus live, on commit, push and deploy, and on keeping secret keys out of the repository.
Against spec-driven development tools, the difference is where the specification comes from. A typical spec workflow takes your description and formalises it. vibe-check tries to challenge the description first, using external evidence, and only then formalises what survives. That is a heavier front end and a slower start, and it is the whole point: the README's claim is that the expensive failure is building the wrong thing well.
The trade-off is real. If your idea is already validated, the evidence-gathering stages are overhead, and the planning-only on-ramp exists precisely to skip them. If your idea is not researchable, the heavier front end buys you less than it costs.
Licence, maintenance and the cost of keeping the skill current
The repository is MIT licensed, which permits commercial use, modification and redistribution provided the licence and copyright notice are retained. This article is not legal advice; read `LICENSE` before shipping anything derived from it.
The last push was on 2026-07-17, and the repository is not archived. Recent releases are close together: v2.5.1 on 2026-07-10, v2.6.0 on 2026-07-10, and v2.6.1 on 2026-07-17. The v2.6.0 tag calls itself the lean core release, which suggests the project has already gone through a consolidation pass rather than only accumulating features. The repository carries a `CHANGELOG.md`, a `RELEASING.md`, a `VERSION` file and a `bump.sh` script, so versioning is deliberate rather than incidental.
Upgrade cost is low by construction. There is no dependency tree to reconcile and no service to redeploy. CLI installs update with `npx skills update`; clones update with `git pull`. The real maintenance question is not mechanical but editorial: the skill's advice is tuned to how Claude Code, Codex and Antigravity behave, and those tools change. A planning skill that tells a beginner to copy `SKILL.md` into a system prompt will need revisiting as agent configuration conventions move. The changelog is the place to watch for that, and it is the file to read before assuming a pinned version still reflects current agent behaviour.
Editorial conclusion
Adopt vibe-check if you have an app idea and no engineering background, and you want the problem, the flows and the stack settled before an agent starts writing files. Skip it if you already know what you are building and only need implementation help, or if your idea cannot be researched from public sources, because the discovery steps lean on Reddit pain-mining and competitor analysis. Verify two things first: that your agent actually loads SKILL.md, and that the generated plan names the auth, database, payment and hosting decisions you are willing to live with. The repository's own examples directory is the cheapest way to judge the output before you commit a session to it.
Frequently asked questions
What is TexasBedouin/vibe-check?
It is an MIT-licensed skill for AI coding tools that guides a beginner from a vague app idea to a buildable blueprint. The README positions it before the build, not during it: it discovers the underlying problem, maps the experience, surfaces decisions like auth and hosting, and produces a plan document plus an interactive PRD.
How do I use vibe-check with Claude Code?
The README gives two install routes: run `npx skills add TexasBedouin/vibe-check`, or clone the repository into `.claude/skills/vibe-check`. Then prompt the agent with something like "Use the vibe-check skill to help me plan my app." Other AI tools take the contents of `SKILL.md` pasted into their system prompt or project instructions.
Is vibe-check for engineers or for beginners?
For beginners. The README lists people who have never built software, vibe coders who can get something running but cannot see the full picture, and anyone who wants a structured plan before touching code. The repository contrasts it with grill-me, which it describes as the engineer-facing skill.
Does vibe-check write the application code for me?
No. It produces a plan document, an interactive PRD, user flows, a Story Map and a stack recommendation, and the README frames it as the coding tool's onboarding manual. The build itself is handed to your coding agent, with checkpoints after each phase.
What happens if my idea is already validated?
The README describes three on-ramps: the full journey, validate only, and plan only. If you already have research or a findings summary, the plan-only path skips discovery and goes straight to planning the build.
Community notes