Concord

Modular overhauls for Minecraft's core systems.

Concord is a collection of independent Minecraft 1.21.1 Fabric mods, each overhauling exactly one vanilla system. Every mod is fully functional standalone; when siblings are installed together they detect each other and light up extra integration — never a hard dependency, never a shared jar.

Mod	Domain	Tagline	Status
Tribulation	Difficulty & scaling	"Survive what comes next."	Released
Meridian	Enchanting	"Chart your enchantments."	Released
Mercantile	Villagers & trade	"Every villager remembers."	Released
Prosperity	Loot & containers	"Every chest, yours to discover."	Released

Install any. Combine all.

What this repo is

Concord's single source of truth: the collection's vision, the suite-wide standards every member mod conforms to, and (eventually) the collection landing site served from docs/. Mod repos link to these documents — they never copy them.

Document	What it governs
VISION.md	The collective vision, narrative, integration matrix, per-mod and cross-cutting roadmaps
API-STANDARD.md	The public-API + event pattern every mod's api package follows
HUD-STANDARD.md	The shared HUD element spec: slots, stacking, visibility, coordination
REPO-LAYOUT.md	The common repository layout all mod repos mirror
design/REPO-SETTINGS.md	The GitHub-side settings standard every member repo carries — merge policy, branch protection, Actions permissions & secrets, Pages, security — with gh commands to apply and audit it; issue labels are reconciled automatically from labels.json
AGENTS-COMMON.md	The Concord-owned regions shared by every member's AGENTS.md (skills pointer, dev lifecycle, version scheme) — proposed to each member via the concord-sync PR by propagate.yml; edit shared agent guidance HERE
design/DESIGN-SYSTEM.md	Color tokens, per-mod palettes, typography, logo formula
design/VISION-GUIDE.md · DESIGN-GUIDE.md · SPEC-GUIDE.md · ASSETS-GUIDE.md	Authoring guides for the four fixed member docs under design/ — each prescribes its document's shape, requirements, and truth direction: the player-facing vision, the brand record, the behavioral contract, and the asset manifest
docs/tokens.css	The shared design tokens as consumable CSS — mod sites hot-link this
template/	The shared website template — mod repos hold only site/ content; CI builds and deploys via build-site.yml
members.json	The member registry — per-member status, conformance (layout migration), name/tagline/url, and store (Modrinth/CurseForge project id + slug); drives every site's cross-mod footer and the propagate workflow. The store ids are the canonical source for the publish (modrinth-id/curseforge-id) and listing-sync workflow inputs
labels.json	The shared issue-label manifest (name, color, description) — the suite lifecycle, integration, and triage labels; propagate.yml reconciles it onto every member via sync-labels.py (create missing, update drift, never delete). Edit HERE, never per-repo — see design/REPO-SETTINGS.md §6
site/	The collection landing site's content (same page schema as member sites, built by template/ and deployed by site.yml). status.json, pages/status.json, and the landing page's "suite status" section are generated by gen-status.py from members.json plus the public GitHub and Modrinth APIs — the nightly status workflow regenerates them, commits only when the data changed, and dispatches the site rebuild (make status runs the same generation locally)
propagate/	Canonical concord-owned files (currently the .github/ISSUE_TEMPLATE/ forms) proposed verbatim to every member repo via a concord-sync PR by propagate.yml (member default branches are protected) — edit HERE, never in a mod repo
.github/workflows/	Reusable CI for all members: mod-ci, mod-release, mod-build-artifact, mod-listing-sync, claude-review, claude-spec, claude-mention, build-site — mod repos carry only thin trigger stubs
workflow-stubs.json	The canonical caller-stub contract — for each member .github/workflows/*.yml stub, the reusable uses: ref and least-privilege permissions: block that must never drift. Enforced by check-workflow-stubs.py (make stubs-check locally, the scheduled stub-drift workflow in CI); a member's own on:/with: inputs are deliberately not compared
.ai/	Suite-default Claude prompts (code-reviewer, spec-writer) and review-criteria.yml — generic, mod identity comes from each repo's AGENTS.md. Resolution: explicit prompt-file/criteria-file workflow input → repo-local .ai/ file (whole-file override) → these defaults
.ai/skills/	Canonical mc-* domain skills for all member repos. Mod repos keep vendored copies (so Claude Code, Jules, and bare clones all work) and refresh them with make sync — edit skills HERE, never in a mod repo. The generated CATALOG.md (make catalog) indexes them — one row per skill, summary + when to read it — and rides the same sync, so each AGENTS.md points at it instead of carrying its own table
.ai/commands/	Canonical slash commands (/glyph, /sfx, /assess, /align, /implement) for all member repos — vendored by the same make sync target, surfaced to Claude Code via a .claude/commands → .ai/commands symlink. Edit HERE, never in a mod repo
.ai/agents/	Canonical sub-agents the /implement pipeline dispatches (recon, domain-reviewer, standards-reviewer, performance-reviewer), each pinning its own model. Surfaced via a .claude/agents → .ai/agents symlink. Vendored by make sync only — unlike skills and commands, these do not ride the concord-sync PR
makefile-targets.json	The canonical Makefile target contract — the thirteen universal targets with their exact recipes and help descriptions, plus coverage and run-datagen owed only where build.gradle wires them. Enforced by check-makefile-targets.py (make makefile-check locally, the scheduled makefile-drift workflow in CI); targets beyond the contract are a member's own business

The CI contract

The reusable workflows assume every member repo provides: repo name == mod id == jar prefix (build/libs/<mod>-<version>.jar), and gradle tasks build (compile + unit tests + jar), runGametest (JUnit XML at build/junit-gametest.xml), jacocoMergedReport (merged unit + gametest coverage XML at build/reports/jacoco/jacocoMergedReport/jacocoMergedReport.xml), and printVersion. verifyDatagenIdempotent runs where a member defines it and is skipped where it doesn't. Secrets per repo: CLAUDE_CODE_OAUTH_TOKEN (for the Claude workflows). Each mod repo's stubs declare only triggers, concurrency, and permissions — the stub bodies are documented at the top of each reusable workflow. The uses: ref and permissions: block each stub must carry are pinned in workflow-stubs.json; make stubs-check (and the weekly stub-drift workflow) flag any member stub that drifts from it — a widened token in particular, since the reusable workflows cap their own job tokens and a stub granting more is the sharp edge.

Syncing skills & commands

Skills and slash commands are edited in this repo and vendored into each mod repo. Propagation is automatic: when .ai/skills/** or .ai/commands/** change on master, propagate.yml stages the trees onto each member's concord-sync PR (scripts/open-sync-pr.py), mirroring the rsync -a --delete semantics below — concord-dropped files are removed and .ai/skills/.concord-rev is stamped with the source concord commit. Merging the PR adopts the change. make sync is the local convenience for working ahead of that PR — the standard member Makefile target (copy into new member repos):

CONCORD_DIR ?= ../concord

sync:
	@test -d $(CONCORD_DIR)/.ai/skills || { echo "concord checkout not found at $(CONCORD_DIR) (set CONCORD_DIR=...)"; exit 1; }
	rsync -a --delete $(CONCORD_DIR)/.ai/skills/ .ai/skills/
	rsync -a --delete $(CONCORD_DIR)/.ai/commands/ .ai/commands/
	rsync -a --delete $(CONCORD_DIR)/.ai/agents/ .ai/agents/
	@git -C $(CONCORD_DIR) rev-parse HEAD > .ai/skills/.concord-rev
	@echo "synced .ai/skills + .ai/commands + .ai/agents from concord @ $$(git -C $(CONCORD_DIR) rev-parse --short HEAD)"

This recipe is the canonical one in makefile-targets.json; make makefile-check holds every member to it.

.ai/skills/, .ai/commands/, and .ai/agents/ in a mod repo are wholly owned by the sync (--delete propagates removals); .concord-rev records provenance. The concord-sync PR carries the first two automatically; .ai/agents/ travels by make sync only. Claude Code loads them through .claude/skills → .ai/skills, .claude/commands → .ai/commands, and .claude/agents → .ai/agents symlinks, so the vendored skills, slash commands (like /glyph), and sub-agents work in every member repo. A repo needing a repo-local skill or command puts it outside the synced directory and wires the symlink accordingly.

How mod repos reference Concord

Each mod's AGENTS.md carries this section (and nothing more — content lives here):

## Suite standards (Concord)

This mod is a member of Concord, a modular collection of system overhauls. Suite-wide standards live in
the [concord repo](https://github.com/rfizzle/concord) — checked out at `../concord/`
in the local workspace. Normative for this repo:

- [API-STANDARD.md](https://github.com/rfizzle/concord/blob/master/API-STANDARD.md) — the `api` package conventions
- [HUD-STANDARD.md](https://github.com/rfizzle/concord/blob/master/HUD-STANDARD.md) — HUD slot, stacking, accessors
- [DESIGN-SYSTEM.md](https://github.com/rfizzle/concord/blob/master/design/DESIGN-SYSTEM.md) — palette, typography, logo rules
- [REPO-LAYOUT.md](https://github.com/rfizzle/concord/blob/master/REPO-LAYOUT.md) — where non-code files live

Conformance is declared, not copied: a mod states which suite standards it conforms to in its AGENTS.md rather than vendoring the standard text. The only mechanically consumed artifact is docs/tokens.css, which the mod websites hot-link once the Concord site is on Pages.

Shared AGENTS.md regions

Most of a member's AGENTS.md is mod-specific (overview, mod id, entrypoints, assets, compat, commit-scope examples) and stays repo-owned. But a few sections are byte-identical across every mod — the domain-skills pointer, the development lifecycle, and the version scheme. Those live once in AGENTS-COMMON.md, delimited by <!-- concord:NAME:start --> / <!-- concord:NAME:end --> markers, and propagate.yml opens a concord-sync PR rewriting the matching marked region in each member's AGENTS.md whenever the canonical copy changes (direct commits — issue templates and these regions alike — go through a PR because member default branches are protected). Only the marked regions move; prose outside them is never touched, and a repo that hasn't seeded the markers is skipped. To opt a repo in, paste the marker pairs around the corresponding sections once (or run make agents-sync locally against a sibling checkout). Edit shared agent guidance in AGENTS-COMMON.md, never in a mod repo.

What stays deliberately duplicated in each mod: the ~80 lines of HUD offset logic and the api package code itself. Concord rejects a shared runtime library on principle (see VISION.md §8.1) — convention over dependency, in standards as in code.

The principles (the reason this is a collection and not a modpack)

1. Independent gates — every mod works alone; cross-mod behavior is guarded by FabricLoader.getInstance().isModLoaded(...).
2. Siloed functionality — each mod owns exactly one vanilla system; no scope bleed.
3. Exposed public APIs — each mod publishes a stable, read-only-by-default com.rfizzle.<mod>.api package and event surface (see API-STANDARD.md).
4. Bounded by structure, not by purity — a mod overhauls its domain as deeply as that domain needs, free to deepen, replace, or run a system parallel to vanilla's; what it must not do is add a new dimension, require another mod to load, or break multiplayer fairness.