feat(kb,okf): OKF init viewer and script fixes

.claude-plugin/marketplace.json

@@ -118,6 +118,11 @@
       "name": "unsloth-training",
       "source": "./unsloth-training",
       "description": "Fine-tune LLMs with Unsloth using GRPO or SFT. Includes dataset preparation, synthetic data generation, environment flags, MLX (Apple Silicon), FP8, vision models, mobile export, GGUF."
+    },
+    {
+      "name": "command-code",
+      "source": "./command-code",
+      "description": "Drive the Command Code CLI (`cmd`) and orchestrate it as a headless sub-agent. Fan out `cmd -p --yolo --max-turns 100000` workers across isolated git worktrees to implement issues and tasks in parallel, each committed to its own branch for review."
     }
   ]
 }

command-code/.claude-plugin/plugin.json

@@ -0,0 +1,12 @@
+{
+  "name": "command-code",
+  "version": "1.0.0",
+  "description": "Drive the Command Code CLI (`cmd`) and orchestrate it as a headless sub-agent. Skill + /command-code:dispatch command + cmd-dispatcher agent for fanning out `cmd -p --yolo --max-turns 100000` workers across isolated git worktrees to implement issues and tasks in parallel.",
+  "author": {
+    "name": "duyet",
+    "url": "https://github.com/duyet"
+  },
+  "homepage": "https://github.com/duyet/claude-plugins",
+  "repository": "https://github.com/duyet/codex-claude-plugins",
+  "license": "MIT"
+}

command-code/.codex-plugin/plugin.json

@@ -0,0 +1,21 @@
+{
+  "name": "command-code",
+  "version": "1.0.0",
+  "description": "Drive the Command Code CLI (`cmd`) and orchestrate it as a headless sub-agent. Skill + /command-code:dispatch command + cmd-dispatcher agent for fanning out `cmd -p --yolo --max-turns 100000` workers across isolated git worktrees to implement issues and tasks in parallel.",
+  "author": {
+    "name": "duyet"
+  },
+  "skills": "./skills/",
+  "commands": "./commands/",
+  "agents": "./agents/",
+  "interface": {
+    "displayName": "Command Code",
+    "shortDescription": "Drive & orchestrate the Command Code CLI (`cmd`) as a headless sub-agent.",
+    "developerName": "duyet",
+    "category": "Developer Tools",
+    "capabilities": ["Skill", "Command", "Agent"],
+    "links": {
+      "homepage": "https://github.com/duyet/claude-plugins"
+    }
+  }
+}

command-code/README.md

@@ -0,0 +1,45 @@
+# command-code
+
+Drive the **Command Code CLI (`cmd`)** from Claude Code — and orchestrate it as a **headless sub-agent** to implement work in parallel.
+
+`cmd` (Command Code) is a standalone terminal coding agent that continuously learns your taste of writing code. This plugin teaches Claude how to run it correctly, and how to fan it out across isolated git worktrees so several `cmd` workers implement independent tasks (or GitHub issues) at once.
+
+## What's inside
+
+| Component | What it does |
+|---|---|
+| **Skill** `command-code` | The full contract for running `cmd`: the mandatory headless invocation, the worktree dispatch workflow, taste/MCP/skills, and safety rules. Auto-triggers on "cmd", "Command Code", "dispatch cmd", etc. |
+| **Reference** `references/cli-reference.md` | Complete flag list, sub-commands, slash commands, and exit codes. |
+| **Command** `/command-code:dispatch` | Guided fan-out: turn issues/tasks into isolated `cmd` workers, launch, track, review. |
+| **Agent** `cmd-dispatcher` | Sub-agent that orchestrates the whole dispatch loop end to end. |
+
+## The one rule to remember
+
+For any unattended / background run, always:
+
+```bash
+cmd -p "<detailed self-contained prompt>" --yolo --max-turns 100000 --skip-onboarding
+```
+
+Miss any of these and the headless task **breaks**:
+- no `-p` → opens a REPL and waits for a human
+- no `--yolo` → hangs on the first permission prompt
+- default `--max-turns` (10) → exits code 8 mid-implementation
+- no `--skip-onboarding` → blocks on the taste-onboarding demo
+
+## Dispatch pattern
+
+1. One git worktree + branch per worker (never two `cmd` runs in one dir).
+2. A self-contained spec as the prompt — `cmd` shares none of your context; give it exact file seams, scope, style, and the commit message.
+3. Launch in the background, capture a per-worker log.
+4. Tell workers **not** to build; verify once after collecting branches (parallel builds OOM).
+5. Review each diff; nothing is pushed or merged without your approval.
+
+## Safety
+
+`--yolo` runs an autonomous agent loop with no approval gate. Only launch with the user's explicit consent, always in a dedicated worktree on a branch (never straight onto `main`), with "do not push" in the prompt. You are the approval gate — moved to diff-review time.
+
+## Requirements
+
+- `cmd` installed and authenticated (`cmd login`; verify with `cmd status`).
+- `git` (for worktree isolation), and `gh` if dispatching over GitHub issues.

