/project-settings

name: project-settings
description: "Shows or changes a project setting and where its value comes from. Use to check or set one."
argument-hint: "[key | key=value | --local key=value]"
user-invocable: true
allowed-tools: Read, Glob, Grep, Write, Edit, AskUserQuestion, Bash(bash "*/.claude/skills/project-settings/../../hooks/yaml-helper.sh" resolve_setting *), Bash(bash "*/.claude/skills/project-settings/../../hooks/yaml-helper.sh" get_yaml_key *), Bash(bash "*/.claude/skills/project-settings/../../hooks/yaml-helper.sh" validate_yaml_enum *), Bash(bash "*/.claude/skills/project-settings/../../hooks/yaml-helper.sh" validate_enum_value *), Bash(bash "*/.claude/skills/project-settings/../../hooks/yaml-helper.sh" is_locally_overridable *), Bash(bash .claude/scripts/config-set.sh *), Bash(grep -B14 '^> ### RESERVED' .claude/docs/effects-map.md), Bash(grep -E '^## ')
model: sonnet

/project-settings — view or change project config

Manages `project.yaml` (team-wide config, committed) and `project.local.yaml` (per-developer overrides, gitignored). Use this skill to inspect current settings or change them without manually editing YAML.

**Automation mode**: Resolve `modes.automation` (`project.local.yaml` → `project.yaml` → default `collaborative`). The approval gates in Phase 4 and Phase 5 follow the pattern in `.claude/docs/automation-modes.md`. **Note**: writing to `project.yaml` is a `schema_changes` decision (a default `automation_always_ask` category), so `/project-settings` confirms config writes even in `autonomous` mode unless the user has removed `schema_changes` from their always-ask list.

Phase 0: Parse Arguments

Determine which of the four forms the user invoked:

| Form | Mode | |------|------| | `/project-settings` (no args) | **View-all** (Phase 2) | | `/project-settings <key>` (single arg, no `=`) | **View-one** (Phase 3) | | `/project-settings <key>=<value>` (single arg with `=`) | **Set-yaml** (Phase 4) | | `/project-settings --local <key>=<value>` (`--local` prefix) | **Set-local** (Phase 5) |

For Set-yaml and Set-local, `<key>` is a dotted YAML path (e.g. `modes.review_mode`, `testing.strict.logic`) and `<value>` is the new value.

**Empty-operand validation:** After splitting the `key=value` operand on `=`, if either `<key>` or `<value>` is empty, this is malformed — route to Phase 6 (usage) rather than attempting the write. The rule applies in both Set-yaml and Set-local routing: for `--local`, strip the `--local` token first, then check the remaining operand the same way (so `/project-settings --local =foo` and `/project-settings --local key=` both go to Phase 6).

Anything else that doesn't match the four forms above → Phase 6 (usage).

Phase 1: Load Helper

All four subcommands need `yaml-helper.sh`. Run each helper call as its own plain command:

bash "${CLAUDE_SKILL_DIR}/../../hooks/yaml-helper.sh" <helper call>

`<helper call>` is the function each phase below names, for example `resolve_setting modes.review_mode` or `validate_yaml_enum project.yaml`. The helper moves to the project root itself, so those `project.yaml` and `project.local.yaml` arguments resolve when the session was started in a subfolder, and it keeps the function's exit status. `is_locally_overridable` also prints its `0` or `1`. Run the call exactly as shown: do not `source` the file, wrap it in `cd ... &&` or append `; echo $?`. This skill pre-approves the plain form only, and a compound command asks the user every time.

If `.claude/hooks/yaml-helper.sh` is missing, this is not a Claude Code Game Studios project. Report the error and exit.

Phase 1b: Reserved-setting detection

Some settings are fully documented and settable, and **no skill or hook reads them** — setting one changes nothing. **This skill must say so.** Returning an ordinary success lets a user reasonably believe the behaviour the setting describes is now enforced — an accessibility tier being the case that motivates this. (The key is not named here on purpose; see the note below.) The banner exists only in `.claude/docs/effects-map.md`, which someone configuring their project will never open. A setting that does nothing must never look exactly like one that works — `.claude/rules/skill-authoring.md` obligation 3.

Derive the set; do not hardcode it (obligation 5):

grep -B14 '^> ### RESERVED' .claude/docs/effects-map.md | grep -E '^## '

**Match the banner HEADING (`> ### RESERVED`), never the bare word "RESERVED".** `platform.cert_tier`'s section *mentions* the banner in prose, to record that it carried one and later became a live setting. A looser match re-reports a working setting as dead — the direction that understates what the framework does, and why the dead-settings gate asserts both directions.

A heading may name **two keys joined by " and "** — split on that separator so both are captured, or the second one silently escapes the set. Let `RESERVED_SET` be the result.

> Deliberately phrased without naming those keys. The dead-settings gate asserts > that a setting on the allowlist has **no** readers, and it counts any skill > file that spells the key. Naming them here to illustrate the split would make > `/project-settings` register as a reader of two settings nothing reads, and the gate > would fail — correctly. Spelling a dead path out while explaining why not to > use it trips the same wire. Reword instead of adding an exemption: the > strictness is the point, so do not re-introduce the literal names to make an > example clearer.

Never refuse a write to a reserved key. Storing the value a user intends is legitimate; storing it *silently* is the defect.

Phase 2: View-all Mode

(when no arguments)

1. Confirm `project.yaml` exists. If missing, report: > "No `project.yaml` found — run `/start` to create one." And exit.

2. Check if `project.local.yaml` exists.

3. Run `validate_yaml_enum project.yaml` and capture any errors. If `project.local.yaml` exists, also