@plainconceptsplatform/agent-harness 2.4.1 → 2.5.0

package/cli/fragments/ops-ship/az.md

@@ -1,81 +1,82 @@
-**Browser MCP tools are FORBIDDEN for all Azure DevOps operations.**
-Browser tools are ONLY permitted for screenshots of the LOCAL running app on `localhost` URLs.
-
----
-
-### Step 1: Verify feature branch
-
-```bash
-git branch --show-current
-```
-
-Branch must be `feature/{id}-{slug}`. NEVER push to `main`.
-
-### 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
-
-```bash
-git add .
-git commit -m "feat({scope}): {description} (#{id})"
-git push origin feature/{id}-{slug}
-```
-
-### Step 4: Create PR
-
-```bash
-az repos pr create \
-  --repository {repo} \
-  --source-branch feature/{id}-{slug} \
-  --target-branch main \
-  --title "feat({scope}): {title} (#{id})" \
-  --description "{description}"
-```
-
-### Step 5: Link work item (MANDATORY, run sequentially, not in parallel)
-
-```bash
-az repos pr work-item add --id {pr-id} --work-items {workitem-id}
-```
-
-### Step 6: Post screenshot comment
-
-Build raw URL for each image:
-
-```
-https://dev.azure.com/{org}/{project}/_apis/git/repositories/{repo}/items?path=openspec/changes/{change}/images/{file}.png&versionType=branch&version={branch}&api-version=7.1
-```
-
-Post via:
-
-```bash
-az devops invoke \
-  --area git --resource pullRequestThreads \
-  --route-parameters project={project} repositoryId={repo} pullRequestId={pr-id} \
-  --http-method POST --api-version 7.1 --in-file body.json
-```
-
-`body.json`:
-
-```json
-{
-  "comments": [
-    {
-      "parentCommentId": 0,
-      "content": "## Screenshots\n\n![{feature}]({raw-url})",
-      "commentType": 1
-    }
-  ],
-  "status": "active"
-}
-```
-
+Azure DevOps data comes from the `az` CLI; a page fetch of dev.azure.com is denied (pc-system-reminders). If `az` is unavailable, report it as a blocker. Browser tools reach only the local app on `localhost`.
+
+---
+
+### Step 1: Verify feature branch
+
+```bash
+git branch --show-current
+```
+
+Branch must be `feature/{id}-{slug}`. NEVER push to `main`.
+
+### 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 the paths you actually changed; unscoped staging is denied (`pc-system-reminders`):
+
+```bash
+git add openspec/changes/{change-name}/images/  # plus any other paths you actually changed
+git commit -m "feat({scope}): {description} (#{id})"
+git push origin feature/{id}-{slug}
+```
+
+### Step 4: Create PR
+
+```bash
+az repos pr create \
+  --repository {repo} \
+  --source-branch feature/{id}-{slug} \
+  --target-branch main \
+  --title "feat({scope}): {title} (#{id})" \
+  --description "{description}"
+```
+
+### Step 5: Link work item (MANDATORY, run sequentially, not in parallel)
+
+```bash
+az repos pr work-item add --id {pr-id} --work-items {workitem-id}
+```
+
+### Step 6: Post screenshot comment
+
+Build raw URL for each image:
+
+```
+https://dev.azure.com/{org}/{project}/_apis/git/repositories/{repo}/items?path=openspec/changes/{change}/images/{file}.png&versionType=branch&version={branch}&api-version=7.1
+```
+
+Post via:
+
+```bash
+az devops invoke \
+  --area git --resource pullRequestThreads \
+  --route-parameters project={project} repositoryId={repo} pullRequestId={pr-id} \
+  --http-method POST --api-version 7.1 --in-file body.json
+```
+
+`body.json`:
+
+```json
+{
+  "comments": [
+    {
+      "parentCommentId": 0,
+      "content": "## Screenshots\n\n![{feature}]({raw-url})",
+      "commentType": 1
+    }
+  ],
+  "status": "active"
+}
+```
+
 ---

package/cli/fragments/ops-ship/gh.md

