← Devpost HackathonsCONTENT HISTORYWHAT CHANGED · RULE-BASED ANALYSIS
Update to Devpost Hackathons
Snapshot Sep 30, 2026 · 22:48 UTC · version 4.0.1
Collection source: not recorded for this historical snapshot.
First saved snapshot
No earlier snapshot is available to establish a change.
Compare saved observations
Download comparison JSONFull technical diff · 0 changed fields
Full snapshot data
{
"name": "build-prd",
"description": "Convert the scoped hackathon idea into user-facing product requirements.",
"included_files": [
{
"relative_path": "agents/openai.yaml",
"size_in_bytes": 195
},
{
"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-prd\ndescription: Convert the scoped hackathon idea into user-facing product requirements.\n---\n\n# Guided Build: PRD\n\nRead `references/build-guide.md`, then follow this command.\n\nThis is the Codex version of the learning curriculum's PRD command.\n\n## Goal\n\nTurn `scope.md` into a product requirements document. This step is about user behavior and acceptance criteria, not code structure.\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 `scope.md` does not exist, direct the user to `$build-scope`.\n\n## Flow\n\nInterview in small batches of related questions (per the build guide). You are a sharp interviewer here — no code talk, no technical\ndecisions; pure \"what does this thing need to do?\" If implementation questions come up,\ndefer warmly: \"Great question — we'll get into that in `$build-spec`. For now, what does\nthe user experience?\"\n\nMandatory beats:\n\n1. Walk the scope section by section, converting brainstorm language into precise\n behavior: \"You said the app helps people find X. What does a user see when they first\n open it?\" Zoom in relentlessly (Sharpening Questions in the build guide).\n2. Organize behaviors into user stories and epics with stable headings — introduced\n without jargon: \"Let me capture what you're describing — 'As a [person], I want [thing]\n so that [reason].' Does that match?\"\n3. Testable acceptance criteria per story: \"How would you know this is working? What would\n you see on screen?\" Not vague (\"search works well\"), not implementation (\"query under\n 100ms\"), not untestable (\"the UX is intuitive\").\n4. Edge cases: empty states, first-run experience, error cases, \"what if they do X before\n Y?\" Aim for 2-3 genuine \"oh, I hadn't thought of that\" moments.\n5. Guard scope against the time budget recorded in scope.md. When something grows: \"This\n is getting bigger than the time you have. Essential for your submission, or would you\n add it later?\" That one question sorts everything into What We're Building versus What\n We'd Add With More Time. Keep Non-Goals specific and reasoned — \"NOT building user\n profiles, because the app works fine anonymous\" beats \"no extra features.\"\n\nOccasionally make the expansion visible: \"See how much more specific we're getting? The\nscope said 'users can search' — now we know exactly what that means.\"\n\nAfter mandatory beats, offer a deepening round per the build guide. Good PRD deepening\ntopics: feature interactions (\"if a user changes X while looking at Y, what should\nhappen?\"), persistence (\"close the app and come back — is their stuff still there?\"),\nboundary cases (\"what if someone adds 100 of these?\"), the Devpost \"wow moment\" (\"which\nfeature makes someone stop scrolling on the submission page?\"), user-order assumptions\n(\"you're assuming they do X first — what if they don't?\"), and what would make it feel\nreally good, not just functional.\n\n## Output\n\nUse `references/templates/prd-template.md`.\n\nCreate or update:\n\n- `docs/hackathon-build/prd.md`\n- `docs/hackathon-build/build-notes.md`\n\nThe PRD should feel significantly more substantial than the scope doc. If it's roughly the same length, you haven't expanded enough.\n\n## State Update\n\nSet:\n\n- `learning.current_step` to `prd`\n- add `scope` to `learning.completed_steps` if missing\n- `next_command` to `build-spec`\n\n## Presentation Output\n\nCompose the response in-context per `references/plugin-runtime.md` (\"Composing the Response\"): read `references/content/learning/prd.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 by recommending `$build-spec`.\n\n## Required References\n\n- `references/plugin-runtime.md`\n- `references/build-guide.md`\n- `references/content/learning/prd.md`\n"
}SHA-256: 46321b27a88acb068c203cbef0e3c2714b3ff32dd6f83173075434789ac101c7