agents-plugins AGENTS.md

AGENTS.md

Project overview

agents-plugins is the CS Modding marketplace (csmodding) of agent plugins for Claude Code and OpenAI Codex CLI.

• plugins/coherent-gameface/: flagship plugin. Drives a running Coherent Gameface UI (Cohtml) over a direct CDP WebSocket; TypeScript MCP server (npm @csmodding/gameface-devtools-mcp) + skills.
• plugins/unity-devtools/: drives a running Unity Mono development build over the Mono Soft Debugger protocol (SDB); C# MCP server + SDB class library.

Both are generic toolkits, developed and verified against Cities: Skylines II as the reference target. Each plugin documents its own architecture and gotchas in its AGENTS.md (with a CLAUDE.md symlink).

Everything a plugin ships MUST live inside its plugins/<name>/ directory: marketplace installs copy only that subtree. New plugins get a sibling directory and an entry in both marketplace files.

Tech stack

• mise-en-place: dev tools, env vars and tasks.
• Bun workspaces: the root package.json carries lint/format tooling (oxfmt.config.ts, oxlint.config.ts), lefthook, and what scripts/ and bench/ import; the gameface mcp/ is the only workspace package, and bun.lock lives at the root. The root tsconfig types against Node, since the scripts share its program with the mcp; bench/ overrides that with its own nested tsconfig typing against Bun, which it runs on exclusively.
• .NET 10 SDK: the unity-devtools C# projects, grouped by agents-plugins.slnx at the repo root.

Repository structure

• .claude-plugin/marketplace.json and .agents/plugins/marketplace.json: the Claude Code and Codex CLI marketplace files. Both list every plugin.
• .mcp.json (root): LOCAL DEV ONLY, wiring both MCP servers for sessions in this repo (gameface from its committed bundle, unity from sources via dotnet run). Installed users get each plugin's own .mcp.json; keep them in sync when changing server wiring.
• scripts/: check-plugin-sync.ts (manifest consistency) and check-skill-content.ts (the cs2-modding shipped-prose rules), both part of mise check; check-skill-changelog.ts (mise skills:check-changelog, network-dependent, not in CI). hook-skill-content.ts is a PostToolUse hook spawning the shipped-prose lint on any edit under that plugin's skills/, so a broken warning block, link or marker fails at the edit rather than at the commit; it adds no rule of its own.
• .agents/hooks/check-line-length.ts: PostToolUse hook reporting .ts/.cs lines over 100 characters. Synced verbatim from the scrolls repo, which is why oxlint and oxfmt ignore .agents. Markdown is deliberately out of scope: these docs are agent-facing and unwrapped by design.
• docs/ROADMAP.md: planned facets. docs/solutions/: one file per hard-won problem, linked from where it bites. docs/adr/: numbered decision records.
• docs/authoring/: standing authoring contracts. The ticket template any spec's tickets take, pointed at from docs/agents/cantrips-loop.md's publish-tickets verb; and the cs2-modding reference pipeline's own — one shape doc per reference family and the reference-ticket protocol — disclosed out of the plugin's AGENTS.md because only an authoring pass reaches them. check-skill-content.ts enforces both families' prose-line budgets.
• docs/SOURCES.md: every source the cs2-modding pipeline may read, what each settles, and how to locate it. Other files point at it; keep it pointing at as few as possible.
• bench/: the skill-efficacy benchmark, measuring what the cs2-modding skill is worth against the same model without it. Its README.md holds the invocation contract and the question-file format; core.ts holds every decision and run.ts is a thin, deliberately untested shell.
• docs/research/: the cs2-modding pipeline's cited stage, sitting outside plugins/ so none of it ships. Its README.md holds the conventions a research file satisfies; nothing under plugins/ may reference it or SOURCES.md, and check-skill-content.ts fails any shipped link resolving outside the plugin directory, since existence alone passes one that works here and dead-ends for every installed user.