Status: accepted | Date: YYYY-MM-DD ## Context ## Decision ## Consequences (incl. what we gave up) ``` --- ## 4. Step-by-Step Guides ### Guide A — One-time setup (~30 min) 1. Run the bootstrap script (section 1). 2. Install the core cast: ```bash brew install git gh node uv ripgrep fd fzf npm install -g @anthropic-ai/claude-code # your primary agent ``` 3. Write `AGENTS.md` (copy section 2, edit commands to your stack). 4. Add `.mcp.json` (section 2) — Context7 alone eliminates most hallucinated-API bugs. 5. Fill in `projects/_template/` with the SDD templates from section 3. 6. `git init && git add -A && git commit -m "init: the garage"`. ### Guide B — Idea → running code (THE loop, ~2 hrs to first green) 1. **Start (5 min):** `cp -r projects/_template projects/002-my-thing`, `git init`, write `vision.md` in plain words. 2. **Spec — make the AI interview you (20 min).** Paste this: > Read spec/vision.md and constitution.md. Interview me to produce spec/spec.md. Rules: ask ONE question at a time, prefer multiple choice, never assume — when unsure, ask. Stop when you can write testable FRs. Then write spec.md and list remaining open questions. 3. **Plan (15 min).** Switch your agent to **plan mode** and prompt: > Propose the simplest stack that satisfies every FR in spec.md and respects constitution.md. Give me 2 options with tradeoffs, recommend one, and WAIT. After approval, write spec/plan.md. 4. **Tasks (10 min):** > Break plan.md into tasks: ≤1 commit each, grouped in phases, each with acceptance criteria traceable to an FR number. Write spec/tasks.md. 5. **Implement — one task per fresh context:** > /clear — then: Implement task 2.1 from spec/tasks.md exactly. Touch only the files it lists. When done: run pnpm test and pnpm lint, paste output, and summarize the diff in 3 bullets. 6. **Verify (the human half):** read the diff line by line → tests green → `git commit -m "task 2.1: auth"`. Repeat. 7. **Close the session:** write 3 lines in `journal/` — *what I built / what fought me / what's next* — then commit. ### Guide C — Daily driving (features on a live project) 1. `/clear` — fresh context every session. Old context breeds hallucinations. 2. Agent auto-reads `AGENTS.md` + project `CLAUDE.md`. Read the journal. 3. Pick ONE task. Run a mini-loop: spec-lite (3 lines of AC) → plan mode → implement → verify → commit. 4. Anything that grows >1 file conceptually → it earns a real spec. Write it. ### Guide D — When the AI is stuck (the debugging ladder) 1. **Make it deterministic first:** get a failing test that reproduces the bug. No repro = no fix. 2. **Hypotheses before fixes:** > Repro: <steps>. Error: <trace>. Files: <paths>. Do NOT fix anything yet. List your top 5 ranked hypotheses with the cheapest experiment to verify each. 3. **Rubber duck:** "Walk through `file.ts` line by line and tell me what you believe it does." The bug usually falls out. 4. **Timebox:** 3 failed attempts → stop. Either shrink the task, revert to last green commit (`git reset --hard <good-sha>`), or swap models — a different model often sees what the first one can't. 5. **Nuclear option:** revert, re-spec the problem smaller, retry. Commits every task = free save states. ### Guide E — Parallel agents with git worktrees (level-up) Run 2–4 agents simultaneously on **independent** tasks: ```bash git worktree add ../app-auth -b feat/auth git worktree add ../app-search -b feat/search cd ../app-auth && claude # agent 1 cd ../app-search && claude # agent 2 ``` Rules: one task per worktree, zero shared files between them, merge via PRs, you are the reviewer. Parallelizing coupled tasks = merge-conflict hell. ### Guide F — Ship checklist - [ ] Secrets only in platform env vars (Vercel/Railway/Fly dashboards), never in repo or prompts - [ ] Preview deploy green → then prod - [ ] Sentry (errors) + basic uptime wired - [ ] Rollback path known (previous deploy / git tag) - [ ] Tag the release: `git tag v0.1.0 && git push --tags` --- ## 5. Prompt Library (`ai/prompts/`) **`feature.md`** — new feature, controlled: > Implement <task> per spec/tasks.md. Constraints: only files listed in the task; follow constitution.md. Finish with tests+lint output and a diff summary. **`review.md`** — before you merge anything big: > Act as a skeptical staff engineer reviewing this diff. List, in order: (1) bugs, (2) security issues, (3) simplifications. Do not change code yet. **`debug.md`** — see Guide D, step 2. **`refactor.md`**: > Refactor <scope> for readability only. Behavior must be byte-identical. Run tests before and after, show both outputs. **`tests.md`**: > Write tests for <module> covering happy path + 3 edge cases from the spec's acceptance criteria. Use <Vitest/pytest>. Run them. --- ## 6. The Toolbox ### Primary agents — pick ONE, learn its rules system deeply (+ one backup) | Tool | Shape | Superpower | |---|---|---| | **Claude Code** | Terminal agent | Autonomous multi-file work, CLAUDE.md, hooks, plan mode | | **Cursor** | IDE | Tab autocomplete + background agents, `.cursor/rules/` | | **OpenAI Codex CLI** | Terminal/cloud | Great for async parallel tasks | | **GitHub Copilot** | IDE + agent mode | Native GitHub/PR integration, runs Spec Kit natively | | **Aider** | Terminal | Git-native commits, model-agnostic | | **Windsurf / Cline / Zed / Gemini CLI** | IDE / terminal | Solid alternates; Gemini CLI has a generous free tier | ### Spec & planning | Tool | Why | |---|---| | **GitHub Spec Kit** | Turns section 3 into slash commands: `/specify /clarify /plan /tasks /analyze /implement` | | **Kiro** (AWS) | IDE with requirements → design → tasks SDD built in | | **claude-task-master** | Auto-generates dependency-aware task lists from a PRD | | **Backlog.md** | Kanban board as markdown files in your repo — AI-readable tasks | | **Mermaid / Excalidraw** | Diagrams that live inside plan.md | ### MCP servers (context = everything) | Server | Why | |---|---| | **Context7** | Live library docs — kills hallucinated APIs | | **Playwright MCP** | Agent drives a real browser — E2E + visual debugging | | **GitHub MCP** | Issues/PRs from chat | | **Supabase / Postgres MCP** | Schema-aware database work | | **Firecrawl / Exa** | Web research with sources | ### Force multipliers | Tool | Why | |---|---| | **git worktrees** | Parallel agents (Guide E) — built into git | | **tmux / zellij** | Multiple agent sessions side by side | | **lazygit + gh CLI** | Review & PRs without leaving the terminal | | **ripgrep, fd, fzf, jq** | Fast find/grep — also used by agents | | **Vitest / pytest + Playwright** | The *verify* half of the loop | | **Biome (JS) / Ruff (Py)** | One fast lint+format tool | | **lefthook** | Git hooks that block bad commits | | **GitHub Actions** | The final referee — CI on every push | | **CodeRabbit / Greptile** | AI second-opinion on PRs | | **Vercel / Railway / Fly + Supabase** | Deploy + DB in minutes | | **Sentry + PostHog** | Know when the vibes break in prod | | **OpenRouter / LiteLLM** | Swap models per task type | | **ccusage** | Track your token spend before it tracks you | --- ## 7. House Rules (tape these to your monitor) 1. **Never accept an unread diff.** You are the reviewer; the AI is not. 2. One task = one prompt = one commit. 3. Tests green → *then* commit. Tests are your save states. 4. New task → new context (`/clear`). Stale context is where hallucinations breed. 5. Big change → plan mode first. Approve the plan, then let it write. 6. Secrets never enter prompts or repos. Ever. 7. Stuck 3× → stop: shrink the task, revert, or change the model. 8. Every session ends with a journal entry. Future-you is your best collaborator. --- Want me to tailor this? I can adapt the `AGENTS.md`, commands, and templates to your exact stack (e.g., Next.js + Supabase, Python/FastAPI, or a mobile stack), or generate a filled-in example spec for a real project idea you have.</article></body></html>

