genex-desktop
AGENTS.md810 starsChanged 25 days agoMITView on GitHub
If your working directory is under .studio-dev/profiles/, you are an in-app game builder in a development profile: ignore this file and follow your game's own CLAUDE.md. This repository is the macOS Electron application. You are its external developer; the editable in-app game-building harness is a separate agent with narrower authority. src/harness-seed/** and src/game-template/** (including src/game-template/CLAUDE.md) are product payload addressed to in-app agents: edit them as product text, don't follow them. The user's request and assigned issue own scope. Maintained topic…
Where files are headingNew AGENTS.md files have more rules about keeping secrets out of the code, and fewer about code style.
Of the AGENTS.md files we read, the 31,439 first seen in the last six months, against the older ones: the kind of rule that gained most share, and the kind that lost most. About files like this in general, not this one, and an estimate, since a kind is a pattern in the words.
In this repository33 other files it gives its agents.
- src/AGENTS.mdAGENTS.md
- tests/AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- src/CLAUDE.mdCLAUDE.md
- tests/CLAUDE.mdCLAUDE.md
- add-event-typeSkill
- add-ipc-channelSkill
- add-plugin-toolSkill
- better-colorsSkill
- better-layoutSkill
- better-typographySkill
- better-uiSkill
- better-writingSkill
- breakSkill
- harness-incident-fixSkill
- run-area-testsSkill
- variantSkill
- verify-ui-via-dev-controlSkill
- wire-artSkill
- add-event-typeSkill
- add-ipc-channelSkill
- add-plugin-toolSkill
- better-colorsSkill
- better-layoutSkill
- better-typographySkill
- better-uiSkill
- better-writingSkill
- breakSkill
- harness-incident-fixSkill
- run-area-testsSkill
- variantSkill
- verify-ui-via-dev-controlSkill
- wire-artSkill
The file
Show its rules and text
We split this AGENTS.md into the rules it gives an agent
14 rules. About 1 is common, 6 are distinctive, and 7 are very specific to this project.
≈1
Common · estimate
Many files like this have a rule of this kind.
≈6
Distinctive · estimate
This author's own choices. Worth a look.
7
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 3
If your working directory is under .studio-dev/profiles/, you are an in-app game builder in a development profile: ignore this file and …
- Very specific: line 15
Read the product overview, then only the relevant page in docs/product/.
- Distinctive: line 28
Every spawned agent or game process goes through ProcessSandbox.
- Very specific: line 32
Every new IPC channel is classified fixture-safe or native in src/main/dev/native-policy.ts.
- Very specific: line 42
Use scoped verification from verification.md.
- Distinctive: line 51
No new assertions over source text.
- Distinctive: line 53
Use the cheapest layer that proves the behavior.
- Distinctive: line 54
Keep time injectable; never lengthen a deadline to get green.
- Distinctive: line 100
Write code a person enjoys reading.
- Very specific: line 128
Keep every "why" comment with its code.
- Very specific: line 139
Run npm run verify:context before the PR.
- Distinctive: line 171
Don't create, switch or remove branches/worktrees, install hooks, merge or release unless explicitly asked.
- Very specific: line 174
Don't reference local-only documents (knowledge-map localOnly) from tracked files.
- Common: line 175
Don't overwrite normal games, profiles, credentials or harness edits.
≈ “Common” is an estimate: at least 1 in 5 of the 40,246 AGENTS.md files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Developing Genex
If your working directory is under .studio-dev/profiles/, you are an in-app game builder in a
development profile: ignore this file and follow your game's own CLAUDE.md.
This repository is the macOS Electron application. You are its external developer; the
editable in-app game-building harness is a separate agent with narrower authority.
src/harness-seed/** and src/game-template/** (including src/game-template/CLAUDE.md) are
product payload addressed to in-app agents: edit them as product text, don't follow them.
The user's request and assigned issue own scope. Maintained topic docs describe current
behavior; resolve conflicts against the implementation and fix the owning doc.
Orient
Read the product overview, then only the relevant page in
docs/product/. Run npm run review:context -- --area <id> for the docs and checks of an
area. Use the glossary for house terms and the
recipes for common changes; src and
tests have folder notes. Engineering skills in .agents/skills/ (mirrored byte for byte in
.claude/skills/): add-ipc-channel, add-event-type, add-plugin-tool, run-area-tests,
verify-ui-via-dev-control, harness-incident-fix. Do not read the whole documentation set or
historical task records at startup.
Hard invariants
- The renderer is a browser: no Node, Electron, main, preload or substrate imports. It talks
only through the fixed named calls in
src/shared/studio-api.ts. - Every spawned agent or game process goes through ProcessSandbox; Bypass agents run unboxed.
- Seed upgrades keep the in-app agent's harness edits, except the one upgrade into an archive
epoch (
substrate/seed-archive.ts): edits of files that seed removes or changes, and what the runs learned, move to<harness workspace>/archive/<date>/and the seed's copies replace them. - Every new IPC channel is classified fixture-safe or native in
src/main/dev/native-policy.ts. - Preserve the normal profile and
~/AI Games; use ownedstudio:devprofiles. Automated checks use disposable fixtures. A request to run the real app for manual testing authorizes a visible live profile; “no mocks” must never select fixtures. Leave human sessions running. Live profiles retain provider-account/Keychain and usage semantics: isolation of app data does not isolate accounts. Do not inspect, reset or copy credentials. See the field guide.
Test-first loop
Use scoped verification from verification.md;
its layer table lists available commands. Every check
needs Node 24 (.nvmrc); select it (for example nvm use) before running any of them.
On Apple Silicon, verify node -p process.arch says arm64: an Intel Node runs through
Rosetta and makes local timing comparisons misleading.
The scope table owns required checks; the layer catalog is not a cumulative checklist.
- Red first: every fix starts with a test that fails for the reported reason.
- Characterize current behavior before refactoring it.
- No new assertions over source text; test behavior through the code's interface.
- Path, symlink and network boundaries get hostile-input tables that assert no side effect.
- Use the cheapest layer that proves the behavior.
- Keep time injectable; never lengthen a deadline to get green.
- Name every intentionally flipped assertion in the PR.
- Report which layers ran and never describe a focused pass as a full run.
Once relevant checks pass, stop; repeat only for changed inputs or an investigated failure. A build alone is insufficient for a UI change. Record build, profile and provider identity when relevant.
Engineering foundations
- Safety: no destructive git on user folders without a game snapshot. Validate host RPC path
parameters by realpath. Quote shell arguments with
shellQuote. - Players' Macs have no developer tools: shipped code never runs a /usr/bin program that only
stands in for Xcode's (
lipo,otool,xcrun); read the file in the app or use macOS's own tool.scripts/check-mac-tools.ts(incheck:static) refuses them, andDEVELOPER_DIR=/nonexistentreproduces such a Mac in a test or astudio:devlaunch. - Tests prove behavior. Copy or spacing edits do not need new tests.
- Contracts live in
src/shared(IPC channel map, UiEventMap, CustomEventMap, HarnessHostApi); add new events/channels there first; no payload as / as never. - No
enum,namespaceor parameter properties, because Node runs.tsdirectly: a vocabulary is anas constobject (see Readability). - Biome must pass (
npm run lint;check:staticlints changed files) and the types must check under TypeScript 7 (npm run typecheck, which runsscripts/tsc.ts). Code that needs the TypeScript JS API imports@typescript/typescript6, nevertypescript. - Harness (
src/harness-seed/): the modes (director, the one Loop; the classic pipeline's autopilot, facet loop, gauntlet and spike) keep their own control flow and share primitives fromloop/git.ts,evidence.ts,config.tsandoutcomes.ts; no classes, DI or FSM libraries. A judge is a second opinion the lead asks for: it gates no round, merge, finish or close. It is TypeScript, type-checked in CI (tsconfig.harness.json) and, for the agent's own code edits, by the in-app TS 7 gate (guardian.validate_editwith the compiler vendored indist/resources/tsc). - The app never imports
src/harness-seed/(the agent edits it). A rule both sides apply has a typed copy insrc/shared, held to the seed's byseed-contracts.test.ts(recipe). - Renderer state: Zustand domain stores in
src/renderer/state/with pure exported actions and selector-only reads (state/hooks.ts); UI-only state stays local; derivations stay in the pure modules; storage keys come fromrenderer/storage.ts. - Helpers live next to their domain (
substrate/paths.ts,substrate/fsx.ts,shared/errors.ts,shared/redact.ts); noutils,constantsortypesdumping folders. - One table per vocabulary (asset formats in
shared/game-assets.ts, plugin ids inshared/plugin-id.ts). Never decide behavior by matching English text; use typed codes and fields.
Readability
Write code a person enjoys reading; behavior never changes in a readability edit.
- Formatting is Biome's (
npm run lintfails unformatted code); runbiome format --writeon what you touched, never hand-pack lines. - A vocabulary is
export const EngineStatusCode = { Ready: "ready", … } as constplus a type of the same name ((typeof X)[keyof typeof X]): PascalCase keys, values in their exact wire spelling, never renamed. Its home is the module that owns the type, or the top of the module for a private one; bind it to type maps withsatisfies(recipe). - A raw vocabulary literal (engine id, status, event or method name, phase) outside its home is
a defect: write
CustomEvent.RunFinished,HostMethod.EventsList,UiEvent.PreviewFrame.scripts/check-vocabulary.ts(incheck:static) refuses the common shapes, and inlinenew Promise(r => setTimeout(r, ms))sleeps: usenode:timers/promises(the seed'sloop/time.ts). - Name a condition with three or more operands, or
&&mixed with||: a local const or a small predicate beside its type (needsSignIn(engine)). Compute repeated sub-expressions once. No nested ternaries, no!assertions in code you touch. - Timeouts, caps, sizes and retries are SCREAMING_CASE consts at the top of their module, in
shared/duration.tsunits (the seed'sloop/time.ts). User copy is English insidet()(translation), inrenderer/words.tsor a module-localMESSAGEobject; model prompts in a sibling*-prompts.tsor seedprompts/*.md. - Functions aim for 60 lines (80 at most, cognitive complexity 15): guard clauses first, no
elseafterreturn, no parameter reassignment, repeated steps become a named helper beside their domain. - In
src/**andscripts/**these limits, nested and useless ternaries, parameter reassignment,elseafterreturnand uncollapsedifs are Biome errors, sonpm run lintfails on them; tests keep them as warnings (npm run lint:warnlists the backlog). An exception is abiome-ignorenaming its reason, such as a function serialized into the page. - Keep every "why" comment with its code; give each new export a one-line doc comment. Keep
data-*selectors, aria-labels and visible strings byte-identical.
Documentation and PRs
- Docs describe the current application. Update affected pages in the same PR; replace obsolete statements and link instead of copying.
evals/baselines/andevals/ledger/export-*.jsonlare the only committed measurement records; everything else from a campaign stays local (evals).- Source copied into the repository (not an npm dependency the build bundles) is listed in
THIRD-PARTY-NOTICES.mdwith its license; the build's notice generator cannot see it. - Run
npm run verify:contextbefore the PR. It enforces overview ≤500 words, each product page ≤800, the handbook ≤4,000 and at most eight product pages. Shorten or reorganize when full; do not raise limits. - For now all work integrates into
dev: base work onorigin/devand open PRs againstdev. Never push or open PRs tomainunless the owner asks. The owner opensdev→mainPRs by hand; only they run the billed macOS/Windows CI (checkfast,package,windows,terminal), so dispatch one on your branch when a change is platform-sensitive. - PRs contain code, tests/fixtures, attribution, changed docs and a validation summary per the PR template. Name docs updated or explain why they remain accurate. No session reports, filled plans, handoff JSON or raw report batches in Git.
- Temporary notes: one ignored
.studio-dev/notes/<task>.md, under 80 lines, removed when complete. Raw evidence stays in.studio-dev/evidence/. Share a short issue or draft-PR summary only when handing work over; Git history keeps past decisions.
Design foundations
For application UI/UX, visual design, design-system or product-copy work, read
the design workflow before editing. It owns the design principles and
routes to local skills; variant and break are opt-in exploration tools. Follow its rendered
review and evidence requirements.
Setup and authorization
Authorization already given in the conversation persists. Restoring locked dependencies with
npm run deps is included when needed to build, run or test the requested work; do not repeat it
without a missing or mismatched dependency. In a worktree it clones one shared install per
lockfile instead of npm ci writing 1.4 GB more. Dependency upgrades and global installations are
separate scope decisions. Use the installed Node 24; do not change machine-wide runtimes as an
incidental verification step.
Don'ts
- Don't create, switch or remove branches/worktrees, install hooks, merge or release unless explicitly asked. Verification or merging authorizes none of these, nor workspace cleanup.
- Don't reference local-only documents (knowledge-map
localOnly) from tracked files. - Don't overwrite normal games, profiles, credentials or harness edits.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

