mirror of
https://github.com/Donchitos/Claude-Code-Game-Studios.git
synced 2026-10-16 09:58:36 +00:00
Release 1.1.0 — one config file, and a process weight you choose
`project.yaml` at the repo root is now the single source of truth for a project's configuration, replacing `production/stage.txt`, `production/review-mode.txt` and `.claude/docs/technical-preferences.md` (all three still read as a fallback; nothing is force-deleted). **`modes.rigor` — one question instead of six.** `minimal`, `standard` or `full` fronts six knobs: `modes.workflow`, `docs.density`, `qa.level`, `modes.story_granularity`, `modes.review_mode` and `team.size`. It defaults to `minimal`, which is a change from 1.0's behaviour: the heavier tier was measured costing several times more to reach working code without producing a better result, and returning nothing when a fresh developer inherited the project. Pin `modes.rigor: standard` to keep 1.0's process level. Also in this release: - `/settings` to view or change any setting, and `project.local.yaml` for per-developer preferences that should not be committed. - `system_overrides` to hold one system to a higher standard than the rest of the project, and `testing.strict` to set per test type whether missing evidence blocks a story or warns. - A story that changes anything the player sees is not closed until the game has been launched, observed, and a screenshot retained in `production/qa/evidence/`. A parse check is not a run. This holds at every rigor level, including `minimal`, where automated tests are waived but the look is not. - The code root is engine-specific and enforced as such: Godot `src/`, Unity `Assets/`, Unreal `Source/<Module>/`. Two of the three will not build a project laid out any other way. - Migration tooling for existing projects: `.claude/scripts/migrate-v1-config.sh` converts a 1.0 layout, non-destructively by default, with a report to review before `--finalize` deletes anything. - Ask-before-write holds regardless of personal automation settings. Upgrading from 1.0 or earlier: see UPGRADING.md. Full list of changes: CHANGELOG.md. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_016xvzG3i7pWQg4LjyDwWMXd
This commit is contained in:
co-authored by
Claude Opus 5
parent
984023ddac
commit
d05699707f
@@ -1,11 +1,48 @@
|
||||
---
|
||||
name: balance-check
|
||||
description: "Analyzes game balance data files, formulas, and configuration to identify outliers, broken progressions, degenerate strategies, and economy imbalances. Use after modifying any balance-related data or design. Use when user says 'balance report', 'check game balance', 'run a balance check'."
|
||||
description: "Find balance outliers, broken progressions, degenerate strategies, economy imbalances in formulas and data. 'Check game balance'."
|
||||
argument-hint: "[system-name|path-to-data-file]"
|
||||
user-invocable: true
|
||||
allowed-tools: Read, Glob, Grep, Write, AskUserQuestion
|
||||
model: sonnet
|
||||
agent: economy-designer
|
||||
---
|
||||
|
||||
!`source "${CLAUDE_PROJECT_DIR:-.}/.claude/hooks/yaml-helper.sh" 2>/dev/null && resolve_config --keys automation`
|
||||
|
||||
|
||||
|
||||
Every `AskUserQuestion` call follows `.claude/docs/automation-modes.md`
|
||||
(collaborative asks always · guided major-only · autonomous logs and proceeds;
|
||||
`automation_always_ask` categories always prompt).
|
||||
|
||||
## Insufficient input — check this before producing any report
|
||||
|
||||
**If the inputs this skill needs do not exist, the answer is "could not run" —
|
||||
not a filled-in report.** Check first, and stop if the check fails.
|
||||
|
||||
1. List the inputs this skill reads (data files, prior reports, profiler output,
|
||||
test results, registries, source code).
|
||||
2. For each, record `FOUND` or `ABSENT` — not "assumed present".
|
||||
3. If any input required for a section is ABSENT, that section is
|
||||
**`NOT ASSESSED — NO DATA`**. Do not estimate it, do not infer it from an
|
||||
adjacent artifact, and do not leave a mandated cell to be filled by whoever
|
||||
reads the template next.
|
||||
4. If **every** required input is ABSENT, stop and report
|
||||
**`NOT ASSESSED — NO DATA`** as the whole verdict, naming what was missing and
|
||||
which skill produces it.
|
||||
|
||||
**A verdict of `NOT ASSESSED` is a success.** It is the correct, useful answer to
|
||||
"what does the data say?" when there is no data. The failure mode this prevents is
|
||||
specific and has been observed in practice: report templates whose verdict
|
||||
enum had no "could not run" state produced **false clean passes** — an asset audit
|
||||
returning COMPLIANT on a project with no assets and no standards, and a
|
||||
performance profile reporting ">99% headroom against a 16.67ms budget" with zero
|
||||
profiler data and no budget ever set.
|
||||
|
||||
**Absence of evidence is never evidence of absence.** A scan that finds no
|
||||
matches because there are no files to scan has not verified anything. Say which of
|
||||
the two happened — a reader cannot tell from a green result.
|
||||
|
||||
---
|
||||
|
||||
## Phase 1: Identify Balance Domain
|
||||
@@ -31,8 +68,22 @@ Note every file read — they will appear in the Data Sources section of the rep
|
||||
|
||||
## Phase 3: Read Design Document
|
||||
|
||||
Read the GDD for the system from `design/gdd/` to understand intended design targets,
|
||||
tuning knobs, and expected value ranges. This is the baseline for "correct" behaviour.
|
||||
**Registry first.** If `design/registry/entities.yaml` exists, read it before the
|
||||
GDD. Its `constants` and `formulas` sections hold the cross-GDD named values and
|
||||
output ranges — the balance targets — already distilled, each with a `source:`
|
||||
GDD and any `revised:` date:
|
||||
```
|
||||
Grep pattern="^ - name:" path="design/registry/entities.yaml" output_mode="content" -A 6
|
||||
```
|
||||
Take the intended values from the registry for any constant or formula it lists
|
||||
(the `constants:` and `formulas:` blocks); these are the authoritative cross-doc
|
||||
figures a GDD must not contradict. **If `design/registry/entities.yaml` does not
|
||||
exist or has no entries** (it ships as an empty stub until `/design-system`
|
||||
populates it), skip this and use the GDD alone.
|
||||
|
||||
Then read the GDD for the system from `design/gdd/` to understand intended design
|
||||
targets, tuning knobs, and expected value ranges — for anything the registry did
|
||||
not already supply. This is the baseline for "correct" behaviour.
|
||||
|
||||
---
|
||||
|
||||
@@ -77,7 +128,7 @@ Run domain-specific checks:
|
||||
### Data Sources Analyzed
|
||||
- [List of files read]
|
||||
|
||||
### Health Summary: [HEALTHY / CONCERNS / CRITICAL ISSUES]
|
||||
### Health Summary: [NOT ASSESSED / HEALTHY / CONCERNS / CRITICAL ISSUES]
|
||||
|
||||
### Outliers Detected
|
||||
| Item/Value | Expected Range | Actual | Issue |
|
||||
|
||||
Reference in New Issue
Block a user