ksh999000/Claude-Code-Game-Studios
1
0
Fork 0
mirror of https://github.com/Donchitos/Claude-Code-Game-Studios.git synced 2026-10-16 01:37:05 +00:00
Code Issues Packages Projects Releases Wiki Activity

Release 1.1.2 — the default path works end to end

Browse Source 
Fix release for 1.1.1: the minimal path end to end, engine commands that
run on Godot, Unity and Unreal, hook warnings you can see, and verdicts
that say when they could not check. Details in CHANGELOG.md; upgrade
steps in UPGRADING.md (v1.1.1 → v1.1.2).

Fixes #67
Fixes #131

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01WuJn2FdynEybfL5KC697nJ
This commit is contained in:
Donchitos
2026-09-29 21:32:19 +10:00
co-authored by Claude Opus 5.5
parent 7ed2c3e9c4
commit b21fa0f7f2
383 changed files with 22888 additions and 10618 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.claude/skills/design-review/SKILL.md
+29 -19
View File
@@ -9,8 +9,11 @@ model: sonnet
!`bash "${CLAUDE_SKILL_DIR}/../../hooks/yaml-helper.sh" resolve_config --keys review_mode,automation,workflow,system_overrides`
Resolved above — use as-is; `--review` overrides `review_mode`. No block →
defaults in `.claude/docs/config-resolution.md`.
Resolved above — use as-is; `--review` overrides `review_mode`. `--depth` is
the pre-1.1 name for the same flag: treat `--depth <mode>` exactly as
`--review <mode>`, and say once that it was renamed. Given both, `--review`
wins and `--depth` is ignored — say so. No block → defaults in
`.claude/docs/config-resolution.md`.
## Phase 0: Parse Arguments
@@ -45,7 +48,7 @@ Resolved mode controls how thorough this review is:
## Phase 1: Load Documents
**Freshness check first — a re-review of an unchanged document costs full
price (~46k tokens, measured) and reproduces the same verdict.** Run:
price and reproduces the same verdict.** Run:
```
Bash: bash .claude/scripts/review-receipts.sh check "design/gdd/reviews/[doc-name]-review-log.md" "[target-doc-path]" "design/registry/entities.yaml"
@@ -73,13 +76,9 @@ appear in the output and doesn't block the skip).
escalate to a full re-review only if a conflict appears.
- **Target doc `CHANGED` or `NEW`, or `RECEIPT: NONE`** — proceed with the
full review below. **Do not offer a partial/delta re-review that skips
reading or re-analyzing unchanged sections.** Measured against a full review:
three independent designs (a straightforward section-scoped pass, one with
an explicit forced whole-document scan step, and one gated on a
genuinely thorough two-round prior review) each caught only 2 of 6 real
defects a full review found on the same document, and the most
careful version cost *more* tokens than the full review while catching
the same reduced fraction. "Unchanged since last review" only means
reading or re-analyzing unchanged sections.** A section-scoped re-review
misses defects a full review finds, and saves little or nothing.
"Unchanged since last review" only means
byte-identical to what was reviewed then — it says nothing about whether
that prior pass was itself complete, and no amount of "scan everything
anyway" instruction reliably overcame a model's attention naturally
@@ -109,7 +108,7 @@ everything "implied". Do not glob-read all of `design/gdd/`.
**Dependency graph validation:** For every system listed in the Dependencies section, use Glob to check whether its GDD file exists in `design/gdd/`. Flag any that don't exist yet — these are broken references that downstream authors will hit.
**Lore/narrative alignment:** If `design/gdd/game-concept.md` or any file in `design/narrative/` exists, read it. Note any mechanical choices in this GDD that contradict established world rules, tone, or design pillars. Pass this context to `game-designer` in Phase 3b.
**Lore/narrative alignment:** If `design/gdd/game-concept.md` (or, at `rigor: minimal`, the one-page brief `design/game-brief.md`) or any file in `design/narrative/` exists, read it. Note any mechanical choices in this GDD that contradict established world rules, tone, or design pillars. Pass this context to `game-designer` in Phase 3b.
**Prior review check:** Check whether `design/gdd/reviews/[doc-name]-review-log.md` exists. If it does, read the most recent entry — note what verdict was given and what blocking items were listed. This session is a re-review; track whether prior items were addressed.
@@ -159,6 +158,11 @@ spot-read any section the verdict actually turns on.
- Are the rules precise enough for a programmer to implement without guessing?
- Are there any "hand-wave" sections where details are missing?
- Are performance implications considered?
- Is every acceptance criterion independently testable? Flag each one that is
not, quoting it — "feels balanced", "works correctly", "performs well" are not
criteria — with a measurable rewrite. In `full` mode `qa-lead` also checks them
(Phase 3b); in `lean` and `solo` no specialist runs, so this main-review check
is the only one.
**Cross-system consistency:**
- Does this conflict with any existing mechanic?
@@ -230,8 +234,8 @@ Issue all `Agent` calls simultaneously. Do NOT spawn one at a time.
After all specialists respond, spawn `creative-director` as the **senior reviewer**:
- Provide: the GDD, all specialist findings, any disagreements between them
- Ask: "Synthesise these findings. What are the most important issues? Do you agree with the specialists? What is your overall verdict on this design?"
- The creative-director's synthesis becomes the **final verdict** in Phase 4.
- Ask: "Synthesise these findings. What are the most important issues? Do you agree with the specialists? What is your overall verdict on this design — APPROVED, NEEDS REVISION or MAJOR REVISION NEEDED?"
- The creative-director's synthesis becomes the **final verdict** in Phase 4, in this skill's verdict words — never a director-gate word such as READY or REJECT.
### Step 4 — Surface disagreements
@@ -319,10 +323,16 @@ Use `AskUserQuestion` for ALL closing interactions. Never plain text.
If APPROVED (first-pass, no revision needed), proceed directly to the systems-index widget, review-log widget, then the final closing widget. Do not show a separate "what to do" widget — the final closing widget covers next steps.
If NEEDS REVISION or MAJOR REVISION NEEDED, options:
If NOT ASSESSED, nothing was reviewed: offer no tracking update and go straight
to the final closing widget, leading with the skill that produces the missing
input (e.g. `/design-system [system]` for a GDD that does not exist).
If NEEDS REVISION or MAJOR REVISION NEEDED, build the options from the findings:
- `[A] Revise the GDD now — address blocking items together`
- `[B] Stop here — revise in a separate session`
- `[C] Accept as-is and move on (only if all items are advisory)`
- `[C] Accept as-is and move on` — include only when every finding is advisory
(Required Before Implementation is empty). With any blocking item, offer [A]
and [B] only.
**If user selects [A] — Revise now:**
@@ -334,7 +344,7 @@ After all revisions are complete, show a summary table (blocker → fix applied)
- Note current context usage: if context is above ~50%, add: "(Recommended: /clear before re-review — this session has used X% context. A full re-review runs 5 agents and needs clean context.)"
- Options:
- `[A] Re-review in a new session — run /design-review [doc-path] after /clear`
- `[B] Accept revisions and mark Approved — update systems index, skip re-review`
- `[B] Accept revisions for now — mark In Review in the systems index; a re-review decides Approved`
- `[C] Move to next system — /design-system [next-system] (#N in design order)`
- `[D] Stop here`
@@ -355,7 +365,7 @@ If the review-log option is selected, append the same format as below. Execute b
When the verdict is NEEDS REVISION or MAJOR REVISION NEEDED, use separate widgets as before:
Use a second `AskUserQuestion`:
- Prompt: "May I update `design/gdd/systems-index.md` to mark [system] as [In Review / Approved]?"
- Prompt: "May I update `design/gdd/systems-index.md` to mark [system] as [Needs Revision / In Review]?" — `Needs Revision` (that exact string) while the revisions are outstanding, `In Review` once they are applied and await re-review. This prompt never offers `Approved`: a revision verdict is not an approval.
- Options: `[A] Yes — update it` / `[B] No — leave it as-is`
Use a third `AskUserQuestion`:
@@ -397,12 +407,12 @@ verbatim).
Once the systems-index and review-log widgets are answered, check project state and show one final `AskUserQuestion`:
Before building options, read:
- `design/gdd/systems-index.md` — find any system with Status: In Review or NEEDS REVISION (other than the one just reviewed)
- `design/gdd/systems-index.md` — find any system with Status: In Review or Needs Revision (other than the one just reviewed)
- Count `.md` files in `design/gdd/` (excluding game-concept.md, systems-index.md) to determine if `/review-all-gdds` is worth offering (≥2 GDDs)
- Find the next system with Status: Not Started in design order
Build the option list dynamically — only include options that are genuinely next:
- `[_] Run /design-review [other-gdd-path] — [system name] is still [In Review / NEEDS REVISION]` (include if another GDD needs review)
- `[_] Run /design-review [other-gdd-path] — [system name] is still [In Review / Needs Revision]` (include if another GDD needs review)
- `[_] Run /consistency-check — verify this GDD's values don't conflict with existing GDDs` (always include if ≥1 other GDD exists)
- `[_] Run /review-all-gdds — holistic design-theory review across all designed systems` (include if ≥2 GDDs exist)
- `[_] Run /design-system [next-system] — next in design order` (always include, name the actual system)