Update to Devpost Hackathons

{
  "name": "build-project",
  "description": "Execute the guided build checklist with Codex while preserving verification pauses.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 187
    },
    {
      "relative_path": "references/SETUP.md",
      "size_in_bytes": 1231
    },
    {
      "relative_path": "references/build-guide.md",
      "size_in_bytes": 7347
    },
    {
      "relative_path": "references/config/hackathon.json",
      "size_in_bytes": 1897
    },
    {
      "relative_path": "references/content/learning/build.md",
      "size_in_bytes": 939
    },
    {
      "relative_path": "references/content/learning/checklist.md",
      "size_in_bytes": 618
    },
    {
      "relative_path": "references/content/learning/onboard.md",
      "size_in_bytes": 1333
    },
    {
      "relative_path": "references/content/learning/prd.md",
      "size_in_bytes": 972
    },
    {
      "relative_path": "references/content/learning/scope.md",
      "size_in_bytes": 403
    },
    {
      "relative_path": "references/content/learning/spec.md",
      "size_in_bytes": 356
    },
    {
      "relative_path": "references/content/steps/check.md",
      "size_in_bytes": 1150
    },
    {
      "relative_path": "references/content/steps/help.md",
      "size_in_bytes": 2595
    },
    {
      "relative_path": "references/content/steps/map.md",
      "size_in_bytes": 948
    },
    {
      "relative_path": "references/content/steps/prepare.md",
      "size_in_bytes": 1599
    },
    {
      "relative_path": "references/content/steps/resources.md",
      "size_in_bytes": 1601
    },
    {
      "relative_path": "references/content/steps/rules.md",
      "size_in_bytes": 840
    },
    {
      "relative_path": "references/content/steps/start.md",
      "size_in_bytes": 1868
    },
    {
      "relative_path": "references/plugin-runtime.md",
      "size_in_bytes": 11707
    },
    {
      "relative_path": "references/templates/checklist-template.md",
      "size_in_bytes": 890
    },
    {
      "relative_path": "references/templates/learner-profile-template.md",
      "size_in_bytes": 394
    },
    {
      "relative_path": "references/templates/prd-template.md",
      "size_in_bytes": 298
    },
    {
      "relative_path": "references/templates/scope-template.md",
      "size_in_bytes": 245
    },
    {
      "relative_path": "references/templates/spec-template.md",
      "size_in_bytes": 294
    }
  ],
  "skill_md_contents": "---\nname: build-project\ndescription: Execute the guided build checklist with Codex while preserving verification pauses.\n---\n\n# Guided Build: Build\n\nRead `references/build-guide.md`, then follow this command.\n\nThis is the Codex version of the learning curriculum's build command.\n\n## Goal\n\nBuild from `docs/hackathon-build/checklist.md` according to the selected build mode.\n\nThe intelligence is in the checklist and spec. Do not improvise new items or skip verification preferences.\n\n**Never build unprompted.** Generate code only when executing the current checklist item the participant has confirmed. If they ask to \"move to the next stage,\" test, or submit, that is navigation — route them to the right command without scaffolding anything. When in doubt about whether they want you to build, ask.\n\n## Preconditions\n\nRead `.devpost-hackathon-state.json`.\n\nIf the state file does not exist, direct the user to `$start-hackathon`.\n\nRead everything in `docs/hackathon-build/`. If `checklist.md` is missing, direct the user to `$build-checklist`.\n\nIf every checklist item is complete, go straight to **Completion**.\n\n## Step-By-Step Mode\n\nEach `$build-project` run handles exactly one unchecked checklist item.\n\nFor the first unchecked item:\n\n1. Announce what you are building and why it is next.\n2. Build only that item.\n3. Verify according to the item's `Verify` field if verification is enabled — the participant runs the check with their own eyes (\"run your dev server and tell me what you see when you click X\"). The item isn't done until verification passes.\n4. If comprehension checks are enabled, ask one precise question about what was built — single unambiguous answer (\"which file handles incoming search requests in the code we just wrote?\"), never an essay prompt. On a wrong answer, give a 2-3 sentence explanation pointing at the specific code — fill the gap, don't lecture.\n5. Mark the item complete in `docs/hackathon-build/checklist.md`.\n6. Append build notes to `docs/hackathon-build/build-notes.md`.\n7. End by telling the participant to say \"next item\" when ready — or type `$build-project` again (works in a fresh chat too). If that was the last item, go to **Completion** instead.\n\n## Autonomous Mode\n\nIf the checklist selects autonomous mode, work through the checklist in order.\n\nPause for verification every 3-4 items if verification is enabled, or sooner if risk rises. Each checkpoint: a short summary of what was built, one concrete thing for the participant to try (\"run the dev server and search for something — you should see results appear\"), and \"everything look good?\" before continuing.\n\nIf you use subagents, give each one the relevant checklist item, the full spec, the relevant PRD section, and the instruction that others may be working in the codebase.\n\n## When Something Breaks\n\nStop immediately — don't try to be a hero. Explain what happened, what you tried, and why\nit is not a quick fix. Propose reverting to the last clean state if one exists.\n\nThen think holistically about the checklist, not just the broken item: propose concrete\nedits (\"I think item 5 splits into two smaller steps, and item 7 depends on an approach\nthat won't work anymore\"), get the participant's agreement, update\n`docs/hackathon-build/checklist.md`, and resume. The checklist is a living document —\nplans meet reality and adapt, and that's worth saying out loud: \"this is what happens in\nreal development.\"\n\n## Completion\n\nWhen the last checklist item completes — or a run finds every item already done:\n\n1. **Render the stepper on this turn** (`active_step: resources`, `build_assistant: true`,\n   `build_step: build`). Completion is worth showing even though the top-level stage has\n   not changed — do not let the final turn be the one with no progress visual.\n2. **Close the bookend opened at `$build-onboard`**, under the exact heading\n   `### You have a proof of concept — not a finished project` (heading level `###`,\n   nothing larger — as in `content/learning/build.md`; the header exists so this line\n   cannot be skimmed past), in language close to: this is your\n   proof of concept — now it's time for you to really work on it. You're in a freeform\n   environment now: if you want to start a new chat and prompt this app some more to make\n   new changes, you're only just getting started. This is the beginning. Make it your own,\n   and if this planning sequence was useful, run it yourself on your next round of changes\n   until you have the best version of your project you can imagine.\n3. **Do not rush them to submit.** Recommend `$prepare-submission` only as the step for\n   when the project feels ready — not as the immediate next action. On this turn, replace\n   the standard callout with the when-ready phrasing (as in `content/learning/build.md`):\n   ``When your project feels ready — not before — say so, or type `$prepare-submission`.``\n   This is a sanctioned exception to the standard final-line format, like the resources\n   two-path callout.\n\n## Thumbnails And Screenshots\n\nBuild and verification steps sometimes produce a screenshot or image worth using as the Devpost project thumbnail. The `devpost` MCP server offers two upload services for that (both AUTH-REQUIRED) — pick by encoded size: `devpost.upload_project_thumbnail` sends a small image inline as base64 (target ≤ 50 KB encoded), while `devpost.prepare_thumbnail_upload` returns an upload URL plus a curl/PowerShell command that streams a larger file straight from disk without putting the bytes through the conversation. Both accept JPEG/PNG/GIF up to 5 MB.\n\nUploading is `$prepare-submission` / `$submit-project` work — do not upload during the build unless the participant explicitly asks. If they do ask, pick the service by size and confirm what was uploaded and where it went.\n\n## State Update\n\nSet:\n\n- `learning.current_step` to `build`\n- add `checklist` to `learning.completed_steps` if missing\n- `next_command` to `build-project` until the checklist is complete\n- when complete, add `build` to `learning.completed_steps`, set `learning.status` to `completed`, keep `current_stage` at `resources` (the build lives inside Step 3 — prepare hasn't run yet), and set `next_command` to `prepare-submission`\n\n## Presentation Output\n\nCompose the response in-context per `references/plugin-runtime.md` (\"Composing the Response\"): read `references/content/learning/build.md`, strip maintainer `<!-- -->` comments, interpolate the event name, then present a short stage headline, the page content, and the next-step callout. Do not run any script. End with what changed, how it was verified, and the next step.\n\n## Required References\n\n- `references/plugin-runtime.md`\n- `references/build-guide.md`\n- `references/content/learning/build.md`\n"
}