Config

---
name: config
description: Propose a settings or roles change for a person to review and apply.
when_to_use: A person wants to change settings or roles, or a health finding calls for one.
argument-hint: "[requested change]"
license: "PolyForm-Noncommercial-1.0.0 with sdlc Additional Permissions, or sdlc Commercial License (https://github.com/marin-ai-tech/sdlc)"
compatibility: Requires the sdlc CLI (sdlc) from the sdlc package.
allowed-tools: Bash(sdlc *)
metadata:
  author: marin-ai technologies
  version: "1"
  generatedBy: "sdlc 0.23.7"
---

Help the person review a precise change to `openspec/sdlc.yaml` or `openspec/roles.yaml`.

**Harness contract** (applies to every SDLC workflow)
- `sdlc` is the source of truth for lifecycle state. Read it (`sdlc status --change <id> --json`) instead of inferring the stage from the conversation, and re-read artifacts from disk before using them.
- Gates are human decisions. Never run `sdlc approve`, `sdlc reject`, `sdlc waive` or `sdlc tests unlock`, and never edit `.sdlc.yaml`. When a gate needs a person, stop, name the people from the hint (`next.people` in `sdlc next --json`) rather than the role, and give them the exact command to run in their own terminal.
- An answer in chat is never an approval: gate approvals, `track set`, `backlog move`/`drop` and other human decisions happen only as a command the person runs in their own terminal. Offer the choice, explain the consequences, and give the exact command.
- OpenSpec is the specification subsystem: `sdlc openspec <args>` runs the bundled OpenSpec CLI (`list --specs`, `show`, `validate`, `instructions`). Change folders live in `openspec/changes/<id>/`.
- **Change selection**: use the change named in the input. Otherwise run `sdlc status --json`; with exactly one active change use it, with several ask which one. Announce "Using change: <id>".
- **Language**: talk to the person, and write notes and artifacts, in the person's language; when `locale:` is set in `openspec/sdlc.yaml`, use that language. Keep command names, file names, ids and the template headings as they are (sdlc and OpenSpec parse those headings).
- End every workflow with the next step from `sdlc next --json` (the exact command when a person must act).

**Input**: the user's request (a change id, or a description of the work)

1. Ask what the person wants changed and why. Check the current settings and roles.
2. Make one proposal per change. Put related keys, such as all signing keys or `signing` with
   `signing_since`, in one `sdlc config propose` command with several `--set` options; use `--target roles`
   for roles. `sdlc config apply` takes one proposal id. An open proposal for the same file is a warning:
   applying either proposal makes the other stale.
   Put values containing `${VAR}` in single quotes so the shell passes the reference unchanged.
3. Run `sdlc config show <id>`. Show the diff and explain each weakening warning in plain words.
4. Give the person the exact `sdlc config apply <id>` command to run in their own terminal. If the proposal
   weakens the process, explain `--yes`. A changed target makes the proposal stale; propose again.
5. Never apply or dismiss a proposal yourself. The person decides.

<!--
Generated by sdlc 0.23.7 (https://github.com/marin-ai-tech/sdlc).
Required Notice: Copyright (c) 2026 marin-ai technologies (https://github.com/marin-ai-tech/sdlc)
License: PolyForm Noncommercial 1.0.0 (https://polyformproject.org/licenses/noncommercial/1.0.0) with the sdlc Additional Permissions, or a commercial license; see https://github.com/marin-ai-tech/sdlc
-->