The user wants me to build "the perfect workspace for vibecoding AI enthusiasts" — they want: 1. A directory (folder structure) 2. SDD (Spec-Driven Development — likely referring to the spec-driven development workflow popularized by tools like GitHub's Spec Kit, or "Software Design Document"? In vibecoding context, SDD almost certainly means Spec-Driven Development, which is a big trend with tools like spec-kit, Kiro, etc.) 3. Step-by-step guides 4. Any tools that could be useful This is a request to essentially produce a comprehensive workspace kit/playbook for "vibecoding" — the practice of using AI coding assistants (Cursor, Claude Code, Copilot, Windsurf, etc.) with natural language prompts to build software, popularized by Andrej Karpathy in early 2025. Let me think about what a truly excellent answer looks like. This is a content-generation task where the user wants a comprehensive, well-organized deliverable. Format matters a lot here: this should be a long-form, structured document with headers, code blocks (for directory trees, config files, templates), and step-by-step guides. Markdown is appropriate since this is a conversational interface likely rendering markdown. Let me plan the content: ## 1. What is vibecoding / philosophy (brief) - Brief framing: AI-first development where you direct AI agents, focus on specs, taste, and review - The "vibe coder's loop": Idea → Spec → Plan → Prompt → Generate → Review → Test → Iterate → Ship ## 2. The Directory Structure A complete workspace scaffold. Let me design something like: ``` ~/vibe-workspace/ ├── README.md ├── CLAUDE.md / AGENTS.md / .cursorrules (AI context files) ├── projects/ │ ├── 001-project-name/ │ │ ├── spec/ (SDD artifacts) │ │ │ ├── 00-vision.md │ │ │ ├── 01-prd.md │ │ │ ├── 02-architecture.md │ │ │ ├── 03-tasks.md │ │ │ └── decisions/ (ADRs) │ │ ├── src/ │ │ ├── tests/ │ │ ├── prompts/ (reusable prompts) │ │ └── journal/ (session logs) ├── templates/ ├── prompts/ (global prompt library) ├── snippets/ ├── learnings/ (playbook, postmortems) ├── tools/ (scripts, MCP configs) └── archive/ ``` Actually, let me think about the modern conventions: - CLAUDE.md (Claude Code memory file) - AGENTS.md (emerging standard for agent instructions) - .cursor/rules/*.mdc (Cursor rules) - .windsurfrules (Windsurf) - .github/copilot-instructions.md (Copilot) - MCP (Model Context Protocol) config: .mcp.json A good workspace should support multiple AI tools. I'll design a structure that's tool-agnostic. ## 3. SDD (Spec-Driven Development) This is the big one. Spec-driven development with AI: write specs first, then have AI implement. Tools: GitHub Spec Kit (specify CLI), Kiro, Tessl, OpenAI's approach. I should explain the workflow: 1. **Constitution** — project principles 2. **Specify** — what to build (requirements, user stories) 3. **Clarify** — resolve ambiguities 4. **Plan** — technical implementation plan 5. **Tasks** — breakdown into implementable tasks 6. **Analyze** — cross-artifact consistency check 7. **Implement** — execute tasks I should provide templates for each artifact: - constitution.md - spec.md (PRD-ish) - plan.md - tasks.md - ADR template Also mention spec-kit commands: `/specify`, `/plan`, `/tasks`, `/implement`, `/clarify`, `/analyze`, `/constitution`. ## 4. Step-by-Step Guides Several guides: - Guide 0: One-time workspace setup - Guide 1: Starting a new project from zero (the full vibe loop) - Guide 2: Daily driving session workflow - Guide 3: Debugging when the AI is stuck - Guide 4: Context management (compacting, context engineering) - Guide 5: Review & testing discipline - Guide 6: Ship it (deploy) ## 5. Tools Categories: - AI coding agents: Claude Code, Cursor, Windsurf, GitHub Copilot, Aider, Cline/Roo Code, Zed, Gemini CLI, OpenCode, Amp - Spec tooling: GitHub Spec Kit, Kiro, Taskmaster AI, Backlog.md - MCP servers: Context7 (docs), Playwright MCP (browser), GitHub MCP, Filesystem, Sequential Thinking, Supabase MCP, Figma MCP - Terminal/tools: tmux, zellij, Git worktrees (parallel agents!), lazygit, gh CLI - Testing/quality: Playwright, Vitest, pytest, ruff/eslint/biome, pre-commit, CI (GitHub Actions) - Context/docs: DeepWiki,Exa/Firecrawl search, Perplexity - Model routing: OpenRouter, LiteLLM - Others: CodeRabbit (AI code review), Greptile, Sentry, Supabase/Vercel/Railway/Fly for deploy, Clerk/Auth The "pro stack": git worktrees for parallel agents, worktree scripts, kanban via Backlog.md or beads... maybe keep it focused. ## 6. Rules file templates Provide a starter CLAUDE.md / AGENTS.md template with: - Project overview - Tech stack with versions - Commands (dev, test, lint) - Code style rules - Guardrails (don't touch X, always run tests, etc.) - The "definition of done" ## 7. Prompt library Key prompts to keep: - Feature request prompt template - Debugging prompt - Refactor prompt - Code review prompt ("ultraview" style) - Test generation ## 8. Guardrails / best practices (the anti-slop checklist) - Commit often, small diffs - Never vibe production secrets - Test before accepting - Read the diff - Keep context clean: /clear between tasks - Use plan mode for big changes - The 90% problem — finishing is on you Formatting considerations: This will be a long response, but the user explicitly asked for a comprehensive kit ("Include a directory, SDD, step by step guides, any tool that could be useful"). So a long, well-structured markdown doc is appropriate. I should use: - Headers for sections - Code blocks for directory trees and file templates - Tables for tool lists (tables are great for scanning tools) - Numbered steps for guides But I should avoid making it bloated. Aim for comprehensive but tight. Maybe ~ a well-organized mega-guide. The user asked for a lot. I'll keep prose minimal and let the structure/artifacts carry the weight. Let me draft the actual content. --- # The Vibe Coder's Workspace (name it something fun: "The Vibe Garage"? "VibeKit"?) Let me structure: 1. **Philosophy** (3 bullets — short) 2. **The Directory** (annotated tree + bootstrap script) 3. **The Brain Files** (CLAUDE.md / AGENTS.md template + Cursor rules) 4. **SDD — Spec-Driven Development** (workflow diagram + artifact templates) 5. **Step-by-Step Guides** - Setup guide - New project guide (the full loop) - Daily driver guide - Debugging guide - Parallel agents with worktrees 6. **Prompt Library** (a few high-value templates) 7. **The Toolbox** (tables by category) 8. **House Rules / Guardrails** (checklist) 9. Maybe a closing "how to use this" note Let me write the directory tree carefully — this is a deliverable they'll actually copy. ``` vibeworkspace/ ├── README.md # How this workspace works ├── AGENTS.md # Agent instructions (read by Claude Code, Codex, etc.) ├── CLAUDE.md # -> AGENTS.md (symlink or pointer) ├── .cursor/rules/ # Cursor rules (mirror of AGENTS.md content) │ └── core.mdc ├── .mcp.json # Shared MCP server config ├── ai/ │ ├── prompts/ # Reusable prompt library │ │ ├── feature.md │ │ ├── debug.md │ │ ├── refactor.md │ │ ├── review.md │ │ └── tests.md │ ├── templates/ # SDD artifact templates │ │ ├── constitution.md │ │ ├── spec.md │ │ ├── plan.md │ │ ├── tasks.md │ │ └── adr.md │ └── learnings/ # Postmortems, gotchas, model notes ├── projects/ │ └── _template/ # Copy-me project scaffold │ ├── spec/ │ │ ├── constitution.md │ │ ├── vision.md │ │ ├── spec.md │ │ ├── plan.md │ │ └── tasks.md │ ├── journal/ # Session notes (what worked, what broke) │ ├── src/ │ ├── tests/ │ └── CLAUDE.md # Project-level agent context ├── scratch/ # Experiments; cheap to delete └── archive/ # Dead projects, kept for reference ``` Good. Also provide a bootstrap script? A short bash one-liner using mkdir -p could be nice. Yes, a small script adds practical value. Now the AGENTS.md template — this is critical. Contents: ```markdown # AGENTS.md — Workspace Instructions ## Identity & Goal You are my pair programmer. Optimize for correct, minimal, well-tested code. ## Environment - OS, editors, runtimes ## Commands - dev / test / lint / typecheck / build ## Workflow Rules 1. Plan before large changes; confirm plan. 2. Small diffs; one concern per commit. 3. Run tests + lint before declaring done. 4. Never invent APIs; check docs via context7 MCP. 5. Ask when ambiguous; don't guess silently. 6. Update spec/tasks docs when scope changes. ## Style - Language, formatter, naming, error handling, no comments unless needed ## Guardrails - Never touch .env, migrations without asking, main branch direct pushes ``` SDD section — the heart. Explain the seven phases with a flow diagram: ``` Idea → Constitution → Specify → Clarify → Plan → Tasks → (Analyze) → Implement → Review → Ship ``` For each artifact, a template. I'll write compact but genuinely usable templates. **Constitution** — non-negotiable principles. Template with sections: Purpose, Tech principles (simple > clever, libraries first, etc.), Quality gates, Non-goals. **Spec** — WHAT not HOW. Sections: Problem, Users, User stories with acceptance criteria (Given/When/Then), Functional requirements (numbered, testable), Non-functional, Out of scope, Open questions. **Plan** — HOW. Stack choices, architecture diagram (ASCII), data model, file structure, risks, tech decisions as ADR links. **Tasks** — bite-size, ordered, with acceptance criteria per task, sized "one prompt/one commit". Format: ```markdown ### Task 1.1: Project scaffold - [ ] Acceptance: `npm run dev` serves homepage Files: package.json, vite.config.ts, src/App.tsx ``` Also mention numbering phases (1. Setup, 2. Core, 3. Polish, 4. Ship). Mention GitHub Spec Kit as the toolized version: `uvx specify init`, slash commands /constitution /specify /clarify /plan /tasks /analyze /implement. And Kiro for AWS-flavored SDD. And task-master-ai for auto task generation. Guides — write 4-5 crisp guides: **Guide 1: One-time setup (30 min)** 1. Create dirs (script) 2. Install the core tools (list) 3. Write AGENTS.md 4. Configure MCP (.mcp.json example) 5. Create project template 6. Init git + first commit **Guide 2: New project from idea → running code (the core loop)** 1. mkdir from template; write vision.md in 10 min 2. Write spec (have the AI interview you! — nice trick: "Ask me one question at a time until the spec is complete") 3. Plan with AI in plan mode 4. Generate tasks; human-review 5. Implement task-by-task: fresh context per task, prompt = task + acceptance criteria 6. After each task: run tests, read diff, commit 7. Journal at end of session Include actual copy-paste prompts for each step. That's high value. **Guide 3: Daily driving (greenfield maintenance / features on existing project)** - Start: /clear, read journal, pick task - Feature flow: spec-lite → plan → implement → verify - End: journal, commit, push **Guide 4: When the AI is stuck (debugging ladder)** 1. Reproduce deterministically (failing test) 2. Paste error + relevant file, ask for hypotheses list before fixing 3. Rubber duck: ask AI to explain what the code does line by line 4. Timebox: 3 failed attempts → stop, simplify scope, or swap model 5. Nuclear: revert to last green commit **Guide 5: Parallel agents (level-up)** - git worktrees: `git worktree add ../proj-auth auth-feature` - run Claude Code / Cursor in each - one agent per independent task; merge via PRs - note: share nothing; only parallelize independent tasks **Guide 6: Ship** - envs, secrets, deploy (Vercel/Supabase/Fly), monitoring (Sentry), CI Maybe merge Ship into Guide 2 or keep as short guide. Keep it short. Prompt library — give 4-6 templates inline: 1. **Spec interview**: "I want to build X. Interview me one question at a time... then write spec.md" 2. **Task implementer**: "Implement Task 2.3 from spec/tasks.md. Acceptance criteria: ... Do not modify files outside [X]. Run tests when done." 3. **Reviewer**: "Review this diff as a staff engineer. List: bugs, security, simplicity wins. No code changes yet." 4. **Debugger**: "Here's the error and repro. List top 5 hypotheses ranked. Then propose the minimal experiment to confirm #1." 5. **Refactor**: "Refactor [X] for readability only. Behavior must be identical. Run tests before and after." 6. **Ultrathink/plan**: "Think hard. Produce a step plan first. Do not write code until I approve." Tools tables — categories: **AI coding agents** (pick one primary + one backup): - Claude Code (terminal, agentic, CLAUDE.md, MCP) — strong default - Cursor (IDE, rules, composer/background agents) - Windsurf - GitHub Copilot (Copilot agent, spec kit integration) - Codex CLI / cloud - Aider (git-native, terminal) - Gemini CLI (free tier) - Cline/Roo (VS Code, BYOK) - Zed **Spec & planning:** - GitHub Spec Kit - Kiro - Taskmaster (claude-task-master) - Backlog.md (kanban in markdown) - Mermaid/Excalidraw for diagrams **Context & knowledge (MCP):** - Context7 — up-to-date library docs - Sequential Thinking - Playwright MCP — browser control/testing - GitHub MCP — issues/PRs - Filesystem MCP - Supabase MCP / Postgres MCP - Firecrawl / Exa / Perplexity — web research **Support cast:** - git + gh CLI, lazygit - Git worktrees (built-in) - ripgrep, fd, jq, fzf - tmux/zellij for multiple agent sessions - Docker - Playwright/Vitest/pytest - Biome/Ruff/prettier - pre-commit / lefthook - GitHub Actions - Sentry, PostHog - Vercel/Fly/Railway/Supabase - CodeRabbit / Greptile for PR review - OpenRouter/LiteLLM to switch models I should keep tool tables scannable: Name | What it's for | Why/when. Keep each row short. Guardrails checklist (the discipline that separates "works" from "slop"): - Read every diff before accepting - Tests green or you don't merge - Small prompts, fresh contexts - Commit after every green step (checkpoint = revert point) - Secrets in .env only, .env in .gitignore, never paste prod secrets into prompts - Ask for plans before big changes - Timebox stuck sessions - Keep a journal - Don't let AI touch migrations/main without review - Note: legal/license care when vendoring code? Maybe too much. Keep list ~8 items. Also a "definition of done" checklist: - [ ] Acceptance criteria met - [ ] tests pass - [ ] lint/typecheck pass - [ ] no console.log debris - [ ] diff read - [ ] docs/spec updated if scope changed I might add a small "vibe loop" ASCII diagram at top for flavor: ``` ┌──────────── vibe loop ────────────┐ idea ─▶ spec ─▶ plan ─▶ tasks ─▶ generate ─▶ verify ─▶ commit ─┐ ▲ │ └───────────────── learn (journal) ◀───────────────────────┘ ``` Length: This is a "build me a comprehensive kit" request — long is justified. But I must keep it tight: avoid fluffy prose, prefer code blocks and tables. Target maybe 700-1100 lines rendered? That's a lot. Let me aim for thorough but not exhausting — I'll trim templates to essentials. Probably ~500-700 lines of markdown equivalent. The user asked for directory + SDD + guides + tools — four deliverables. Each deserves real content. I'll aim for high signal density. Should I offer to customize at the end? A brief closing line offering to tailor (e.g., "want me to tailor this for Python/web/etc.") is fine and useful. Keep it one sentence. Let me now write the final response carefully. Headers plan: - Title - The philosophy (one short block + loop diagram) - 1. The Directory - 2. The Brain Files (AGENTS.md + .mcp.json) - 3. SDD (workflow + templates: constitution, spec, plan, tasks) - 4. Step-by-step guides (setup, new project loop, daily driving, debugging, parallel agents, ship) - 5. Prompt library - 6. Toolbox tables - 7. House rules / definition of done - Closing offer Actually, to reduce redundancy, put prompt templates inside Guide 2 where they're used AND in a compact library section. Hmm — better to define them once in the prompt library and reference from guides, to avoid duplication. Or embed key prompts in guides since guides say "paste this." I'll embed short prompts in the guides (most useful placement) and keep the library section for the generic reusable ones (review, refactor, tests). Some overlap is fine but minimize. Let me write the templates compactly. Constitution template: ```markdown # Constitution — ## Prime directives 1. Working software over clever code. Simple > fast to write. 2. Small diffs. Every change must leave tests green. 3. Libraries before bespoke code. Boring tech wins. 4. The spec is the contract. Scope changes require editing the spec first. ## Quality gates (every task) - [ ] Tests pass, lint/typecheck clean - [ ] No new deps without written justification - [ ] No secrets, no console.log debris ## Non-goals - (things we will NOT build) ``` Spec template: ```markdown # Spec — ## Problem ## Users - : ## User stories US1: As a , I can so that . Acceptance: Given , when , then . ## Functional requirements FR1. The system shall . ← numbered = referenceable in tasks FR2. ... ## Non-functional Perf / security / a11y / platform constraints. ## Out of scope - Explicitly not doing: ... ## Open questions - (resolve via /clarify before planning) ``` Plan template: ```markdown # Plan — ## Stack (with versions) - Frontend: ... / Backend: ... / DB: ... ## Architecture ASCII diagram: browser → API → DB, external services ## Data model tables/objects with key fields ## Project structure one-line file tree ## Key decisions (ADR links) - D1: Why Next.js over X → adr/001.md ## Risks - R1: → mitigation ``` Tasks template: ```markdown # Tasks — generated from spec; each = one prompt, one commit, one green test run ## Phase 1 — Skeleton - [ ] 1.1 Scaffold repo, CI runs on push. AC: CI green. - [ ] 1.2 ... ## Phase 2 — Core (FR1–FR3) - [ ] 2.1 . AC: ... Rules: never batch >1 task per prompt; if a task takes >3 prompts, split it. ``` .mcp.json example: ```json { "mcpServers": { "context7": { "command": "npx", "args": ["-y", "@upstash/context7-mcp"] }, "playwright": { "command": "npx", "args": ["-y", "@playwright/mcp@latest"] }, "github": { "command": "npx", "args": ["-y", "@modelcontextprotocol/server-github"], "env": { "GITHUB_TOKEN": "..." } } } } ``` I should be careful with exact package names. Known ones: - `@upstash/context7-mcp` — yes, that's Context7's MCP package (npx @upstash/context7-mcp). Correct. - `@playwright/mcp@latest` — Microsoft's Playwright MCP, yes. - GitHub MCP: official is `@modelcontextprotocol/server-github` (archived but widely used) or the newer github/github-mcp-server (Go binary, docker). I can present the docker form or keep it simple. I'll use the filesystem server and mention github server generally. Maybe: ```json { "mcpServers": { "context7": { "command": "npx", "args": ["-y", "@upstash/context7-mcp"] }, "playwright": { "command": "npx", "args": ["-y", "@playwright/mcp@latest"] }, "sequential-thinking": { "command": "npx", "args": ["-y", "@modelcontextprotocol/server-sequential-thinking"] }, "filesystem": { "command": "npx", "args": ["-y", "@modelcontextprotocol/server-filesystem", "./projects"] } } } ``` These are all real. Good. Add a comment line that tokens/secrets go in env. Bootstrap script: ```bash mkdir -p ~/vibe/{ai/{prompts,templates,learnings},projects,scratch,archive} # plus template ``` Write it fully: ```bash #!/usr/bin/env bash set -e W="$HOME/vibe" mkdir -p "$W"/{ai/prompts,ai/templates,ai/learnings,projects,scratch,archive} mkdir -p "$W"/projects/_template/{spec/decisions,journal,src,tests} touch "$W"/AGENTS.md ln -sf "$W"/AGENTS.md "$W"/CLAUDE.md echo "Workspace ready at $W" ``` Nice touch: symlink CLAUDE.md → AGENTS.md so one file serves all agents. Setup guide tool installs: ```bash # core brew install git gh node uv ripgrep fd npm i -g @anthropic-ai/claude-code # or your agent of choice uv tool install specify-cli --from git+https://github.com/github/spec-kit # spec-kit ``` Hmm, spec-kit install: `uvx --from git+https://github.com/github/spec-kit.git specify init `. The CLI is `specify`, invoked via `uvx`. Let me write: ```bash uvx --from git+https://github.com/github/spec-kit.git specify init my-project ``` That's the documented command pattern. Good enough; I'll phrase it as "or use spec-kit's CLI". Claude Code install: `npm install -g @anthropic-ai/claude-code` — correct. Guide 2 detailed steps with prompts: Step 1 — Start (5 min): copy template, `git init`, write one-paragraph vision. Step 2 — Spec (20–30 min): prompt: ``` Read spec/vision.md. Interview me to write spec/spec.md. Rules: one question at a time; prefer multiple-choice; stop when you can write testable FRs. Then produce spec.md and list open questions. ``` Step 3 — Plan: switch to plan mode; prompt: ``` Propose the simplest stack that satisfies spec/spec.md and constitution.md. Give me 2 options with tradeoffs; recommend one; wait for approval. ``` then "Write the approved plan to spec/plan.md." Step 4 — Tasks: ``` Break plan.md into tasks ≤1 commit each, grouped in phases, each with acceptance criteria traceable to an FR number. Write to spec/tasks.md. ``` Step 5 — Implement loop per task: ``` Implement task 2.1 from spec/tasks.md exactly. Only touch the files it lists. When done: run the test suite and `npm run lint`, then summarize the diff. ``` Then: read diff → tests green → `git commit -m "task 2.1: ..."`. Step 6 — Session close: journal + commit. Daily driving guide (features on existing app): 1. `/clear` fresh context, read AGENTS.md auto-loads 2. Pick one task 3. Lite spec → plan → implement → verify → commit (same loop, smaller) 4. Keep journal: 3 lines per session (what I built / what fought me / next) Debugging ladder — as planned above. Add the killer prompt: ``` Repro: . Error: . Relevant files: . Do NOT fix yet. List your top 5 ranked hypotheses with how you'd verify each. ``` Parallel agents: ```bash git worktree add ../app-auth -b feat/auth git worktree add ../app-pay -b feat/payments cd ../app-auth && claude # agent 1 cd ../app-pay && claude # agent 2 ``` Rules: independent tasks only, separate branches, PRs, one human reviewer (you), merge order matters for conflicts. Ship checklist: - secrets → platform env vars, never repo - staging or preview deploy first - Sentry + basic uptime - rollback path (previous deploy / git tag) Toolbox tables. Let me draft rows concisely. Agents: | Tool | Shape | Superpower | | Claude Code | terminal agent | autonomous multi-file work, CLAUDE.md, hooks, MCP | | Cursor | IDE | tab autocomplete + background agents, .cursor/rules | | Codex CLI | terminal | OpenAI models, cloud tasks | | Copilot | IDE + agent mode | deep GitHub integration, spec-kit native | | Aider | terminal | git-native commits, model-agnostic | | Windsurf | IDE | Cascade agent flow | | Cline / Roo | VS Code extension | BYOK, browser use | | Gemini CLI | terminal | generous free tier, big context | Pick-one advice: "one primary agent + one terminal backup; learn its rules system deeply." Spec & planning: | GitHub Spec Kit | SDD harness | /specify /plan /tasks /implement slash commands | | Kiro | AWS IDE | requirements → design → tasks SDD native | | claude-task-master | task engine | generates dependency-aware task lists from PRD | | Backlog.md | kanban in markdown | tasks live in repo, AI-readable | | Excalidraw/Mermaid | diagrams | ASCII/arch diagrams in plan.md | MCP servers: | Context7 | fresh library docs | kills hallucinated APIs | | Playwright MCP | browser | agent drives a real browser; E2E | | GitHub MCP | repo ops | issues, PRs from chat | | Filesystem MCP | scoped file access | sandbox an agent to ./projects | | Supabase MCP | DB | schema-aware DB work | | Firecrawl / Exa | web | research with citations | Force multipliers: | git worktrees | parallel agents | built-in isolation | | tmux / zellij | session mgmt | many agents at once | | lazygit + gh CLI | git speed | review/PR without leaving terminal | | ripgrep, fd, fzf, jq | search | agents + you find things fast | | Vitest/pytest + Playwright | tests | the verification half of the loop | | Biome / Ruff | lint+format | one fast tool each | | lefthook / pre-commit | git hooks | block bad commits | | GitHub Actions | CI | the final referee | | CodeRabbit / Greptile | AI PR review | second pair of eyes | | Sentry + PostHog | prod telemetry | know when vibes break | | Vercel / Fly / Railway / Supabase | deploy+DB | ship in minutes | | OpenRouter / LiteLLM | model routing | swap models per task | | Claude-Code-Usage-Monitor / ccusage | spend tracking | know your burn | Maybe trim to keep tables digestible. That's fine. House rules (final checklist): 1. Never accept an unread diff. 2. One task = one prompt = one commit. 3. Tests green → then, and only then, commit. 4. New task → new context (/clear). Old context breeds hallucination. 5. Big change → plan mode first, approve before code. 6. Secrets never in prompts or repo. 7. Stuck 3× → stop, shrink the task, or change the model. 8. End every session with journal + clean git state. Definition of done: AC met / tests / lint+types / no debris / diff read / spec+tasks updated. Okay — I think the shape is solid. Now compress prose everywhere. Use bold sparingly-ish. The response will be long but every section is requested deliverables. Let me make sure headers are clean and numbered so it reads as a kit. One more consideration: the user said "Include a directory, SDD, step by step guides, any tool that could be useful" — I cover all four. Good. I'll write it now. Keep intro to one or two sentences. Use a fun name like "The Vibe Garage" or just "The Vibecoder's Workshop." I'll go with "THE VIBE GARAGE" or simpler: "The Vibecoding Workspace Kit". Keep it practical. Also small flavor: the loop diagram near the top. Final check on factual accuracy for tools: - Claude Code: npm i -g @anthropic-ai/claude-code ✓; supports CLAUDE.md, MCP, hooks, subagents, plan mode ✓ - Cursor: .cursor/rules/*.mdc ✓, background agents ✓ - Spec Kit: github/spec-kit, specify CLI via uvx, commands /constitution /specify /clarify /plan /tasks /analyze /implement ✓ - Kiro: AWS's spec-driven agentic IDE ✓ - Taskmaster: eyaltoledano/claude-task-master ✓ - Backlog.md: kanban CLI in markdown ✓ (real project) - Context7 by Upstash ✓ - Playwright MCP by Microsoft ✓ - sequential-thinking MCP ✓ - filesystem MCP ✓ - Supabase MCP ✓ - Exa, Firecrawl MCPs ✓ - Aider ✓, Cline ✓, Roo Code ✓, Windsurf ✓, Gemini CLI ✓, Zed ✓, Codex CLI ✓ - lazygit ✓, gh ✓, ripgrep ✓, fzf ✓, zellij ✓, tmux ✓ - lefthook ✓, pre-commit ✓ - Biome ✓, Ruff ✓ - CodeRabbit ✓, Greptile ✓ - Sentry, PostHog ✓ - OpenRouter, LiteLLM ✓ - ccusage ✓ (real tool for Claude Code spend) Good. Write it. Length control: I'll aim for a comprehensive doc but trim template examples to essentials, avoid repeating the same advice in multiple sections. Probably on the order of 600-800 lines of rendered markdown. Given explicit request for a full kit, that's appropriate — but I'll stay disciplined: no filler paragraphs, everything is artifact or instruction. # The Vibe Garage 🏗️ — A Complete Vibecoding Workspace Kit Everything below is copy-paste ready: directory scaffold, agent brain files, a full SDD (Spec-Driven Development) system with templates, step-by-step guides, a prompt library, and the tool stack. **The one rule that makes it all work:** you are the architect, the AI is the builder. Specs before code, small diffs, verify everything. ``` idea ──▶ spec ──▶ plan ──▶ tasks ──▶ generate ──▶ verify ──▶ commit ─┐ ▲ │ └─────────────────── learn (journal) ◀──────────────────────────────┘ ``` --- ## 1. The Directory One workspace, many projects, tool-agnostic (Claude Code, Cursor, Codex, Copilot, Aider all read from this structure). ``` ~/vibe/ ├── README.md # How this workspace works ├── AGENTS.md # 🧠 The brain — agent instructions (universal standard) ├── CLAUDE.md # symlink → AGENTS.md (one file, every agent) ├── .mcp.json # Shared MCP servers (docs, browser, repo access) │ ├── ai/ │ ├── prompts/ # Reusable prompt library │ │ ├── feature.md │ │ ├── debug.md │ │ ├── review.md │ │ └── refactor.md │ ├── templates/ # SDD artifact templates (section 3) │ │ ├── constitution.md │ │ ├── spec.md │ │ ├── plan.md │ │ ├── tasks.md │ │ └── adr.md │ └── learnings/ # Postmortems, model quirks, gotchas │ ├── projects/ │ ├── _template/ # Copy-me scaffold for every new project │ │ ├── spec/ │ │ │ ├── constitution.md │ │ │ ├── vision.md │ │ │ ├── spec.md │ │ │ ├── plan.md │ │ │ ├── tasks.md │ │ │ └── decisions/ # ADRs (architecture decision records) │ │ ├── journal/ # Session notes — your flight log │ │ ├── src/ │ │ ├── tests/ │ │ └── CLAUDE.md # Project-level agent context │ └── 001-my-app/ │ ├── scratch/ # Experiments. Cheap to delete, never commit-worthy └── archive/ # Dead projects, kept for parts ``` ### Bootstrap script ```bash #!/usr/bin/env bash set -e W="$HOME/vibe" mkdir -p "$W"/{ai/{prompts,templates,learnings},projects,scratch,archive} mkdir -p "$W"/projects/_template/{spec/decisions,journal,src,tests} ln -sf "$W/AGENTS.md" "$W/CLAUDE.md" echo " garage ready → $W" ``` --- ## 2. The Brain Files ### `AGENTS.md` — the single most important file Every agent session starts here. Keep it under ~100 lines; it's loaded into every context window, so tokens are money. ```markdown # AGENTS.md ## Role You are my pair programmer. Optimize for correct, minimal, well-tested code. Never invent APIs — look them up (Context7 MCP) or ask. ## Environment - macOS, zsh. Node 22 / Python 3.12. Package managers: pnpm / uv. ## Commands - Dev: pnpm dev - Test: pnpm test # must pass before any "done" claim - Lint/type: pnpm lint && pnpm typecheck - Format: pnpm format ## Workflow rules 1. Plan before large changes. Present the plan. Wait for approval. 2. One concern per change. Small diffs. 3. Run tests + lint before saying "done." Paste the output. 4. Never touch: .env*, migrations, main branch, /infra without asking. 5. Ambiguity → ask. Never guess silently. 6. Scope changed? Update spec/tasks docs FIRST, then code. ## Style - TypeScript strict. No `any` unless justified in a comment. - Early returns, no nesting >2 levels. - No comments except "why" — code should explain "how." - No console.log debris. No dead code left behind. ## Definition of done [ ] Acceptance criteria met [ ] tests green [ ] lint clean [ ] diff read by human [ ] no secrets ``` ### `.mcp.json` — give your agent superpowers ```json { "mcpServers": { "context7": { "command": "npx", "args": ["-y", "@upstash/context7-mcp"] }, "playwright": { "command": "npx", "args": ["-y", "@playwright/mcp@latest"] }, "think": { "command": "npx", "args": ["-y", "@modelcontextprotocol/server-sequential-thinking"] }, "filesystem": { "command": "npx", "args": ["-y", "@modelcontextprotocol/server-filesystem", "./projects"] } } } ``` *(Tokens/API keys go in `env` blocks or your shell profile — never in the repo.)* --- ## 3. SDD — Spec-Driven Development The core discipline: **the AI writes code, you write intent.** Four artifacts per project, generated in order. (If you want this automated, GitHub's **Spec Kit** implements exactly this pipeline with `/specify` `/plan` `/tasks` `/implement` commands — see the toolbox.) ### The flow ``` constitution ──▶ vision ──▶ spec ──▶ clarify ──▶ plan ──▶ tasks ──▶ implement (one task = one prompt) "rules" "why" "what" "gotchas?" "how" "steps" "go" ``` ### 3.1 `spec/constitution.md` — the non-negotiables ```markdown # Constitution — ## Prime directives 1. Working software > clever code. Simplest thing that works wins. 2. Libraries before bespoke code. Boring tech wins. 3. Small diffs only. Every change leaves tests green. 4. The spec is the contract. Changing scope = edit spec first, always. 5. Human reads every diff before commit. No exceptions. ## Quality gates (every single task) - [ ] tests pass - [ ] lint/typecheck pass - [ ] no new deps without written reason ## Non-goals - (List what we will NOT build. This kills 80% of AI over-engineering.) ``` ### 3.2 `spec/vision.md` — 10-minute pitch ```markdown # Vision One paragraph: what it is, who it's for, why now. One sentence: what "v1 success" looks like. ``` ### 3.3 `spec/spec.md` — WHAT, never HOW ```markdown # Spec — ## Problem ## Users - : wants ## User stories US1: As a , I can so that . AC: Given , when , then . ## Functional requirements (numbered = referenceable by tasks) FR1. The system shall . FR2. ... ## Non-functional Perf / security / accessibility / platform constraints. ## Out of scope - Explicitly not doing: ... ## Open questions - (Every one of these gets answered before planning. No silent assumptions.) ``` ### 3.4 `spec/plan.md` — HOW ```markdown # Plan ## Stack (pinned versions) Frontend: ... | Backend: ... | DB: ... | Deploy: ... ## Architecture [ASCII diagram: client → API → DB, external services] ## Data model Tables/objects with key fields and relations. ## Key decisions (→ decisions/ADR-NNN.md) - D1: Chose SQLite over Postgres because ## Risks - R1: → mitigation ``` ### 3.5 `spec/tasks.md` — the work queue ```markdown # Tasks — one task = one prompt = one commit = green tests ## Phase 1 — Skeleton - [ ] 1.1 Scaffold repo + CI. AC: CI pipeline green on push. - [ ] 1.2 Health endpoint. AC: GET /health → 200. ## Phase 2 — Core (FR1–FR4) - [ ] 2.1 Auth: email+password. AC: US2 acceptance criteria pass. ## Phase 3 — Polish ## Phase 4 — Ship RULES: Never batch tasks. A task taking >3 prompts gets split. ``` ### 3.6 `spec/decisions/adr-template.md` ```markdown # ADR-001: Status: accepted | Date: YYYY-MM-DD ## Context ## Decision ## Consequences (incl. what we gave up) ``` --- ## 4. Step-by-Step Guides ### Guide A — One-time setup (~30 min) 1. Run the bootstrap script (section 1). 2. Install the core cast: ```bash brew install git gh node uv ripgrep fd fzf npm install -g @anthropic-ai/claude-code # your primary agent ``` 3. Write `AGENTS.md` (copy section 2, edit commands to your stack). 4. Add `.mcp.json` (section 2) — Context7 alone eliminates most hallucinated-API bugs. 5. Fill in `projects/_template/` with the SDD templates from section 3. 6. `git init && git add -A && git commit -m "init: the garage"`. ### Guide B — Idea → running code (THE loop, ~2 hrs to first green) 1. **Start (5 min):** `cp -r projects/_template projects/002-my-thing`, `git init`, write `vision.md` in plain words. 2. **Spec — make the AI interview you (20 min).** Paste this: > Read spec/vision.md and constitution.md. Interview me to produce spec/spec.md. Rules: ask ONE question at a time, prefer multiple choice, never assume — when unsure, ask. Stop when you can write testable FRs. Then write spec.md and list remaining open questions. 3. **Plan (15 min).** Switch your agent to **plan mode** and prompt: > Propose the simplest stack that satisfies every FR in spec.md and respects constitution.md. Give me 2 options with tradeoffs, recommend one, and WAIT. After approval, write spec/plan.md. 4. **Tasks (10 min):** > Break plan.md into tasks: ≤1 commit each, grouped in phases, each with acceptance criteria traceable to an FR number. Write spec/tasks.md. 5. **Implement — one task per fresh context:** > /clear — then: Implement task 2.1 from spec/tasks.md exactly. Touch only the files it lists. When done: run pnpm test and pnpm lint, paste output, and summarize the diff in 3 bullets. 6. **Verify (the human half):** read the diff line by line → tests green → `git commit -m "task 2.1: auth"`. Repeat. 7. **Close the session:** write 3 lines in `journal/` — *what I built / what fought me / what's next* — then commit. ### Guide C — Daily driving (features on a live project) 1. `/clear` — fresh context every session. Old context breeds hallucinations. 2. Agent auto-reads `AGENTS.md` + project `CLAUDE.md`. Read the journal. 3. Pick ONE task. Run a mini-loop: spec-lite (3 lines of AC) → plan mode → implement → verify → commit. 4. Anything that grows >1 file conceptually → it earns a real spec. Write it. ### Guide D — When the AI is stuck (the debugging ladder) 1. **Make it deterministic first:** get a failing test that reproduces the bug. No repro = no fix. 2. **Hypotheses before fixes:** > Repro: <steps>. Error: <trace>. Files: <paths>. Do NOT fix anything yet. List your top 5 ranked hypotheses with the cheapest experiment to verify each. 3. **Rubber duck:** "Walk through `file.ts` line by line and tell me what you believe it does." The bug usually falls out. 4. **Timebox:** 3 failed attempts → stop. Either shrink the task, revert to last green commit (`git reset --hard <good-sha>`), or swap models — a different model often sees what the first one can't. 5. **Nuclear option:** revert, re-spec the problem smaller, retry. Commits every task = free save states. ### Guide E — Parallel agents with git worktrees (level-up) Run 2–4 agents simultaneously on **independent** tasks: ```bash git worktree add ../app-auth -b feat/auth git worktree add ../app-search -b feat/search cd ../app-auth && claude # agent 1 cd ../app-search && claude # agent 2 ``` Rules: one task per worktree, zero shared files between them, merge via PRs, you are the reviewer. Parallelizing coupled tasks = merge-conflict hell. ### Guide F — Ship checklist - [ ] Secrets only in platform env vars (Vercel/Railway/Fly dashboards), never in repo or prompts - [ ] Preview deploy green → then prod - [ ] Sentry (errors) + basic uptime wired - [ ] Rollback path known (previous deploy / git tag) - [ ] Tag the release: `git tag v0.1.0 && git push --tags` --- ## 5. Prompt Library (`ai/prompts/`) **`feature.md`** — new feature, controlled: > Implement <task> per spec/tasks.md. Constraints: only files listed in the task; follow constitution.md. Finish with tests+lint output and a diff summary. **`review.md`** — before you merge anything big: > Act as a skeptical staff engineer reviewing this diff. List, in order: (1) bugs, (2) security issues, (3) simplifications. Do not change code yet. **`debug.md`** — see Guide D, step 2. **`refactor.md`**: > Refactor <scope> for readability only. Behavior must be byte-identical. Run tests before and after, show both outputs. **`tests.md`**: > Write tests for <module> covering happy path + 3 edge cases from the spec's acceptance criteria. Use <Vitest/pytest>. Run them. --- ## 6. The Toolbox ### Primary agents — pick ONE, learn its rules system deeply (+ one backup) | Tool | Shape | Superpower | |---|---|---| | **Claude Code** | Terminal agent | Autonomous multi-file work, CLAUDE.md, hooks, plan mode | | **Cursor** | IDE | Tab autocomplete + background agents, `.cursor/rules/` | | **OpenAI Codex CLI** | Terminal/cloud | Great for async parallel tasks | | **GitHub Copilot** | IDE + agent mode | Native GitHub/PR integration, runs Spec Kit natively | | **Aider** | Terminal | Git-native commits, model-agnostic | | **Windsurf / Cline / Zed / Gemini CLI** | IDE / terminal | Solid alternates; Gemini CLI has a generous free tier | ### Spec & planning | Tool | Why | |---|---| | **GitHub Spec Kit** | Turns section 3 into slash commands: `/specify /clarify /plan /tasks /analyze /implement` | | **Kiro** (AWS) | IDE with requirements → design → tasks SDD built in | | **claude-task-master** | Auto-generates dependency-aware task lists from a PRD | | **Backlog.md** | Kanban board as markdown files in your repo — AI-readable tasks | | **Mermaid / Excalidraw** | Diagrams that live inside plan.md | ### MCP servers (context = everything) | Server | Why | |---|---| | **Context7** | Live library docs — kills hallucinated APIs | | **Playwright MCP** | Agent drives a real browser — E2E + visual debugging | | **GitHub MCP** | Issues/PRs from chat | | **Supabase / Postgres MCP** | Schema-aware database work | | **Firecrawl / Exa** | Web research with sources | ### Force multipliers | Tool | Why | |---|---| | **git worktrees** | Parallel agents (Guide E) — built into git | | **tmux / zellij** | Multiple agent sessions side by side | | **lazygit + gh CLI** | Review & PRs without leaving the terminal | | **ripgrep, fd, fzf, jq** | Fast find/grep — also used by agents | | **Vitest / pytest + Playwright** | The *verify* half of the loop | | **Biome (JS) / Ruff (Py)** | One fast lint+format tool | | **lefthook** | Git hooks that block bad commits | | **GitHub Actions** | The final referee — CI on every push | | **CodeRabbit / Greptile** | AI second-opinion on PRs | | **Vercel / Railway / Fly + Supabase** | Deploy + DB in minutes | | **Sentry + PostHog** | Know when the vibes break in prod | | **OpenRouter / LiteLLM** | Swap models per task type | | **ccusage** | Track your token spend before it tracks you | --- ## 7. House Rules (tape these to your monitor) 1. **Never accept an unread diff.** You are the reviewer; the AI is not. 2. One task = one prompt = one commit. 3. Tests green → *then* commit. Tests are your save states. 4. New task → new context (`/clear`). Stale context is where hallucinations breed. 5. Big change → plan mode first. Approve the plan, then let it write. 6. Secrets never enter prompts or repos. Ever. 7. Stuck 3× → stop: shrink the task, revert, or change the model. 8. Every session ends with a journal entry. Future-you is your best collaborator. --- Want me to tailor this? I can adapt the `AGENTS.md`, commands, and templates to your exact stack (e.g., Next.js + Supabase, Python/FastAPI, or a mobile stack), or generate a filled-in example spec for a real project idea you have.</article></body></html>

Build the perfect workspace for vibecoding AI enthusiastic. ...