@@ -1,69 +1,69 @@
-**ALL GitHub data MUST come from `gh` CLI. NEVER use webfetch, HTTP requests, or browser MCP tools for GitHub operations, even if gh CLI fails. If `gh` 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 .`, 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 "feat({scope}): {description} (#{id})"   # only if there is something to commit
-git push -u origin "$BRANCH"
-```
-
-### Step 4: Create PR
-
-```bash
-gh pr create \
-  --repo {owner}/{repo} \
-  --base "$DEFAULT_BRANCH" \
-  --head "$BRANCH" \
-  --title "feat({scope}): {title} (#{id})" \
-  --body "{description}"
-```
-
-### Step 5: Post screenshot comment
-
-Resolve commit SHA (the commit that includes screenshots):
-
-```bash
-git rev-parse HEAD
-```
-
-Build blob URL for each image with `?raw=true` (a plain blob URL renders the GitHub HTML page, not the image, inside `![...]()`):
-
-```
-https://github.com/{owner}/{repo}/blob/{sha}/openspec/changes/{change}/images/{file}.png?raw=true
-```
-
-Note: on private repos the embedded image is only visible to users with repo access.
-
-Post comment:
-
-```bash
-gh pr comment {pr-number} --repo {owner}/{repo} --body $'## Screenshots\n\n![{feature}]({blob-url})'
-```
-
+GitHub data comes from the `gh` CLI; a page fetch of github.com is denied (pc-system-reminders). If `gh` is unavailable, report it 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 the paths you actually changed; unscoped staging is denied (`pc-system-reminders`):
+
+```bash
+git add openspec/changes/{change-name}/images/  # plus any other paths you actually changed
+git commit -m "feat({scope}): {description} (#{id})"   # only if there is something to commit
+git push -u origin "$BRANCH"
+```
+
+### Step 4: Create PR
+
+```bash
+gh pr create \
+  --repo {owner}/{repo} \
+  --base "$DEFAULT_BRANCH" \
+  --head "$BRANCH" \
+  --title "feat({scope}): {title} (#{id})" \
+  --body "{description}"
+```
+
+### Step 5: Post screenshot comment
+
+Resolve commit SHA (the commit that includes screenshots):
+
+```bash
+git rev-parse HEAD
+```
+
+Build blob URL for each image with `?raw=true` (a plain blob URL renders the GitHub HTML page, not the image, inside `![...]()`):
+
+```
+https://github.com/{owner}/{repo}/blob/{sha}/openspec/changes/{change}/images/{file}.png?raw=true
+```
+
+Note: on private repos the embedded image is only visible to users with repo access.
+
+Post comment:
+
+```bash
+gh pr comment {pr-number} --repo {owner}/{repo} --body $'## Screenshots\n\n![{feature}]({blob-url})'
+```
+
 ---

package/cli/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}
-```
-
+GitLab data comes from the `glab` CLI; a page fetch of gitlab.com is denied (pc-system-reminders). If `glab` is unavailable, report it 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 the paths you actually changed; unscoped staging is denied (`pc-system-reminders`):
+
+```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/cli/presets/agents-content.json

