@plainconceptsplatform/agent-harness 2.0.0 → 2.1.0

package/src/fragments/ops-ship/gl.md

@@ -1,86 +1,86 @@
-**ALL GitLab data MUST come from `glab` CLI. NEVER use webfetch, HTTP requests, or browser MCP tools for GitLab operations, even if glab CLI fails. If `glab` is unavailable, report as a blocker.**
-Always pass `--repo {owner}/{repo}` explicitly, never rely on git context to resolve the repo.
-
----
-
-### Step 1: Verify feature branch
-
-```bash
-BRANCH="$(git branch --show-current)"
-DEFAULT_BRANCH="$(git symbolic-ref --short refs/remotes/origin/HEAD 2>/dev/null | sed 's|^origin/||')"
-[ -z "$DEFAULT_BRANCH" ] && DEFAULT_BRANCH="main"
-```
-
-`$BRANCH` must be a work branch (`feature/*` or `bugfix/*`: the `pc-plan-apply` skill creates `feature/{change-slug}`). NEVER push the default branch.
-
-### Step 2: Capture screenshots (if UI changes exist)
-
-```bash
-browser_navigate url="http://localhost:{port}/{route}"
-browser_wait ms=2000
-browser_screenshot
-```
-
-Save to: `openspec/changes/{change-name}/images/{feature}.png`
-
-### Step 3: Commit and push
-
-The `pc-plan-apply` skill already committed each task group: usually only screenshots or small residuals remain. Stage **specific paths only** (never `git add -A`, it sweeps unrelated files into the ship commit):
-
-```bash
-git add openspec/changes/{change-name}/images/  # plus any other paths you actually changed
-git commit -m "{change}: {summary}"   # only if there is something to commit
-git push -u origin "$BRANCH"
-```
-
-### Step 4: Upload screenshots (if any)
-
-If screenshots exist, upload them so they can be referenced in the MR description:
-
-```bash
-glab api --method POST "projects/:id/uploads" -f "file=@openspec/changes/{change-name}/images/{feature}.png"
-```
-
-(`:id` is glab's placeholder for the current project: this is the one sanctioned use of git context in this skill.)
-
-Parse the returned `markdown` field: use it to embed the image in the MR description. If the upload fails (the endpoint needs multipart form data and `-f` support varies by glab version), fall back to referencing the image committed on the branch instead.
-
-If no UI changes, skip this step.
-
-### Step 5: Create Merge Request
-
-```bash
-glab mr create \
-  --source-branch "$BRANCH" \
-  --target-branch "$DEFAULT_BRANCH" \
-  --title "{title}" \
-  --description "Closes {issue-link}
-
-## Summary
-{summary from proposal.md}
-
-## Changes
-{key changes from tasks.md}
-
-## Test plan
-- [ ] {checklist of manual verification steps}
-{screenshots if available}" \
-  --remove-source-branch \
-  --squash-before-merge
-```
-
-Do NOT use `--yes` unless running in autopilot/non-interactive mode.
-
-### Step 6: Report
-
-Display:
-
-```text
-Merge Request created
-  MR: {mr-url}
-  Title: {title}
-  Source: {branch}
-  Target: {default-branch}
-```
-
+**ALL GitLab data MUST come from `glab` CLI. NEVER use webfetch, HTTP requests, or browser MCP tools for GitLab operations, even if glab CLI fails. If `glab` is unavailable, report as a blocker.**
+Always pass `--repo {owner}/{repo}` explicitly, never rely on git context to resolve the repo.
+
+---
+
+### Step 1: Verify feature branch
+
+```bash
+BRANCH="$(git branch --show-current)"
+DEFAULT_BRANCH="$(git symbolic-ref --short refs/remotes/origin/HEAD 2>/dev/null | sed 's|^origin/||')"
+[ -z "$DEFAULT_BRANCH" ] && DEFAULT_BRANCH="main"
+```
+
+`$BRANCH` must be a work branch (`feature/*` or `bugfix/*`: the `pc-plan-apply` skill creates `feature/{change-slug}`). NEVER push the default branch.
+
+### Step 2: Capture screenshots (if UI changes exist)
+
+```bash
+browser_navigate url="http://localhost:{port}/{route}"
+browser_wait ms=2000
+browser_screenshot
+```
+
+Save to: `openspec/changes/{change-name}/images/{feature}.png`
+
+### Step 3: Commit and push
+
+The `pc-plan-apply` skill already committed each task group: usually only screenshots or small residuals remain. Stage **specific paths only** (never `git add -A`, it sweeps unrelated files into the ship commit):
+
+```bash
+git add openspec/changes/{change-name}/images/  # plus any other paths you actually changed
+git commit -m "{change}: {summary}"   # only if there is something to commit
+git push -u origin "$BRANCH"
+```
+
+### Step 4: Upload screenshots (if any)
+
+If screenshots exist, upload them so they can be referenced in the MR description:
+
+```bash
+glab api --method POST "projects/:id/uploads" -f "file=@openspec/changes/{change-name}/images/{feature}.png"
+```
+
+(`:id` is glab's placeholder for the current project: this is the one sanctioned use of git context in this skill.)
+
+Parse the returned `markdown` field: use it to embed the image in the MR description. If the upload fails (the endpoint needs multipart form data and `-f` support varies by glab version), fall back to referencing the image committed on the branch instead.
+
+If no UI changes, skip this step.
+
+### Step 5: Create Merge Request
+
+```bash
+glab mr create \
+  --source-branch "$BRANCH" \
+  --target-branch "$DEFAULT_BRANCH" \
+  --title "{title}" \
+  --description "Closes {issue-link}
+
+## Summary
+{summary from proposal.md}
+
+## Changes
+{key changes from tasks.md}
+
+## Test plan
+- [ ] {checklist of manual verification steps}
+{screenshots if available}" \
+  --remove-source-branch \
+  --squash-before-merge
+```
+
+Do NOT use `--yes` unless running in autopilot/non-interactive mode.
+
+### Step 6: Report
+
+Display:
+
+```text
+Merge Request created
+  MR: {mr-url}
+  Title: {title}
+  Source: {branch}
+  Target: {default-branch}
+```
+
 ---

package/src/index.js

@@ -1,107 +1,107 @@
-#!/usr/bin/env node
-import chalk from 'chalk'
-import { createRequire } from 'node:module'
-import { runJoin } from './commands/join.js'
-import { runUpdate } from './commands/update.js'
-import { runSingleCommand } from './commands/single.js'
-import { runWizard } from './commands/wizard.js'
-import { exit } from './utils/process.js'
-import { findLegacyInstall } from './utils/legacy-check.js'
-
-function printHelp(version) {
-  console.log(`agent-harness v${version}`)
-  console.log()
-  console.log('Usage:')
-  console.log('  npx @plainconceptsplatform/agent-harness             Install the harness (full wizard)')
-  console.log('  npx @plainconceptsplatform/agent-harness <command>   Run a single step command')
-  console.log()
-  console.log('Commands:')
-  console.log('  update          Bring the harness up to date from saved config (no prompts)')
-  console.log('  join            Set up a teammate\'s machine (checks & local installs only)')
-  console.log('  clean           Run AI files cleanup step')
-  console.log('  platform        Run platform selection step')
-  console.log('  copy            Run content copy step')
-  console.log('  openspec        Run OpenSpec initialization step')
-  console.log('  models          Run models selection step')
-  console.log('  optimization    Run token optimization tools step')
-  console.log('  browser         Run opencode-browser installer step')
-  console.log('  metadata        Write onboarding metadata step')
-  console.log()
-  console.log('Options:')
-  console.log('  -h, --help      Show this help message')
-}
-
-if (process.stdout.isTTY) console.clear()
-console.log()
-const require = createRequire(import.meta.url)
-const { version } = require('../package.json')
-const args = process.argv.slice(2)
-
-if (args.includes('-h') || args.includes('--help')) {
-  printHelp(version)
-  exit()
-}
-
-async function refuseLegacyInstall() {
-  const legacy = await findLegacyInstall()
-  if (!legacy) return false
-
-  console.log(chalk.red('This project was set up by opencode-onboard v1.'))
-  console.log()
-  if (legacy.files.length > 0) console.log(chalk.dim(`  config:  ${legacy.files.join(', ')}`))
-  if (legacy.skills.length > 0) {
-    const shown = legacy.skills.slice(0, 3).join(', ')
-    const rest = legacy.skills.length > 3 ? `, +${legacy.skills.length - 3} more` : ''
-    console.log(chalk.dim(`  skills:  ${shown}${rest}`))
-  }
-  console.log()
-  console.log('agent-harness v2 renamed both the config files and the skill prefix,')
-  console.log('and it does not migrate v1 projects. Continuing would leave the harness')
-  console.log('half-patched without reporting an error.')
-  console.log()
-  console.log('Re-onboard on a clean branch instead:')
-  console.log(chalk.dim('  git switch -c chore/agent-harness'))
-  console.log(chalk.dim('  rm -rf .opencode .agents/skills/ob-*'))
-  console.log(chalk.dim('  npx @plainconceptsplatform/agent-harness'))
-  return true
-}
-
-// Ctrl-C out of an @inquirer prompt throws ExitPromptError; that is a normal
-// cancellation, not a crash, so it must not exit non-zero.
-async function main() {
-  if (await refuseLegacyInstall()) {
-    exit(1)
-    return
-  }
-  if (args.length === 0) {
-    await runWizard(version)
-    return
-  }
-  if (args[0] === 'join') {
-    await runJoin()
-    return
-  }
-  if (args[0] === 'update') {
-    await runUpdate()
-    return
-  }
-  if (!await runSingleCommand(args[0])) {
-    console.log(chalk.red(`Unknown command: ${args[0]}`))
-    console.log()
-    printHelp(version)
-    exit(1)
-  }
-}
-
-try {
-  await main()
-} catch (err) {
-  if (err.name === 'ExitPromptError') {
-    console.log()
-    console.log(chalk.yellow('Cancelled.'))
-  } else {
-    console.error(chalk.red('\nUnexpected error:'), err.message)
-    exit(1)
-  }
-}
-exit()
+#!/usr/bin/env node
+import chalk from 'chalk'
+import { createRequire } from 'node:module'
+import { runJoin } from './commands/join.js'
+import { runUpdate } from './commands/update.js'
+import { runSingleCommand } from './commands/single.js'
+import { runWizard } from './commands/wizard.js'
+import { exit } from './utils/process.js'
+import { findLegacyInstall } from './utils/legacy-check.js'
+
+function printHelp(version) {
+  console.log(`agent-harness v${version}`)
+  console.log()
+  console.log('Usage:')
+  console.log('  npx @plainconceptsplatform/agent-harness             Install the harness (full wizard)')
+  console.log('  npx @plainconceptsplatform/agent-harness <command>   Run a single step command')
+  console.log()
+  console.log('Commands:')
+  console.log('  update          Bring the harness up to date from saved config (no prompts)')
+  console.log('  join            Set up a teammate\'s machine (checks & local installs only)')
+  console.log('  clean           Run AI files cleanup step')
+  console.log('  platform        Run platform selection step')
+  console.log('  copy            Run content copy step')
+  console.log('  openspec        Run OpenSpec initialization step')
+  console.log('  models          Run models selection step')
+  console.log('  optimization    Run token optimization tools step')
+  console.log('  browser         Run opencode-browser installer step')
+  console.log('  metadata        Write onboarding metadata step')
+  console.log()
+  console.log('Options:')
+  console.log('  -h, --help      Show this help message')
+}
+
+if (process.stdout.isTTY) console.clear()
+console.log()
+const require = createRequire(import.meta.url)
+const { version } = require('../package.json')
+const args = process.argv.slice(2)
+
+if (args.includes('-h') || args.includes('--help')) {
+  printHelp(version)
+  exit()
+}
+
+async function refuseLegacyInstall() {
+  const legacy = await findLegacyInstall()
+  if (!legacy) return false
+
+  console.log(chalk.red('This project was set up by opencode-onboard v1.'))
+  console.log()
+  if (legacy.files.length > 0) console.log(chalk.dim(`  config:  ${legacy.files.join(', ')}`))
+  if (legacy.skills.length > 0) {
+    const shown = legacy.skills.slice(0, 3).join(', ')
+    const rest = legacy.skills.length > 3 ? `, +${legacy.skills.length - 3} more` : ''
+    console.log(chalk.dim(`  skills:  ${shown}${rest}`))
+  }
+  console.log()
+  console.log('agent-harness v2 renamed both the config files and the skill prefix,')
+  console.log('and it does not migrate v1 projects. Continuing would leave the harness')
+  console.log('half-patched without reporting an error.')
+  console.log()
+  console.log('Re-onboard on a clean branch instead:')
+  console.log(chalk.dim('  git switch -c chore/agent-harness'))
+  console.log(chalk.dim('  rm -rf .opencode .agents/skills/ob-*'))
+  console.log(chalk.dim('  npx @plainconceptsplatform/agent-harness'))
+  return true
+}
+
+// Ctrl-C out of an @inquirer prompt throws ExitPromptError; that is a normal
+// cancellation, not a crash, so it must not exit non-zero.
+async function main() {
+  if (await refuseLegacyInstall()) {
+    exit(1)
+    return
+  }
+  if (args.length === 0) {
+    await runWizard(version)
+    return
+  }
+  if (args[0] === 'join') {
+    await runJoin()
+    return
+  }
+  if (args[0] === 'update') {
+    await runUpdate()
+    return
+  }
+  if (!await runSingleCommand(args[0])) {
+    console.log(chalk.red(`Unknown command: ${args[0]}`))
+    console.log()
+    printHelp(version)
+    exit(1)
+  }
+}
+
+try {
+  await main()
+} catch (err) {
+  if (err.name === 'ExitPromptError') {
+    console.log()
+    console.log(chalk.yellow('Cancelled.'))
+  } else {
+    console.error(chalk.red('\nUnexpected error:'), err.message)
+    exit(1)
+  }
+}
+exit()

package/src/presets/agents-content.json

@@ -1,53 +1,53 @@
-{
-  "platform": {
-    "none": {
-      "devopsSkills": "- Selected platform: `none` (from onboarding platform step).\n- Do NOT load `pc-userstory` or `pc-ops-ship`.\n- Work only from direct user instructions in the main conversation or from local OpenSpec artifacts.\n- Ignore GitHub/Azure DevOps URL inference unless the user explicitly reconfigures onboarding later.",
-      "devopsMode": "This project does not use GitHub or Azure DevOps integration. Do not read work items, create PRs, or process PR feedback. Operate only from direct user instructions and local repository context.",
-      "workflow": "When the user gives a task directly in the conversation, **I own the full lifecycle**. I work from the user request and local repository context. I may use OpenSpec when structured planning helps, but I do not depend on issue links or PR workflows.\n\nTrigger patterns, I recognize ALL of these, exact wording does not matter:\n- User describes a feature, bug, or refactor directly → clarify if needed → optionally load the `pc-plan-propose` skill → implement in the main session or `pc-plan-apply` as appropriate\n- `implement the plan` / `implement` / `start` / `go` → load the `pc-plan-apply` skill against the current OpenSpec change when one exists\n- `just do it` / `quick fix` / `raw conversation` → work directly in the main session without PR or work-item automation\n\n**GitHub Issue URLs, Azure DevOps work item URLs, and PR URLs are NOT automatic triggers in this mode.** Only use platform-specific flows if onboarding is later reconfigured for GitHub or Azure DevOps.",
-      "pipeline": "```\nlead (main session)\n  → pc-plan-propose (propose + enrich tasks)\n        ↓\n  [confirm when scope needs it]\n        ↓\n*-engineer specialists (parallel via pc-plan-apply)\n  → implement assigned tasks (parallel waves)\n        ↓\nlead verifies and reports to user\n```\n\n### Phase 1, Clarify & Plan\n\n```\n1. Understand the task from the conversation and local repo context.\n2. If the work benefits from explicit specs/tasks, load the pc-plan-propose skill.\n   Enrich tasks.md: assign each task its best matching engineer (the engineer's tier sets the model) plus depends_on and touches.\n3. Show the plan or intended scope when non-trivial.\n4. If the request is small, implement directly in the main session.\n```\n\n### Phase 2, Implement\n\n```\n0. Run /quota before spawning, when available.\n1. If using OpenSpec tasks, load the pc-plan-apply skill.\n   - Classify cost tier, confirm if ≥4 tasks.\n   - Lead discovers engineers, builds dependency- and file-disjoint waves, and spawns each wave as parallel subagents.\n   - Each subagent implements its assigned tasks and returns; the lead commits each group and marks tasks done.\n2. If task is small, implement directly in the main session.\n3. Verify with tests/build/lint.\n```\n\nThere is no PR shipping phase in `none` mode. Report completion directly to the user.",
-      "skillsGuide": "No platform skills installed (platform: none). Work from direct user instructions and local OpenSpec artifacts only."
-    },
-    "azure": {
-      "devopsSkills": "- Selected platform: `azure` (from onboarding platform step).\n- Load Azure DevOps skills: `pc-userstory`, `pc-ops-ship`.\n- Use URL-based platform inference only if onboarding metadata is missing or ambiguous.",
-      "devopsMode": "This project uses platform-integrated workflow modes described below.",
-      "workflow": "When the user provides a work item URL or says \"implement the plan\" or \"I've added comments to the PR\", **I own the full lifecycle**. I load the appropriate userstory skill and coordinate implementation as native subagent waves via the `pc-plan-apply` skill.\n\nTrigger patterns, I recognize ALL of these, exact wording does not matter:\n- User pastes or mentions an Azure DevOps URL → load `pc-userstory` skill → parse work item → load the `pc-plan-propose` skill → confirm with user → load the `pc-plan-apply` skill → ship\n- `implement the plan` / `implement` / `start` / `go` → load the `pc-plan-apply` skill → ship\n- `I've added comments to the PR` → read PR comments → fix → update PR\n- Any Azure DevOps PR URL in a feedback/fix request (e.g. \"check comments\", \"fix PR feedback\") → run PR Feedback Loop\n\n**An Azure DevOps URL in the user's message is a strong trigger: follow the pipeline unless the user explicitly asks for analysis or context only.**",
-      "pipeline": "```\nlead (main session)\n  → pc-plan-propose (parse work item + propose + enrich tasks)\n        ↓\n  [confirm with user]\n        ↓\n*-engineer specialists (parallel via pc-plan-apply)\n  → implement assigned tasks (parallel waves)\n        ↓\nlead loads the pc-ops-ship skill → commit + push + create PR\n```\n\n### Phase 1, Parse & Propose\n\n```\n1. If a work item URL is provided, load @pc-userstory skill.\n2. Load the pc-plan-propose skill → fetches work item, generates proposal.md, specs/, tasks.md, enriches tasks with agent + dependencies.\n3. Show the plan: change name, total tasks, task list with agent assignments.\n4. STOP. Ask user: \"Ready to implement? (yes/no)\", DO NOT proceed until confirmed.\n```\n\n### Phase 2, Implement\n\n```\n0. Run /quota to check remaining budget before spawning.\n1. Load the pc-plan-apply skill.\n   - Classify cost tier, announce scope, ask user to confirm if ≥4 tasks.\n   - Lead discovers available engineers from .opencode/agents/*.md, prefers matching custom engineers.\n   - Lead builds dependency- and file-disjoint waves, then spawns each wave as parallel subagents (by agent name; each engineer carries its own model).\n   - Each subagent implements its assigned tasks and returns; the lead commits each group and marks tasks done in tasks.md.\n2. Verify with tests/build/lint according to task scope.\n3. Run /quota after all waves complete.\n```\n\n### Phase 3, Ship\n\n```\n1. Load the pc-ops-ship skill to create the PR.\n2. Done: report PR URL to user.\n```\n\n### Handling PR Feedback\n\n```\nWhen user says \"I've added comments to the PR\" or shares a PR URL:\n1. Triage feedback: read and classify the PR comments via the repo platform CLI (the /ops-review flow).\n2. Fix items by loading the pc-plan-apply skill for the required tasks.\n3. Load the pc-ops-ship skill again to push updates and reply to PR threads.\n```",
-      "skillsGuide": "Platform skills (Azure DevOps):\n- `@pc-userstory`: load when an Azure DevOps work item URL is detected. Fetches the work item via `az` CLI and creates an OpenSpec change. NEVER use browser tools for Azure DevOps operations.\n- `pc-ops-ship`: load in ship mode to create a PR and link the work item, or in feedback mode to read and classify PR review comments."
-    },
-    "github": {
-      "devopsSkills": "- Selected platform: `github` (from onboarding platform step).\n- Load GitHub skills: `pc-userstory`, `pc-ops-ship`.\n- Use URL-based platform inference only if onboarding metadata is missing or ambiguous.",
-      "devopsMode": "This project uses platform-integrated workflow modes described below.",
-      "workflow": "When the user provides a work item URL or says \"implement the plan\" or \"I've added comments to the PR\", **I own the full lifecycle**. I load the appropriate userstory skill and coordinate implementation as native subagent waves via the `pc-plan-apply` skill.\n\nTrigger patterns, I recognize ALL of these, exact wording does not matter:\n- User pastes or mentions a GitHub Issue URL → load `pc-userstory` skill → parse issue → load the `pc-plan-propose` skill → confirm with user → load the `pc-plan-apply` skill → ship\n- `implement the plan` / `implement` / `start` / `go` → load the `pc-plan-apply` skill → ship\n- `I've added comments to the PR` → read PR comments → fix → update PR\n- Any GitHub PR URL in a feedback/fix request (e.g. \"check comments\", \"fix PR feedback\") → run PR Feedback Loop\n\n**A GitHub URL in the user's message is a strong trigger: follow the pipeline unless the user explicitly asks for analysis or context only.**",
-      "pipeline": "```\nlead (main session)\n  → pc-plan-propose (parse work item + propose + enrich tasks)\n        ↓\n  [confirm with user]\n        ↓\n*-engineer specialists (parallel via pc-plan-apply)\n  → implement assigned tasks (parallel waves)\n        ↓\nlead loads the pc-ops-ship skill → commit + push + create PR\n```\n\n### Phase 1, Parse & Propose\n\n```\n1. If a work item URL is provided, load @pc-userstory skill.\n2. Load the pc-plan-propose skill → fetches work item, generates proposal.md, specs/, tasks.md, enriches tasks with agent + dependencies.\n3. Show the plan: change name, total tasks, task list with agent assignments.\n4. STOP. Ask user: \"Ready to implement? (yes/no)\", DO NOT proceed until confirmed.\n```\n\n### Phase 2, Implement\n\n```\n0. Run /quota to check remaining budget before spawning.\n1. Load the pc-plan-apply skill.\n   - Classify cost tier, announce scope, ask user to confirm if ≥4 tasks.\n   - Lead discovers available engineers from .opencode/agents/*.md, prefers matching custom engineers.\n   - Lead builds dependency- and file-disjoint waves, then spawns each wave as parallel subagents (by agent name; each engineer carries its own model).\n   - Each subagent implements its assigned tasks and returns; the lead commits each group and marks tasks done in tasks.md.\n2. Verify with tests/build/lint according to task scope.\n3. Run /quota after all waves complete.\n```\n\n### Phase 3, Ship\n\n```\n1. Load the pc-ops-ship skill to create the PR.\n2. Done: report PR URL to user.\n```\n\n### Handling PR Feedback\n\n```\nWhen user says \"I've added comments to the PR\" or shares a PR URL:\n1. Triage feedback: read and classify the PR comments via the repo platform CLI (the /ops-review flow).\n2. Fix items by loading the pc-plan-apply skill for the required tasks.\n3. Load the pc-ops-ship skill again to push updates and reply to PR threads.\n```",
-      "skillsGuide": "Platform skills (GitHub):\n- `@pc-userstory`: load when a GitHub Issue URL is detected. Fetches the issue via `gh` CLI and creates an OpenSpec change. NEVER use webfetch to access GitHub URLs.\n- `pc-ops-ship`: load in ship mode to create a PR with screenshots, or in feedback mode to read and classify PR review comments."
-    },
-    "mixed": {
-      "default": {
-        "workflow": "This project uses a mixed-platform setup: the backlog (work items) and the repo (PRs) live on different platforms. Check `.opencode/harness.json` → `platform.backlog` and `platform.repo`.\n\nWhen the user provides a work item URL or says \"implement the plan\" or \"I've added comments to the PR\", **I own the full lifecycle**: parse the work item with `@pc-userstory` (backlog platform CLI), plan via the `pc-plan-propose` skill, confirm with the user, implement via the `pc-plan-apply` skill, ship via the `pc-ops-ship` skill (repo platform CLI).\n\nTrigger patterns, I recognize ALL of these, exact wording does not matter:\n- A backlog work-item URL or issue key → load `pc-userstory` → parse → load the `pc-plan-propose` skill → confirm with user → load the `pc-plan-apply` skill → ship\n- `implement the plan` / `implement` / `start` / `go` → load the `pc-plan-apply` skill → ship\n- A PR/MR URL or \"I've added comments to the PR\" → read the PR comments via the repo platform CLI → run the PR Feedback Loop\n\nNever mix the CLIs: work items always go through the backlog platform CLI, PRs/MRs always through the repo platform CLI.",
-        "pipeline": "{repo}",
-        "skillsGuide": "Mixed platform setup: the two platform skills target different hosts:\n- `@pc-userstory` → fetches work items from the backlog platform. Load when a work-item URL or issue key is provided.\n- `pc-ops-ship` → creates PRs/MRs and triages review feedback on the repo platform. Load in ship mode or PR-feedback mode."
-      }
-    },
-    "jira": {
-      "devopsSkills": "- Selected backlog platform: `jira` (from onboarding platform step).\n- Jira is a BACKLOG-ONLY platform. Work items are fetched via `acli jira` CLI.\n- PRs and code review use the repo platform (GitHub or Azure DevOps) configured separately.\n- Load `pc-userstory` skill when a Jira URL is provided.\n- Load `pc-ops-ship` skill from the repo platform for PR operations.",
-      "devopsMode": "This project uses Jira for backlog/work items and a separate repo platform (GitHub or Azure DevOps) for code. Fetch work items via `acli jira` CLI. Create PRs via the repo platform CLI. Do NOT use browser tools for Jira operations.",
-      "workflow": "When the user provides a Jira URL or mentions a Jira issue key, **I own the full lifecycle**. I load `pc-userstory` skill to parse the Jira issue via `acli jira workitem view`, then load the `pc-plan-propose` skill to create the plan.\n\nTrigger patterns, I recognize ALL of these, exact wording does not matter:\n- User pastes or mentions a Jira URL (atlassian.net/browse/PROJ-123) -> load `pc-userstory` skill -> fetch via `acli jira` -> load the `pc-plan-propose` skill -> confirm -> load the `pc-plan-apply` skill -> ship\n- User mentions a Jira issue key (e.g. \"PROJ-123\") -> same flow\n- `implement the plan` / `implement` / `start` / `go` -> load the `pc-plan-apply` skill -> ship\n- PR feedback -> use the repo platform CLI (gh or az) for PR operations\n\n**A Jira URL or issue key in the user's message is a strong trigger: follow the pipeline unless the user explicitly asks for analysis or context only.**\n\nFor PR creation and code review, use the repo platform (configured as `platform.repo`). Jira has no PR capability.",
-      "pipeline": "```\nlead (main session)\n  -> fetch Jira work item (acli jira workitem view)\n  -> pc-plan-propose (propose + enrich tasks)\n        |\n  [confirm when scope needs it]\n        |\n*-engineer specialists (parallel via pc-plan-apply)\n  -> implement assigned tasks (parallel waves)\n        |\nlead verifies, creates PR via repo platform (gh or az)\n  -> transition Jira work item to Done (acli jira workitem transition)\n```\n\n### Phase 1, Fetch & Plan\n\n```\n1. Fetch the Jira work item via acli jira workitem view --key KEY.\n2. Load the pc-plan-propose skill to create the OpenSpec change from the work item.\n3. Confirm with the user.\n```\n\n### Phase 2, Implement & Ship\n\n```\n1. Load the pc-plan-apply skill to implement via parallel subagent waves.\n2. Create PR via repo platform CLI (gh pr create or az repos pr create).\n3. Transition Jira work item: acli jira workitem transition --key KEY --status \"Done\"\n```",
-      "skillsGuide": "### Backlog Platform: Jira\n- `pc-userstory` -> fetches Jira work items via `acli jira` CLI. Load when a Jira URL or issue key is provided.\n\n### Repo Platform\n- PR skills are loaded based on `platform.repo` (GitHub or Azure DevOps)."
-    },
-    "gitlab": {
-      "devopsSkills": "- Selected repo platform: `gitlab` (from onboarding platform step).\n- GitLab is a REPO-ONLY platform. MRs and code review via `glab` CLI.\n- Backlog/work items use the backlog platform (GitHub / Azure / Jira) configured separately.\n- Load `pc-ops-ship` skill for GitLab MR operations.",
-      "devopsMode": "This project uses GitLab for code repository and merge requests, with a separate backlog platform for work items. Create MRs via `glab mr create` CLI. Fetch work items via the backlog platform CLI. Do NOT use browser tools for GitLab operations.",
-      "workflow": "When the user provides a GitLab MR URL or says \"implement the plan\", **I own the full lifecycle**. I load the appropriate userstory skill (from backlog platform) and `pc-ops-ship` skill (for GitLab MRs).\n\nTrigger patterns, I recognize ALL of these, exact wording does not matter:\n- User pastes or mentions a backlog work item URL -> load `pc-userstory` skill -> fetch via backlog CLI -> load the `pc-plan-propose` skill -> confirm -> load the `pc-plan-apply` skill -> ship\n- `implement the plan` / `implement` / `start` / `go` -> load the `pc-plan-apply` skill -> ship\n- User says \"I've added comments to the MR\" -> read MR comments via `glab mr note list` -> triage feedback\n- Any GitLab MR URL in a feedback/fix request -> run MR Feedback Loop via `glab` CLI\n\n**A GitLab MR URL in the user's message is a strong trigger: follow the pipeline unless the user explicitly asks for analysis or context only.**\n\nFor work item fetching, use the backlog platform (configured as `platform.backlog`). GitLab has no backlog integration.",
-      "pipeline": "```\nlead (main session)\n  -> fetch work item (backlog platform CLI: gh / az / acli)\n  -> pc-plan-propose (propose + enrich tasks)\n        |\n  [confirm when scope needs it]\n        |\n*-engineer specialists (parallel via pc-plan-apply)\n  -> implement assigned tasks (parallel waves)\n        |\nlead verifies, creates MR via GitLab (glab mr create)\n```\n\n### Phase 1, Fetch & Plan\n\n```\n1. Fetch the work item via backlog platform CLI.\n2. Load the pc-plan-propose skill to create the OpenSpec change.\n3. Confirm with the user.\n```\n\n### Phase 2, Implement & Ship\n\n```\n1. Load the pc-plan-apply skill to implement via parallel subagent waves.\n2. Create MR via glab mr create.\n3. Archive change after MR is merged.\n```",
-      "skillsGuide": "### Repo Platform: GitLab\n- `pc-ops-ship` -> creates GitLab merge requests via `glab` CLI. Load when shipping a branch or processing MR feedback.\n\n### Backlog Platform\n- Work item skills are loaded based on `platform.backlog` (GitHub / Azure / Jira)."
-    },
-    "browser": {
-      "devopsSkills": "- Selected backlog platform: `browser` (from onboarding platform step).\n- No CLI integration for the backlog system. Work items are fetched via opencode-browser plugin.\n- The `pc-userstory` skill navigates to work item URLs the user provides and reads page content.\n- PRs and code review use the repo platform (GitHub / Azure DevOps / GitLab) configured separately.",
-      "devopsMode": "This project uses browser automation for backlog/work items (no CLI) and a separate repo platform for code. Work items are read from web pages using the opencode-browser plugin. Create PRs via the repo platform CLI. The browser navigation exception ONLY applies to work item URLs the user explicitly provides.",
-      "workflow": "When the user provides a work item URL from any backlog tool (Azure DevOps, Linear, Trello, etc.), **I own the full lifecycle**. I load `pc-userstory` skill to navigate to the URL via browser and read the page content.\n\nTrigger patterns, I recognize ALL of these, exact wording does not matter:\n- User pastes any URL to a work item/ticket/issue -> load `pc-userstory` skill -> navigate via browser -> read page text + snapshot -> parse work item -> load the `pc-plan-propose` skill -> confirm -> load the `pc-plan-apply` skill -> ship\n- `implement the plan` / `implement` / `start` / `go` -> load the `pc-plan-apply` skill -> ship\n- PR feedback -> use the repo platform CLI (gh, az, or glab) for PR operations\n\n**Any work item URL in the user's message is a trigger, regardless of the backlog tool it points to.**\n\nFor PR creation and code review, use the repo platform (configured as `platform.repo`). Browser is backlog-only: it has no PR capability.",
-      "pipeline": "```\nlead (main session)\n  -> open work item URL in browser (browser_open_tab)\n  -> read page content (browser_query mode=page_text + browser_snapshot)\n  -> parse work item fields from page text\n  -> pc-plan-propose (propose + enrich tasks)\n        |\n  [confirm when scope needs it]\n        |\n*-engineer specialists (parallel via pc-plan-apply)\n  -> implement assigned tasks (parallel waves)\n        |\nlead verifies, creates PR via repo platform (gh / az / glab)\n```\n\n### Phase 1, Fetch & Plan\n\n```\n1. User provides a work item URL.\n2. Navigate to the URL via browser_open_tab.\n3. Read page text via browser_query mode=page_text.\n4. Take accessibility snapshot via browser_snapshot.\n5. Parse title, description, acceptance criteria from the page.\n6. Load the pc-plan-propose skill to create the OpenSpec change.\n7. Confirm with the user.\n```\n\n### Phase 2, Implement & Ship\n\n```\n1. Load the pc-plan-apply skill to implement via parallel subagent waves.\n2. Create PR via repo platform CLI (gh pr create, az repos pr create, or glab mr create).\n3. Archive change after PR is merged.\n```",
-      "skillsGuide": "### Backlog Platform: Others (Browser)\n- `pc-userstory` -> navigates to work item URLs via browser plugin, reads page content, creates OpenSpec changes. Load when a URL the user provides does not match GitHub/Azure/Jira CLI platforms.\n\n### Repo Platform\n- PR skills are loaded based on `platform.repo` (GitHub / Azure DevOps / GitLab)."
-    }
-  }
-}
+{
+  "platform": {
+    "none": {
+      "devopsSkills": "- Selected platform: `none` (from onboarding platform step).\n- Do NOT load `pc-userstory` or `pc-ops-ship`.\n- Work only from direct user instructions in the main conversation or from local OpenSpec artifacts.\n- Ignore GitHub/Azure DevOps URL inference unless the user explicitly reconfigures onboarding later.",
+      "devopsMode": "This project does not use GitHub or Azure DevOps integration. Do not read work items, create PRs, or process PR feedback. Operate only from direct user instructions and local repository context.",
+      "workflow": "When the user gives a task directly in the conversation, **I own the full lifecycle**. I work from the user request and local repository context. I may use OpenSpec when structured planning helps, but I do not depend on issue links or PR workflows.\n\nTrigger patterns, I recognize ALL of these, exact wording does not matter:\n- User describes a feature, bug, or refactor directly → clarify if needed → optionally load the `pc-plan-propose` skill → implement in the main session or `pc-plan-apply` as appropriate\n- `implement the plan` / `implement` / `start` / `go` → load the `pc-plan-apply` skill against the current OpenSpec change when one exists\n- `just do it` / `quick fix` / `raw conversation` → work directly in the main session without PR or work-item automation\n\n**GitHub Issue URLs, Azure DevOps work item URLs, and PR URLs are NOT automatic triggers in this mode.** Only use platform-specific flows if onboarding is later reconfigured for GitHub or Azure DevOps.",
+      "pipeline": "```\nlead (main session)\n  → pc-plan-propose (propose + enrich tasks)\n        ↓\n  [confirm when scope needs it]\n        ↓\n*-engineer specialists (parallel via pc-plan-apply)\n  → implement assigned tasks (parallel waves)\n        ↓\nlead verifies and reports to user\n```\n\n### Phase 1, Clarify & Plan\n\n```\n1. Understand the task from the conversation and local repo context.\n2. If the work benefits from explicit specs/tasks, load the pc-plan-propose skill.\n   Enrich tasks.md: assign each task its best matching engineer (the engineer's tier sets the model) plus depends_on and touches.\n3. Show the plan or intended scope when non-trivial.\n4. If the request is small, implement directly in the main session.\n```\n\n### Phase 2, Implement\n\n```\n0. Run /quota before spawning, when available.\n1. If using OpenSpec tasks, load the pc-plan-apply skill.\n   - Classify cost tier, confirm if ≥4 tasks.\n   - Lead discovers engineers, builds dependency- and file-disjoint waves, and spawns each wave as parallel subagents.\n   - Each subagent implements its assigned tasks and returns; the lead commits each group and marks tasks done.\n2. If task is small, implement directly in the main session.\n3. Verify with tests/build/lint.\n```\n\nThere is no PR shipping phase in `none` mode. Report completion directly to the user.",
+      "skillsGuide": "No platform skills installed (platform: none). Work from direct user instructions and local OpenSpec artifacts only."
+    },
+    "azure": {
+      "devopsSkills": "- Selected platform: `azure` (from onboarding platform step).\n- Load Azure DevOps skills: `pc-userstory`, `pc-ops-ship`.\n- Use URL-based platform inference only if onboarding metadata is missing or ambiguous.",
+      "devopsMode": "This project uses platform-integrated workflow modes described below.",
+      "workflow": "When the user provides a work item URL or says \"implement the plan\" or \"I've added comments to the PR\", **I own the full lifecycle**. I load the appropriate userstory skill and coordinate implementation as native subagent waves via the `pc-plan-apply` skill.\n\nTrigger patterns, I recognize ALL of these, exact wording does not matter:\n- User pastes or mentions an Azure DevOps URL → load `pc-userstory` skill → parse work item → load the `pc-plan-propose` skill → confirm with user → load the `pc-plan-apply` skill → ship\n- `implement the plan` / `implement` / `start` / `go` → load the `pc-plan-apply` skill → ship\n- `I've added comments to the PR` → read PR comments → fix → update PR\n- Any Azure DevOps PR URL in a feedback/fix request (e.g. \"check comments\", \"fix PR feedback\") → run PR Feedback Loop\n\n**An Azure DevOps URL in the user's message is a strong trigger: follow the pipeline unless the user explicitly asks for analysis or context only.**",
+      "pipeline": "```\nlead (main session)\n  → pc-plan-propose (parse work item + propose + enrich tasks)\n        ↓\n  [confirm with user]\n        ↓\n*-engineer specialists (parallel via pc-plan-apply)\n  → implement assigned tasks (parallel waves)\n        ↓\nlead loads the pc-ops-ship skill → commit + push + create PR\n```\n\n### Phase 1, Parse & Propose\n\n```\n1. If a work item URL is provided, load @pc-userstory skill.\n2. Load the pc-plan-propose skill → fetches work item, generates proposal.md, specs/, tasks.md, enriches tasks with agent + dependencies.\n3. Show the plan: change name, total tasks, task list with agent assignments.\n4. STOP. Ask user: \"Ready to implement? (yes/no)\", DO NOT proceed until confirmed.\n```\n\n### Phase 2, Implement\n\n```\n0. Run /quota to check remaining budget before spawning.\n1. Load the pc-plan-apply skill.\n   - Classify cost tier, announce scope, ask user to confirm if ≥4 tasks.\n   - Lead discovers available engineers from .opencode/agents/*.md, prefers matching custom engineers.\n   - Lead builds dependency- and file-disjoint waves, then spawns each wave as parallel subagents (by agent name; each engineer carries its own model).\n   - Each subagent implements its assigned tasks and returns; the lead commits each group and marks tasks done in tasks.md.\n2. Verify with tests/build/lint according to task scope.\n3. Run /quota after all waves complete.\n```\n\n### Phase 3, Ship\n\n```\n1. Load the pc-ops-ship skill to create the PR.\n2. Done: report PR URL to user.\n```\n\n### Handling PR Feedback\n\n```\nWhen user says \"I've added comments to the PR\" or shares a PR URL:\n1. Triage feedback: read and classify the PR comments via the repo platform CLI (the /ops-review flow).\n2. Fix items by loading the pc-plan-apply skill for the required tasks.\n3. Load the pc-ops-ship skill again to push updates and reply to PR threads.\n```",
+      "skillsGuide": "Platform skills (Azure DevOps):\n- `@pc-userstory`: load when an Azure DevOps work item URL is detected. Fetches the work item via `az` CLI and creates an OpenSpec change. NEVER use browser tools for Azure DevOps operations.\n- `pc-ops-ship`: load in ship mode to create a PR and link the work item, or in feedback mode to read and classify PR review comments."
+    },
+    "github": {
+      "devopsSkills": "- Selected platform: `github` (from onboarding platform step).\n- Load GitHub skills: `pc-userstory`, `pc-ops-ship`.\n- Use URL-based platform inference only if onboarding metadata is missing or ambiguous.",
+      "devopsMode": "This project uses platform-integrated workflow modes described below.",
+      "workflow": "When the user provides a work item URL or says \"implement the plan\" or \"I've added comments to the PR\", **I own the full lifecycle**. I load the appropriate userstory skill and coordinate implementation as native subagent waves via the `pc-plan-apply` skill.\n\nTrigger patterns, I recognize ALL of these, exact wording does not matter:\n- User pastes or mentions a GitHub Issue URL → load `pc-userstory` skill → parse issue → load the `pc-plan-propose` skill → confirm with user → load the `pc-plan-apply` skill → ship\n- `implement the plan` / `implement` / `start` / `go` → load the `pc-plan-apply` skill → ship\n- `I've added comments to the PR` → read PR comments → fix → update PR\n- Any GitHub PR URL in a feedback/fix request (e.g. \"check comments\", \"fix PR feedback\") → run PR Feedback Loop\n\n**A GitHub URL in the user's message is a strong trigger: follow the pipeline unless the user explicitly asks for analysis or context only.**",
+      "pipeline": "```\nlead (main session)\n  → pc-plan-propose (parse work item + propose + enrich tasks)\n        ↓\n  [confirm with user]\n        ↓\n*-engineer specialists (parallel via pc-plan-apply)\n  → implement assigned tasks (parallel waves)\n        ↓\nlead loads the pc-ops-ship skill → commit + push + create PR\n```\n\n### Phase 1, Parse & Propose\n\n```\n1. If a work item URL is provided, load @pc-userstory skill.\n2. Load the pc-plan-propose skill → fetches work item, generates proposal.md, specs/, tasks.md, enriches tasks with agent + dependencies.\n3. Show the plan: change name, total tasks, task list with agent assignments.\n4. STOP. Ask user: \"Ready to implement? (yes/no)\", DO NOT proceed until confirmed.\n```\n\n### Phase 2, Implement\n\n```\n0. Run /quota to check remaining budget before spawning.\n1. Load the pc-plan-apply skill.\n   - Classify cost tier, announce scope, ask user to confirm if ≥4 tasks.\n   - Lead discovers available engineers from .opencode/agents/*.md, prefers matching custom engineers.\n   - Lead builds dependency- and file-disjoint waves, then spawns each wave as parallel subagents (by agent name; each engineer carries its own model).\n   - Each subagent implements its assigned tasks and returns; the lead commits each group and marks tasks done in tasks.md.\n2. Verify with tests/build/lint according to task scope.\n3. Run /quota after all waves complete.\n```\n\n### Phase 3, Ship\n\n```\n1. Load the pc-ops-ship skill to create the PR.\n2. Done: report PR URL to user.\n```\n\n### Handling PR Feedback\n\n```\nWhen user says \"I've added comments to the PR\" or shares a PR URL:\n1. Triage feedback: read and classify the PR comments via the repo platform CLI (the /ops-review flow).\n2. Fix items by loading the pc-plan-apply skill for the required tasks.\n3. Load the pc-ops-ship skill again to push updates and reply to PR threads.\n```",
+      "skillsGuide": "Platform skills (GitHub):\n- `@pc-userstory`: load when a GitHub Issue URL is detected. Fetches the issue via `gh` CLI and creates an OpenSpec change. NEVER use webfetch to access GitHub URLs.\n- `pc-ops-ship`: load in ship mode to create a PR with screenshots, or in feedback mode to read and classify PR review comments."
+    },
+    "mixed": {
+      "default": {
+        "workflow": "This project uses a mixed-platform setup: the backlog (work items) and the repo (PRs) live on different platforms. Check `.opencode/harness.json` → `platform.backlog` and `platform.repo`.\n\nWhen the user provides a work item URL or says \"implement the plan\" or \"I've added comments to the PR\", **I own the full lifecycle**: parse the work item with `@pc-userstory` (backlog platform CLI), plan via the `pc-plan-propose` skill, confirm with the user, implement via the `pc-plan-apply` skill, ship via the `pc-ops-ship` skill (repo platform CLI).\n\nTrigger patterns, I recognize ALL of these, exact wording does not matter:\n- A backlog work-item URL or issue key → load `pc-userstory` → parse → load the `pc-plan-propose` skill → confirm with user → load the `pc-plan-apply` skill → ship\n- `implement the plan` / `implement` / `start` / `go` → load the `pc-plan-apply` skill → ship\n- A PR/MR URL or \"I've added comments to the PR\" → read the PR comments via the repo platform CLI → run the PR Feedback Loop\n\nNever mix the CLIs: work items always go through the backlog platform CLI, PRs/MRs always through the repo platform CLI.",
+        "pipeline": "{repo}",
+        "skillsGuide": "Mixed platform setup: the two platform skills target different hosts:\n- `@pc-userstory` → fetches work items from the backlog platform. Load when a work-item URL or issue key is provided.\n- `pc-ops-ship` → creates PRs/MRs and triages review feedback on the repo platform. Load in ship mode or PR-feedback mode."
+      }
+    },
+    "jira": {
+      "devopsSkills": "- Selected backlog platform: `jira` (from onboarding platform step).\n- Jira is a BACKLOG-ONLY platform. Work items are fetched via `acli jira` CLI.\n- PRs and code review use the repo platform (GitHub or Azure DevOps) configured separately.\n- Load `pc-userstory` skill when a Jira URL is provided.\n- Load `pc-ops-ship` skill from the repo platform for PR operations.",
+      "devopsMode": "This project uses Jira for backlog/work items and a separate repo platform (GitHub or Azure DevOps) for code. Fetch work items via `acli jira` CLI. Create PRs via the repo platform CLI. Do NOT use browser tools for Jira operations.",
+      "workflow": "When the user provides a Jira URL or mentions a Jira issue key, **I own the full lifecycle**. I load `pc-userstory` skill to parse the Jira issue via `acli jira workitem view`, then load the `pc-plan-propose` skill to create the plan.\n\nTrigger patterns, I recognize ALL of these, exact wording does not matter:\n- User pastes or mentions a Jira URL (atlassian.net/browse/PROJ-123) -> load `pc-userstory` skill -> fetch via `acli jira` -> load the `pc-plan-propose` skill -> confirm -> load the `pc-plan-apply` skill -> ship\n- User mentions a Jira issue key (e.g. \"PROJ-123\") -> same flow\n- `implement the plan` / `implement` / `start` / `go` -> load the `pc-plan-apply` skill -> ship\n- PR feedback -> use the repo platform CLI (gh or az) for PR operations\n\n**A Jira URL or issue key in the user's message is a strong trigger: follow the pipeline unless the user explicitly asks for analysis or context only.**\n\nFor PR creation and code review, use the repo platform (configured as `platform.repo`). Jira has no PR capability.",
+      "pipeline": "```\nlead (main session)\n  -> fetch Jira work item (acli jira workitem view)\n  -> pc-plan-propose (propose + enrich tasks)\n        |\n  [confirm when scope needs it]\n        |\n*-engineer specialists (parallel via pc-plan-apply)\n  -> implement assigned tasks (parallel waves)\n        |\nlead verifies, creates PR via repo platform (gh or az)\n  -> transition Jira work item to Done (acli jira workitem transition)\n```\n\n### Phase 1, Fetch & Plan\n\n```\n1. Fetch the Jira work item via acli jira workitem view --key KEY.\n2. Load the pc-plan-propose skill to create the OpenSpec change from the work item.\n3. Confirm with the user.\n```\n\n### Phase 2, Implement & Ship\n\n```\n1. Load the pc-plan-apply skill to implement via parallel subagent waves.\n2. Create PR via repo platform CLI (gh pr create or az repos pr create).\n3. Transition Jira work item: acli jira workitem transition --key KEY --status \"Done\"\n```",
+      "skillsGuide": "### Backlog Platform: Jira\n- `pc-userstory` -> fetches Jira work items via `acli jira` CLI. Load when a Jira URL or issue key is provided.\n\n### Repo Platform\n- PR skills are loaded based on `platform.repo` (GitHub or Azure DevOps)."
+    },
+    "gitlab": {
+      "devopsSkills": "- Selected repo platform: `gitlab` (from onboarding platform step).\n- GitLab is a REPO-ONLY platform. MRs and code review via `glab` CLI.\n- Backlog/work items use the backlog platform (GitHub / Azure / Jira) configured separately.\n- Load `pc-ops-ship` skill for GitLab MR operations.",
+      "devopsMode": "This project uses GitLab for code repository and merge requests, with a separate backlog platform for work items. Create MRs via `glab mr create` CLI. Fetch work items via the backlog platform CLI. Do NOT use browser tools for GitLab operations.",
+      "workflow": "When the user provides a GitLab MR URL or says \"implement the plan\", **I own the full lifecycle**. I load the appropriate userstory skill (from backlog platform) and `pc-ops-ship` skill (for GitLab MRs).\n\nTrigger patterns, I recognize ALL of these, exact wording does not matter:\n- User pastes or mentions a backlog work item URL -> load `pc-userstory` skill -> fetch via backlog CLI -> load the `pc-plan-propose` skill -> confirm -> load the `pc-plan-apply` skill -> ship\n- `implement the plan` / `implement` / `start` / `go` -> load the `pc-plan-apply` skill -> ship\n- User says \"I've added comments to the MR\" -> read MR comments via `glab mr note list` -> triage feedback\n- Any GitLab MR URL in a feedback/fix request -> run MR Feedback Loop via `glab` CLI\n\n**A GitLab MR URL in the user's message is a strong trigger: follow the pipeline unless the user explicitly asks for analysis or context only.**\n\nFor work item fetching, use the backlog platform (configured as `platform.backlog`). GitLab has no backlog integration.",
+      "pipeline": "```\nlead (main session)\n  -> fetch work item (backlog platform CLI: gh / az / acli)\n  -> pc-plan-propose (propose + enrich tasks)\n        |\n  [confirm when scope needs it]\n        |\n*-engineer specialists (parallel via pc-plan-apply)\n  -> implement assigned tasks (parallel waves)\n        |\nlead verifies, creates MR via GitLab (glab mr create)\n```\n\n### Phase 1, Fetch & Plan\n\n```\n1. Fetch the work item via backlog platform CLI.\n2. Load the pc-plan-propose skill to create the OpenSpec change.\n3. Confirm with the user.\n```\n\n### Phase 2, Implement & Ship\n\n```\n1. Load the pc-plan-apply skill to implement via parallel subagent waves.\n2. Create MR via glab mr create.\n3. Archive change after MR is merged.\n```",
+      "skillsGuide": "### Repo Platform: GitLab\n- `pc-ops-ship` -> creates GitLab merge requests via `glab` CLI. Load when shipping a branch or processing MR feedback.\n\n### Backlog Platform\n- Work item skills are loaded based on `platform.backlog` (GitHub / Azure / Jira)."
+    },
+    "browser": {
+      "devopsSkills": "- Selected backlog platform: `browser` (from onboarding platform step).\n- No CLI integration for the backlog system. Work items are fetched via opencode-browser plugin.\n- The `pc-userstory` skill navigates to work item URLs the user provides and reads page content.\n- PRs and code review use the repo platform (GitHub / Azure DevOps / GitLab) configured separately.",
+      "devopsMode": "This project uses browser automation for backlog/work items (no CLI) and a separate repo platform for code. Work items are read from web pages using the opencode-browser plugin. Create PRs via the repo platform CLI. The browser navigation exception ONLY applies to work item URLs the user explicitly provides.",
+      "workflow": "When the user provides a work item URL from any backlog tool (Azure DevOps, Linear, Trello, etc.), **I own the full lifecycle**. I load `pc-userstory` skill to navigate to the URL via browser and read the page content.\n\nTrigger patterns, I recognize ALL of these, exact wording does not matter:\n- User pastes any URL to a work item/ticket/issue -> load `pc-userstory` skill -> navigate via browser -> read page text + snapshot -> parse work item -> load the `pc-plan-propose` skill -> confirm -> load the `pc-plan-apply` skill -> ship\n- `implement the plan` / `implement` / `start` / `go` -> load the `pc-plan-apply` skill -> ship\n- PR feedback -> use the repo platform CLI (gh, az, or glab) for PR operations\n\n**Any work item URL in the user's message is a trigger, regardless of the backlog tool it points to.**\n\nFor PR creation and code review, use the repo platform (configured as `platform.repo`). Browser is backlog-only: it has no PR capability.",
+      "pipeline": "```\nlead (main session)\n  -> open work item URL in browser (browser_open_tab)\n  -> read page content (browser_query mode=page_text + browser_snapshot)\n  -> parse work item fields from page text\n  -> pc-plan-propose (propose + enrich tasks)\n        |\n  [confirm when scope needs it]\n        |\n*-engineer specialists (parallel via pc-plan-apply)\n  -> implement assigned tasks (parallel waves)\n        |\nlead verifies, creates PR via repo platform (gh / az / glab)\n```\n\n### Phase 1, Fetch & Plan\n\n```\n1. User provides a work item URL.\n2. Navigate to the URL via browser_open_tab.\n3. Read page text via browser_query mode=page_text.\n4. Take accessibility snapshot via browser_snapshot.\n5. Parse title, description, acceptance criteria from the page.\n6. Load the pc-plan-propose skill to create the OpenSpec change.\n7. Confirm with the user.\n```\n\n### Phase 2, Implement & Ship\n\n```\n1. Load the pc-plan-apply skill to implement via parallel subagent waves.\n2. Create PR via repo platform CLI (gh pr create, az repos pr create, or glab mr create).\n3. Archive change after PR is merged.\n```",
+      "skillsGuide": "### Backlog Platform: Others (Browser)\n- `pc-userstory` -> navigates to work item URLs via browser plugin, reads page content, creates OpenSpec changes. Load when a URL the user provides does not match GitHub/Azure/Jira CLI platforms.\n\n### Repo Platform\n- PR skills are loaded based on `platform.repo` (GitHub / Azure DevOps / GitLab)."
+    }
+  }
+}