/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 /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
/settings (no args)	View-all (Phase 2)
/settings <key> (single arg, no =)	View-one (Phase 3)
/settings <key>=<value> (single arg with =)	Set-yaml (Phase 4)
/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 /settings --local =foo and /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>