# Kanban Setup — Project Bootstrap & Profile Configuration Once the brief is locked and the team is designed, the next step is producing the actual `setup.sh` that creates the project workspace, configures Hermes profiles, and fires the initial kanban task. This file documents the patterns. The companion script `scripts/bootstrap_pipeline.py` automates most of it from a structured input JSON. > **Credit:** the single-project-workspace layout, profile-config patching > approach, SOUL.md-per-profile convention, and `--workspace dir:` rule > are adapted from alt-glitch's original multi-agent video pipeline: > [NousResearch/kanban-video-pipeline](https://github.com/NousResearch/kanban-video-pipeline). > This skill generalizes those patterns across video styles and replaces the > string-replacement config patcher with a PyYAML-based one. ## Project workspace structure Every video project gets one workspace under `~/projects/video-pipeline//`: ``` ~/projects/video-pipeline// ├── brief.md ← the contract; all tasks reference ├── TEAM.md ← team composition + task graph (director reads this) ├── taste/ │ ├── brand-guide.md ← color, typography, motion rules │ ├── emotional-dna.md ← what the piece should FEEL like │ └── style-frames/ ← optional: visual references ├── audio/ │ ├── track.mp3 ← provided music (if any) │ ├── voiceover/ ← per-line TTS clips │ └── sfx/ ← sound effects ├── assets/ │ ├── logos/ │ ├── fonts/ │ └── existing-footage/ ← reusable provided clips ├── scenes/ │ ├── scene-01/ │ │ ├── VISUAL_SPEC.md ← cinematographer's per-scene spec │ │ ├── render.py ← renderer's code (or sketch.html, etc.) │ │ ├── checkpoints/ ← preview frames for QA │ │ └── clip.mp4 ← the deliverable for this scene │ ├── scene-02/... │ └── ... ├── checkpoints/ ← global review frames ├── tools/ ← optional project-local helpers └── output/ ├── final.mp4 ← stitched + audio ├── final-noaudio.mp4 ├── final-9x16.mp4 ← optional: vertical alternate └── captions.srt ← optional: subtitle file ``` **The slug** is derived from the brief title: lowercase, hyphen-separated. Example: `q3-product-teaser`, `ascii-mood-loop`, `interview-cut-2026-q1`. ## The setup.sh script The setup script does six things in order: 1. **Create workspace tree** — all directories above 2. **Create profiles** — `hermes profile create --clone` 3. **Configure profiles** — patch each profile's `~/.hermes/profiles//config.yaml` to set toolsets, always_load skills, and `cwd` 4. **Write SOUL.md per profile** — the personality + role definition 5. **Copy any provided assets + write `brief.md`, `TEAM.md`, and `taste/`** 6. **Fire the initial kanban task** — `hermes kanban create` assigned to the director See `assets/setup.sh.tmpl` for the skeleton. ### Profile creation pattern ```bash hermes profile create director --clone 2>/dev/null || true ``` The `--clone` flag clones from the active profile (preserving model, base config). The `|| true` makes the script idempotent — re-running won't error if the profile already exists. ### Profile config patching Each profile has a YAML config at `~/.hermes/profiles//config.yaml`. The setup script edits exactly two keys: 1. `toolsets:` — replace the default with the role's required toolsets 2. `skills.always_load:` — list the role's must-load skills (may be empty) **Do NOT** modify `approvals.mode` (controls user-confirmation of tool calls — a security setting that must stay as the user configured it). **Do NOT** modify `terminal.cwd` — the kanban dispatcher overrides cwd per-task via `--workspace dir:`, so the profile's cwd is irrelevant to the kanban work and changing it could break the user's interactive use of the profile. Use **PyYAML**, not string replacement, so the patch is robust against default-config schema drift: ```bash configure_profile() { local profile="$1" local toolsets_json="$2" # JSON array, e.g. '["kanban","terminal","file"]' local skills_json="$3" # JSON array, e.g. '["kanban-worker","ascii-video"]' python3 - "$profile" "$toolsets_json" "$skills_json" <<'PY' import json, os, sys, yaml profile, ts_json, sk_json = sys.argv[1:4] p = os.path.expanduser(f"~/.hermes/profiles/{profile}/config.yaml") with open(p) as f: cfg = yaml.safe_load(f) or {} cfg["toolsets"] = json.loads(ts_json) cfg.setdefault("skills", {})["always_load"] = json.loads(sk_json) with open(p, "w") as f: yaml.safe_dump(cfg, f, sort_keys=False) PY } ``` PyYAML must be installed in the user's Python (it ships with most Hermes installs). If absent: `pip install pyyaml`. The setup script should also **validate** the patch by re-reading the file and comparing — see `assets/setup.sh.tmpl` for the validation pattern. ### SOUL.md per profile Each profile gets a `SOUL.md` at `~/.hermes/profiles//SOUL.md` that defines its role, voice, and rules. See `assets/soul.md.tmpl` for the template. Customize per role and per project. The director's SOUL.md should be the most opinionated — its voice flavors the entire production. **Critical content for the director's SOUL.md:** - **Anti-temptation rules:** "Do not execute the work yourself. For every concrete task, create a kanban task and assign it. Decompose, route, comment, approve — that's the whole job." (The `kanban-orchestrator` skill provides the deeper playbook; load it.) - **Decomposition steps:** Read `brief.md`, `TEAM.md`, `taste/`. Use the team graph in `TEAM.md` to fan out tasks. - **The workspace_path rule** (see below). Other profiles' SOUL.md is briefer; mostly mechanical: who you are, what you read, what you produce, what skills/tools to use, where to write outputs. Most non-director profiles should `always_load: kanban-worker` for the deeper-than-baseline kanban guidance. ### Initial kanban task The final action of setup.sh is firing the kanban: ```bash hermes kanban create "Direct production of