/build

name: build
description: Plan and execute code implementation for a feature or product. Can generate a plan file for Cursor or build directly with Claude. Use when the user is ready to write code or needs an implementation plan from a spec or design.
argument-hint: ticket, spec, or feature description
disable-model-invocation: true

Build: $ARGUMENTS

You are handling implementation for the CEO. Determine the input type from `$ARGUMENTS`:

• If it's a **ticket file path** (e.g., `.solopreneur/backlog/{dir}/MVP-001.md`), read the ticket for requirements, acceptance criteria, and technical notes. Also read `backlog.md` in the same directory for dependency context — check that all blocking tickets (listed in `depends_on`) have `status: done` or `status: tested` before proceeding. If blockers remain, tell the CEO which tickets need to be completed first and suggest building one of those instead.
• If it's a **design directory** (e.g., `.solopreneur/designs/{date}-{slug}/`), read `design-brief.md` inside it and scan for `.html` mockup files — these contain the visual structure the engineer should implement.
• If it's a **spec file path**, read it for context.
• Otherwise, treat it as the feature description.

Step 1: Ask how to build

Before doing anything else, ask the CEO:

> **How would you like to build this?** > 1. **Plan only** — I'll create a plan file you can take to Cursor (or any other coding agent) > 2. **Build it now** — I'll write the code directly, right here

Wait for their answer before proceeding. If they say "plan", follow the **Plan Path**. If they say "build" (or "now", "do it", "just build it", etc.), follow the **Direct Path**.

Step 1.5: Branch Setup (ticket builds only)

If building from a ticket file, set up an isolated branch before building:

1. **Check for active ticket branches**: Run `git branch` to see if any `ticket/*` branches exist that are not yet merged. If another ticket branch is currently checked out, ask the CEO: > You're currently on branch `ticket/{OTHER-ID}`. To start this ticket, I need to switch branches. > 1. **Switch now** — I'll save your current work and switch to a new branch for this ticket > 2. **Finish the other ticket first** — Let's wrap up {OTHER-ID} before starting this one > 3. **Build in parallel** — Use `/solopreneur:sprint` to build multiple tickets simultaneously

If the CEO chooses to switch: commit or stash any uncommitted changes on the current branch, then proceed.

2. **Create the ticket branch**:

   git checkout -b ticket/{ID}

3. **Update the ticket file**: Set `status: in-progress` and `branch: ticket/{ID}` in the YAML frontmatter.

4. **Adapt explanation to user's technical level**: If `.solopreneur/preferences.yaml` exists, read it for the CEO's git comfort level. Explain accordingly:

• Technical: "Creating branch `ticket/MVP-001`"
• Basic: "I'm creating a separate branch for this ticket"
• Non-technical: "I'm saving your work in a separate space so it doesn't interfere with other work"

If preferences don't exist yet, ask the CEO: "Quick question — how comfortable are you with git? (I use it daily / I know the basics / What's git?)" and save their answer to `.solopreneur/preferences.yaml`.

---

Step 1.75: Deployment Strategy (first build only)

Check if `.solopreneur/preferences.yaml` has a `deployment` key. If yes, skip this step entirely.

If no deployment strategy exists yet, ask the CEO:

> **Where should this run when it's ready?** > The engineer will set up deployment based on your tech stack. Common options: > 1. **Vercel** — Best for Next.js, React, static sites (free tier available) > 2. **Netlify** — Similar to Vercel, good for static sites and serverless > 3. **GitHub Pages** — Free, simple, static sites only > 4. **I'll figure it out later** — Skip for now, we'll set it up when you're ready to ship > > Not sure? The engineer can recommend one based on what we're building.

If the CEO picks a platform or asks for a recommendation: 1. Delegate to `@engineer` to configure the project for that platform:

• Install the platform CLI if needed (e.g., `npm i -g vercel`)
• Create platform config files (e.g., `vercel.json`, `netlify.toml`)
• If an MCP server exists for the platform (e.g., Vercel), add it to `.mcp.json`
• Link the project to the platform (`vercel link`, etc.)

2. Save the deployment strategy to `.solopreneur/preferences.yaml`:

   deployment:
     platform: vercel  # or netlify, github-pages, fly, railway, custom, none
     configured: true
     notes: "Next.js app on Vercel, linked via CLI"
     rollback: "Run `vercel rollback` or go to vercel.com/[project]/deployments and promote the previous deployment"

If the CEO picks "I'll figure it out later", save:

deployment:
  platform: none
  configured: false

This step only runs once. Subsequent `/build` calls skip it because the preference exists.

---

Plan Path

1. Delegate to the `@engineer` subagent to create a plan file following the standard plan format (from conventions). The engineer should break the work into 3-8 sequential steps with instructions specific enough that another agent can execute without additional context. Build-specific additions to the plan:

• Include `**Branch**: \`ticket/{ID}\`` in the Context section (ticket builds only)
• Add a `## Deployment Notes` section if deployment was just configured (platform, config files created, setup status)

2. Save the plan:

• If building from a ticket: save co-located as `.solopreneur/backlog/{dir}/{ID}-plan.md`
• Otherwise: save to `.solopreneur/plans/build-{feature-slug}.md` (create the directory if needed)

3. Present a summary of the plan to the CEO:

• Number of steps
• Files that will be created/modified
• Any decisions that need CEO input
• Estimated complexity (Simple / Moderate / Complex)

4. End with the handoff prompt (adapt for ticket builds):

**For ticke