Keeping this wiki right

This wiki explains how to do things with Team Cereus's modding tools. It is only useful while it matches the tools, so whoever changes a tool updates its pages in the same change. That means agents too.

The rule

1. Before you finish a change to any tool listed in README.md, find the pages that document the files you touched:

   py -3.12 -I -B S:/eclipse-build/docs/wiki/check.py --for <path you changed> [<another path> ...]
   

2. Open each page it lists. Fix every step, menu name, command, flag, path or default your change made wrong. Add a page when you add a workflow someone will ask "how do I ...?" about.

3. Set the page's verified: line to now. check.py --stamp <page> does that for you. Only stamp a page you actually re-read against the code.

4. Put the update on the site: py -3.12 -I -B S:/eclipse-build/docs/wiki/site/publish.py (no need to ask first).

5. Say in your report which wiki pages you updated.

A change that only moves code around and changes nothing a reader does still needs step 3, so the page stops showing as stale.

Finding stale pages

py -3.12 -I -B S:/eclipse-build/docs/wiki/check.py

It lists every page with a source that changed after the page's verified: time, and the files that changed. It also reports sources that no longer exist and links between pages that point nowhere. It only reads; it never changes a page (except --stamp).

The site

The Markdown pages are the only source. site/build.py turns them into a static site with a sidebar, search and the status of each page:

py -3.12 -I -B S:/eclipse-build/docs/wiki/site/build.py [--out DIR]

• Output: S:/eclipse-build-out/tooling-wiki-site (not in git). Open index.html from disk, or serve the folder.
• It needs the markdown_it Python package (markdown-it-py). It fails if a link between pages points nowhere.
• Never edit the built HTML. Change the look in site/site.css, site/site.js or the template in site/build.py.
• A new section folder needs a line in SECTIONS in site/build.py to show in the sidebar.

What does not belong here

The site is public at https://tools.cereus.games, and the wiki is for the tools and the people who use them.

• No publishing steps: releasing Eclipse, the launcher or a Smithbox team build, Discord patch notes, the players' wiki, deploying a site, running the server. Those notes live in S:/eclipse-build/docs/internal/ (not built into the site; check.py still watches them). Never link from a wiki page to that folder.
• No user-profile paths (write %USERPROFILE%), e-mail addresses, teammates' names, report contents or secrets.

Page format

Every page starts with this block. check.py reads it, so keep the shape exactly.

---
title: Place an Elden Ring asset in a Nightreign map
status: checked
verified: 2026-11-12T15:00
sources:
  - smithbox:src/Smithbox.Program/Editors/Map Editor/Tools/Object Palette/
  - smithbox:Tools/mcp/smithbox_mcp.py
---

• status
  • checked: every step was read against the code or run.
  • partial: some of it is checked; the page says which parts are not.
  • stub: a placeholder for something being built or not yet written up.
• verified: local time, YYYY-MM-DDTHH:MM, of the last time someone compared the whole page with the sources.
• sources: the files and folders the page describes, as <repo>:<path inside it>. A folder covers everything in it. Keep the list tight: the files where a change would make the page wrong, not everything the tool touches. The repo names are in repos.toml.

Kinds of page

• Workflow pages answer one question, "how do I ...?". The title is the task. Give what you need before you start, then numbered steps with the exact menu names, keys and commands, then how to tell it worked, then what goes wrong.
• Reference pages (reference.md in each folder) list what a tool has: commands, flags, panels, settings, file locations.
• The folder's README.md is its index. Add new pages to it and to the top README.md.

Writing rules

• Plain language. Short sentences. Readers are the team's modders and other agents.
• Use the names the game and the tool show: menu items, panel titles, in-game names. Never invent a label.
• Take every step from the code or the running tool. If you could not check something, say so on the page.
• Say plainly when something has not been proven in game.
• Never write a secret (webhook URL, key, token) or a teammate's personal details. Name the file a secret lives in, not its content.
• Link between pages with relative links.

Where the rule is written down

• S:/eclipse-build/AGENTS.md and docs/AGENTS-GUIDE.md
• S:/Smithbox/CLAUDE.md
• S:/fromsoftware-rs/tools/debug-nightreign/README.md (the release scripts README points at docs/internal/release/)
• the agent memory tooling-wiki.md