command-code/agents/cmd-dispatcher.md

@@ -0,0 +1,32 @@
+---
+name: cmd-dispatcher
+description: Orchestrates the Command Code CLI (`cmd`) as headless sub-agents. Use proactively when the task is "spawn cmd", "dispatch cmd", "use cmd to implement these issues", "fan out cmd workers", or any request to run `cmd` unattended/in parallel. Sets up isolated worktrees, launches `cmd -p --yolo --max-turns 100000`, tracks the runs, and reviews the resulting branches.
+tools: Bash, Read, Edit, Write, Glob, Grep
+---
+
+# cmd Dispatcher
+
+You orchestrate **Command Code (`cmd`)** running headlessly to implement work in parallel. Load the `command-code` skill for the full contract; the essentials are below.
+
+## The invocation (never deviate)
+
+```bash
+cmd -p "<self-contained spec>" --yolo --max-turns 100000 --skip-onboarding
+```
+
+Every flag is required for unattended runs:
+- `-p` headless (no REPL), `--yolo` no permission gate (else it hangs on the first action), `--max-turns 100000` (default 10 exits code 8 mid-task), `--skip-onboarding` (else the taste demo blocks a fresh run).
+
+## Operating rules
+
+1. **Consent + auth first.** `--yolo` is unsupervised. Confirm the user authorized autonomous dispatch, and `cmd status` shows authenticated, before launching anything.
+2. **One worktree + branch per worker.** Never two `cmd` sessions in one directory — they corrupt each other's edits and index. `git worktree add -b feat/<slug> <dir> <base>`.
+3. **The prompt is the whole brief.** `cmd` shares none of your context. Include: what & why, exact file seams (path:line + pattern to copy), scope in/out, style rules, `do not run pnpm install or any build`, the exact commit message, `do not push`, and `print a summary at the end`.
+4. **Background + log.** Launch each worker as a background process, redirecting to a per-worker log file.
+5. **No parallel builds.** Tell every worker not to install/build; verify once yourself after collecting branches (concurrent builds OOM).
+6. **Review the diff, not the log.** On completion: `git -C <wt> diff --stat <base>..HEAD` and read it. Exit code 8 = unfinished; resume with `cmd -c -p "continue…" --yolo --max-turns 100000`.
+7. **Never push or merge** without the user's explicit approval. `--yolo` moved the approval gate to you, at review time.
+
+## Output
+
+Report a table of workers (slug → branch → worktree → log), then, as each finishes, a concise per-branch review: what changed, whether it's complete, and any deviations from spec. End with a recommendation on what's ready to merge.

command-code/commands/dispatch.md

