| name | new-config |
| description | Interactively scaffold a new smug tmux session configuration (a YAML template). Use when the user wants to create, scaffold, or set up a new smug project/config file, or asks for "smug new config", "a smug template", or "/new-config". Walks the user through session name, root, windows, panes, commands, env, and hooks, then writes a valid smug YAML file. |
Create a new smug configuration
Scaffold a new smug session config by interviewing the user with the
AskUserQuestion tool, then writing a valid YAML file in the smug format.
Do not write the file until you have asked the questions below. Ask in small
batches, infer sensible defaults, and only ask what you can't infer.
1. Gather requirements (interactive)
Ask with AskUserQuestion. Group related questions into a single call when you
can. Always offer a clear default and let the user override via "Other".
- Session name — the tmux session name (
session:). Suggest the current
directory's basename as the default.
- Where to save — one of:
.smug.yml in the current working directory (used by default by smug).
~/.config/smug/<session>.yml (loadable as smug start <session>).
- A custom path the user types.
- Root directory — the session
root: (where windows start). Default .
for a cwd config, or the cwd's absolute path for a ~/.config/smug config.
- Windows — ask how many windows and, for each, the name and what it runs
(e.g. "editor", "server", "tests"). Keep it light; one window with a
command is a fine minimal config. Only dig into panes/layout if the user
wants a split window.
- Optional extras — only ask if the user signals they want them:
attach: true (auto-attach after creation).
env: variables.
before_start: / stop: commands (e.g. docker-compose up -d).
attach_hook: / detach_hook:.
If the user says "just give me a basic one" or similar, skip straight to a
minimal config (session + root + one window) — don't force the full interview.
2. Smug config schema (reference)
Generate YAML matching this structure. Omit empty/optional fields.
session: my_project
root: ~/code/my_project
attach: true
env:
FOO: bar
before_start:
- docker-compose up -d
stop:
- docker-compose stop
attach_hook: echo hi
detach_hook: echo bye
windows:
- name: code
root: .
selected: true
manual: false
layout: main-vertical
commands:
- $EDITOR .
panes:
- type: horizontal
root: .
commands:
- npm run dev
Notes:
session is the only truly required field. A useful minimal config is
session + root + one windows entry with a commands list.
${var} in the YAML is substituted from custom settings passed on the CLI
(smug start project var=value) or the environment — only use it if the
user asks for parameterization.
- Quote nothing unnecessarily; keep it idiomatic, readable YAML.
3. Write and confirm
- Write the file to the chosen path with the
Write tool. If saving to
~/.config/smug/, expand ~ to the home directory and ensure the directory
exists (it normally does — smug creates it).
- Show the generated YAML to the user.
- Tell them how to use it:
- cwd
.smug.yml: smug start
~/.config/smug/<session>.yml: smug start <session>
- custom path:
smug start -f <path>
- Offer to validate it. If a
smug binary is on PATH, run
smug print -f <path> (parses the config and prints the tmux commands
without starting a session). Inside this repo you can instead run
go run . print -f <path>. If it errors, fix the YAML and retry.
Keep the result minimal and tailored to what the user actually asked for — no
speculative windows, panes, or hooks they didn't request.