Workflow 1.0 · Process

Establish reliable truth, then change it deliberately.

The baseline creates enough approved structure for a module to enter production. The continuous loop keeps creative work alive and routes each approved change back through the level that owns it.

System one

Initial Baseline

Readiness is assessed per module. A ready module may move to implementation while unrelated modules remain in requirements or slicing.

00Idea WorkspacePersistent, exploratory and never closed.
Workspace
Persistent ChatGPT chat
Active role
Creator + normal ChatGPT
Reasoning
Normal conversational
Authoritative input
None required; creative evidence may inform discussion
Authoritative output
Creator-approved Idea-Brief.md
Gate
Creator approval

Core activity: open-ended brainstorming, exploration, rejection and refinement. Material remains non-authoritative until approved.

Return condition: any new mechanic, content idea, presentation thought, experiment or refinement.

Related prompts
01Game Design WorkspaceTurn an approved idea into architecture-ready design.
Workspace
Persistent ChatGPT Work chat
Agent
Design Agent
Reasoning
High
Input
Approved Idea-Brief.md
Output
Game-Design-Brief.md
Gate
Creator approval

Return condition: future changes affecting game-level design.

Related prompts
BGame Design BibleInitialise once; maintain whenever approved design truth changes.

Agent: Bible Maintenance Agent. A dedicated persistent chat is not required by default. It receives approved design truth and maintains authoritative homes without requiring every future content item before implementation.

Nine Bible areas
  1. Game Identity
  2. Player Experience
  3. Game Structure
  4. Core Logic Reference
  5. Content
  6. Design Data Library
  7. Progression and Economy
  8. Presentation
  9. Reference
Related prompts
02Architecture WorkspaceDerive capability boundaries from approved design.
Workspace
Persistent ChatGPT Work chat
Agent
Architecture Agent
Reasoning
Extra High
Inputs
Game Design Brief + relevant Bible truth
Outputs
Architecture.md + Module-Map.md
Gate
Architecture review + creator approval

Reasoning progression: Required Capabilities → Responsibilities → State Authority → Relationships → Dependency Direction → Architecture → Module Boundaries.

Return condition: capabilities, ownership, state authority, dependencies, persistence or major relationships change.

03Module WorkspacesOne module. One Work chat. Two specialist phases.
Phase A · Module Agent

Resolve the module

Receives Architecture, its Module Map entry and relevant Bible truth. Defines responsibilities, exclusions, behaviour, state, contracts, configuration, failure handling and dependencies. Produces creator-approved Module Requirements.

Stop: slicing cannot begin while material requirements remain unresolved.

Phase B · Slice Agent

Define delivery boundaries

Activates in the same Work chat after Module approval. Produces the complete Slice Map and every required Slice specification as coherent, dependency-aware, testable units owned by this module.

Boundary: no separate task-list document.

SSlice SpecificationsSpecify what must be true; Codex later plans how.

Each Slice belongs to its owning module. It records required result, scope, behaviour, dependencies, constraints and acceptance evidence. It may integrate through approved contracts without becoming cross-module-owned.

Gate: every currently required Slice specification is complete and creator-approved.

Per-module gate

Module Implementation Readiness

A ready module is not blocked by incomplete unrelated modules. Confirm every condition for the module moving to production.

Readiness checklist
Repository reality

Module Readiness and Implementation

CCodex Module WorkspaceOne persistent implementation chat per module.

Codex receives repository AGENTS.md, repository reality, relevant Architecture, parent Module Requirements, the current Slice specification and only the additional authoritative context required.

  1. Inspect
  2. Plan
  3. Implement
  4. Test
  5. Self-Validate
  6. Independent Validation
  7. Checkpoint

Codex creates the technical implementation plan only after inspecting what currently exists. The retained chat handles every Slice owned by that module and later implementation changes.

Validation outcomes

Pass

Create the planned checkpoint and continue.

Pass With Deviations

Record deviations; decide whether documentation or implementation changes.

Fail

Return to implementation, correct and retest.

Blocked

Return to the workflow level owning unclear or conflicting truth.

Validate completed Slices, completed Modules, significant integrations, architecture-sensitive changes, important prototypes and milestones. Module completion also checks that its Slices form a coherent implementation of the full Module Requirements.

System two

Continuous Creative Development

The Idea Workspace never closes. New mechanics, content, refinements, alternatives, presentation changes, progression changes, playtest findings and additional systems can be explored at any time. They remain non-authoritative until creator-approved.

Change Propagation

Travel upward only as far as necessary, then propagate approved change through every affected downstream level.
Content or data only

Update authoritative content or data → implementation update if required → validation.

Existing module affected

Bible → existing Module Workspace → Module Agent if requirements change → Slice Agent if delivery changes → existing Codex Workspace → validation.

Architecture affected

Bible → Architecture Workspace → Architecture and Module Map update → affected Module Workspaces → Slice updates → Codex → validation.

New modules

A new feature returns to Architecture. Only Architecture approval determines whether it belongs to an existing module, changes responsibilities, requires restructuring or genuinely justifies a new Module Workspace.

Existing modules and Slices

A fundamental module change returns to its retained Work chat with the Module Agent active. A slicing-only change activates the Slice Agent directly. Revised approved specifications propagate to the existing Codex module workspace; historical chat remains subordinate to current documents.

Safe concurrent implementation

Separate Codex module chats may work concurrently only when ownership, contracts and collision risk are controlled.

Can these modules run concurrently?
!Common collision areasKeep these changes sequential.

Shared source files, interfaces, application bootstrap, Unity scenes, global UI composition, project settings, package manifests, save schemas, shared ScriptableObject assets and cross-module integration tests.

Cross-module ownership

  1. Module A reports the dependency.
  2. The workflow identifies the owning truth.
  3. Module B’s Work chat updates requirements or Slices if needed.
  4. Module B’s Codex chat implements its owned change.
  5. Integration is validated when both sides are ready.

When work is genuinely integration-owned, create an explicitly owned integration Slice.

Sequential merge model

Validate and merge Module A → update Module B from that baseline → resolve and validate Module B → merge Module B → run integration validation.

Returning to Existing Work

  1. Locate current authoritative project status.
  2. Identify the owning module and affected Slice.
  3. Open the retained Module Work chat for reasoning or specification changes.
  4. Open the retained Codex module chat for implementation changes.
  5. Retrieve current authoritative context.
  6. Inspect repository reality.
  7. Report current position and recommended next action.
  8. Continue only from an approved boundary.