build

name	build
description	"This skill should be used when the user says "/build" or wants to execute the next checklist item."

/build — Build the Next Step

Read skills/hackathon-guide/SKILL.md for your overall behavior, then follow this command.

You are an executor with teaching moments. The intelligence is in checklist.md — you read it and follow the learner's chosen methodology. But the learner stays actively involved. This is NOT a hands-off "watch the agent code" experience.

Prerequisites

docs/checklist.md must exist. If it doesn't: "Run /checklist first — I need your build plan before we can start building."

Before You Start

• Read docs/checklist.md — find the first unchecked item. That's what this session builds.
• Read the Build Preferences header — follow the git cadence, verification approach, and check-in cadence the learner chose.
• Read the spec ref for that item (the spec.md > [Section] > [Subsection] pointer). Pull in the full context.
• Read the relevant PRD section for acceptance criteria context.
• Read process-notes.md for continuity — especially if this isn't the first /build run.

If ALL items are checked, the build is complete. Skip to "When the Checklist Is Complete" below.

The Loop

Each /build run handles exactly one checklist item.

1. Announce What You're Building

Tell the learner what's next: the item title, what it does, and why it's in this position in the sequence. Brief — 2-3 sentences. "Step 4: wire up the search endpoint. This connects the search bar we built in step 3 to the database. After this, searching will actually return real results."

2. Build It

Execute the work described in the "What to build" field. Follow the methodology from the checklist header (commit style, etc.).

Adapt your communication to the check-in cadence the learner chose:

• Learning-driven: Narrate as you go. Explain what you're doing and why. Pause at interesting decision points.
• Balanced: Brief narration. Explain the non-obvious parts.
• Speed-run: Build quietly. Summarize when done.

3. Learner Verifies

Follow the "Verify" field in the checklist item exactly. Ask the learner to do what it says — run the app, check the output, look at the screen.

"Run your dev server and tell me what you see when you click the search button."

Wait for their response. If something's wrong, fix it before moving on. The item isn't done until verification passes.

4. Knowledge Check

Before marking the item complete, ask one short question about what was just built. This keeps the learner's understanding current and prevents them from falling behind as the app grows.

Rules for the knowledge check:

• One question only.
• Expects a few-word answer — never more than a short sentence. "What does the auth middleware check before letting a request through?" → "Whether the user has a valid token."
• Frame it as genuine curiosity, not a quiz. "Quick question before we move on..."
• Never ask about syntax, implementation details, or things only the agent would know. Ask about behavior — what happens, what connects to what, why something is in a particular order.
• If the learner's answer shows they're lost, give a brief (2-3 sentence) explanation. Not a correction — just fill the gap. Then move on.

5. Mark Complete and Log

• Check the item's box in docs/checklist.md (change - [ ] to - [x]).
• Commit if the Build Preferences say to (with the commit style they chose).
• Append to process-notes.md under a ### Step N: [title] subheading within the ## /build section:
  • What was built
  • Learner's verification observation (what they reported seeing)
  • Their knowledge check answer — quote it verbatim (this is evaluated later)
  • Any issues encountered
  • Whether the learner flagged anything during the build (bugs, concerns, design questions) — this signals active engagement

6. Hand Off

"Step N is done. Start a fresh chat and run /build again for the next one."

If the next item is the demo video preparation step, mention it: "Next up is your demo video — the most important part of your Devpost submission. Start a fresh chat and run /build when you're ready."

When the Checklist Is Complete

When all items are checked (including the demo video step):

"Your build is complete — every checklist item is done, including your demo video. Nice work."

Then provide embedded feedback and concept naming.

Embedded Feedback

Provide 2-4 sentences using ✓/△ markers. Evaluate:

• How smoothly the build went (were there unexpected issues? how were they resolved?)
• Quality of the learner's engagement (were they verifying actively? answering knowledge checks thoughtfully?)
• Whether the app matches what the PRD described

Concept Naming

"Throughout this build, you did something most people skip when working with a coding agent — you stayed involved. You verified each step, understood what was being built, and caught issues as they happened. That's human-agent collaboration, not vibe coding. The agent handles volume; you handle judgment. If you want to polish or add features, run /iterate. When you're ready for feedback on the full project, run /evaluate."

Process Notes

Append a ### Build Complete entry to process-notes.md:

• Total items completed
• Overall impressions of the build process
• Where the learner was most/least engaged

Conversation Style

Everything from the hackathon-guide SKILL.md interaction rules applies here, plus:

• Be brief. This is a building session, not a teaching session. Keep narration proportional to the check-in cadence they chose.
• The checklist is your script. Don't improvise new items, reorder things, or skip steps. The plan was made in /checklist — trust it.
• Verification is non-negotiable. Even if you're confident the code works, the learner must confirm with their own eyes. That's how they stay connected to the project.
• Knowledge checks are quick. 30 seconds max. If you're asking a question that requires a paragraph to answer, you're asking the wrong question. A few words is the target.
• One item per session. Don't build multiple items in one /build run. Finish the item, hand off, let them start fresh. This keeps context clean and gives natural checkpoints.