Reviews Hedron changes against the architecture invariant checklist. Runs in two modes — spec-review (an implementation plan, before implementation) and code-review (a diff, before merge). Use spec mode after implementation-planner and before implement-plan; use code mode after any PR-sized change to Core/ and before…
Turns a new gameplay idea into a docs/implementation-plans/ file and a concrete implementation plan (components, systems, handlers, events, commands, dependencies). Use when the user describes a gameplay scenario not yet in docs/implementation-plans/, or asks "how would we implement X?".
Use when adding a new entity archetype (e.g. Portal, Trigger, Mount, NPC variant) or when the user asks "what archetype should this be?". Archetypes are validation + detection, not construction — covers the enum entry, ArchetypeDefinition, registry wiring, and doc updates. Invoke when introducing a new gameplay entity…
Use when adding a new player or admin command (wear, drink, cast, craft, buy, etc.). Covers the ICommand shape, argument schema, privilege declaration, output via IOutputWriter, and how it connects to the dispatcher and event pipeline. Invoke when the user asks to add a command, wire up a verb, or extend the command…
Use when adding a new ECS component. Handles file placement (shared vs feature-owned), shape of the component class, registration on archetypes, and updating docs/reference/components.md. Invoke when the user asks to add a component, extract state into a component, or split an existing component.
Use when adding a core system (DiceSystem, TimeSystem, SkillSystem, etc.) at Core/Systems/ — cross-cutting utilities that multiple domains depend on. Covers the rule that core systems cannot depend on domain systems, and the shape of pure, reusable logic. Invoke when the user asks to add a shared helper system or…
Use when adding a new domain (feature) system under Core/Modules/ /Systems/. Covers interface-first shape, dependency rules (domain-on-core fine; same-or-lower-level domain-on-domain direct calls permitted; peer/lateral coordination prefers events), pure-result pattern, and registration. Invoke when the user asks to…
Use when adding a new event type to the event bus. Covers naming (past tense, specific), payload shape (thin vs enriched), where to publish, and who subscribes. Invoke when the user asks to add an event, fire a signal, or wire up a cross-cutting notification.
Use when adding a new handler or splitting an existing one. Covers responsibilities (orchestration only), priority choice, subscription registration, and the rule that handlers call systems and publish events but never contain domain logic. Invoke when the user asks to add a handler, route an event, or orchestrate a…
Use when writing or updating automated tests for a Hedron slice — covering a system's decision, a handler's orchestration, a use-case flow, a persistence round-trip, or an architecture invariant. Covers which tier to use, the shared test harness, the test-vs-skip rubric, and a worked example per tier. Invoke when…
Use BEFORE the implementation-planner when a net-new feature or a non-trivial change needs higher-tier architectural framing — where the seam belongs, what existing/planned feature family it is an instance of, and which future concerns to design for now. The interactive, forward-looking counterpart to…
Use when changing any balance number or balance-affecting mechanic — tuning oracle weights/bands, progression curves, combat/regen/economy constants, the balance-standards document, or when a slice adds a new power source, a new tunable knob, or content that must land in a (Tier, Band) cell. Covers where every knob…
Use when adding or tuning an experience/advancement source, adjusting progression curves or anti-grind, adding a progression track, or generalizing XP triggers to a rule table. Covers the three-layer extensibility model — mechanism (handler-on-event), tuning (constants→YAML), generalization (rule registry at ≥3…
Use when implementing a full gameplay use case end-to-end (shop purchase, combat pulse, crafting, etc.). Translates an implementation plan into the concrete set of components/systems/handlers/events needed, and sequences the work so each piece is independently testable. Invoke when the user picks a use case to build…
Use when creating, updating, moving, or trimming any Hedron documentation — feature docs, per-system design docs, runtime flows/journeys, reference catalogs, implementation plans, or roadmap/completed records. Covers the doc taxonomy (where each fact lives), which template to use, the disintegrate-on-ship plan…
Use FIRST — before the architecture-advisor (/advise) and the implementation-planner (/new-plan) — whenever the user brings a high-level, low-detail outcome that needs fleshing out into concrete requirements. An interactive requirements-gathering intake, it grounds the idea in the existing docs (features, design…
Use after a slice merges (or before a PR is created) to keep plan.md, done.md, and completed/ in sync with the implemented state, and to disintegrate the slice's implementation plan into the living docs. Run on any PR that completes a slice.
The command framework sits between the session transport and the domain layer. A raw input line in → a resolved, authorized, argument-parsed command execution out. No command body ever calls session.SendLineAsync or branches on verb strings — INV-11.