build

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 ticket builds:

   -> Next: Take this plan to your coding agent (Cursor, Windsurf, etc.) for execution:
      Make sure you're on branch `ticket/{ID}`, then open:
      .solopreneur/backlog/{date}-{slug}/{ID}-plan.md
      Tell it: "Execute this plan step by step"
   
      When the code is written, come back for review and merge:
      /solopreneur:review .solopreneur/backlog/{date}-{slug}/{ID}.md
   

   For non-ticket builds:

   -> Next: Take this plan to your coding agent (Cursor, Windsurf, etc.) for execution:
      Open .solopreneur/plans/{filename} and tell it:
      "Execute this plan step by step"
   
      When done, come back and run:
      /solopreneur:review
   

---

Direct Path

1. Delegate to the @engineer subagent to plan and execute the implementation directly. The engineer should:

   • First, create a plan following the standard plan format (from conventions), with the same build-specific additions as the Plan Path
   • Save the plan: if building from a ticket, co-locate as .solopreneur/backlog/{dir}/{ID}-plan.md; otherwise save to .solopreneur/plans/build-{feature-slug}.md
   • Then execute each step: create/modify files, install dependencies, write the actual code
   • After each step, briefly report progress to the CEO

2. Once the engineer finishes, present a summary:

   • What was built (files created/modified)
   • Any decisions that were made along the way
   • Anything that needs CEO input or attention

3. If building from a ticket: Update the ticket YAML — set status: built, populate the ## Files section with files created/modified. Then suggest review:

   -> Ticket {ID} is built on branch `ticket/{ID}`. Let's review it:
      /solopreneur:review .solopreneur/backlog/{dir}/{ID}.md
   

4. If not a ticket build: End with the review prompt:

   -> Next: Let's review what was built:
      /solopreneur:review