/create-control-manifest

name: create-control-manifest
description: "After architecture is complete, produces a flat actionable rules sheet for programmers — what you must do, what you must never do, per system and per layer. Extracted from all Accepted ADRs, technical preferences, and engine reference docs. More immediately actionable than ADRs (which explain why)."
argument-hint: "[update — regenerate from current ADRs]"
user-invocable: true
allowed-tools: Read, Glob, Grep, Write, Task
model: sonnet
agent: technical-director

Create Control Manifest

The Control Manifest is a flat, actionable rules sheet for programmers. It answers "what do I do?" and "what must I never do?" — organized by architectural layer, extracted from all Accepted ADRs, technical preferences, and engine reference docs. Where ADRs explain *why*, the manifest tells you *what*.

**Output:** `docs/architecture/control-manifest.md`

**When to run:** After `/architecture-review` passes and ADRs are in Accepted status. Re-run whenever new ADRs are accepted or existing ADRs are revised.

---

1. Load All Inputs

ADRs

• Glob `docs/architecture/adr-*.md` and read every file
• Filter to only Accepted ADRs (Status: Accepted) — skip Proposed, Deprecated,

Superseded

• Note the ADR number and title for every rule sourced

Technical Preferences

• Read `.claude/docs/technical-preferences.md`
• Extract: naming conventions, performance budgets, approved libraries/addons,

forbidden patterns

Engine Reference

• Read `docs/engine-reference/[engine]/VERSION.md` for engine + version
• Read `docs/engine-reference/[engine]/deprecated-apis.md` — these become

forbidden API entries

• Read `docs/engine-reference/[engine]/current-best-practices.md` if it exists

Report: "Loaded [N] Accepted ADRs, engine: [name + version]."

---

2. Extract Rules from Each ADR

For each Accepted ADR, extract:

Required Patterns (from "Implementation Guidelines" section)

• Every "must", "should", "required to", "always" statement
• Every specific pattern or approach mandated

Forbidden Approaches (from "Alternatives Considered" sections)

• Every alternative that was explicitly rejected — *why* it was rejected becomes

the rule ("never use X because Y")

• Any anti-patterns explicitly called out

Performance Guardrails (from "Performance Implications" section)

• Budget constraints: "max N ms per frame for this system"
• Memory limits: "this system must not exceed N MB"

Engine API Constraints (from "Engine Compatibility" section)

• Post-cutoff APIs that require verification
• Verified behaviours that differ from default LLM assumptions
• API fields or methods that behave differently in the pinned engine version

Layer Classification

Classify each rule by the architectural layer of the system it governs:

• **Foundation**: Scene management, event architecture, save/load, engine init
• **Core**: Core gameplay loops, main player systems, physics/collision
• **Feature**: Secondary systems, secondary mechanics, AI
• **Presentation**: Rendering, audio, UI, VFX, shaders

If an ADR spans multiple layers, duplicate the rule into each relevant layer.

---

3. Add Global Rules

Combine rules that apply to all layers:

From technical-preferences.md:

• Naming conventions (classes, variables, signals/events, files, constants)
• Performance budgets (target framerate, frame budget, draw call limits, memory ceiling)

From deprecated-apis.md:

• All deprecated APIs → Forbidden API entries

From current-best-practices.md (if available):

• Engine-recommended patterns → Required entries

From technical-preferences.md forbidden patterns:

• Copy any "Forbidden Patterns" entries directly

---

4. Present Rules Summary Before Writing

Before writing the manifest, present a summary to the user:

## Control Manifest Preview
Engine: [name + version]
ADRs covered: [list ADR numbers]
Total rules extracted:
  - Foundation layer: [N] required, [M] forbidden, [P] guardrails
  - Core layer: [N] required, [M] forbidden, [P] guardrails
  - Feature layer: ...
  - Presentation layer: ...
  - Global: [N] naming conventions, [M] forbidden APIs, [P] approved libraries

Use `AskUserQuestion`:

• Prompt: "Does this rule summary look complete?"
• Options:
• `[A] Yes — looks good, run the director review and write the manifest`
• `[B] Add rules — I have additional rules to include before writing`
• `[C] Remove rules — some extracted rules should be dropped`
• `[D] Stop here — I need to review the ADRs first`

---

4b. Director Gate — Technical Review

**Review mode check** — apply before spawning TD-MANIFEST:

• `solo` → skip. Note: "TD-MANIFEST skipped — Solo mode." Proceed to Phase 5.
• `lean` → skip. Note: "TD-MANIFEST skipped — Lean mode." Proceed to Phase 5.
• `full` → spawn as normal.

Spawn `technical-director` via Task using gate **TD-MANIFEST** (`.claude/docs/director-gates.md`).

Pass: the Control Manifest Preview from Phase 4 (rule counts per layer, full extracted rule list), the list of ADRs covered, engine version, and any rules sourced from technical-preferences.md or engine reference docs.

The technical-director reviews whether:

• All mandatory ADR patterns are captured and accurately stated
• Forbidden approaches are complete and correctly attributed
• No rules were added that lack a source ADR or preference document
• Performance guardrails are consistent with the ADR constraints

Apply the verdict:

• **APPROVE** → proceed to Phase 5
• **CONCERNS** → surface via `AskUserQuestion` with options: `Revise flagged rules` / `Accept and proceed` / `Discuss further`
• **REJECT** → do not write the manifest; fix the flagged rules and re-present the summary

---

5. Write the Control Manifest

Use `AskUserQuestion`:

• Prompt: "May I write the Control Manifest?"
• Options:
• `[A] Yes — write to docs/architecture/control-manifest.md`
• `[B] Show me the full draft first, then ask again`
• `[C] Not yet — I want to make more chan