Update to Devpost Hackathons

{
  "name": "prepare-submission",
  "description": "Draft the participant's Devpost submission materials from the current project and saved state. Use when the user has a build worth describing and needs help preparing the title, write-up, testing notes, screenshots, and demo materials. Drafting only — nothing is sent to Devpost from this command.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 217
    },
    {
      "relative_path": "references/SETUP.md",
      "size_in_bytes": 1231
    },
    {
      "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/submission-template.md",
      "size_in_bytes": 824
    }
  ],
  "skill_md_contents": "---\nname: prepare-submission\ndescription: Draft the participant's Devpost submission materials from the current project and saved state. Use when the user has a build worth describing and needs help preparing the title, write-up, testing notes, screenshots, and demo materials. Drafting only — nothing is sent to Devpost from this command.\n---\n\n# Prepare Submission\n\n## Purpose\n\nCreate or update the local Devpost draft document, update state, compose the Prepare chat response, and give a compact \"go do these things\" checklist.\n\n**This command does not submit anything.** The actual submission to Devpost happens in `$submit-project`. Never imply otherwise: until `$submit-project` reports success, nothing has been sent.\n\nChat is the primary participant interface. Keep responses text-first so they render in any Codex host; the bundled `devpost` MCP server supplies rich inline visuals on hosts that support them.\n\n## Required Data Source\n\nOfficial submission requirements come from the `devpost` MCP server — follow **Devpost MCP Server** in `references/plugin-runtime.md` (call only what you need, never verify or set up the server, degrade in one line on failure).\n\nDraw on these only as needed: `devpost.get_submission_requirements`, `devpost.get_judging_criteria`, `devpost.get_key_dates`. Shape the draft toward the real submission fields and judging criteria; do not invent official form fields.\n\n## Required Reference\n\nRead `references/plugin-runtime.md`, `references/content/steps/prepare.md`, and `references/submission-template.md` before responding.\n\n## Preconditions\n\nRead `.devpost-hackathon-state.json`.\n\nIf the file does not exist, direct the user to `$start-hackathon`.\n\nIf `rules_acknowledged` is not `true`, direct the user to `$review-hackathon-rules` first.\n\nIf the workspace or conversation still does not reveal a real project, warn that the draft will contain placeholders rather than a truthful final submission.\n\n## Able-To-Submit Gate\n\nBefore the participant invests in drafting, verify they will actually be able to submit:\n\n1. Call `devpost.whoami` (AUTH-REQUIRED). If it fails on auth, hard-stop per **On auth\n   failure** in `references/plugin-runtime.md` — one-line notice, the sign-in recovery,\n   and stop. Drafting for a submission the participant cannot make is how people miss\n   deadlines.\n2. If authenticated, confirm they are registered for this hackathon: call\n   `devpost.list_hackathons` and look for the current hackathon with a `registered`\n   relationship. If they are not registered, say so plainly and direct them to\n   `$start-hackathon` before drafting continues — registration can close before the\n   submission deadline.\n3. If the registration lookup fails for non-auth reasons, degrade in one line and continue\n   drafting — availability problems should not block local work.\n\n## Output File\n\nCreate or update `devpost-submission.md` in the current project root.\n\nPreserve any user edits already in that file.\n\nUse `references/submission-template.md` as the outline.\n\n**If `docs/hackathon-build/` exists, read it before drafting.** The guided build tool's\ndocuments are raw material: `build-notes.md` (and a legacy `process-notes.md`, if present)\nrecords real decisions, deepening rounds, pushback moments, and per-item build notes —\nquote from it for \"how AI capabilities are used\", \"how Codex was used in the build\nprocess\", and the testing instructions, rather than inventing process claims. The scope,\nPRD, spec, and checklist ground the problem/solution story in what was actually planned\nand built.\n\nThe draft should include:\n\n- title\n- one-line summary\n- problem\n- solution\n- why this matters\n- how AI capabilities are used\n- how Codex was used in the build process\n- key features\n- architecture summary\n- testing instructions\n- screenshot shot list\n- demo video outline\n- draft readiness notes\n- placeholders for repo URL, public demo URL, and video URL\n- clearly labeled official form-specific fields where the real event later requires exact copy\n\n**Codex session ID (only when the official form asks for one).** If the live\n`get_submission_requirements` response includes a question asking for a Codex session ID,\nlook it up for the participant rather than making them hunt. Where the local Codex\nenvironment exposes session identifiers (for example under `~/.codex/sessions/`), extract\nthe identifier only — e.g. from the filename; never read or quote session *contents*,\nwhich are private conversation data. The sessions directory is machine-wide, not\nproject-scoped, so never record an ID silently: show the participant the candidate ID\n(with its timestamp) and have them confirm it's the session for this project — or have\nthem copy the ID from their Codex app's session/status view instead. Record the confirmed\nID under **TODO Official Form Fields** in the draft. This is an optional capability, not a\ngate — if the form doesn't ask for a session ID, skip all of this; if it asks and no ID\ncan be confirmed, list it as one line in the \"go do these things\" checklist and move on.\n\nMake the draft honest about what exists today versus what is still placeholder material.\n\n**Confirm every asset you receive.** When the participant provides a screenshot or file,\nsay explicitly what was received and what you did with it (saved at which path, referenced\nwhere in the draft, or nothing yet and why). Never handle an upload silently.\n\n## Getting The Project Public\n\nWhen the repo URL is still a placeholder, offer a short pointer list — the participant picks and drives their own tooling; do not fold a push flow into this command:\n\n- the GitHub CLI (`gh repo create`, then `git push`), if they have it\n- a GitHub MCP server or connector, if their host has one\n- plain `git push` to a repository created on github.com\n\nAdd one line: they can ask for help with whichever route they pick.\n\nAlongside the pointers, one caution: before pushing anywhere public, check the project for\ncommitted secrets — `.env` files, API keys, tokens. The full security scan runs at\n`$submit-project`, but a public push happens now and cannot be un-published; a ten-second\nlook (or asking the AI to grep for secrets) beats finding out later.\n\n## Review And Feedback\n\nAfter updating `devpost-submission.md`, give a compact \"go do these things\" checklist that tells the participant what to gather, fix, or verify before `$submit-project`. Cover:\n\n- missing draft components\n- weak or vague claims\n- unclear product positioning\n- missing proof points, demo assets, or testing details\n- anything that could make the Devpost submission less convincing\n\nUse checklist syntax. Start each action with a verb. Do not turn this into a long essay; keep the checklist short, specific, and actionable.\n\n## Presentation Output\n\nCompose the response in-context per `references/plugin-runtime.md` (\"Composing the Response\"): read `references/content/steps/prepare.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.\n\n## State Update\n\nAfter drafting:\n\n- add `prepare-submission` to `completed_stages` only when the packet is materially complete and remaining gaps are minor\n- set `submission.status` to `drafting`\n- set `submission.draft_file` to `devpost-submission.md`\n- set `current_stage` to `prepare-submission`\n- set `next_command` to:\n  - `submit-project` when the packet is materially complete and only minor follow-ups remain\n  - otherwise `prepare-submission`\n\n## Chat Output\n\nKeep chat output compact.\n\nDo not hand-write a separate dashboard. Let the CLI composer render the response.\n\n**Mandatory status block.** Every response from this command must include, verbatim, near the top, the ⏳ block from **Submission Status Blocks** in `references/plugin-runtime.md`. Do not reword, soften, or omit it. Verb discipline: outside that line, never use \"submitted\" or \"submission complete\" about the participant's work — this command produces a **draft**. \"Your draft is complete\" is fine; \"your submission is complete\" is banned.\n\nRespond with:\n\n- the status line\n- whether `devpost-submission.md` was created or updated\n- the short \"go do these things\" checklist\n- next recommendation: either another `$prepare-submission` pass or `$submit-project`\n\nIf composer generation fails, use a compact text fallback:\n\n- the status line\n- current stage: Prepare\n- draft file path\n- shortest useful \"go do these things\" checklist\n- next recommended command\n"
}