workspace-init

What this skill does

# workspace-init

Set up (or refresh) a workspace for the `engineer-toolkit` plugin's Jira-driven dev workflow. Interactive — runs in the current chat session.

## Invocation

`/workspace-init` — no arguments.

## Phase 0 — Prerequisite check

Verify each required plugin is **both installed AND enabled**. These are two separate things:

- **Installed** — present in `~/.claude/plugins/installed_plugins.json` under the `plugins` key.
- **Enabled** — set to `true` in `enabledPlugins` in `~/.claude/settings.json` (user-level) or in `<cwd>/.claude/settings.json` (project-level). Either one is sufficient.

A plugin can be installed but disabled (the user installed it once, then disabled it via `/plugin`). MCP calls to a disabled plugin fail at runtime with a confusing error, so we gate up front.

**Required plugins:**
- `superpowers@claude-plugins-official`
- `atlassian@claude-plugins-official`
- `playwright@claude-plugins-official`

**Optional plugins (warn only, do not gate):**
- `csharp-lsp@claude-plugins-official`
- `claude-md-management@claude-plugins-official`

### Check algorithm

For each required plugin `<name>@<marketplace>`:

1. Read `~/.claude/plugins/installed_plugins.json`. If `plugins["<name>@<marketplace>"]` is missing or its array is empty → status is **not-installed**.
2. Else read `~/.claude/settings.json` and (if it exists) `<cwd>/.claude/settings.json`. If `enabledPlugins["<name>@<marketplace>"] === true` in either → status is **enabled**. Otherwise → status is **installed-but-disabled**.

Apply the same algorithm to optional plugins; warn only, do not gate.

For each required plugin not in **enabled** state, print the matching remediation block:

```
[!] Required plugin <status>: <plugin-name>
    <fix>
    <secondary-line>
```

Status / fix / secondary-line by case:

| Case | `<status>` | `<fix>` | `<secondary-line>` |
|---|---|---|---|
| not-installed | `not installed` | `Install: in Claude Code, run /plugin → Discover → install "<short-name>"` | `Marketplace: <marketplace-name>` |
| installed-but-disabled | `installed but disabled` | `Enable: in Claude Code, run /plugin → enable "<short-name>"` | `Or edit ~/.claude/settings.json: set enabledPlugins["<plugin>@<marketplace>"] to true` |

For each missing optional plugin, print a warning but continue.

If any required plugin is missing/disabled, prompt:

```
Continue with workspace setup anyway? (yes / no)  [default: no]
```

If the user picks `no`, exit without scaffolding.

## Phase 0.5 — CLI binary check

Warn-only: these tools aren't validated by the plugin system but are required by individual skills later in the workflow. The checks don't gate initialization — they tell the user what'll break and where.

Run the checks in parallel via Bash. Treat a non-zero exit as "not configured."

| Tool | Why it matters | Check |
|---|---|---|
| `git` | All repo cloning + branch ops in `/work`, `/direct`, `/smoke` | `git --version` |
| `dotnet` | `dotnet build`/`dotnet test` in `/author-review` and `/smoke` | `dotnet --version` |

> The GitHub CLI (`gh`) is intentionally not checked. PCI hosts code on Azure DevOps on-prem, where `gh` doesn't work — the review skills fall back to user-supplied diffs / local `git diff`. See workflow doctrine "No GitHub CLI".

For each failed check, print:

```
[!] CLI tool not configured: <tool>
    Needed by: <skill list>
    Install: <one-line pointer>
    Continuing — will fail later when that skill runs.
```

Suggested install pointers:

- `git` → `winget install Git.Git` (or https://git-scm.com/)
- `dotnet` → `winget install Microsoft.DotNet.SDK.9`

Then always print one info note (regardless of outcomes above):

```
[i] Dashboard links use vscode://file/<path>. If you use a different editor:
      Cursor              → works automatically (cursor://file/<path>)
      VS Code Insiders    → works automatically (vscode-insiders://file/<path>)
      Visual Studio, JetBrains, Sublime → no native URL handler; links open the OS picker
    Override in <workspace>\CLAUDE.md under "Open-in-editor links".
```

No prompt. Proceed to Phase 1 regardless.

## Phase 1 — Detect existing workspace

Default workspace path: `C:\ClaudeWorkspace`.

If the default path doesn't exist → skip directly to Phase 2 with the default path.

If the default path exists, classify it by checking for files in this order:

| Detected | Classification | Refresh behavior |
|---|---|---|
| `<workspace>\.engineer-toolkit\VERSION` exists and matches plugin version | **Up to date** | `refresh` is a no-op — offer to skip |
| `<workspace>\.engineer-toolkit\VERSION` exists but older than plugin version | **Doctrine out of date** | `refresh` overwrites `workflow.md` + `VERSION` only; CLAUDE.md untouched |
| `<workspace>\.engineer-toolkit\` missing AND `<workspace>\CLAUDE.md` exists | **Pre-split workspace** | Migration path (see below) |
| None of `<workspace>\CLAUDE.md`, `Active\`, `Complete\` present | **Empty-ish** | Treat as new — skip to Phase 2 |

The plugin version comes from `${CLAUDE_PLUGIN_ROOT}/.claude-plugin/plugin.json` → `version`.

### Prompt (Up to date / Doctrine out of date)

```
Workspace at <path>: <classification tag>
  refresh        — overwrite <workspace>\.engineer-toolkit\workflow.md and VERSION with the
                   latest plugin doctrine. CLAUDE.md, Active\, Complete\, Archive\ are never
                   touched.
  pick-different — choose a different workspace path.
  cancel         — exit without changes.
```

### Pre-split migration (one-time)

When `.engineer-toolkit\` is missing but `CLAUDE.md` exists, the workspace was created by an older version of the plugin. Migrate before scaffolding:

1. Read `<workspace>\CLAUDE.md`. Parse the `## Configuration` section's table rows. Extract:
   - `Workspace path` → use as the workspace path (sanity-check matches the path we're inspecting)
   - `User Account ID`
   - `User Name`
   Tolerate either the old single-table layout or the User-specific/Org-wide split layout — both have the same row labels.
2. Prompt:

   ```
   Pre-split workspace detected at <path>. Migration will:
     - Extract your Configuration values from the existing CLAUDE.md (User Account ID, User Name).
     - Back up the existing CLAUDE.md to CLAUDE.md.bak-<YYYYMMDDHHMMSS>.
     - Write a new minimal CLAUDE.md (Configuration table + one @import line).
     - Write <workspace>\.engineer-toolkit\workflow.md (plugin doctrine, managed file).
     - Write <workspace>\.engineer-toolkit\VERSION.
   Active\, Complete\, Archive\ are untouched.
   Type `migrate` to proceed, anything else to cancel.
   ```

3. If the user types `migrate`, store the extracted values for Phase 3 (skipping Phase 2's collection) and continue. Otherwise, exit.

If extraction fails (e.g., CLAUDE.md is mangled and the Configuration rows can't be found), fall through to Phase 2 — collect values fresh, but still back up the existing file before write.

## Phase 2 — Collect user-specific config

Skip this phase entirely if Phase 1 returned `migrate` (the values were extracted from the existing CLAUDE.md). Skip if Phase 1 returned `refresh` (we're only rewriting doctrine, not CLAUDE.md). Run only for new workspaces.

Prompt for two values (one at a time, via AskUserQuestion or chat):

1. **Workspace path** — default `C:\ClaudeWorkspace`. Accept any absolute path. Create it if it doesn't exist.

2. **Jira account ID** — first try the `atlassianUserInfo` MCP tool. If it returns a valid account ID, use it without prompting. Otherwise prompt:

   ```
   Couldn't auto-detect your Jira account ID. Enter it (looks like 712020:abc-123-...):
   ```

3. **Display name** — first try `atlassianUserInfo` for the user's display name. If it returns a name, use it without prompting. Otherwise prompt for it.

## Phase 3 — Scaffold the workspace

The plugin's templates live at `${CLAUDE_PLUGIN_ROOT}/templates/` (`CLAUDE_PLUGIN_ROOT` is set by Claude Code when a plugin's skill runs). The plugin version com