create-control-manifest skill

!bash "${CLAUDESKILLDIR}/../../hooks/yaml-helper.sh" resolve_config --keys automation

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.

Every AskUserQuestion call follows .claude/docs/automation-modes.md (collaborative asks always · guided major-only · autonomous logs and proceeds; automationalwaysask categories always prompt).

1. Load All Inputs

ADRs

Establish the denominator first. Glob docs/architecture/adr-.md. Call the count N**. If N is 0: "No ADRs found — run /architecture-decision before building a control manifest." Stop.

Resolve status without reading the ADRs — the filter must precede the read, not follow it:

Grep pattern="^## Status" glob="docs/architecture/adr-*.md" output_mode="content" -A 3

Interpret against N:

• Note the ADR number and title for every rule sourced.

Project Config

empty, fall back to .claude/docs/technical-preferences.md

• Read naming. and performance. from project.yaml; for any key absent or

.claude/docs/technical-preferences.md (not migrated to project.yaml)

• Read approved libraries/addons and forbidden patterns from

Engine Reference

forbidden API entries

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

• 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

Read only these four sections per Accepted ADR — not the whole file. Context, Consequences, Migration Plan and Validation Criteria explain why a decision was made; the manifest records what to do, so they are not needed here:

Grep pattern="^## (Decision|Alternatives Considered|Performance Implications|Engine Compatibility)" glob="docs/architecture/adr-*.md" output_mode="content" -A 30

Filter the results to the Accepted set A resolved above. If a section is absent for a given ADR, note it per ADR and continue; if a section is absent across all of A, report "No Accepted ADR contains a [section] section — the manifest's [category] rules will be empty. Verify this is intended." Escalate to a full read of one ADR only when its scanned sections cross-reference material outside them (e.g. a Decision that says "subject to the constraints in Context").

For each Accepted ADR, extract:

Required Patterns (from the ## Decision section)

— including any ### Implementation Guidelines sub-heading when the ADR has one (newer ADRs emit it; older ones state mandates directly in ## Decision). Never scan for ### Implementation Guidelines alone — it is absent from many skill-authored ADRs, and scanning for it yields an empty Required Patterns section on a manifest that should have been full.

• Every "must", "should", "required to", "always" statement in the Decision body

• Every specific pattern or approach mandated

Forbidden Approaches (from "Alternatives Considered" sections)

the rule ("never use X because Y")

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

• 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 project config (project.yaml, else technical-preferences.md):

• Naming conventions — naming.*: classes, variables, signals/events, files, constants
• Performance budgets — performance.*: target framerate, frame budget, draw call limits, memory ceiling

From deprecated-apis.md:

project**. Do not copy the deprecation table wholesale.

• Deprecated APIs → Forbidden API entries, **filtered for relevance to this

Each entry must apply to what this project actually builds. deprecated-apis.md

mixes dimensions and subsystems: its GodotPhysics3D → Jolt Physics 3D row is

3D-only, so emitting it unqualified gives a 2D project a global rule about

a physics engine it never uses. If you cannot tell whether an entry applies —

2D vs 3D, a module the project does not include — either scope the rule

("when using 3D physics: ...") or omit it and note it as unresolved. A manifest

of rules that do not apply is one nobody reads, and /create-stories consumes

this file.

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