@@ -0,0 +1,48 @@
+---
+description: Dispatch one or more headless Command Code (`cmd`) workers to implement well-scoped tasks or GitHub issues in parallel — each in its own git worktree, running `cmd -p --yolo --max-turns 100000`, committed to its own branch for review.
+---
+
+# /command-code:dispatch
+
+Fan out implementation work to the **Command Code CLI (`cmd`)** running headlessly as sub-agents. Read the `command-code` skill first — it has the invocation contract, the worktree workflow, and the safety rules.
+
+The user's request (issues, tasks, or a description) is: **$ARGUMENTS**
+
+## Step 0 — Preconditions
+
+- Confirm `cmd` is installed and authenticated: `which cmd && cmd status`. If not authenticated, tell the user to run `cmd login` and stop.
+- Confirm you're in a git repo with a clean base branch. Note the base branch (usually `main`).
+- **Get explicit consent for `--yolo`.** These workers run unsupervised with no permission gate. State that plainly and confirm the user wants autonomous background dispatch. If the host blocks the launch, surface it and let the user decide — do not try to bypass.
+
+## Step 1 — Resolve the work-list
+
+Turn `$ARGUMENTS` into a concrete list of independent units of work:
+- GitHub issue numbers → one worker per issue (each will `gh issue view <N>`).
+- A larger task → decompose into independent, separately-committable pieces. If pieces have dependencies, dispatch only the independent ones now and note the rest as follow-ups.
+- If the work isn't cleanly separable or is too small to be worth a handoff, say so and offer to just do it inline instead.
+
+## Step 2 — Write a self-contained spec per worker
+
+`cmd` shares none of this conversation's context. For each unit, write a prompt that stands alone (see the skill's "Write a self-contained spec"): what & why, exact file seams with paths/line numbers and the pattern to copy, scope in/out, style rules, `do not run pnpm install or any build`, the exact conventional-commit message, `do not push`, and a closing `print a summary of files changed + deviations`.
+
+## Step 3 — Isolate + launch
+
+One worktree + branch per worker; launch each in the background with the mandatory flags:
+
+```bash
+BASE=<a worktrees dir outside the main tree>
+git worktree add -b feat/<slug> "$BASE/<slug>" <base-branch>
+( cd "$BASE/<slug>" && \
+  cmd -p "<spec>" --yolo --max-turns 100000 --skip-onboarding > "$BASE/<slug>.log" 2>&1 ) &
+```
+
+`--yolo --max-turns 100000 --skip-onboarding` is non-negotiable — without them the headless task hangs or exits code 8 mid-run. Never run two workers in the same directory.
+
+## Step 4 — Track, then review
+
+- Report the launched workers (slug → branch → worktree → log path). Let them run in the background; you'll be notified as each finishes.
+- On completion, review each branch (`git -C <wt> log/diff --stat <base>..HEAD`) and read the diff — don't trust the log alone. Note anyone that exited code 8 (unfinished) and offer to resume it with `cmd -c`.
+
+## Step 5 — Verify once, after collecting branches
+
+Do NOT build inside the parallel workers. After the branches are ready, bring them into one tree and run a single consolidated typecheck/test pass, then report per-branch status (clean / needs-fix) so the user can decide what to merge. Nothing is pushed or merged without the user's say-so.

command-code/skills/command-code/SKILL.md