@@ -1,53 +1,34 @@
-{
-  "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 agent-browser.\n- The `pc-userstory` skill opens 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 agent-browser. 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 (agent-browser --session backlog --restore open)\n  -> wait for load (agent-browser wait --load networkidle)\n  -> read page content (agent-browser snapshot + read)\n  -> parse work item fields from snapshot\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. Open the URL via agent-browser --session backlog --restore open.\n3. Wait for load via agent-browser wait --load networkidle.\n4. Take an accessibility snapshot via agent-browser snapshot.\n5. Parse title, description, acceptance criteria from the snapshot.\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` -> opens work item URLs via agent-browser, 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": {
+      "workflow": "There is no backlog and no PR integration here, so the work arrives in the conversation and the local repository is the only context.\n\n- A described feature, bug or refactor: clarify if needed, then `pc-plan-propose` when the change is worth planning, or straight to `pc-plan-apply`.\n- An existing OpenSpec change, plus any of `implement` / `start` / `go`: `pc-plan-apply`.\n- `just do it` or `quick fix`: work in this session, no proposal, no ceremony.\n\nA GitHub or Azure DevOps URL is not a trigger in this mode; re-run onboarding to configure a platform.",
+      "skillsGuide": "No platform skills installed (platform: none). Work from direct user instructions and local OpenSpec artifacts only."
+    },
+    "azure": {
+      "workflow": "An Azure DevOps work item or PR URL in the user's message means run the pipeline, in whatever words it arrives, unless they asked for analysis or context only.\n\n- Work item URL: `pc-userstory` to parse it, `pc-plan-propose` for the plan, confirm, `pc-plan-apply` to build, then ship.\n- An existing OpenSpec change, plus any of `implement` / `start` / `go`: `pc-plan-apply`, then ship.\n- A PR URL with a feedback or fix request: read the PR comments, fix, update the PR.",
+      "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": {
+      "workflow": "A GitHub Issue or PR URL in the user's message means run the pipeline, in whatever words it arrives, unless they asked for analysis or context only.\n\n- Issue URL: `pc-userstory` to parse it, `pc-plan-propose` for the plan, confirm, `pc-plan-apply` to build, then ship.\n- An existing OpenSpec change, plus any of `implement` / `start` / `go`: `pc-plan-apply`, then ship.\n- A PR URL with a feedback or fix request: read the PR comments, fix, update the PR.",
+      "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": "The backlog and the repo are on different platforms here: `.opencode/harness.json` → `platform.backlog` and `platform.repo`. Never cross them. Work items always come from the backlog CLI and pull requests always from the repo CLI, or the command fails against the wrong host and the fallback is a page fetch that is denied.\n\nA work item URL, or a PR URL with a feedback request, means run the pipeline, in whatever words it arrives, unless the user asked for analysis or context only.\n\n- Work item URL or issue key: `pc-userstory` (backlog CLI) to parse it, `pc-plan-propose` for the plan, confirm, `pc-plan-apply` to build, `pc-ops-ship` (repo CLI) to ship.\n- An existing OpenSpec change, plus any of `implement` / `start` / `go`: `pc-plan-apply`, then ship.\n- A PR or MR URL with a feedback or fix request: read its comments through the repo CLI, fix, update it.",
+        "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": {
+      "workflow": "A Jira URL or a bare issue key (`PROJ-123`) means run the pipeline, in whatever words it arrives, unless they asked for analysis or context only.\n\n- Either one: `pc-userstory` to fetch it through `acli jira`, `pc-plan-propose` for the plan, confirm, `pc-plan-apply` to build, then ship.\n- An existing OpenSpec change, plus any of `implement` / `start` / `go`: `pc-plan-apply`, then ship.\n\nJira has no pull requests: PR work runs on the repo platform in `platform.repo`.",
+      "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": {
+      "workflow": "A backlog work item URL, or a GitLab MR URL with a feedback request, means run the pipeline, in whatever words it arrives, unless they asked for analysis or context only.\n\n- Work item URL: `pc-userstory` to fetch it through the backlog CLI, `pc-plan-propose` for the plan, confirm, `pc-plan-apply` to build, then ship.\n- An existing OpenSpec change, plus any of `implement` / `start` / `go`: `pc-plan-apply`, then ship.\n- An MR URL with a feedback or fix request: `glab mr note list`, triage, fix, update the MR.\n\nGitLab has no backlog here: work items come from the platform in `platform.backlog`.",
+      "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": {
+      "workflow": "Any work item URL means run the pipeline, whichever tool it points at, unless the user asked for analysis or context only.\n\n- The URL: `pc-userstory` to open and read the page, `pc-plan-propose` for the plan, confirm, `pc-plan-apply` to build, then ship.\n- An existing OpenSpec change, plus any of `implement` / `start` / `go`: `pc-plan-apply`, then ship.\n\nBrowser is backlog-only: PR work runs on the repo platform in `platform.repo`.",
+      "skillsGuide": "### Backlog Platform: Others (Browser)\n- `pc-userstory` -> opens work item URLs via agent-browser, 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)."
+    }
+  }
+}