DEV Community

bin1874
bin1874

Posted on • Originally published at beforeyoubuild.fyi

I added a pre-build check to my AI coding workflow

AI coding agents are good at starting.

That is useful, but it also creates a bad habit: I can ask an agent to build a feature before I have checked whether the feature should exist.

I kept seeing the same failure mode in my own workflow:

  • the target user was fuzzy;
  • the current alternative was not named;
  • the pain sounded real, but not frequent;
  • the distribution path was a guess;
  • the first version was already too large.

None of those are architecture problems. They are product risk problems. If I skip them, the code can still be clean and the project can still be wrong.

So I packaged the check as a small open-source skill:

npx before-you-build-skill install codex
Enter fullscreen mode Exit fullscreen mode

There are also local adapters for Claude Code, Cursor, OpenClaw, Hermes, and Gemini CLI:

npx before-you-build-skill install claude
npx before-you-build-skill install cursor --path /path/to/project
npx before-you-build-skill install openclaw
npx before-you-build-skill install hermes
npx before-you-build-skill install gemini
Enter fullscreen mode Exit fullscreen mode

The skill does not build the app.

It asks the coding assistant to pause before implementation and review questions like:

  • Who is this for?
  • What do they use today?
  • Why would they switch?
  • How often does the problem happen?
  • What would make this fail?
  • What is the smallest useful test before writing the full version?

The output is meant to be short. A useful answer is not a business plan. It should usually end with a verdict such as:

  • build small;
  • validate first;
  • pivot first;
  • do not build yet.

Here is the kind of prompt I use:

Use before-you-build to review this idea before implementation:

I want to build an AI tool that helps freelancers summarize client calls and turn them into follow-up emails.
Enter fullscreen mode Exit fullscreen mode

A good review should push back on the weakest assumptions:

  • freelancers may already use meeting notes or the client's own recap;
  • the pain may be occasional rather than weekly;
  • privacy concerns may block call recording;
  • a paid buyer may be hard to reach through a repeatable channel;
  • a manual email template test may be enough before building the full app.

That kind of answer saves more time than another generated file tree.

The package is open source:

https://github.com/bin1874/before-you-build-skill

The install page is here:

https://beforeyoubuild.fyi/en/skill

I am still improving the adapters and examples. The main question I am testing is simple: should this live inside the coding assistant as a skill, or is a normal checklist enough?

Top comments (0)