manage-settings

Manage Settings

Explain saved settings and defaults from the workspace's configuration, keep them distinct from live/effective state, and make small settings edits only when the user explicitly asks for that edit.

Scope

• Manage Settings is exclusively for Muse Code-owned settings.
• Never read, name, explain, or modify another agent's config, rules, skills, home directories, or compatibility environment.
• Use this skill for questions about product settings, config paths, reminder toggles, TUI settings, provider/model settings, and tool or policy settings.
• "Product settings" here means Muse Code itself. Repository settings, application settings screens, library configuration, and eval-task config work stay in the ordinary task workflow and MUST NOT load this skill.
• Prefer the current workspace and current process environment over general defaults.
• Do not create issues, branches, commits, PRs, plugins, or skills.
• Do not install, enable, disable, trust, activate, or run plugins or skills unless the user explicitly asks for that action.
• Do not print secrets. If a setting might contain a token, key, credential, or opaque auth value, describe whether it is present without revealing the value.

Decide Before Any Tool Call

• Manage Settings owns persistent saved settings, not current runtime state.
• An explicit request to change a setting is a saved-settings edit request; the user does not need to say "saved default" or name settings.json.
• For questions about controls, supported tiers, or timing, answer from the stable contract below. Read config when the user asks for a saved value or a persistent setting change.
• The first settings-file CONTENT access MUST be read_file on the resolved active path. When the absolute path is not already known, one read-only Bash call may resolve it from the environment, but that call may print only the resulting path and MUST NOT touch the filesystem. Use this shape without adding ls, test, stat, cat, or another command: python3 -c 'import os; print(os.path.join(os.environ.get("XDG_CONFIG_HOME") or os.path.join(os.environ["HOME"], ".config"), "muse", "settings.json"))'. YOLO mode alone never authorizes direct Bash file access.
• Use edit_file or write_file for the smallest safe JSON change. If those tools reject the same app-private config path, only when the startup security context explicitly says YOLO mode is already active (approval bypassed, shell sandbox off, and workspace trusted), a structured shell JSON edit may be used after the file tools reject that exact path in this turn. Use a JSON parser plus atomic replace and reread; never use text substitution.
• A shell file-access fallback must operate on that one resolved path. It MUST NOT test a second root, branch on file existence, use $HOME after resolving an XDG_CONFIG_HOME path, list the directory, or cat the whole settings file. Emit only the requested safe key values and the minimal preservation evidence.
• Never ask the user to change security mode just to edit settings.
• Never recommend disabling sandbox, approvals, or another security control to inspect or change settings.
• Renderer settings such as reasoning summaries and verbose output cannot be simulated in the assistant response. Explain the owning control instead of promising equivalent behavior.