ccb-configlisted

# CCB Config Use this skill to design, edit, or migrate CCB project configuration. The normal output is a valid `.ccb/ccb.config` or, only when explicitly requested, a user-level `~/.ccb/ccb.config`. This skill is not a workflow-memory designer. Do not edit `.ccb/ccb_memory.md`, `.ccb/agents/<agent>/memory.md`, generated memory, provider-state homes, installed role stores, or runtime records. After finishing config work, remind the user that workflow memory can be set separately if they want persistent collaboration rules. ## Core Workflow 1. Resolve the config authority first. CCB config precedence is built-in default < user config `~/.ccb/ccb.config` < project config `.ccb/ccb.config`. `.ccb_config/ccb.config` is legacy residue and must be treated as read-only migration evidence. 2. Read the current `.ccb/ccb.config` when it exists. Do not read memory files for ordinary config work. 3. Summarize the active config source and current shape: topology type, windows, agents, tool windows, sidebar, workspace modes, and notable advanced overrides. 4. Show the configuration menu below when the user asks what can be configured, asks for broad redesign, or leaves the target vague. 5. Ask one focused clarification question only when required. Do not ask a long questionnaire. 6. Propose one complete TOML preview or one clear patch. Prefer `version = 2` `[windows]` topology unless the user explicitly wants compact/cmd. 7. Write only after confirmation or an explicit apply request. 8