rsc-universal 0.1.1

package/skills/wordpress/scripts/verify.sh

@@ -0,0 +1,96 @@
+#!/usr/bin/env bash
+#
+# verify.sh — static, read-only scan of a WordPress theme/plugin/config tree for
+# the anti-patterns this skill warns about. Emits PASS/FAIL lines.
+#
+# Usage:   scripts/verify.sh [TARGET_DIR]   (default: current directory)
+# Exit:    0 if clean OR target has no PHP to scan; 1 if any FAIL.
+#
+# Read-only: never writes, never modifies. Safe to run in CI.
+
+set -u
+
+TARGET="${1:-.}"
+
+if [ ! -d "$TARGET" ]; then
+  echo "verify.sh: target '$TARGET' is not a directory" >&2
+  exit 2
+fi
+
+# Collect PHP files, ignoring dependency/build/VCS dirs.
+PHP_FILES="$(find "$TARGET" -type f -name '*.php' \
+  -not -path '*/vendor/*' \
+  -not -path '*/node_modules/*' \
+  -not -path '*/.git/*' \
+  -not -path '*/build/*' 2>/dev/null)"
+
+if [ -z "$PHP_FILES" ]; then
+  echo "PASS  no PHP files found under '$TARGET' — nothing to scan"
+  exit 0
+fi
+
+fails=0
+
+# report CHECK_NAME PATTERN_DESC HITS  — runs in the parent shell (no pipe/subshell)
+# so the failure counter survives.
+report() {
+  local name="$1" desc="$2" hits="$3"
+  if [ -n "$hits" ]; then
+    echo "FAIL  $name — $desc"
+    echo "$hits" | sed 's/^/        /'
+    fails=$((fails + 1))
+  else
+    echo "PASS  $name"
+  fi
+}
+
+# grep helper across collected PHP files; prints file:line, never errors out.
+scan() {
+  echo "$PHP_FILES" | tr '\n' '\0' | xargs -0 grep -nE "$1" 2>/dev/null
+}
+
+# 1. Hardcoded DB credentials with a real (non-empty, non-placeholder) value.
+report "no-hardcoded-db-creds" "DB_* defined with a literal value in committed PHP" \
+  "$(scan "define\(\s*['\"]DB_(PASSWORD|USER|NAME|HOST)['\"]\s*,\s*['\"][^'\"]+['\"]" \
+     | grep -viE "database_name_here|username_here|password_here|put your")"
+
+# 2. Salt/auth keys committed with a literal (not the sample placeholder).
+report "no-committed-salts" "AUTH/NONCE key or salt with a literal value" \
+  "$(scan "define\(\s*['\"](AUTH|SECURE_AUTH|LOGGED_IN|NONCE)_(KEY|SALT)['\"]\s*,\s*['\"][^'\"]+['\"]" \
+     | grep -viE "put your unique phrase here")"
+
+# 3. Obfuscation / dynamic-exec smells.
+report "no-eval-obfuscation" "eval()/base64_decode()/gzinflate()/str_rot13()" \
+  "$(scan "\b(eval|base64_decode|gzinflate|str_rot13)\s*\(")"
+
+# 4. query_posts() instead of WP_Query.
+report "no-query-posts" "query_posts() — use WP_Query or pre_get_posts" \
+  "$(scan "\bquery_posts\s*\(")"
+
+# 5. Raw \$wpdb query/get_results with interpolated vars (no prepare on the line).
+report "wpdb-prepared" "\$wpdb call with interpolated variable and no prepare()" \
+  "$(scan "\\\$wpdb->(query|get_results|get_var|get_row|get_col)\s*\(\s*[\"'][^\"']*\\\$" \
+     | grep -v "prepare")"
+
+# 6. Hardcoded script/style tags in templates (must enqueue).
+report "no-hardcoded-assets" "<script src>/<link stylesheet> in PHP — enqueue instead" \
+  "$(scan "<(script[^>]*\bsrc=|link[^>]*\brel=[\"']?stylesheet)")"
+
+# 7. DISALLOW_FILE_EDIT present when a wp-config.php is in scope.
+WPCONFIG="$(echo "$PHP_FILES" | grep -E '/wp-config\.php$' || true)"
+if [ -n "$WPCONFIG" ]; then
+  if echo "$WPCONFIG" | tr '\n' '\0' | xargs -0 grep -qE "define\(\s*['\"]DISALLOW_FILE_EDIT['\"]\s*,\s*true" 2>/dev/null; then
+    echo "PASS  disallow-file-edit"
+  else
+    echo "FAIL  disallow-file-edit — wp-config.php present without define('DISALLOW_FILE_EDIT', true)"
+    fails=$((fails + 1))
+  fi
+fi
+
+echo "---"
+if [ "$fails" -gt 0 ]; then
+  echo "$fails check(s) FAILED"
+  exit 1
+fi
+echo "all checks PASSED"
+exit 0

package/skills/worktrees/SKILL.md

@@ -0,0 +1,199 @@
+---
+name: worktrees
+description: "Use when feature work needs an isolated workspace before code is touched — branch or git worktree off the default branch so the main checkout stays clean while a plan is executed. Triggers: 'isolate this work', 'I don't want to touch main', 'set up a worktree', 'work on a branch for this', 'spin up an isolated checkout', 'start the feature without dirtying my tree', 'create a worktree for the plan', 'I'm on main and need to implement', 'keep the working tree clean', 'parallel checkout for this branch'. The on-demand SDD step that runs right before implement: it confirms a clean, isolated workspace exists (native EnterWorktree first, git worktree fallback), records nothing to runtime, and hands back to implement. NOT the task breakdown (tasks), NOT writing code (implement), NOT branch cleanup/merge after the work (that's the ship phase). Honors the harness accompaniment dial."
+tags: [git, worktree, isolation]
+recommends: []
+profiles: [core, full]
+origin: risco
+---
+
+# worktrees — isolate the work before you touch it
+
+Before you execute a plan you guarantee one thing: **the work happens somewhere that can be thrown
+away without harming the main checkout.** A feature branch keeps history clean; a *worktree* goes
+further — a second working directory on its own branch, so you can build, run, and test the feature
+without disturbing the files you (or another agent, or a running dev server) have open on the
+default branch.
+
+`worktrees` is an **on-demand** step in the SDD chain — not a numbered phase, but the gate that
+`implement` calls when it finds itself on `main`. It does exactly one job: confirm an isolated
+workspace exists, create one if it doesn't, and hand back. It writes no runtime code and leaves no
+artifact under `02-DOCS`; isolation is plumbing, not knowledge.
+
+```text
+constitution → specify → clarify → plan → tasks → analyze → [ worktrees ] → implement → verify → review → ship
+                                                              on-demand, called before the first commit
+```
+
+## The one rule that defines this step
+
+**Never run `implement` on the default branch.** The moment a plan is about to become commits, the
+work belongs in isolation. If `git rev-parse --abbrev-ref HEAD` says `main` or `master`, you stop
+and create the isolated workspace *first* — before the first edit, not after the diff already exists
+on the wrong branch. Recovering a half-built feature off `main` is strictly more expensive than
+branching one command earlier.
+
+## The decision: branch vs. worktree
+
+Both isolate history. A worktree also isolates the *filesystem*. Pick by what's actually in play.
+
+| Situation | Use | Why |
+| --- | --- | --- |
+| Solo, single task, clean tree, no parallel work | **branch** (`git switch -c`) | Cheapest isolation; nothing else needs the main checkout right now. |
+| A dev server, build watcher, or editor is live on the current files | **worktree** | A branch switch yanks files out from under the running process; a worktree leaves them put. |
+| You'll run two streams of work at once (see the parallel pattern) | **worktree** | Each stream gets its own directory; no stash-juggling, no checkout thrash. |
+| The current tree is dirty and the user wants both the WIP and the new work | **worktree** | Stash-and-switch risks losing the WIP; a worktree sidesteps the stash entirely. |
+| You're an agent that may keep the main session running elsewhere | **worktree** | Filesystem isolation is the whole point — the parent session keeps its files. |
+
+When in doubt, prefer a **worktree**: it is the strictly stronger isolation and the cost is one
+extra directory. The rest of this skill assumes a worktree; the branch path is the degenerate case
+(skip the directory, keep the branch).
+
+## Before you create anything — the pre-flight gate
+
+Run this in order. Each check prevents a class of "lost work" you can't easily undo.
+
+1. **Read the accompaniment dial.** Open `02-DOCS/wiki/harness/user-profile.md` for the technical +
+   accompaniment level (L0..L3) — it sets how much you narrate and whether you confirm before acting
+   (see the dial table below). No profile yet → assume non-technical, explain what a worktree is in
+   one plain sentence before making one. No `02-DOCS/` at all (a worktree can be created in any git
+   repo with no rsc harness present) → skip the dial, assume non-technical, and proceed.
+2. **Confirm you're in a git repo.** `git rev-parse --is-inside-work-tree`. If not, there's nothing
+   to isolate with git — tell the user; don't fabricate a worktree.
+3. **Check the current branch.** `git rev-parse --abbrev-ref HEAD`. On `main`/`master` with work
+   about to start → this skill is exactly right. Already on a feature branch with a clean tree →
+   isolation may already be sufficient; say so and don't create a redundant one.
+4. **Check the tree state.** `git status --short`. A **dirty tree is a fork in the road**, not a
+   thing to bulldoze:
+   - Uncommitted changes that belong to the *new* feature → a worktree built from a clean base means
+     those changes stay on the old branch. Surface this; ask whether to commit/stash them first or
+     carry them over. Never silently leave a user's WIP behind.
+   - Unrelated WIP → that's the textbook reason to use a worktree (isolate the new work, leave the
+     WIP exactly where it sits).
+5. **Pick the base ref.** Branch from an up-to-date default branch unless the user wants to build on
+   local HEAD. Stale base = predictable merge pain later. Default: fresh from `origin/<default>`.
+6. **Choose a name** tied to the feature slug — the same `<slug>` the spec and plan use
+   (`feat/<slug>`), so the branch, the spec at `02-DOCS/wiki/sdd/specs/<slug>.md`, and the plan at
+   `02-DOCS/wiki/sdd/plans/<slug>.md` all line up and are trivially traceable.
+
+Only once the tree state is understood and the user's WIP is accounted for do you create anything.
+
+## Creating the workspace — native first, git fallback
+
+**Prefer the native worktree tool when it's available in your environment.** An `EnterWorktree`-style
+tool typically creates an isolated worktree (often under something like `.claude/worktrees/`, though
+the exact location is tool-dependent), switches the session into it, and tracks it for clean exit —
+which is exactly the lifecycle this skill wants, with no manual path management.
+
+- **Enter:** create/enter the worktree (e.g. an `EnterWorktree`-style native tool, named for the
+  feature slug). The session's working directory moves into the isolated checkout.
+- **Exit:** on the native tool, `keep` to leave the worktree and branch on disk for later, `remove`
+  to delete both when the work is done or abandoned. Removal of a worktree holding uncommitted or
+  unmerged work must be an explicit, confirmed choice — never a silent cleanup.
+
+If no native worktree tool is present, fall back to plain git. The mechanics:
+
+```bash
+# from the repo root, default branch up to date
+git fetch origin
+git worktree add -b feat/<slug> ../<repo>-<slug> origin/<default-branch>
+# work happens in ../<repo>-<slug>; the main checkout is untouched
+```
+
+```bash
+# branch-only path (the degenerate case: no separate directory needed)
+git switch -c feat/<slug> origin/<default-branch>
+```
+
+```bash
+# when the work is done and merged (or abandoned) — clean up the worktree
+git worktree remove ../<repo>-<slug>      # refuses if dirty; resolve first, don't force blindly
+git branch -d feat/<slug>                  # -d (safe) not -D, unless the user confirms discarding
+```
+
+Either way, the contract is identical: **after this step, the cwd is an isolated branch off a clean
+base, and the default-branch checkout is exactly as it was.** Confirm that out loud (at the dial's
+level) before handing to `implement`.
+
+## Native vs. git fallback — which you're using
+
+| You have… | Create | Leave intact | Discard |
+| --- | --- | --- | --- |
+| A native worktree tool (`EnterWorktree`-style) | enter, named for the slug | exit with `keep` | exit with `remove` (confirm if dirty/unmerged) |
+| Plain git only | `git worktree add -b feat/<slug> …` | leave the dir; it persists | `git worktree remove` + `git branch -d` |
+
+The native tool is preferred because it owns the session-switch and the exit lifecycle for you. The
+git path is the universal fallback and is exactly what the native tool does under the hood.
+
+## Adapting to the dial
+
+Read `02-DOCS/wiki/harness/user-profile.md` and match your volume — the isolation is identical at
+every level; only the talking changes.
+
+| Level | How `worktrees` behaves |
+| --- | --- |
+| **L0** | Create the isolated workspace, state the branch/dir in one line, hand to `implement`. No explanation. |
+| **L1** | Same, plus one line of *why* a worktree over a branch (or vice-versa) for this case. |
+| **L2** | Justify the base-ref choice and the branch-vs-worktree call; surface the dirty-tree decision explicitly. |
+| **L3** | Explain in plain language what a worktree is and why isolation protects their work; ask before touching any uncommitted changes; confirm the base ref. |
+
+At every level, a **dirty tree with the user's uncommitted work is a hard stop for a confirmation** —
+the dial controls verbosity, never whether you check before risking someone's WIP.
+
+## Anti-patterns → STOP
+
+| Rationalization | Reality / Fix |
+| --- | --- |
+| "I'll just implement on `main`, it's a small change" | Small changes become commits on the wrong branch. Branch/worktree first — always, before the first edit. |
+| "There's uncommitted WIP, I'll stash it and switch" | A worktree avoids the stash entirely and can't drop it. Use a worktree; if you must stash, confirm with the user and name the stash. |
+| "I'll branch off local HEAD, fetching is slow" | Stale base = merge conflicts you pay for later. Branch off an up-to-date `origin/<default>` unless the user wants HEAD. |
+| "The worktree's dirty but I'll `remove --force` to clean up" | Force-removing a dirty/unmerged worktree throws away work irreversibly. Resolve or confirm explicitly first; never silent-force. |
+| "I'll name it `wip` / `temp` / `branch2`" | An untraceable name divorces the branch from its spec/plan. Name it `feat/<slug>` to match the SDD artifacts. |
+| "I'll create the worktree AND start writing code right here" | This skill only isolates. Hand a clean isolated workspace to `implement`; don't blur the two steps. |
+| "Already on a feature branch, I'll make a worktree anyway" | Redundant isolation is just clutter. If the current branch is already isolated and clean, say so and proceed. |
+| "I'll record the worktree path into 02-DOCS so it's tracked" | Isolation is plumbing, not knowledge. No artifact; the branch name traces it. Don't pollute the wiki. |
+
+## Red flags — stop and re-route
+
+- **Not a git repo** → nothing to isolate with git. Tell the user; don't invent a workspace.
+- **Dirty tree you don't understand** → don't bulldoze it. Surface every modified path and ask
+  before branching/stashing. Lost WIP is the one unrecoverable failure here.
+- **Asked to merge, open a PR, or delete the branch after the work** → that's `../ship/SKILL.md`, not
+  this one. This skill opens isolation; ship closes it.
+- **Asked to actually write the feature code** → that's `../implement/SKILL.md`. Create the workspace,
+  then hand off; don't start coding in this step.
+- **A native `remove`/`git worktree remove` would drop uncommitted or unmerged work** → refuse the
+  silent path. Confirm the discard explicitly with the user, quoting what would be lost.
+
+## Checklist (copy when isolating)
+
+```text
+- [ ] Read the accompaniment dial (user-profile.md); set verbosity
+- [ ] Confirmed inside a git repo
+- [ ] Checked current branch; on main/master if implement is next
+- [ ] Checked `git status --short`; accounted for any uncommitted WIP (asked, didn't bulldoze)
+- [ ] Picked base ref (fresh origin/<default> unless user chose HEAD)
+- [ ] Named the workspace feat/<slug> to match the spec/plan artifacts
+- [ ] Created isolation: native worktree tool if available, else git worktree (branch = degenerate case)
+- [ ] Confirmed: cwd is the isolated branch; the main checkout is untouched
+- [ ] Wrote NO runtime code and NO 02-DOCS artifact here
+- [ ] Handed off to implement
+```
+
+## What this skill is NOT
+
+- **Not the task breakdown.** Slicing the plan into ordered, verifiable tasks is `../tasks/SKILL.md`.
+- **Not the coding.** Writing the feature test-first, task by task, is `../implement/SKILL.md`.
+- **Not branch cleanup / merge / PR.** Closing the branch — merge, PR, or discard, with Eric-only
+  git authorship — is `../ship/SKILL.md`. This skill only *opens* the isolation.
+- **Not a place for runtime or wiki artifacts.** It touches git state only; nothing under `02-DOCS`.
+
+## Where you are in the chain
+
+`constitution` → `specify` → `clarify` → `plan` → `tasks` → `analyze` → **worktrees** (on-demand) →
+`implement` → `verify` → `review` → `ship`. The **parallel** pattern leans on this skill too: each
+independent stream gets its own worktree so the streams never fight over files.
+
+**Next:** with a clean isolated workspace in hand, hand to **`../implement/SKILL.md`** — walk the
+task list test-first, one commit per task, on this branch. When the feature is built and verified,
+**`../ship/SKILL.md`** closes the branch.

package/skills/worktrees/evals/README.md

@@ -0,0 +1,78 @@
+# Eval harness — `worktrees` skill
+
+These evals are run by an **agent harness** (an LLM agent with the rsc-sdd + stack skill catalog
+available), not a byte-exact shell script. `cases.yaml` is the fixture; this file is the procedure.
+Grading is judgment-based — a human or a judge-agent scores against the rubrics.
+
+`worktrees` is a process skill — an **on-demand** SDD step that runs right before `implement`. It is
+judged on **routing accuracy** (does it fire only when the intent is *isolate a workspace before
+code is touched*, and stay silent on the adjacent coding/cleanup/diagnosis steps) and **capability**
+(does it run the pre-flight gate, pick branch-vs-worktree correctly, prefer the native tool, and
+hand off without writing code).
+
+## 1. Triggering accuracy
+
+Goal: `worktrees` fires when the user wants an isolated workspace before implementing, and stays
+silent on the neighbouring steps (the coding loop, the task breakdown, the branch cleanup/ship, the
+debug protocol, the workspace bootstrap).
+
+1. Load **only** the `worktrees` skill description into the agent, plus the bare names of the sibling
+   skills for routing: the rsc-sdd phases (constitution, specify, clarify, plan, tasks, analyze,
+   implement, verify, review, ship, debug, parallel) and the stack/other skills (fastapi, nextjs,
+   go, postgresdb, flutter, design, marketing, presentations, course-storytelling, building-agents,
+   secure-coding, deployment, harness, init). Do **not** load any skill bodies.
+2. For each prompt in `should_trigger` and `should_not_trigger`, ask the agent which skill (if any)
+   it would invoke. Run **3–5 trials per prompt** at production temperature to catch flakiness.
+3. Score:
+   - `should_trigger` → PASS if `worktrees` is selected in the majority of trials.
+   - `should_not_trigger` → PASS if `worktrees` is **not** selected; bonus-correct if it routes to
+     the `route_to` sibling named in the case.
+4. **Pass bar: ≥ 90% of prompts pass** (at most 1 miss across the 12 prompts), and no
+   `should_not_trigger` prompt may fire `worktrees` in a majority of its trials. The two
+   highest-value near-misses to get right are `implement` (the phase immediately after — coding on an
+   already-isolated branch must NOT re-trigger isolation) and `ship` (the phase that *closes* the
+   branch — merge/PR/cleanup is not this skill's open-isolation job).
+
+### Routing note (which siblings exist on disk)
+
+`route_to` is a conceptual label, not a link. All five near-miss targets — `implement`, `tasks`,
+`ship`, `debug`, `harness` — exist as skill directories in this repo, so each route is to a real
+sibling. The skill body links the resolvable cross-references it uses (`../implement/SKILL.md`,
+`../tasks/SKILL.md`, `../ship/SKILL.md`) and names the on-demand `parallel` / `debug` patterns in
+prose; verify links still resolve if the catalog is reorganized.
+
+## 2. Capability uplift (with vs without)
+
+Goal: the skill measurably improves the isolation step, not just gates it.
+
+1. For the `capability` scenario, run the agent **twice**:
+   - **WITHOUT**: base agent, no `worktrees` skill loaded.
+   - **WITH**: same prompt, `worktrees` skill fully loaded.
+2. Grade each output against the `must_include` checklist — count a point only if it is genuinely
+   satisfied, not merely gestured at. The load-bearing points are: the pre-flight gate (repo +
+   branch + `git status` before acting), the branch-vs-worktree decision justified by the live dev
+   server, preferring the native tool with a git fallback, a slug-matched name, and handing off to
+   `implement` without writing code.
+3. Coverage = points satisfied / total points, per run.
+4. **Pass bar:**
+   - WITH-skill coverage **≥ 80%** of the rubric.
+   - WITH clearly beats WITHOUT. The signature uplift to look for: the WITHOUT run tends to run a
+     bare `git checkout -b` (or even start editing on `main`), skip the dirty-tree check, ignore the
+     native tool, and blur straight into writing code; the WITH run runs the pre-flight gate, picks a
+     *worktree* because a process is live on the current files, names it `feat/<slug>`, confirms the
+     main checkout is untouched, and hands to `implement`.
+5. Run 2–3 trials per condition and average; note any rubric point the skill never produces — that is
+   a gap to fix in `SKILL.md`.
+
+## Notes
+
+- Prompts deliberately vary phrasing; several omit the word "worktree" (the live-dev-server case, the
+  dirty-WIP case) so triggering rests on the signal "isolate a workspace before touching code", not
+  keyword matching.
+- Near-misses route to the genuinely correct sibling: already-isolated-now-code → implement,
+  plan-to-checklist → tasks, merge/PR/cleanup → ship, failing-test-root-cause → debug,
+  workspace-bootstrap → harness.
+- The one unrecoverable failure mode for this skill is bulldozing a user's uncommitted WIP; the
+  capability rubric and the SKILL.md red flags both gate on checking `git status` before acting.
+- This is judgment-based, not byte-exact. Record trial counts and the judge (human or model)
+  alongside results for reproducibility.

package/skills/worktrees/evals/cases.yaml

@@ -0,0 +1,47 @@
+skill: worktrees
+
+should_trigger:
+  - prompt: "Before we start building this feature I want it isolated from my main checkout — set up a worktree so my open files don't get disturbed."
+    why: "Explicit request for filesystem isolation via a worktree before code is touched — the exact job this skill owns."
+  - prompt: "I'm on main and about to implement the plan. I don't want to dirty my working tree — get me onto something I can throw away."
+    why: "On the default branch, implement is next, wants disposable isolation first — the on-demand gate that runs right before implement."
+  - prompt: "Spin up an isolated checkout on a branch for the checkout-reservation work, branched off an up-to-date main."
+    why: "Isolated checkout + feature branch + fresh base ref is precisely the worktree creation flow, including the base-ref decision."
+  - prompt: "My dev server is running against the current files and I need to start a second stream of work without yanking the files out from under it."
+    why: "Live process on current files is the textbook reason to prefer a worktree over a branch switch — non-obvious phrasing, no keyword 'worktree'."
+  - prompt: "I've got uncommitted WIP I want to keep, but I also need to start the new feature cleanly somewhere else. How do I do both?"
+    why: "Dirty tree + need both the WIP and clean new work is the canonical worktree case (avoid the stash, isolate the new work)."
+  - prompt: "Keep the working tree clean while I execute this plan — create the branch/worktree and then we code."
+    why: "Wants isolation established before executing the plan, then hand to implement — the open-isolation-then-handoff contract."
+  - prompt: "Make me a parallel checkout for feat/notifications so I can build it alongside what I already have open."
+    why: "Parallel checkout for a named feature branch alongside existing open work — a worktree by definition, even without the framing of SDD phases."
+
+should_not_trigger:
+  - prompt: "The isolated branch is ready. Now walk the task list test-first and write the code, one commit per task."
+    route_to: "implement"
+    why: "Isolation already exists; this is the test-first coding loop, which is implement, not the workspace-setup step."
+  - prompt: "We have the approved plan. Break it into an ordered checklist where each item has a done-check I can verify."
+    route_to: "tasks"
+    why: "Slicing the plan into an ordered, verifiable task list is the tasks phase; no isolation request here."
+  - prompt: "The feature's built and all tests pass. Merge the branch, open the PR, and clean up the worktree afterward."
+    route_to: "ship"
+    why: "Closing the branch — merge/PR/cleanup with Eric-only authorship — is the ship phase; this skill only OPENS isolation."
+  - prompt: "A test is failing for a reason I don't understand on this branch. Help me find the root cause before I change anything."
+    route_to: "debug"
+    why: "Root-cause diagnosis of a failing test is the debug protocol, not workspace isolation."
+  - prompt: "I want the canonical 01-TOOLS and 02-DOCS layout set up for this workspace and the root CLAUDE.md generated."
+    route_to: "harness"
+    why: "Bootstrapping the workspace control plane is the harness skill; nothing to do with git isolation for a feature."
+
+capability:
+  - scenario: "User says: 'I'm on main with a clean tree, the plan for the order-reservation feature (slug: order-reservation) is approved, and I'm about to implement it. My editor and a dev server are open against the current files. Set up isolation.' The agent has the worktrees skill loaded and a native worktree tool available."
+    must_include:
+      - "Runs the pre-flight gate: confirms it's a git repo, checks current branch (main), and checks `git status --short` for tree state before creating anything"
+      - "Reads 02-DOCS/wiki/harness/user-profile.md for the accompaniment dial and matches narration to the level"
+      - "Chooses a WORKTREE over a plain branch and justifies it by the live dev server / open editor on the current files (a branch switch would yank files from the running process)"
+      - "Prefers the native worktree tool (EnterWorktree-style) for creation and session-switch, naming it for the slug (feat/order-reservation); states the git `git worktree add -b feat/order-reservation … origin/<default>` fallback if no native tool exists"
+      - "Branches from an up-to-date default base (fresh origin/<default>) rather than stale local HEAD, or asks which the user wants"
+      - "Names the workspace to match the spec/plan slug (feat/order-reservation) so branch, spec, and plan are traceable"
+      - "Confirms the contract out loud: cwd is now the isolated branch and the main checkout is untouched"
+      - "Writes NO runtime code and NO 02-DOCS artifact in this step (isolation is plumbing, not knowledge)"
+      - "Hands off to the implement phase rather than starting to write the feature code itself"