How game site development became a written method after one bad rule
I wrote down game site development because one rule of mine was wrong in a way that left demonstrably incorrect answers live on a site. The rule said that a fact should not be written unless the source-material library had a matching entry. That sounded rigorous. In practice it meant refusing to correct a removed demo and a PC-only platform while waiting for a source that was never going to arrive. The method is built around the correction, not around the original confidence.
This page is a first-person account of why game site development became a written method, how it was developed, what it covers, and who should use it. The repository is at github.com/rockyandtom/gamesite. Everything here was checked on 2026-11-11.
01 /Why did I write a game site development method?
The work splits into three stages, and confusion about who owns which stage caused real damage. An upstream material factory selects keywords, researches them and produces one source document per page without building anything. A middle stage turns those materials into pages and an engineering setup. A downstream stage deploys, binds a domain, connects analytics and handles on-page SEO. My responsibility is the middle and downstream stages only. Topic selection, keyword strategy and monetisation are explicitly out of scope.
The mistake was a scope error. The source-material red lines were written to constrain upstream collection: keep the original text, label the source, do not invent facts, cross-check at least two sources. Those are good rules for collecting material. I then over-applied them to page writing as "if the material library has no hit, do not write the fact", and wrote that into a project convention nobody had asked for. The result was that easily verifiable first-party facts stayed wrong on a live site — a demo that had been removed, a platform that was PC-only — because the folder had no document saying so.
That is why the game site development method exists as prose rather than as a pile of scripts. It records the boundary, the correction and the date. A method that only says "use Astro and deploy to Cloudflare Pages" would be easy to copy and would repeat the same error.
02 /How was the game site development method developed?
It was distilled from a complete project, then corrected once, then extended. The correction is dated 2026-09-17 in the rule source, and eight further pitfalls were added in 2026-10 covering images, external links, H1 hierarchy and preview environments.
| Stage in the method | What was recorded | Why it was recorded |
|---|---|---|
| Division of labour | Upstream materials, middle build, downstream deploy | Prevents a material rule from being applied to page writing |
| Stack decision | Astro static output, Cloudflare Pages, static API token file | Zero runtime JavaScript, plain HTML, directly hostable dist/ |
| Fact classification | A / B / C with different evidence rules | The 2026-09-17 correction after a wrong rule |
| Live verification | Public Steam appdetails endpoint | Time-sensitive facts change faster than a material snapshot |
| Pitfall checklist | Eight additions dated 2026-10 | Real builds produced the same failures repeatedly |
The A/B/C classification is the durable part. Class A covers first-party hard facts — price, release date, platform, system requirements, demo availability, achievement count, language count, developer and publisher. These get verified directly and written immediately with a source and a check date, without waiting for the material library. Class B covers operational and community content such as module solutions, character techniques and play flow, and keeps the two-source rule. Class C is unannounced speculation about future platform plans, which is either not written or explicitly marked as not announced by the vendor.
| Class | Content | Rule |
|---|---|---|
| A | Price, platform, release date, demo availability, requirements | Verify directly, write with source and check date, do not wait for the library |
| B | Techniques, module walkthroughs, play flow | Require two cross-checked sources; otherwise do not write |
| C | Unannounced platform plans and release rumours | Do not write, or state clearly that the vendor has not announced it |
Verification means actively going to find a source, not waiting for one to appear in a folder. The public Steam appdetails API is named as the preferred live check for time-sensitive A-class facts, because one response exposes the official name spelling, formatted price, release date, all three platform flags, demo presence, achievement total, supported languages, requirements text and categories. The rule source notes a specific trap: looking only at linux=false can produce a wrong "Windows only" answer when the Mac flag is true. It also notes that demos: null is better evidence than an old material note saying a demo exists. When the live official API conflicts with a material snapshot, the API wins and the page carries a check date.
Conflicts with other documents are pre-resolved. Launch ordering belongs to a separate Skill, and any SEO judgement is governed by the numbered rules in seo-dev-spec. This document is the "how" and the field notes, not the authority.
For public release, this was one of 5 Skills selected from 19 user-level Skills on this machine. Machine-specific paths were made portable, one install-path reference was made relative, and an English README was added. Two files were published: the Chinese methodology and the README. There are no runnable scripts in the package.
03 /What does the game site development method actually do?
It makes the stack decision explicit, fixes the fact rules, and covers the build-and-deploy checklist.
Astro static output is the default: zero runtime JavaScript, plain HTML, and a dist/ directory that Cloudflare Pages can host directly. It states where this does not fit — heavily interactive single-page applications. Deployment is via direct upload, and credentials are a static API-token file rather than an OAuth MCP flow. Every page needs a Source note distinguishing official from community-sourced facts, and external SEO reports are treated as claims to verify rather than instructions to obey.
| Area | What the method requires |
|---|---|
| Page output | Main copy, H1, breadcrumbs and internal links present in static HTML |
| Facts | A verified directly, B two sources, C refused; Source note on every page |
| Live checks | Steam appdetails for time-sensitive first-party facts, with a check date |
| Deployment | dist/ to Cloudflare Pages, then custom domain binding |
| After launch | GSC / GA4 wiring, AdSense notes, on-page SEO, pitfall checklist re-run |
The pitfall checklist is accumulated from real builds rather than derived from a specification. The eight additions dated 2026-10 cover images, external links, H1 hierarchy and preview environments, among others. A dated list of mistakes is more useful than a generic warning because each entry corresponds to something that actually went wrong.
04 /Who should use the game site development method?
Read it before and during a build that turns a per-page source library into a static content site, and again before deployment. Use it as a checklist for the build-and-deploy stage and as the reference for what to do when a fact conflicts with an external report. It is written for the person doing the middle and downstream work, including the person who has to decide whether an external audit is right.
| Use it for | Do not use it for |
|---|---|
| Turning a source library into static pages | Planning the order of a launch |
| Deciding whether a fact can be written | Making final SEO acceptance decisions |
| Checking a live first-party fact before publishing | Choosing topics, keywords or monetisation |
| Deploying and binding a custom domain | Building a heavily interactive application |
| Re-running a pitfall checklist before adding pages | Translating the Chinese rule source |
The companion verification gate picks up exactly where this one stops: the operating phase after launch. The numbered rule source is the authority on SEO judgement and outranks this document when they disagree. My comparison page is an example of the same restraint about claims, and the notes index holds dated corrections like the one behind this method. The about page states who verifies these pages.
05 /What are the limits of this package?
SKILL.md is in Chinese; the English README is an entry point, not a translation. There are no runnable scripts, and the commands quoted in the document are examples from the described workflow, not bundled tooling. No build step, credential, private bucket or build artifact is included.
External services appear only as part of the described workflow: Cloudflare Pages, the public Steam appdetails API, a page-extraction API, GA4 / GSC, AdSense and a GitHub connector. Availability of third-party endpoints and platform behaviour changes over time; the dates in the document are the dates those observations were made. The 2026-09 availability observations in the companion selection Skill are a snapshot of the same kind. Everything on this page reflects the state checked on 2026-11-11.
06 /Frequently asked questions
Why is there no code in a development Skill?
Because the value here is in the division of labour and the fact rules, not in a generator. The mistake that produced the A/B/C classification was a judgement error, not a missing function. A script would have encoded the wrong rule just as happily. The package is prose guidance and a pitfall checklist.
What exactly was the recorded mistake?
The upstream material red lines were over-applied to page writing as "no source in the library, do not write the fact". It left known-wrong answers live — a removed demo and a PC-only platform — while waiting for material that was never coming. The 2026-09-17 correction says verification means actively finding a source, and separates first-party hard facts from community content and speculation.
Which fact should I trust when a material snapshot and a live API disagree?
The live official API, with a check date written on the page. The rule source names the public Steam appdetails endpoint for price, platform, release date and demo availability, and warns that reading only one platform flag can produce a wrong answer. An old snapshot is a record of what was true when it was collected, not a ruling on what is true now.
Does this Skill decide whether my pages pass an SEO audit?
No. Where this document and seo-dev-spec disagree on an SEO rule, the numbered rules win. The two are companions: this one is the "how" and the field notes, the other is the authority. Launch ordering belongs to yet another Skill and is deliberately excluded here.
07 /Where should you go next?
The post-launch verification gate covers the days after launch, including the embed-source check. The SEO Dev Spec rule source is the authority on page and link rules; the GEO AI Traffic and Presale Validation packages answer other questions, and all five public repositories published on 2026-11-11 are listed on the about page.