mirror of
https://github.com/Donchitos/Claude-Code-Game-Studios.git
synced 2026-10-16 01:37:05 +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:
Donchitos
co-authored by
Claude Opus 5
Claude Opus 5
parent
984023ddac
commit
d05699707f
@@ -0,0 +1,120 @@
|
||||
# Settings Guidance — which value to recommend, and when
|
||||
|
||||
The **advisory** layer for project settings. This doc answers two questions no
|
||||
other doc does:
|
||||
|
||||
1. **Which value should a skill recommend** for a given project or user?
|
||||
2. **When should a skill proactively suggest changing** a setting already set?
|
||||
|
||||
## Boundary with its siblings — do not duplicate their content here
|
||||
|
||||
| Doc | Answers | Nature |
|
||||
|---|---|---|
|
||||
| `effects-map.md` | What each setting *does* | Descriptive |
|
||||
| `config-resolution.md` | How a setting *resolves* (precedence chain) | Mechanical |
|
||||
| **`settings-guidance.md`** (this file) | Which value to *recommend*, and *when* | Prescriptive |
|
||||
|
||||
Skills reference this doc **on demand**, only at a "recommend a setting" moment.
|
||||
It is deliberately **not** a CLAUDE.md import — advisory content must not ride in
|
||||
per-turn context (the same reason `context-management.md` was demoted).
|
||||
|
||||
---
|
||||
|
||||
## 1. The knob that matters most: `modes.rigor`
|
||||
|
||||
Almost every "what settings should I use?" question reduces to one choice:
|
||||
`modes.rigor` (`minimal` | `standard` | `full`, default `minimal`). It fronts six
|
||||
sub-knobs — `modes.workflow`, `docs.density`, `qa.level`, `modes.story_granularity`,
|
||||
`modes.review_mode`, `team.size`. Recommend **rigor**, not the six; let the
|
||||
expansion do the rest. Full expansion table lives in `effects-map.md § modes.rigor`
|
||||
— do not restate it here.
|
||||
|
||||
`modes.automation` (`collaborative` | `guided` | `autonomous`) is a **separate
|
||||
axis** — how often skills stop to confirm — and is *not* fronted by rigor. Pick it
|
||||
by working style, not by game type (see § 5).
|
||||
|
||||
---
|
||||
|
||||
## 2. Archetype → rigor presets
|
||||
|
||||
Match the project to an archetype; recommend the paired rigor. These are starting
|
||||
points, not verdicts — the user can always override.
|
||||
|
||||
| Archetype | Rigor | Why | Common override |
|
||||
|---|---|---|---|
|
||||
| Weekend jam / prototype / throwaway | `minimal` | Shipping beats recording; design lives in the maker's head | Bump one deep system: `workflow_overrides.system_overrides: {combat: full}` |
|
||||
| Small solo / hobby game (arcade, puzzle, short narrative) | `minimal` → `standard` if it grows | Start light; add rigor when scope proves real | — |
|
||||
| Focused commercial indie (platformer, roguelike, tactics, deckbuilder) | `standard` *(default)* | One well-understood loop; enough design to build correctly | "Comprehensive but compact": `rigor: full` + `docs.density: terse` |
|
||||
| Systems-heavy / long-haul (open-world RPG, colony sim, immersive sim, 4X, survival) | `full` | Many interacting systems; a design mistake costs weeks | Solo dev: keep `full` on disk, set `review_mode: solo` locally |
|
||||
| Live-service / competitive multiplayer | `full` + domain emphasis | Full pipeline *plus* netcode/security/live-ops | Raise `qa.level` / `testing.strict.*` for the online-critical types |
|
||||
|
||||
**The model:** the table picks a baseline; overrides handle the diagonal. Most real
|
||||
projects are one baseline plus one or two deliberate exceptions.
|
||||
|
||||
---
|
||||
|
||||
## 3. Seeding rigor from a described concept
|
||||
|
||||
When the user has described their game (e.g. `/start` Phase 2 free text), map it to
|
||||
an archetype and **pre-select** the recommendation rather than asking cold. Signals:
|
||||
|
||||
| Concept mentions… | Lean toward |
|
||||
|---|---|
|
||||
| open-world, RPG, sim, sandbox, faction, crafting, economy, MMO, multiplayer, "systems" | `full` |
|
||||
| jam, weekend, prototype, "first game", small, "just trying", experiment | `minimal` |
|
||||
| "release", "commercial", "on Steam", a single clear core loop | `standard` |
|
||||
| *ambiguous / nothing above* | `standard` (the documented default) |
|
||||
|
||||
**Rules:** these are heuristics, never locks. Always confirm the pre-selection with
|
||||
the user in their own terms ("Sounds like a big systems game — I'd suggest `full`
|
||||
rigor; want that?"). If the user has **no concept yet** (exploring), do not seed
|
||||
`full` — default `minimal`, and revisit once a concept exists.
|
||||
|
||||
"No concept yet" means **no signal**, not a particular onboarding path. A rough
|
||||
one-line hint is still a description: if it trips the signals above, seed from the
|
||||
signal. Only fall back to `minimal`-for-exploring when the user has given you
|
||||
nothing to map. (`/start` Phase 3d states the same rule for its Path A/B branch —
|
||||
the two must agree, since both drive the identical recommendation.)
|
||||
|
||||
---
|
||||
|
||||
## 4. When to recommend a *change* (adaptive triggers)
|
||||
|
||||
Bidirectional and **threshold-based**. Fire only on a threshold *crossing*, never
|
||||
every session — that is what keeps this from becoming the nagging the `automation`
|
||||
modes exist to eliminate.
|
||||
|
||||
| Trigger (crossing) | Direction | Detectable signal | Suggested action |
|
||||
|---|---|---|---|
|
||||
| Project grew past its band | ↑ raise | System-GDD count crosses ~9, or `src/` crosses the Production threshold, while rigor is `minimal` | "You're at N systems on `rigor: minimal` — most projects this size run `standard`. Revisit? → `/settings`" |
|
||||
| Stage advanced into Production | ↑ raise | `/gate-check` PASS into Production while rigor is `minimal` | Same, offered once at the gate |
|
||||
| User sounds overwhelmed by process | ↓ lower | Phrases like "too many steps", "so much documentation", "overwhelmed" — *and* rigor is not already `minimal` | "If the required-doc list feels heavy, a lower rigor trims it → `/settings modes.rigor=standard`" |
|
||||
| Chosen rigor mismatches described scope | flag once | Onboarding pick contradicts the Phase-2 description | State it in one sentence, offer `/settings`, do not re-ask |
|
||||
|
||||
**Frequency guard:** the crossing *is* the gate. Because the hosts (`/gate-check` on
|
||||
PASS, `/help` on request) are themselves infrequent, no persistent "already nudged"
|
||||
state is needed — but never emit the same suggestion twice in one session.
|
||||
|
||||
---
|
||||
|
||||
## 5. Which skills reference this doc, and when
|
||||
|
||||
| Skill | Moment | Sections used |
|
||||
|---|---|---|
|
||||
| `/start` | Phase 3d/4 — choosing rigor | § 2 (presets), § 3 (seed from concept) |
|
||||
| `/help` | escalation footer when user sounds stuck/overwhelmed | § 4 (lower trigger) |
|
||||
| `/gate-check` | on PASS into a new stage | § 4 (raise trigger) |
|
||||
| `/settings` | view output — further reading | § 2 (choosing a value) |
|
||||
|
||||
Each skill carries a **one-line pointer** to this doc, not a copy of its tables.
|
||||
|
||||
---
|
||||
|
||||
## 6. How to phrase a recommendation
|
||||
|
||||
- **Recommend, don't dictate.** State the suggestion and the reason in one line;
|
||||
the user decides. (`collaborative`/`guided` require this; even `autonomous`
|
||||
treats a rigor change as a `schema_changes` decision and asks.)
|
||||
- **Always route to `/settings`** — never edit `project.yaml` as a side effect of a
|
||||
recommendation.
|
||||
- **One line, then stop.** A nudge is a nudge, not a lecture.
|
||||
Reference in New Issue
Block a user