@@ -0,0 +1,141 @@
+---
+name: command-code
+description: Drive the Command Code CLI (`cmd`) — a terminal coding agent that learns your taste — and orchestrate it as a headless sub-agent. Use this skill whenever the user mentions "cmd", "Command Code", "commandcode", asks to "spawn cmd", "dispatch cmd", "use cmd as a subagent", run coding work headlessly/unattended, fan out implementation across GitHub issues or tasks with cmd, learn/manage taste, or set up `cmd` MCP/skills/auth. Also use it whenever you are about to launch `cmd` in print/headless mode and need the correct flags (always `--yolo --max-turns 100000 --skip-onboarding`).
+---
+
+# Command Code (`cmd`)
+
+`cmd` (Command Code) is a standalone terminal coding agent — a sibling to Claude Code / Codex — that **continuously learns the user's taste of writing code**. It has its own model access, permission system, session store, MCP support, and a "taste" personalization layer. This skill teaches you to (a) run it interactively, and (b) drive it **headlessly as a sub-agent** to implement work in parallel.
+
+The high-value use is the second one: `cmd` is excellent at being *dispatched* — you write a precise spec, hand it an isolated worktree, and let it implement, test, and commit autonomously while you do other work.
+
+## The one invocation to memorize
+
+For any unattended / headless / background dispatch, ALWAYS use:
+
+```bash
+cmd -p "<detailed self-contained prompt>" --yolo --max-turns 100000 --skip-onboarding
+```
+
+- **`-p/--print`** runs non-interactive: `cmd` executes the prompt and exits (no REPL). Required for scripting/background.
+- **`--yolo`** bypasses every permission prompt (alias for `--dangerously-skip-permissions`). A headless `cmd` **cannot answer prompts** — without this it will hang forever the first time it wants to run a command or edit a file. This is mandatory for background runs.
+- **`--max-turns 100000`** effectively removes the turn cap. The default is only **10**, and `cmd` **exits with code 8** the moment it hits the cap — mid-implementation, leaving a half-done branch. Real implementation tasks need many turns; set it absurdly high so the task finishes on its own merits, not on an arbitrary limit.
+- **`--skip-onboarding`** skips the interactive taste-onboarding demo, which would otherwise block a fresh headless run.
+
+`--yolo` is powerful and unsupervised. See [Safety & consent](#safety--consent) — you must have the user's go-ahead and you must isolate the work.
+
+## When to reach for `cmd` vs. doing it yourself
+
+Use `cmd` as a sub-agent when:
+- The user explicitly asks to "spawn/dispatch/use cmd".
+- There is **independent, parallelizable** implementation work (e.g. several GitHub issues, several packages) that can each be handed off with a clear spec and acceptance criteria.
+- You want a second, taste-personalized implementer to take a well-scoped task off your plate while you keep orchestrating.
+
+Do it yourself (don't dispatch) when the task is small, exploratory, needs tight back-and-forth, or isn't cleanly specifiable yet — the cost of writing a full handoff spec exceeds just doing it.
+
+## Dispatching `cmd` as a headless sub-agent
+
+This is the core workflow. Follow it exactly; each step exists to prevent a real failure mode.
+
+### 1. Isolate the work in a git worktree
+
+Never run two headless `cmd` sessions in the same working directory — they will clobber each other's edits and git index. Give each its own worktree on its own branch:
+
+```bash
+git worktree add -b feat/<slug> /path/to/wt/<slug> <base-branch>
+```
+
+One worktree per parallel task. Serial tasks in the same repo can reuse the main tree, but isolation is cheap insurance.
+
+### 2. Write a self-contained spec as the prompt
+
+`cmd` starts fresh — it does **not** share your conversation context. The prompt is the entire brief. A good dispatch prompt contains:
+- **What & why** in one or two sentences.
+- **Exact file seams** — paths and line numbers to read first (`packages/x/src/y.ts:120`), and the pattern to copy from. This is the single biggest quality lever; `cmd` implements far better against concrete anchors than against prose.
+- **Scope boundaries** — what's in and explicitly what's out ("stub the gateway; adapter + tests only").
+- **Style rules** — match the repo (indent, quotes, imports); tell it *not* to reformat unrelated code.
+- **Build/test policy** — see [Don't let parallel workers build](#dont-let-parallel-workers-build).
+- **Commit instructions** — exact conventional-commit message; "do not push".
+- **A closing "print a summary of files changed + deviations"** so the log ends with something reviewable.
+
+If the work is a GitHub issue, tell `cmd` to `gh issue view <N>` itself and follow it — but still restate the seams and constraints in the prompt; don't assume the issue body is enough.
+
+### 3. Launch in the background, capture the log
+
+```bash
+cd /path/to/wt/<slug>
+cmd -p "<spec>" --yolo --max-turns 100000 --skip-onboarding > /path/to/wt/<slug>.log 2>&1
+```
+
+Run it as a background process so several `cmd` workers proceed concurrently. Redirect to a per-task log file you can tail for progress and read on completion.
+
+### 4. Review the branch, then verify — after merge, not during
+
+When a worker finishes, inspect its branch, don't trust the log alone:
+
+```bash
+git -C /path/to/wt/<slug> log --oneline <base>..HEAD
+git -C /path/to/wt/<slug> diff --stat <base>..HEAD
+```
+
+Read the diff. Then run the consolidated typecheck/test **once**, after collecting the branches — see below.
+
+### Don't let parallel workers build
+
+Concurrent `pnpm build` / `bun build` across several worktrees causes OOM and thrashing. In every dispatch prompt, tell `cmd`: **do not run `pnpm install` or any full build; writing correct code + tests is sufficient.** Verify once, yourself, after merging the branches into a single tree. This is the same discipline you'd apply to any parallel sub-agent fleet.
+
+## Interactive & other modes
+
+`cmd` is also a normal interactive agent. Common forms:
+
+| Goal | Command |
+|---|---|
+| Start a REPL session | `cmd` |
+| Start with a first message | `cmd "refactor the auth module"` |
+| One-shot answer, then exit | `cmd -p "explain apps/main/src/auth.ts"` |
+| Resume last conversation | `cmd -c` / `cmd --continue` (⚠️ can overflow context on a *large* prior session — for a small leftover task prefer a fresh scoped `cmd -p`; see `references/cli-reference.md`) |
+| Resume a named conversation | `cmd -r "<name>"` |
+| Fork a session (leave original untouched) | `cmd --resume <id> --fork-session` |
+| Plan first, don't edit | `cmd --plan` or `--permission-mode plan` |
+| Auto-accept edits but keep some gates | `cmd --auto-accept` / `--permission-mode auto-accept` |
+| Pick the model | `cmd -m <model>` (`cmd --list-models` to see options) |
+| Add extra context dirs | `cmd --add-dir <dir>` |
+
+For the complete flag list, sub-commands (`taste`, `mcp`, `skills`, `login`), slash commands, and exit codes, read **`references/cli-reference.md`**.
+
+## Taste, goals, MCP, skills — the personalization layer
+
+`cmd`'s differentiator is **taste**: it learns how the user likes code written and applies it automatically.
+- `cmd taste` — manage taste packages; `cmd taste learn <local-repo|github-repo>` — learn taste from a codebase.
+- `cmd learn-taste` / `cmd --learn-taste` — build taste from existing Claude Code / Codex sessions.
+- `/goal "<objective>"` (slash command inside a session) — set a standing objective the agent works toward; `/goal status`, `/goal clear`.
+- `cmd mcp` — manage MCP servers; `cmd skills` — manage skills from GitHub repos.
+- `cmd login` / `cmd status` / `cmd whoami` — auth. Before any headless fleet, confirm `cmd status` shows authenticated, or every worker fails identically.
+
+When dispatching for a taste-sensitive codebase, consider running `cmd taste learn <this-repo>` once up front so the workers inherit the house style.
+
+## Safety & consent
+
+`--yolo` runs an autonomous agent loop with **no approval gate** — it can run any shell command or file edit in its working directory unsupervised. Treat it like handing someone commit access to that worktree.
+
+- **Get explicit user consent** before launching `--yolo` runs. The host harness may also block launching an unsupervised third-party agent until the user has clearly authorized "approvals off"; if a launch is denied, surface it and ask — don't try to work around it.
+- **Contain the blast radius**: dedicated worktree, a branch (never straight onto `main`), and "do not push" in the prompt so nothing leaves the machine without your review.
+- **Never** put secrets in the prompt; `cmd` inherits the environment and its own auth.
+- Review every diff before merging. `--yolo` means *you* are the approval gate, moved to the end.
+
+## Quick reference: dispatch a fleet over GitHub issues
+
+```bash
+BASE=/path/to/worktrees; mkdir -p $BASE
+for spec in "72:publications" "76:webhooks" "78:k8s-sandbox"; do
+  n=${spec%%:*}; slug=${spec##*:}
+  git worktree add -b "feat/issue-$n-$slug" "$BASE/issue-$n" main
+  ( cd "$BASE/issue-$n" && \
+    cmd -p "Implement GitHub issue #$n. Run 'gh issue view $n' and follow it exactly. <restate seams + scope + style + 'do not run pnpm install/build' + exact commit msg + 'do not push' + 'print a summary'>." \
+        --yolo --max-turns 100000 --skip-onboarding > "$BASE/issue-$n.log" 2>&1 ) &
+done
+wait
+# then: review each branch's diff, merge, and run ONE consolidated typecheck/test pass.
+```
+
+Use the `/command-code:dispatch` command for a guided version of this fan-out.