[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6FJRRZMJKSD2523X2SWRP83":3,"skill-same:01M6FJRRZMJKSD2523X2SWRP83":60},{"skillNo":4,"name":5,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":7,"ownerLogin":8,"ownerAvatarUrl":9,"ownerAccountNo":10,"ownerDisplayName":11,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":25,"publishedAt":33,"linkOnly":34,"markdownContent":35,"markdownBody":35,"frontMatter":36,"refName":37,"commitSha":38,"skillDirectory":39,"forksCount":40,"repositoryHtmlUrl":41,"repositoryHomepageUrl":42,"ownerHtmlUrl":43,"ownerBlogUrl":6,"ownerDescription":44,"updatedAt":45,"install":46,"resources":59},"01M6FJRRZMJKSD2523X2SWRP83","parallel-web-game-build",null,"ComeOnOliver\u002Fskillshub","ComeOnOliver","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F43215937?v=4","01M6E5JNFECJAAVFE0W7SMWWD2","Haoran Shu","01M6E5JNNDQS7AJZDYFQ8TPZCK",66,"MIT","https:\u002F\u002Fgithub.com\u002FComeOnOliver\u002Fskillshub\u002Fblob\u002Fmain\u002Fskills\u002Fvosslab\u002Fvosslab-skills\u002Fparallel-web-game-build\u002FSKILL.md",[17,22],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",{"categoryNo":23,"categoryName":24,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000023","Skill与智能体开发",[26,27,28,29,30,31,32],"web","game","parallel","build","parallel web","web game","parallel web game build","2026-11-10 10:12:30",false,"# Parallel Web Game Build\n\n## Overview\n\nBuild a single-file web game (or interactive web app) from modular source files using parallel agents with batched integration checkpoints. The output is one self-contained HTML file assembled from `parts\u002F` via a build script.\n\n**Core principle:** Contracts before code, batches before integration, browser testing before declaring done.\n\n**Orchestrator role:** The lead agent does NOT write game code (except Batch 1 foundation). It gathers requirements, writes contracts, dispatches coding agents in batches, runs smoke tests, and fixes integration issues.\n\n**Relationship to manager planning:** This skill is a domain-specific implementation profile of `manager-make-new-plan` for single-file web games. It keeps the same milestone\u002Fworkstream\u002Fwork-package\u002Fpatch model, but preassigns standard workstreams so execution can start faster with less planning overhead.\n\n## Terminology Contract\n\nCanonical definitions live in `references\u002FDEFINITIONS.md`.\nNaming constraints and legacy handling live in `references\u002FNAMING_GUARDRAILS.md`.\nCapacity and sizing targets live in `references\u002FCAPACITY_AND_SIZING.md`.\n\n## Terminology Collision\n\n- Use Milestone \u002F Workstream \u002F Work package only in planning docs, not in durable code identifiers.\n- Use Stage \u002F Pass \u002F Step for durable gameplay pipeline or algorithm steps in code identifiers.\n- If a repository already has `phaseN_*` artifacts, treat that as legacy naming and do not introduce new planning-phase names into code.\n\n## Preassigned Workstreams\n\nUse these default workstreams unless project requirements force a different split:\n\n- Workstream A: Foundation and state\n  - Files: `constants.js`, `characters.js`, `game_state.js`\n  - Goal: stable contracts and stage\u002Fstate backbone\n- Workstream B: UI shell and styling\n  - Files: `head.html`, `body.html`, `tail.html`, `style.css`, `ui_rendering.js`\n  - Goal: interaction shell, layout, and shared UI controls\n- Workstream C: Core gameplay stage\n  - Files: `scene_stage.js`, `data_generation.js`\n  - Goal: core playable loop with contract-conformant data\n- Workstream D: Advanced gameplay and outcomes\n  - Files: `lab_stage.js`, `gel_rendering.js`, `case_board.js`, `scoring.js`, `educational.js`\n  - Goal: analysis\u002Freview stages, scoring, and endgame flow\n- Workstream E: Runtime utilities\n  - Files: `timer.js`, `save_load.js`, `init.js`\n  - Goal: lifecycle bootstrap, persistence, and timers\n\nWhen available agents are fewer than workstreams, merge adjacent workstreams and keep ownership explicit.\nWhen available agents exceed workstreams, split the largest workstream into work packages, not ad-hoc files.\n\n## When to Use\n\n- Building a single HTML file from modular source files\n- Multiple agents will write JavaScript\u002FCSS\u002FHTML concurrently\n- The app has interacting modules (data generation, display, user interaction)\n- Canvas rendering is involved (gel visualizations, charts, game graphics)\n\n## When NOT to Use\n\n- Simple single-file edits\n- Server-side applications\n- Multi-page web apps with build tooling (webpack, vite)\n- Tasks where one agent can finish in under 10 minutes\n\n## The Process\n\n```dot\ndigraph process {\n    rankdir=TB;\n\n    \"1. Gather UI preferences\" [shape=box];\n    \"2. Define minimum viable scope\" [shape=box];\n    \"3. Write data contracts\" [shape=box];\n    \"4. Write build script\" [shape=box];\n    \"5. Batch 1: Foundation (sequential)\" [shape=box];\n    \"Build + smoke test\" [shape=diamond];\n    \"6. Batch 2: Infrastructure (parallel)\" [shape=box];\n    \"Build + smoke test 2\" [shape=diamond];\n    \"7. Batch 3: Core features (parallel)\" [shape=box];\n    \"Build + smoke test 3\" [shape=diamond];\n    \"8. Batch 4: Advanced features (parallel)\" [shape=box];\n    \"Build + full playthrough\" [shape=diamond];\n    \"Fix?\" [shape=diamond];\n    \"Fix integration bugs\" [shape=box];\n    \"Done\" [shape=doublecircle];\n\n    \"1. Gather UI preferences\" -> \"2. Define minimum viable scope\";\n    \"2. Define minimum viable scope\" -> \"3. Write data contracts\";\n    \"3. Write data contracts\" -> \"4. Write build script\";\n    \"4. Write build script\" -> \"5. Batch 1: Foundation (sequential)\";\n    \"5. Batch 1: Foundation (sequential)\" -> \"Build + smoke test\";\n    \"Build + smoke test\" -> \"6. Batch 2: Infrastructure (parallel)\" [label=\"pass\"];\n    \"6. Batch 2: Infrastructure (parallel)\" -> \"Build + smoke test 2\";\n    \"Build + smoke test 2\" -> \"7. Batch 3: Core features (parallel)\" [label=\"pass\"];\n    \"7. Batch 3: Core features (parallel)\" -> \"Build + smoke test 3\";\n    \"Build + smoke test 3\" -> \"8. Batch 4: Advanced features (parallel)\" [label=\"pass\"];\n    \"8. Batch 4: Advanced features (parallel)\" -> \"Build + full playthrough\";\n    \"Build + full playthrough\" -> \"Fix?\";\n    \"Fix?\" -> \"Fix integration bugs\" [label=\"errors\"];\n    \"Fix integration bugs\" -> \"Build + full playthrough\";\n    \"Fix?\" -> \"Done\" [label=\"clean\"];\n}\n```\n\n## Step 1: Gather UI Preferences (2 min)\n\n**Before writing any code**, ask the user about interaction style:\n\n- Buttons vs dropdowns vs drag-and-drop?\n- Dark theme vs light?\n- Mobile support needed?\n- Any visual references or screenshots?\n\n**You must actually ask.** Do not default to buttons (or any style) without confirmation. The agent prompt template includes a default, but that default exists as a fallback - it does not replace asking.\n\n**Why:** A 2-minute conversation saves a 30-minute rewrite. The DNA forensics build required a near-complete rewrite of the lab stage because agents built dropdowns and the user wanted buttons.\n\n## Step 2: Define Minimum Viable Scope\n\nStart small. Get the core loop working end-to-end before expanding.\n\n**Template:**\n- 1-2 core mechanics (not 5)\n- 1-2 content types (not 5)\n- Fixed difficulty (not 3 levels)\n- No save\u002Fload in first pass\n\n**Why:** The DNA forensics build started with 5 forensic test types and had to cut to 2 after integration failure. Starting with 2 and expanding later would have been faster overall.\n\n**Rule:** If a feature can be added after the core loop works, defer it.\n\n## Step 2b: Decompose into Modules\n\nBreak the game into files in `parts\u002F`. Use this proven 18-file template as a starting point, then adapt per project:\n\n```\nparts\u002F\n  head.html            DOCTYPE, meta, title\n  style.css            All CSS\n  body.html            DOM structure (screens, panels, modals)\n  tail.html            Closing tags\n  constants.js         Game config, data definitions, room\u002Flevel data\n  characters.js        Entity definitions with game-relevant attributes\n  data_generation.js   Randomized content, puzzle\u002Ftest result generators\n  game_state.js        State machine, stage transitions, round management\n  scene_stage.js       Stage 1 gameplay UI (e.g. exploration, collection)\n  lab_stage.js         Stage 2 gameplay UI (e.g. analysis, testing)\n  gel_rendering.js     Canvas rendering (if needed)\n  case_board.js        Stage 3 gameplay UI (e.g. review, decision, endgame)\n  scoring.js           Scoring engine\n  educational.js       Help content, tooltips, explanations\n  ui_rendering.js      Setup screen, modals, notifications, shared UI\n  timer.js             Countdown\u002Ftimer mechanics\n  save_load.js         localStorage persistence\n  init.js              Bootstrap, keyboard shortcuts, DOMContentLoaded\n```\n\n**How to adapt per project:**\n\nNot every game needs all 18 files. Map the template to your game:\n\n- **Always keep:** `head.html`, `body.html`, `tail.html`, `style.css`, `constants.js`, `game_state.js`, `init.js`\n- **Rename stage files** to match your game loop (e.g. `scene_stage.js` becomes `question_stage.js`, `puzzle_stage.js`, etc.)\n- **Keep if applicable:** `characters.js` (entities), `data_generation.js` (randomized content), canvas rendering (rename to match), `scoring.js`, `educational.js`\n- **Defer to post-MVP:** `save_load.js`, `timer.js`, `educational.js` (keep scope minimal if included)\n\n**Estimate module complexity before proceeding:**\n\n| Signal | Action |\n| --- | --- |\n| 4+ content types in one module | Split into separate files or reduce scope |\n| Multiple distinct UI screens | Split by screen |\n| Both data generation AND display | Split generator from renderer |\n| Over ~400 lines expected | Find a split point |\n\nA batch finishes as fast as its slowest agent. Complex modules bottleneck the entire batch.\n\n## Step 3: Write Data Contracts (5-10 min, SEQUENTIAL)\n\n**This is the most important step.** Write contracts BEFORE dispatching any coding agents.\n\nThe contracts document can be a Markdown file (e.g. `parts\u002FCONTRACTS.md`), a comment-only JS file, or inline in the plan document. The format does not matter. What matters is that every cross-module interface is specified with exact property names and types.\n\nWrite the contracts document specifying:\n\n1. **Function return shapes** - exact property names and types for every generator function\n2. **Function signatures** - parameters and expected types for every cross-module call\n3. **DOM element IDs** - every ID that one module creates and another reads\n4. **Global state shape** - the game state object structure\n5. **Event flow** - which functions call which, in what order\n\n**Example contract (blood typing):**\n```javascript\n\u002F\u002F generateBloodTypeResult(sample, sourceCharacter) returns:\n\u002F\u002F {\n\u002F\u002F   bloodType: string,     \u002F\u002F \"A\", \"B\", \"AB\", or \"O\" (no Rh suffix)\n\u002F\u002F   rhFactor: string,      \u002F\u002F \"+\" or \"-\"\n\u002F\u002F   agglutination: {       \u002F\u002F visual display data\n\u002F\u002F     antiA: boolean,\n\u002F\u002F     antiB: boolean,\n\u002F\u002F     antiD: boolean\n\u002F\u002F   }\n\u002F\u002F }\n\u002F\u002F\n\u002F\u002F displayBloodTypeResult() reads: result.bloodType, result.rhFactor,\n\u002F\u002F   result.agglutination.antiA, result.agglutination.antiB, result.agglutination.antiD\n```\n\n**Example contract (RFLP):**\n```javascript\n\u002F\u002F generateRFLPResult(sample, sourceCharacter, enzyme?) returns:\n\u002F\u002F {\n\u002F\u002F   enzyme: string,           \u002F\u002F single enzyme name, e.g. \"EcoRI\"\n\u002F\u002F   fragments: number[],      \u002F\u002F fragment sizes in bp, e.g. [1200, 3400, 5600]\n\u002F\u002F   degraded: boolean\n\u002F\u002F }\n\u002F\u002F\n\u002F\u002F displayRFLPResult() reads: result.enzyme, result.fragments\n\u002F\u002F renderGel() expects lanes: [{label: string, fragments: number[]}]\n```\n\n**Why:** In the DNA forensics build, every single test type had a data structure mismatch between generator and display. `generateTestResult()` nested under `result.data`, displays read flat properties. `generateRFLPResult()` returned all enzymes, display expected one. This consumed 60+ minutes of debugging. A 10-minute contracts doc would have prevented all of it.\n\n## Step 4: Write Build Script (sequential, 2 min)\n\nCreate the build script that concatenates `parts\u002F` into the final HTML file. This runs in the orchestrator context before dispatching agents.\n\n```bash\n#!\u002Fbin\u002Fbash\n# build_game.sh - concatenate parts into single HTML file\ncat parts\u002Fhead.html > output.html\necho \"\u003Cstyle>\" >> output.html\ncat parts\u002Fstyle.css >> output.html\necho \"\u003C\u002Fstyle>\" >> output.html\necho \"\u003Cbody>\" >> output.html\ncat parts\u002Fbody.html >> output.html\necho \"\u003Cscript>\" >> output.html\ncat parts\u002Fconstants.js parts\u002Fcharacters.js parts\u002Fdata_generation.js \\\n    parts\u002Fgame_state.js parts\u002Ftimer.js parts\u002Fscene_stage.js \\\n    parts\u002Flab_stage.js parts\u002Fgel_rendering.js parts\u002Fcase_board.js \\\n    parts\u002Fscoring.js parts\u002Feducational.js parts\u002Fui_rendering.js \\\n    parts\u002Fsave_load.js parts\u002Finit.js >> output.html\necho \"\u003C\u002Fscript>\" >> output.html\ncat parts\u002Ftail.html >> output.html\n```\n\n## Step 5: Batched Agent Dispatch\n\nBefore dispatching, map each batch assignment to one of the preassigned workstreams above and keep owner continuity across batches where possible.\n\n### Batch 1: Foundation (sequential, ~2 min)\n\nWrite in the orchestrator or a single agent:\n- `constants.js` - game config, test definitions, room data\n- `characters.js` - character pool with biological profiles\n- `game_state.js` - state machine, stage transitions\n\n**These define the data model everything else depends on.** They MUST reference the contracts.\n\n**Smoke test:** Build and open in browser. Verify no JS errors.\n\n### Batch 2: Infrastructure (parallel, ~4 min)\n\nDispatch agents in parallel, each owning specific files:\n\n| Agent | Files | Notes |\n| --- | --- | --- |\n| Styling | `style.css`, `head.html`, `body.html`, `tail.html` | All HTML structure + CSS |\n| Timer + utilities | `timer.js`, `save_load.js` | No cross-module UI |\n| UI rendering | `ui_rendering.js` | Setup screen, modals, notifications |\n\n**Each agent prompt MUST include:**\n- The full contracts document\n- The constants.js and game_state.js content (or key excerpts)\n- Their owned files (no other files)\n- Explicit constraint: \"Do NOT modify files outside your assignment\"\n\n**Smoke test:** Build, open in browser, verify skeleton loads, state machine transitions work, timer displays.\n\n### Batch 3: Core game stages (parallel, ~5 min)\n\n| Agent | Files | Notes |\n| --- | --- | --- |\n| Scene stage | `scene_stage.js` | Evidence collection UI |\n| Data generation | `data_generation.js` | Test result generators per contracts |\n\n**Smoke test:** Build, verify evidence collection works end-to-end via Playwright.\n\n### Batch 4: Advanced features (parallel, ~5 min)\n\n| Agent | Files | Notes |\n| --- | --- | --- |\n| Lab + gel | `lab_stage.js`, `gel_rendering.js` | Test running, canvas visualization |\n| Case board + scoring + educational | `case_board.js`, `scoring.js`, `educational.js` | Endgame flow |\n\n**Smoke test:** Build, full playthrough via Playwright from title to game over.\n\n### Total wall-clock: ~20 min with 4 integration checkpoints\n\nCompare: all-at-once parallel (8 min authoring + 60 min debugging = 68 min).\n\n## Step 6: Integration Fix Loop\n\nAfter the final smoke test, if Playwright finds errors:\n\n1. Check `browser_console_messages` for JS errors\n2. Take a browser snapshot to see DOM state\n3. Identify which module(s) are broken\n4. Dispatch a fix agent with the specific error message and the relevant module code\n5. Rebuild and re-test\n\nRepeat until clean. The fix scope should be small (1-2 modules) if contracts were followed.\n\n## Agent Prompt Template\n\nEvery coding agent gets this structure:\n\n```\n## Your Assignment\nFiles you own: [list]\nDO NOT create or modify any other files.\n\n## Data Contracts\n[paste full contracts document]\n\n## Foundation Code\n[paste constants.js, characters.js, game_state.js - or key excerpts]\n\n## Web Platform Rules\n- After setting innerHTML on a container with a \u003Ccanvas>, wrap any\n  canvas drawing calls in requestAnimationFrame:\n    display.innerHTML = html;\n    requestAnimationFrame(function() {\n        renderCanvas('canvas-id', data);\n    });\n- Use button-based UI for user choices (not dropdowns or textareas)\n  unless the user specified otherwise\n- All code runs in a single \u003Cscript> block - no modules, no imports\n- No external dependencies - everything inline\n\n## Your Task\n[specific instructions for this agent's module]\n```\n\n## Smoke Testing with Playwright\n\nAfter each batch, run a Playwright smoke test:\n\n1. Start a local HTTP server: `python3 -m http.server 8000 &`\n2. Navigate to the built HTML file\n3. Take a snapshot, check for expected DOM elements\n4. Click through the current game flow\n5. Check `browser_console_messages` for zero JS errors (ignore favicon 404)\n6. Close browser, kill server\n\n**Critical:** Do not skip smoke tests between batches. The whole point of batching is to catch integration bugs early when they are cheap to fix (1-2 modules to check) rather than late (14 modules to debug).\n\n**When a smoke test fails:** Fix the failing module before proceeding to the next batch. The fix scope is small (only modules from the current and previous batches exist). If the failure is a contract violation, update the contracts document before dispatching the next batch - all subsequent agents need the corrected contract.\n\n## Web Platform Gotchas\n\nInclude these in every agent prompt to prevent known issues:\n\n| Gotcha | Fix |\n| --- | --- |\n| Canvas blank after innerHTML | Wrap render calls in `requestAnimationFrame` |\n| Canvas zero size | Set width\u002Fheight attributes on `\u003Ccanvas>`, not just CSS |\n| onclick not firing | Verify element exists in DOM before attaching handler; prefer `addEventListener` |\n| Global name collision | Use unique function names across all modules (no generic `init()`, `render()`) |\n| Concatenation order matters | Functions must be defined before they are called in the concatenated output |\n\n## Bottlenecks and Mitigation\n\nFour sequential steps gate the parallel work. Each one is mandatory but can be shortened.\n\n| Bottleneck | Time | Why sequential | Mitigation |\n| --- | --- | --- | --- |\n| UI preference interview | ~2 min | Must happen before any code | Prepare a short checklist (buttons\u002Fdropdowns, theme, mobile). Ask before opening the repo. |\n| Data contracts | ~5-10 min | Every agent needs the contracts before writing code | Reuse contract templates from prior builds. Keep contracts to minimum viable scope only - do not write contracts for deferred features. |\n| Batch 1 foundation | ~2 min | Constants, characters, and game state define the data model all other modules depend on | Keep Batch 1 to 3 files max. Write only the data model and state machine - no UI, no game logic. |\n| Smoke tests between batches | ~2 min each, 4 total | Each batch must pass before the next starts | Keep smoke tests tight: build, load page, check console errors, click one element. Save full playthroughs for the final batch only. Reuse a Playwright smoke test script across batches. |\n\n**The hidden bottleneck is skipping these steps.** Without contracts, debugging mismatches cost 60+ minutes. Without batching, all bugs surface at the end in a 14-module pile. The sequential gates are faster than the alternative.\n\n**Where time is NOT a bottleneck:** Agent authoring within a batch is fully parallel. 6 agents writing 14 files in 4 batches takes ~15 min of agent wall-clock time. The sequential overhead (contracts + smoke tests) adds ~15 min. Total: ~30 min. Compare to all-at-once: 8 min authoring + 60 min debugging = 68 min.\n\n### Independent component testing\n\nModules should be testable in isolation, without waiting for integration. Each agent should deliver a module that can run with stub dependencies.\n\n**How:** Each agent's prompt includes instructions to write their module so it degrades gracefully when other modules are absent. For example:\n- A display function should render something when called with hardcoded test data, even if the generator module does not exist yet.\n- A data generator should be callable from the browser console with test inputs, even if no UI exists to trigger it.\n\n**Practical pattern:** After each agent finishes, verify the module in isolation before the batch smoke test:\n\n```javascript\n\u002F\u002F Drop into browser console after building with just this module + foundation\n\u002F\u002F Test data_generation.js independently:\nvar sample = {type: 'blood', quality: 'pristine'};\nvar character = gameState.suspects[0];\nvar result = generateBloodTypeResult(sample, character);\nconsole.log(result.bloodType, result.rhFactor);  \u002F\u002F should print e.g. \"A\" \"+\"\n```\n\nThis catches internal bugs (wrong property names, missing returns) before integration, when the fix scope is one file instead of fourteen.\n\n### Complex module detection and splitting\n\n**A batch finishes as fast as its slowest agent.** If one module is significantly more complex than its batch-mates, it becomes the bottleneck for the entire batch.\n\n**Before dispatching a batch, estimate relative complexity:**\n\n| Signal | Likely complex |\n| --- | --- |\n| Multiple content types (help topics, tooltips, explanations, summaries) | Yes - split by content type |\n| More than 2 distinct UI screens or flows | Yes - split by screen |\n| Both data generation AND display logic | Yes - split generator from renderer |\n| Over ~400 lines expected | Yes - find a split point |\n\n**When you identify a complex module, you have two options:**\n\n1. **Split it into smaller files** that can be assigned to separate agents within the same batch. Example: instead of one `educational.js` handling help topics, tooltips, test explanations, and end-game summaries, split into `educational_help.js` (help topic content) and `educational_display.js` (rendering and tooltip logic).\n\n2. **Reduce scope for first pass.** Ship the simple version in the current batch, expand later. Example: educational content for 2 test types instead of 5, plain text tooltips instead of rich HTML popups.\n\n**Prefer option 2 (reduce scope) over option 1 (split files) when possible.** Splitting adds coordination overhead. Reducing scope removes work entirely.\n\n**Real example:** The DNA forensics build had `educational.js` (~771 lines) covering help topics for 5 test types, concept tooltips, test result explanations, and end-game forensic science summaries. This was the slowest agent in its batch and held up the entire wave. Better approach: first pass covers help topics for 2 test types only, no tooltips, no end-game summary. Add the rest after the core loop works.\n\n## Rationalization Table\n\n| Excuse | Reality |\n| --- | --- |\n| \"Contracts take too long\" | 10 min contracts vs 60 min debugging mismatches. Not negotiable. |\n| \"We can fix integration later\" | Integration bugs compound. 2 mismatched modules = 1 fix. 14 mismatched modules = 20 fixes. |\n| \"Let's add all features now\" | Get 2 working before adding 3 more. Scope creep killed the first build. |\n| \"Smoke tests slow us down\" | 2 min smoke test catches bugs worth 30 min of debugging. |\n| \"Agents can figure out the interface\" | They cannot. Every generator\u002Fdisplay pair mismatched without contracts. Every single one. |\n| \"I'll ask about UI preferences after\" | UI rewrite cost 30 min. Asking first costs 2 min. |\n| \"requestAnimationFrame is optional\" | Canvas will be blank. This is not optional. |\n| \"All agents can run at once\" | Foundation agents must finish first. Batching is the whole point. |\n| \"One agent can handle this big module\" | A batch finishes as fast as its slowest agent. Split or scope-reduce complex modules. |\n| \"We'll test it all together at the end\" | Test each module in isolation first. Console-level checks catch bugs before integration. |\n\n## Red Flags - STOP\n\n- Dispatching coding agents before contracts are written\n- Skipping a smoke test between batches\n- Adding features beyond the minimum viable scope in batch 3-4\n- Agent prompts that don't include the contracts document\n- Two agents assigned to the same file\n- No Playwright browser testing planned\n- Skipping UI preference gathering\n- One agent assigned a module with 4+ content types or 400+ expected lines without splitting or scope-reducing\n- No plan for testing modules independently before integration\n\n## Common Mistakes\n\n**Flat vs nested data:** Generators return `{enzyme: \"EcoRI\", fragments: [...]}`. Do not nest: `{data: {enzyme: \"EcoRI\", fragments: [...]}}`. Flat properties are what display functions will read.\n\n**Scope creep in contracts:** Only write contracts for features in the minimum viable scope. Do not write contracts for deferred features.\n\n**Canvas in innerHTML:** Always use `requestAnimationFrame` after `innerHTML` that creates a canvas. Always set canvas `width` and `height` as element attributes. This is the #1 rendering bug in single-file web apps.\n",{},"main","def8531e65114c0fca8fb8551c1871ee0eed705c","skills\u002Fvosslab\u002Fvosslab-skills\u002Fparallel-web-game-build",24,"https:\u002F\u002Fgithub.com\u002FComeOnOliver\u002Fskillshub","https:\u002F\u002Fskillshub.wtf","https:\u002F\u002Fgithub.com\u002FComeOnOliver","AI & Blockchain Engineer\r\n","2026-06-24 22:07:19",{"source":7,"skillName":5,"commands":47,"prompt":57,"zipAvailable":58},[48,51,54],{"tool":49,"command":50},"npx","npx skills add ComeOnOliver\u002Fskillshub --skill parallel-web-game-build",{"tool":52,"command":53},"bunx","bunx skills add ComeOnOliver\u002Fskillshub --skill parallel-web-game-build",{"tool":55,"command":56},"pnpm","pnpm dlx skills add ComeOnOliver\u002Fskillshub --skill parallel-web-game-build","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FComeOnOliver\u002Fskillshub\u002Fblob\u002Fmain\u002Fskills\u002Fvosslab\u002Fvosslab-skills\u002Fparallel-web-game-build\u002FSKILL.md",true,[],[61,71,81,90,96,103],{"skillNo":62,"name":63,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":7,"ownerLogin":8,"ownerAvatarUrl":9,"ownerAccountNo":10,"ownerDisplayName":11,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":64,"categories":65,"keywords":67,"publishedAt":33},"01M6FKJN13GMG4KY57J3QD8GY5","model-hierarchy-skill","https:\u002F\u002Fgithub.com\u002FComeOnOliver\u002Fskillshub\u002Fblob\u002Fmain\u002Fskills\u002Fzscole\u002Fmodel-hierarchy-skill\u002Fmodel-hierarchy-skill\u002FSKILL.md",[66],{"categoryNo":23,"categoryName":24,"taxonomyType":20,"taxonomyTypeDesc":21},[68,69,70],"model","model hierarchy","model hierarchy skill",{"skillNo":72,"name":73,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":7,"ownerLogin":8,"ownerAvatarUrl":9,"ownerAccountNo":10,"ownerDisplayName":11,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":74,"categories":75,"keywords":77,"publishedAt":33},"01M6FKJJJ6GCAMR4PPPRD12M5X","zoom-mcp","https:\u002F\u002Fgithub.com\u002FComeOnOliver\u002Fskillshub\u002Fblob\u002Fmain\u002Fskills\u002Fzoom\u002Fskills\u002Fzoom-mcp\u002FSKILL.md",[76],{"categoryNo":23,"categoryName":24,"taxonomyType":20,"taxonomyTypeDesc":21},[78,79,80],"MCP","zoom","zoom mcp",{"skillNo":82,"name":83,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":7,"ownerLogin":8,"ownerAvatarUrl":9,"ownerAccountNo":10,"ownerDisplayName":11,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":84,"categories":85,"keywords":86,"publishedAt":33},"01M6FKJE3KYT3KPEZMEEHYKA6K","zoom-apps-sdk","https:\u002F\u002Fgithub.com\u002FComeOnOliver\u002Fskillshub\u002Fblob\u002Fmain\u002Fskills\u002Fzoom\u002Fskills\u002Fzoom-apps-sdk\u002FSKILL.md",[],[87,88,89,79],"sdk","zoom apps sdk","apps",{"skillNo":91,"name":92,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":7,"ownerLogin":8,"ownerAvatarUrl":9,"ownerAccountNo":10,"ownerDisplayName":11,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":93,"categories":94,"keywords":95,"publishedAt":33},"01M6FKJ9EDH9Q5VWDF8HAJRSP0","windows","https:\u002F\u002Fgithub.com\u002FComeOnOliver\u002Fskillshub\u002Fblob\u002Fmain\u002Fskills\u002Fzoom\u002Fskills\u002Fwindows\u002FSKILL.md",[],[92],{"skillNo":97,"name":98,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":7,"ownerLogin":8,"ownerAvatarUrl":9,"ownerAccountNo":10,"ownerDisplayName":11,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":99,"categories":100,"keywords":102,"publishedAt":33},"01M6FKJ666BEEFC3AE9GJ72Q93","whiteboard","https:\u002F\u002Fgithub.com\u002FComeOnOliver\u002Fskillshub\u002Fblob\u002Fmain\u002Fskills\u002Fzoom\u002Fskills\u002Fwhiteboard\u002FSKILL.md",[101],{"categoryNo":23,"categoryName":24,"taxonomyType":20,"taxonomyTypeDesc":21},[98],{"skillNo":104,"name":105,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":7,"ownerLogin":8,"ownerAvatarUrl":9,"ownerAccountNo":10,"ownerDisplayName":11,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":106,"categories":107,"keywords":108,"publishedAt":33},"01M6FKJ21WFCDGTJQ2Q91T9DVW","websockets","https:\u002F\u002Fgithub.com\u002FComeOnOliver\u002Fskillshub\u002Fblob\u002Fmain\u002Fskills\u002Fzoom\u002Fskills\u002Fwebsockets\u002FSKILL.md",[],[105]]