$npx -y skills add Stanestane/game-design-skills-bundle --skill game-design-one-page-design-docCreate a concise one-page game design document and export it as both markdown and PDF. Use when a user wants a one-page design doc, one-pager, pitchable design summary, or compact game concept sheet that captures identity, pillars, summary, features, interface, aesthetic directio
| 1 | # Game Design One-Page Design Doc |
| 2 | |
| 3 | Create a one-page game design document that is readable, decision-useful, and visually polished — exportable as a PDF that looks like a real product. |
| 4 | |
| 5 | Use this skill when the user wants a compact game design summary rather than a bloated GDD. The output is designed to be passed around in meetings, dropped in Slack, or emailed to publishers without embarrassment. |
| 6 | |
| 7 | Read `references/family-conventions.md` when you want the shared style and prioritization rules for this game-design skill family. |
| 8 | Read `references/source-notes.md` when you want the distilled takeaways from the reference template and the GDC talk overview. |
| 9 | |
| 10 | ## Core principle |
| 11 | |
| 12 | A one-page design doc is not a small bad GDD. It is a compressed communication tool. |
| 13 | |
| 14 | It should: |
| 15 | - state what the game is |
| 16 | - state why it is interesting |
| 17 | - state what feeling or fantasy it is chasing |
| 18 | - state the core features and interaction model |
| 19 | - state enough production framing to make it actionable |
| 20 | |
| 21 | It should not: |
| 22 | - try to explain every subsystem |
| 23 | - drown the reader in lore |
| 24 | - use vague slogans instead of specifics |
| 25 | - hide the real game behind marketing fluff |
| 26 | |
| 27 | ## What to produce |
| 28 | |
| 29 | Produce: |
| 30 | 1. **One-page PDF** — the shareable, visually designed version |
| 31 | 2. **One-page markdown doc** — the editable text version |
| 32 | 3. **Structured source JSON** — the intermediate data used for rendering |
| 33 | |
| 34 | ## Visual design |
| 35 | |
| 36 | The PDF renderer (`scripts/render_one_page_gdd.py`) produces a professional dark-theme layout: |
| 37 | |
| 38 | - **Dark background** — near-black navy `#0F111A`, with a lighter panel for the header |
| 39 | - **Teal accent colour** — `#00C8A0` for rules, section headings, pillar tag nubs, and bullet markers |
| 40 | - **Pillar tags** — design pillars rendered as pill-shaped labels with a teal left accent in the header |
| 41 | - **Two-column body** — left column for mechanics-heavy content, right column for production/aesthetic content |
| 42 | - **Section rules** — a teal horizontal rule above each section label |
| 43 | - **Poppins typeface** — used when available (falls back to Liberation Sans or DejaVu) |
| 44 | - **Branded footer** — document label on the left, game title on the right |
| 45 | |
| 46 | The renderer uses **ReportLab** (vector PDF — real text, not a raster image), making the output searchable, copy-pasteable, and print-sharp. |
| 47 | |
| 48 | ### Font requirements |
| 49 | |
| 50 | The renderer searches for fonts in standard system locations automatically: |
| 51 | - Linux: `/usr/share/fonts/truetype/google-fonts/`, `/usr/share/fonts/truetype/liberation/` |
| 52 | - macOS: `~/Library/Fonts/`, `/Library/Fonts/` |
| 53 | - Windows: `C:/Windows/Fonts/` |
| 54 | |
| 55 | Preferred: Poppins (Bold, Medium, Regular, Light) from fonts.google.com |
| 56 | Fallback: Liberation Sans (included in most Linux systems) |
| 57 | |
| 58 | ### Dependencies |
| 59 | |
| 60 | ```bash |
| 61 | pip install reportlab |
| 62 | ``` |
| 63 | |
| 64 | ## Default section structure |
| 65 | |
| 66 | Left column: |
| 67 | - Genre / Story / Mechanics Summary |
| 68 | - Key Features |
| 69 | - Interface & Controls |
| 70 | |
| 71 | Right column: |
| 72 | - Art Style |
| 73 | - Music & Sound |
| 74 | - Roadmap / Launch Criteria (includes platform, audience, milestones, launch date) |
| 75 | |
| 76 | Header band: |
| 77 | - Game title |
| 78 | - Identity / Mantra (subtitle) |
| 79 | - Design Pillars (as pill tags) |
| 80 | |
| 81 | ## Process |
| 82 | |
| 83 | ### 1. Clarify the design input |
| 84 | Collect or infer the minimum needed: |
| 85 | - game title or working title |
| 86 | - game identity / mantra |
| 87 | - 2 to 3 design pillars |
| 88 | - concise gameplay/story/mechanics summary |
| 89 | - 3 to 6 key features |
| 90 | - input / interface model |
| 91 | - art references or aesthetic direction |
| 92 | - sound direction or emotional audio goals |
| 93 | - platform |
| 94 | - target audience |
| 95 | - milestone plan or launch criteria |
| 96 | |
| 97 | If the user gives messy notes, compress them rather than asking endless questions. |
| 98 | |
| 99 | ### 2. Write for one-page density |
| 100 | Keep each section tight. |
| 101 | |
| 102 | Guidelines: |
| 103 | - prefer short bullets over dense paragraphs |
| 104 | - keep pillars punchy (2–4 words each) |
| 105 | - keep the summary to a compact paragraph |
| 106 | - keep features to the strongest few, not every idea |
| 107 | - make roadmap milestones concrete enough to be useful |
| 108 | - write like the doc will be skimmed in under two minutes |
| 109 | |
| 110 | ### 3. Preserve design clarity over style fluff |
| 111 | If the concept is fuzzy: |
| 112 | - choose clarity over hype |
| 113 | - expose contradictions instead of smoothing them over |
| 114 | - keep claims grounded in actual mechanics or fantasy |
| 115 | |
| 116 | ### 4. Build the structured source JSON |
| 117 | Write a JSON file matching the renderer schema. |
| 118 | |
| 119 | Expected fields: |
| 120 | - `title` |
| 121 | - `identity_mantra` |
| 122 | - `design_pillars` (array, 2–4 items) |
| 123 | - `summary` |
| 124 | - `features` (array, 3–6 items) |
| 125 | - `interface` |
| 126 | - `art_style` |
| 127 | - `music_sound` |
| 128 | - `platform` |
| 129 | - `audience` |
| 130 | - `milestones` (array) |
| 131 | - `launch_day` |
| 132 | |
| 133 | See `references/example-input.json` for a worked example. |
| 134 | |
| 135 | ### 5. Render markdown and PDF |
| 136 | |
| 137 | ```bash |
| 138 | # Install dependency first if needed: |
| 139 | pip install reportla |