Free builder toolkit
Prompts that make the next step checkable.
These are working templates for your own project. Fill in the evidence before sending one to an AI agent. You can copy, adapt and share them; no signup is required.
One-feature project brief
Use this before the first prompt. Replace the brackets and leave anything outside this feature in the not-now list.
ONE-FEATURE BRIEF — VibeGym User: [one person or role] Problem: [what they cannot do today] One action: [the smallest useful thing they should finish] Input: [what they provide] Result: [what they can see or use] Data: [where it is stored; use sample data first] Not now: [accounts, payments, integrations you can postpone] Acceptance checks: 1. Given [starting state], when [action], then [visible result]. 2. With empty or invalid input, [expected response]. 3. After refresh, [what should persist or reset]. Ask the agent: Explain your plan and which files you need to change. Build only this feature. State assumptions, then show how to check the result. Source: https://vibegym.space/resources#briefDownload plain text
Evidence-first bug report
Use this when an app fails. Remove passwords, tokens and personal data from logs before sharing them.
AI BUG REPORT — VibeGym Expected: [one concrete behavior] Actual: [what happened instead] Steps to reproduce: 1. [starting page or state] 2. [action] 3. [observed result] First relevant error: [exact message; redact secrets] Last working version: [commit or checkpoint] Last change: [what changed just before the failure] Environment: [local preview or deployed; browser; relevant versions] Impact: [who is affected; can you restore the last working release?] Ask the agent: Explain the likely cause using this evidence. Propose the smallest testable fix. Do not rewrite unrelated features. State how we will reproduce the problem before the fix and verify it after. Retest: [failed flow], [empty state], [one nearby working flow]. Source: https://vibegym.space/resources#debuggingDownload plain text
AI change review checklist
Use this before accepting an agent's change. A passing build is one check; it does not prove the feature or its permissions work.
AI CHANGE REVIEW — VibeGym [ ] I can explain the intended behavior in one sentence. [ ] I have a working checkpoint or reversible branch. [ ] The diff changes only the intended feature and necessary dependencies. [ ] I checked what data is read, written, shared or deleted. [ ] Secrets stay on the server, outside client code and version control. [ ] Two sample accounts cannot access each other's private records. [ ] The original failing case now passes. [ ] Empty, invalid and loading states behave as expected. [ ] Existing project checks pass, and I tested the UI at a narrow width. [ ] I know how to roll back this release if the live check fails. Unresolved questions: [record what remains unverified] Release check: [exact URL/action/result to test after publishing] Source: https://vibegym.space/resources#reviewDownload plain text
Example: a habit tracker that forgets your entries
A vague request says “fix saving.” A useful request says “I add a habit, see it in the list and refresh; the list is empty. I expected the habit to remain. The last change moved state into a new component. Check whether storage is actually written, then propose one fix.” That makes persistence an observable requirement.
Practice this decision in the free exercise, follow the debugging walkthrough, or read how these checks apply to VibeGym itself.