/init-workspace

name: init-workspace
description: >
  One-time workspace setup for the ai-sdlc-harness pipeline. USER-ENTRY and
  HUMAN-ONLY — invoke only when the user explicitly runs /init-workspace;
  never autonomously, never from a subagent (guard-enforced).

init-workspace — the interview (M7)

Human-only: the user's consent point for the whole workspace. Every command below is `${CLAUDE_PLUGIN_ROOT}/bin/harness <verb> …` — always the full path; a bare `harness` is not on PATH, and shell variables set in one Bash call do not persist to the next. Re-running refreshes **one section at a time** (`init-section`), never a full-nuke.

0 · Environment bootstrap (do this FIRST)

**Resolve the plugin root.** Under native Qwen Code (no Claude-plugin conversion), `${CLAUDE_PLUGIN_ROOT}` is not exported until step 6 writes `.qwen/settings.json`, and even then only next session. Each Bash call is a fresh subprocess (an `export` won't persist), so the probe **prints** the resolved path for you to substitute textually; if the var is already set (Claude Code, converted install) the probe passes it through unchanged:

**Folder-trust caveat (Qwen Code):** project-level `.qwen/settings.json` is silently ignored unless the folder is trusted (trusted-folders is OFF by default, measured on 0.22.2) — the `CLAUDE_PLUGIN_ROOT` export and the permission mirror don't apply, so subagents hit the prompts the allowlist was meant to pre-clear. The pipeline's hooks are unaffected (they ship with the extension). Remedy: trust the folder (Qwen `/permissions` → Trust this folder, then restart) or export `CLAUDE_PLUGIN_ROOT` in the launching shell.

# Resolve the plugin root and print it (native Qwen first-run fallback)
R="${CLAUDE_PLUGIN_ROOT:-}"
[ -z "$R" ] && for d in "$HOME/.qwen/extensions/ai-sdlc-harness/bin/harness" \
  "$HOME/.qwen/extensions/ai-sdlc-harness/.qwen-extension-install.json"; do
  [ -e "$d" ] && { case "$d" in *install.json) R=$(python3 -c \
    "import json,sys;print(json.load(open(sys.argv[1])).get('source',''))" "$d");; \
    *) R=$(dirname "$(dirname "$d")");; esac; [ -x "$R/bin/harness" ] && break; }; done
[ -x "$R/bin/harness" ] || { echo "ERROR: set CLAUDE_PLUGIN_ROOT to the dir with bin/harness" >&2; exit 1; }
echo "PLUGIN_ROOT=$R"

**Use the printed `PLUGIN_ROOT=<path>` in place of every `${CLAUDE_PLUGIN_ROOT}` below** for this skill run.

The harness needs PyYAML; system pythons are often externally managed (PEP 668), so the plugin owns a venv that `bin/harness` resolves automatically thereafter. Bootstrap it through ONE dual-clause command — same shape as `hooks/run-guard`'s launcher pair, and for the same reason: the platform picks the interpreting shell, not us. Claude Code's Bash tool always runs bash (Git Bash on Windows); Qwen Code's `run_shell_command` shares hooks' shell-selection logic and falls back to cmd.exe on Windows outside an MSYS-flavored terminal, where a `NAME="$(command …)"`-shaped POSIX assignment is unparseable (cmd treats `=` as an argument delimiter):

exec "${CLAUDE_PLUGIN_ROOT}/bin/setup-venv" || ${CLAUDE_PLUGIN_ROOT}/bin/setup-venv

`exec` replaces bash with the launcher, so the second clause only ever runs under cmd.exe (where `exec` fails fast and `||` falls through to the unquoted path, PATHEXT-resolved to `setup-venv.cmd`). Both halves probe both `.venv` layouts (`bin/` POSIX, `Scripts/` Windows) and the same `python3` → `python` fallback, then exit once PyYAML is importable. Until this step runs, `bin/harness` still works (falling back to the same system-interpreter probe, which is what fails on a PyYAML-less system — hence this step), and the spawn/skill guards degrade open with a one-line notice: expected pre-setup behavior, not a bug to chase.

1 · Must-provide (no defaults — ask)

• **Work-item provider**: local-markdown / github / github-projects / gitlab /

ado (CLI) / ado-mcp / jira / zoho (MCP — walk the user through the model-in-the-loop probe). Two come in pairs: `ado` = `az boards` vs `ado-mcp`; `github` = repo issues vs `github-projects` = a Projects v2 board. Plus specifics (stories dir, `github_repo`, `github_project`/`_owner`, …).

• **Git provider**: local / github / gitlab / ado (CLI) / ado-mcp (MCP).

If the user didn't state one, `local` is the sanctioned inference ONLY when every registered repo has no remote (`git remote` empty) — say so in one line rather than asking; any repo with a remote → ask.

• **Repos**: `name=path` per target repo.

Every `init-section` write is merged straight into the flat config by its top-level keys, so `provider`, `repos`, and `language` payloads must be **self-nested** under their own section key. If any `init-section` result carries a `notice` key, relay its text to the user verbatim:

${CLAUDE_PLUGIN_ROOT}/bin/harness init-section --section provider --json \
  '{"provider": {"work_item": "local-markdown", "git": "local", "stories_dir": "stories"}}'
${CLAUDE_PLUGIN_ROOT}/bin/harness init-section --section repos --json \
  '{"repos": {"backend": "/path/to/backend", "frontend": "/path/to/frontend"}}'

`overrides` is the one exception on both counts: it's a flat grab-bag of top-level config keys (`status_mapping`, `subagent_models`, `quick_mode`, …), never self-nested under an `"overrides"` key, and unlike `provider`/`repos`/`language` (each write replaces the whole file — always send the complete current set) its writes **merge**, so separate `--section overrides` calls accumulate rather than clobbering each other. See step 3.

2 · Discovered, then confirmed

Run `${CLAUDE_PLUGIN_ROOT}/bin/harness discover --repo <path>` per repo. It first ensures the repo is clean and on its default branch (`ensure_default_branch` — the precondition `preflight` reuses later): a dirty or mid-rebase/merge repo refuses with a clear error — surface it to the user (never auto-stash/discard/continue) — and a clean repo on a different branch is switched, reported in `branch_check` so you ca