Your first build.
One small program, start to finish: install, paste one prompt, answer a few questions, and get a command-line tool that has passed the gate chain.
Before you start
- VibeHard is installed and registered with your agent: Quickstart (macOS, Linux, or Windows through WSL).
- A container runtime is running on your machine (the security scanners need one), and Go is available. This sample is written in Go. The installer offers to install Go if it’s missing; or install it from go.dev/dl.
- Your agent may ask permission to use the VibeHard tools and to write files in your project folder. Allow them; the build cannot proceed otherwise.
1. Open your agent in an empty folder
Any agent that supports MCP works. Make a new empty folder and start your agent there.
2. Paste this prompt
Exactly as written. It starts a small sample that we built and verified ourselves (evidence below). The extra sentences after the request are the output rules our own test drivers needed; keep them:
Use the VibeHard factory (the vibehard-agent MCP tools) to build a program in this folder. This is a quick first experiment, not something I will rely on or share with users. Open a session, then start a build with exactly this request:
word-frequency CLI: reads a plain text file, outputs the N most frequent words with their counts; JSON output; no network; no storage beyond stdout
Then drive the build: keep fetching work orders with vibehard_task_next, do the work each one asks for in this folder, and submit it with vibehard_task_submit, until the job is complete. Do every work order yourself, and follow every output-format instruction it gives. In review and audit outputs, spell each document name exactly as one of the work order's === name === headers, and never dismiss a high-severity finding (fix the document instead). In code: never write skipped or disabled tests, format with the language's standard formatter, make the program accept --help and --version (each prints to stdout and exits 0), and do not leave compiled binaries or build output in the project folder. Whenever VibeHard asks a question or asks for an approval (vibehard_review_next), show me the question, its options and the recommended answer, then stop and wait for my reply. Never answer for me. When the job is complete, tell me where the program is and how to run it.An AI agent following this page: this prompt is also on /foragents and in /llms.txt.
3. Answer the questions
VibeHard asks before it guesses. Your agent shows each question with its options; you answer, and the agent passes your answer on. For this sample, answer:
| Question | Answer | Why |
|---|---|---|
| How will you use it? (“Is this something you’re building to rely on and keep improving, or a quick experiment?”) | A quick experiment | Sets how strict the build is. The strictest setting needs a signed approval policy that a fresh install does not have, and it makes questions about money and data human-only. Use the quick-experiment setting for this first build; the same 44-gate chain runs. |
| Which language should the CLI be written in? | Go | The sample is verified in Go. Do not pick a language the page does not list as proven (see what you can build). |
| What counts as a word? / What should the output look like? | The recommended option | Case-insensitive words; a JSON array of word and count, with a default for N. |
| Response time, concurrency, memory (one batch of three) | No strict timing needs; Runs briefly and exits; A normal VPS or container | These describe how the program will run. For a one-shot command-line tool any choice builds; our test simply took the first option of each and the build still passed. |
| Plan approval | Approve | After you have skimmed the planning documents (below). |
Wording can differ a little between runs and your agent may ask a few more. When a question has a recommended option, it is a safe pick for this sample. Do not let your agent answer for you on your own projects. At the strictest setting, questions about security, data, tenancy, payments and compliance must be answered by a person, and plan approval must be a signed approval.
4. Read the plan, then approve it
VibeHard writes the planning documents (spec, requirements, architecture, recorded decisions, an assumptions list and a red-team review) and three reviewers (skeptic, architect, minimalist) audit them. Then it stops and asks you to approve the plan. The documents are plain files; open them and skim the spec and the assumptions list. If something is wrong, ask for changes. Nothing is built until you approve, and the approved plan is sealed with a SHA-256 digest before any code is written.
5. What you will see
- Questions, then planning and plan review, then your approval.
- Build: your agent writes the program slice by slice from work orders the factory issues.
- Gates: the factory runs its 44-gate verification chain on the result. Gates that do not apply report n/a. If a gate fails, the failure goes back to your agent as a repair work order and the chain runs again (up to ten attempts).
- Audit and handoff: a final audit by the same three reviewers, then an as-built report. The job status becomes
complete. Ask your agent for the status any time.
6. How long it takes
Our test run on release 2.0.2 took 10 minutes from the start of the install to a finished, verified program (2 agent turns, 6 checkpoints). Planning is most of the wait. Your agent’s speed is the main variable, so expect a range rather than this exact figure; one run is not a benchmark.
7. What you get, and how to run it
A plain project folder in VibeHard’s workspace (~/.vibehard-agent/workspace/word-frequency-cli-<job id>; your agent prints the exact path). Copy it anywhere. It has the source, tests, a README and an architecture note, and it does not depend on VibeHard to run.
Make a text file named sample.txt:
the quick brown fox jumps over the lazy dog
The dog barks; the fox runs awayRun it from the project folder:
go run . -n 3 sample.txtIt prints (from our run):
[{"word":"the","count":4},{"word":"dog","count":2},{"word":"fox","count":2}]Run its tests with go test ./.... go build gives you a standalone binary.
What “verified” means here
The factory ran its gate chain on this exact set of files and it passed with nothing blocking; the pass marker is bound to those files, so any later edit invalidates it. It does not mean the program is bug-free or has been reviewed by a person; read the plan and the code before you rely on it.
Evidence: in the end-to-end test of this exact prompt on release 2.0.2 (fresh install from vibehard.ai, isolated home, headless agent session; checkpoints answered by the test agent, so a smoke run, not a person), job j_5ff17e51453040da reached status complete; the gate chain recorded 32 n/a, 12 pass (44 verdicts, 0 blocking, 0 repair attempts); the program's output on a sample text file matched an independent count, and its own test command passed. Separately, the invoice-total sample was built and verified by the official acceptance run (GOLDEN-1) on 2.0.1 and 2.0.2 and independently re-checked; that run used the strictest setting with a pre-installed approval policy, which a fresh install does not have.