mirror of
https://github.com/Donchitos/Claude-Code-Game-Studios.git
synced 2026-10-16 01:37:05 +00:00
DonchitosandClaude Opus 5.5
be8993bbc5
Fix release for 1.1.2: the 14 longest skills keep their later phases after a compaction, a question nobody answered is never taken as an answer, settings read the same from a subfolder, the commit check works for a project in a subfolder of a larger repository, every skill opens with a title, and the shipped allow rules no longer approve deleting a branch or writing files without asking. Details in CHANGELOG.md; upgrade steps in UPGRADING.md (v1.1.2 → v1.1.3). Refs #83 Refs #133 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0185en4t76fPn7315q4c3nko
120 lines
6.4 KiB
Markdown
120 lines
6.4 KiB
Markdown
# 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
|
|
|
|
| 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 **not** a CLAUDE.md import — advisory content must not ride in per-turn
|
|
context.
|
|
|
|
---
|
|
|
|
## 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. The full expansion table is in `effects-map.md § modes.rigor`.
|
|
|
|
`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` | 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* | `minimal` (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;
|
|
both drive the same 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 the code root (`src/`, `Assets/` or `Source/`) 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) |
|
|
|
|
These skills each carry a **one-line pointer** to this doc.
|
|
|
|
---
|
|
|
|
## 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.
|