adyusuf configuration

Claude does not ask what a setting already answers (global rule #34). These settings are the answers. The user changes them here; everything else in this skill is mechanics.

Layers, lowest first: the plugin's defaults/adyusuf.json < the user's ~/.claude/adyusuf.json < the project's .claude/adyusuf.json (committed, like .claude/mode) < this session's own layer. A change typed as a command is written to the user layer unless the user says "for this project" (the project layer) or "for this session" (the session layer, --session <id>; the id is on the this session is <id> line of the start-of-session block).

The clickable questions and the Settings box's Session tab change the session layer only. A new session has a new id, finds no session file and starts from the saved defaults; nothing such a click did is kept. A press in the System tab writes the saved defaults (~/.claude/adyusuf.json), which every new session starts from. To keep a value, say so ("make it my default"): then set <key> <value> (user layer) or --project. A resumed session keeps its id, so its changes stay; /clear starts a new one.

The tool is ${CLAUDE_PLUGIN_ROOT}/scripts/adyusuf_config.py (python3):

A value that is not valid is refused and nothing is written (exit 2); an unreadable file is never overwritten (exit 1) - say which file and let the user fix or delete it. After a change, print the changed line and say which layer it went to. Never edit the JSON files by hand when the tool can do it.

The settings, and who reads them

Changing settings with clicks

When the user wants to change settings without naming them (no argument, "change the settings", "open the settings", "show the settings in the right-hand boxes"):

The rail boxes first. This plugin's mod (hooks/register.tsx, the boxes in hooks/boxes.ts) draws ONE pane beside the conversation with four bordered boxes, each folded by the arrow before its title, with nothing beside the title: Status (what runs now and next), Settings (a checkbox for every yes/no setting, a radio list for every choice), Agents (a checkbox per agent, a model radio list; folded at start) and Promotion (dev/test/prod, read-only; folded at start). A click in the Session tab runs adyusuf_config.py set --session <id> and changes this session only; one in the System tab changes the saved defaults. Open them with /adyusuf:panels, say that they are there and stop: the user changes the settings in the boxes, not in the chat. Never build a page or an Artifact for this. In the Claude desktop app the mod only loads when CLAUDE_CODE_PLUGIN_DIRS in ~/.claude/settings.json names the plugin's folder (SETUP.md §6); say so rather than falling back to a page.

Only when the boxes cannot be shown (the surface draws no panes, mods are off, the plugin is an old copy without them): run show, then ask with the AskUserQuestion tool, which draws clickable buttons, checkboxes and dropdowns in the chat. Put the current value in each question or option ("now: yes"), because the tool cannot pre-select.

1. One question, multiSelect: true (checkboxes): "Which settings do you want to change?" with four options: Mode and model · Writing and pod (unit tests, e2e, pod.connect, pod.message_format) · Merge, push and gates · One agent.
2. One AskUserQuestion call for each ticked group (at most four questions per call, two to four options each):
   • Mode and model: mode as buttons A / B / C / D (E through "Other"), then mode_model as buttons keep / sonnet / haiku / fable, then reply.length as buttons short / normal / long.
   • Writing and pod: write.unit_tests, write.e2e and pod.connect, each as yes / no buttons, then pod.message_format as buttons short / full (the pod settings are stored only; nothing acts on them).
   • Merge, push and gates: five checkbox questions (multiSelect: true, two calls): "Merge into", "Run gates before the push", "Push", "Run CI after pushing" (options dev / test / prod) and "Run e2e before deploying" (options on dev before deploying test, on test before deploying prod). A ticked box is yes, an unticked one no.
   • One agent: the role (qa, developer, architect, security, any other through "Other"), then enabled as buttons auto / on / off and model as buttons default / sonnet / haiku / opus (fable through "Other").
3. Write all the answers with one apply --session <id> (validated all-or-nothing; the id is on the this session is <id> line), print show --session <id>, and say that it went to this session's layer. If the user asks to keep them, repeat the same apply without --session. Skip a question the user did not tick in step 1, and never ask again for what they answered.

When a change takes effect

At once, but never in the middle of a step. The files change immediately. A UserPromptSubmit hook and a PostToolUse hook (agent calls and shell commands, the task boundaries) run adyusuf_config.py notify: the first time a session sees different effective settings it receives a note naming what changed, and the note says to apply them from the next task and not to restart or split the step in progress. A note is sent once per change and per session; a session that never saw the settings stays silent.

What reads the settings

• The SessionStart hook prints context: the effective values and the agents, so every session starts knowing them.
• Rule #34 (CLAUDE.md): the merge/push/gate behaviour. A gate set to no is not run and recorded, never skipped silently; a red gate that was asked for still blocks. Force pushes, DROP, deploys and main stay out of reach of every setting (guard-destructive.sh, #20, #27).
• adyusuf:working-mode falls back to mode / mode_model when no session or project choice exists.