The Day-One 10-Page List: Turning a Decision into a Writing Plan
Turn the verdict into a 10-row writing plan — codes page first, then guides, tier list, FAQ, and your validated window queries. Stage one's graduation output.
A true scene first
“Build” is decided — then what? The most common beginner state is staring at an empty site: which page first, how many, when is it done? This lesson compresses that fog into a 10-row table — tomorrow morning you open the laptop and work row one.
Step 1: why these ten pages
The order is not arbitrary; every row has a reason:
- The codes page — the most-searched thing players want, and they assume it updates daily, so they keep coming back (return traffic is the most valuable kind — Lesson 1)
- The beginner guide — the first search of every new player
-
-
- Three guides for the most important bosses — being stuck is search motive number three
-
- The tier list — required reading for players who want to improve, and discussion bait
- A “how to redeem codes” FAQ page — catches the codes page’s second question
-
-
- Your three highest-scale validated queries — every selection pass surfaced openings; now cash them in
-
See the pattern: the first seven are the standard deck every game wiki needs; the last three are the exclusive answers your own selection data surfaced.
Step 2: have AI turn the verdict into the plan
Paste this whole block to AI, <> replaced with yours:
Plan the day-one 10 pages from my selection verdict.
Game: <game name>; validated queries: <the words validated in lessons 4/6, listed one by one>.
Standard deck: codes page, beginner guide, 3 most-important-boss guides, tier list, "how to redeem codes" FAQ.
Add: pages for the 3 highest-scale queries among my validated words.
Output a table: priority / page / suggested slug / category (codes or guides or bosses) / suggested title / target query / material you need from me.
Mark anything short on data as "awaiting my input" and list your questions. Planning only — produce no pages.
Three things to watch: slugs are lowercase English with hyphens (they become the URL); the target-query column must come from words you validated, not AI guesses; and “planning only” — writing pages is Lesson 13’s business, today is plan only.
Step 3: hang the plan on the decision ledger
Row one of the plan maps to the “build” row in your decision ledger. From today, your selection register and your content plan form one line — these tables get reused again at batch production (Lesson 27) and second-site cloning (Lesson 26).
Three classic mistakes (made for you in advance)
- Fifty pages on day one: get ten pages through QA and live first; scale later. Scaling unstable quality mass-produces junk.
- No target-query column: a page without a query is a diary, not a traffic entrance. That column becomes raw material at Lesson 27.
- Letting AI “helpfully” invent data: at planning it only ranks priorities; facts like codes and stats always wait for your verification (Lesson 14 has the red lines).
Three words to know (just these)
- Standard deck: the pages every game wiki needs (codes / guide / bosses / list) — reused for every new game and site.
- Window query: a word validated during selection with competition still open — your exclusive-opportunity page.
- Slug: the page’s English short name in the URL, lowercase with hyphens, like
stormcaller-boss-guide.
✅ Acceptance (all must hold)
- A 10-row plan table: every row has priority, page, slug, target query, material list
- Row one is the codes page; the last three rows are your window queries
- ☐ You answered AI’s question list one by one (instead of letting it guess)
Stage one — graduated
Stage one is done. In your hands: a filtered candidate table, a committed verdict, a 10-page writing plan — the hardest and most valuable part of the business is behind you. Next stop, stage two: stand it up — install the tools, run the site, make it yours. Go to Lesson 9 · Install the 6 Tools