@plainconceptsplatform/agent-harness 3.4.1 → 3.5.0

package/cli/fragments/archive/gl.md

@@ -1,96 +1,96 @@
-2. **Find the oldest change with a completed MR**
-
-   List unarchived changes (top-level only, excludes `archive/`):
-
-   ```bash
-   find "$REPO_ROOT/openspec/changes" -mindepth 1 -maxdepth 1 -type d -not -name 'archive' | sort
-   ```
-
-   If empty, report a blocker and stop.
-
-   List completed merge requests:
-
-   ```bash
-   glab mr list --repo {owner}/{repo} --merged --output json --jq 'sort_by(.merged_at) | .[] | {name: .title, sourceRefName: .source_branch, mergedAt: .merged_at, mergeRequestId: .iid}'
-   ```
-
-   Match each change to a completed MR using its ID and slug as search hints:
-   - No match → skip (record as blocked: `no merged MR found`).
-   - One match → eligible.
-   - Multiple matches → ask the user which MR belongs to that change.
-
-   If nothing is eligible, report a blocker and stop. Otherwise select the eligible change with the **oldest** MR `merged_at` as the candidate.
-
-3. **Confirm the candidate**
-
-   Show the candidate (ID, title, MR ID, merged date) and any blocked changes, then ask:
-
-   ```text
-   Oldest unarchived merged change found:
-     ID: {change-id}
-     Title: {title from resolved MR}
-     MR ID: {iid}
-     Merged: {merged_at}
-
-   Proceed with archiving? [yes/no]
-   ```
-
-   Stop if the user does not confirm.
-
-4. **Archive the change**
-
-   ```bash
-   git checkout -b archive/{change-id}
-   ```
-
-   Load `@openspec-archive-change` skill and follow it to archive the change.
-
-5. **Update docs**
-
-   Compare the archived change's specs against `ARCHITECTURE.md` and `DESIGN.md`. If updates are needed, show them and get user approval before applying.
-
-6. **Create the archive MR**
-
-   ```bash
-   # Stage specific paths only: a shared tree may hold another agent's or a
-   # person's edits, and -A commits them under this message.
-   git add openspec/changes/   # plus ARCHITECTURE.md / DESIGN.md if step 5 updated them
-   git commit -m "archive: {title} ({change-id})"
-   git push origin archive/{change-id}
-
-   glab mr create \
-      --repo {owner}/{repo} \
-      --source-branch "archive/{change-id}" \
-      --target-branch "$DEFAULT_BRANCH" \
-      --title "archive: {title} ({change-id})" \
-      --description "Archive SDD artifacts for {change-id} after merge."
-   ```
-
-   If work was stashed in step 1, restore it after the MR is created unless the user opts out.
-
-7. **Report**
-
-   Display:
-
-   ```text
-   Archive complete
-
-     Change ID: {change-id}
-     Title: {title}
-     Original MR: {original-mr-link}
-     Archive MR: {archive-mr-link}
-
-     Documentation updates:
-     - ARCHITECTURE.md: {count} changes applied
-     - DESIGN.md: {count} changes applied
-   ```
-
-## Rules
-
-- All OpenSpec paths resolve from `git rev-parse --show-toplevel`. Never use `/openspec/...`.
-- Only process top-level directories in `$REPO_ROOT/openspec/changes/`; exclude `archive/`.
-- Use change ID and slug only as search hints; do not assume the source branch name.
-- The oldest eligible merged change is the only candidate: never ask the user which change to archive (but do ask which MR if multiple match one change).
-- Never proceed if the selected MR is not completed.
-- Never use browser tools or direct web requests for GitLab. Use `glab` CLI only.
-- Never invent or guess MR, branch, or merge metadata.
+2. **Find the oldest change with a completed MR**
+
+   List unarchived changes (top-level only, excludes `archive/`):
+
+   ```bash
+   find "$REPO_ROOT/openspec/changes" -mindepth 1 -maxdepth 1 -type d -not -name 'archive' | sort
+   ```
+
+   If empty, report a blocker and stop.
+
+   List completed merge requests:
+
+   ```bash
+   glab mr list --repo {owner}/{repo} --merged --output json --jq 'sort_by(.merged_at) | .[] | {name: .title, sourceRefName: .source_branch, mergedAt: .merged_at, mergeRequestId: .iid}'
+   ```
+
+   Match each change to a completed MR using its ID and slug as search hints:
+   - No match → skip (record as blocked: `no merged MR found`).
+   - One match → eligible.
+   - Multiple matches → ask the user which MR belongs to that change.
+
+   If nothing is eligible, report a blocker and stop. Otherwise select the eligible change with the **oldest** MR `merged_at` as the candidate.
+
+3. **Confirm the candidate**
+
+   Show the candidate (ID, title, MR ID, merged date) and any blocked changes, then ask:
+
+   ```text
+   Oldest unarchived merged change found:
+     ID: {change-id}
+     Title: {title from resolved MR}
+     MR ID: {iid}
+     Merged: {merged_at}
+
+   Proceed with archiving? [yes/no]
+   ```
+
+   Stop if the user does not confirm.
+
+4. **Archive the change**
+
+   ```bash
+   git checkout -b archive/{change-id}
+   ```
+
+   Load `@openspec-archive-change` skill and follow it to archive the change.
+
+5. **Update docs**
+
+   Compare the archived change's specs against `ARCHITECTURE.md` and `DESIGN.md`. If updates are needed, show them and get user approval before applying.
+
+6. **Create the archive MR**
+
+   ```bash
+   # Stage specific paths only: a shared tree may hold another agent's or a
+   # person's edits, and -A commits them under this message.
+   git add openspec/changes/   # plus ARCHITECTURE.md / DESIGN.md if step 5 updated them
+   git commit -m "archive: {title} ({change-id})"
+   git push origin archive/{change-id}
+
+   glab mr create \
+      --repo {owner}/{repo} \
+      --source-branch "archive/{change-id}" \
+      --target-branch "$DEFAULT_BRANCH" \
+      --title "archive: {title} ({change-id})" \
+      --description "Archive SDD artifacts for {change-id} after merge."
+   ```
+
+   If work was stashed in step 1, restore it after the MR is created unless the user opts out.
+
+7. **Report**
+
+   Display:
+
+   ```text
+   Archive complete
+
+     Change ID: {change-id}
+     Title: {title}
+     Original MR: {original-mr-link}
+     Archive MR: {archive-mr-link}
+
+     Documentation updates:
+     - ARCHITECTURE.md: {count} changes applied
+     - DESIGN.md: {count} changes applied
+   ```
+
+## Rules
+
+- All OpenSpec paths resolve from `git rev-parse --show-toplevel`. Never use `/openspec/...`.
+- Only process top-level directories in `$REPO_ROOT/openspec/changes/`; exclude `archive/`.
+- Use change ID and slug only as search hints; do not assume the source branch name.
+- The oldest eligible merged change is the only candidate: never ask the user which change to archive (but do ask which MR if multiple match one change).
+- Never proceed if the selected MR is not completed.
+- Never use browser tools or direct web requests for GitLab. Use `glab` CLI only.
+- Never invent or guess MR, branch, or merge metadata.

package/cli/fragments/archive/none.md

@@ -1,75 +1,75 @@
-2. **Find the oldest unarchived change**
-
-   List unarchived changes (top-level only, excludes `archive/`):
-
-   ```bash
-   find "$REPO_ROOT/openspec/changes" -mindepth 1 -maxdepth 1 -type d -not -name 'archive' | sort
-   ```
-
-   If empty, report a blocker and stop. Otherwise select the **oldest** change (by directory creation/sort order) as the candidate.
-
-   This mode has no platform PR integration, so completion is judged from local state only. Do not look up remote PRs or work items.
-
-3. **Confirm the candidate**
-
-   Show the candidate (ID, title) and any other unarchived changes, then ask:
-
-   ```text
-   Oldest unarchived change found:
-     ID: {change-id}
-     Title: {title from proposal.md}
-
-   Proceed with archiving? [yes/no]
-   ```
-
-   Stop if the user does not confirm.
-
-4. **Archive the change**
-
-   ```bash
-   git checkout -b archive/{change-id}
-   ```
-
-   Load `@openspec-archive-change` skill and follow it to archive the change.
-
-5. **Update docs**
-
-   Compare the archived change's specs against `ARCHITECTURE.md` and `DESIGN.md`. If updates are needed, show them and get user approval before applying.
-
-6. **Commit the archive**
-
-   ```bash
-   # Stage specific paths only: a shared tree may hold another agent's or a
-   # person's edits, and -A commits them under this message.
-   git add openspec/changes/   # plus ARCHITECTURE.md / DESIGN.md if step 5 updated them
-   git commit -m "archive: {title} ({change-id})"
-   ```
-
-   No PR is created in this mode. Leave the `archive/{change-id}` branch for the user to merge or push manually if they choose.
-
-   If work was stashed in step 1, restore it after the commit unless the user opts out.
-
-7. **Report**
-
-   Display:
-
-   ```text
-   Archive complete
-
-     Change ID: {change-id}
-     Title: {title}
-     Archive branch: archive/{change-id}
-
-     Documentation updates:
-     - ARCHITECTURE.md: {count} changes applied
-     - DESIGN.md: {count} changes applied
-   ```
-
-## Rules
-
-- All OpenSpec paths resolve from `git rev-parse --show-toplevel`. Never use `/openspec/...`.
-- Only process top-level directories in `$REPO_ROOT/openspec/changes/`; exclude `archive/`.
-- Use change ID and slug only as search hints; do not assume the source branch name.
-- The oldest unarchived change is the only candidate: never ask the user which change to archive.
-- This mode has no GitHub or Azure DevOps integration. Never call `gh` or `az`, and never use browser tools or direct web requests for PR/work-item lookups.
-- Never invent or guess PR, branch, or merge metadata.
+2. **Find the oldest unarchived change**
+
+   List unarchived changes (top-level only, excludes `archive/`):
+
+   ```bash
+   find "$REPO_ROOT/openspec/changes" -mindepth 1 -maxdepth 1 -type d -not -name 'archive' | sort
+   ```
+
+   If empty, report a blocker and stop. Otherwise select the **oldest** change (by directory creation/sort order) as the candidate.
+
+   This mode has no platform PR integration, so completion is judged from local state only. Do not look up remote PRs or work items.
+
+3. **Confirm the candidate**
+
+   Show the candidate (ID, title) and any other unarchived changes, then ask:
+
+   ```text
+   Oldest unarchived change found:
+     ID: {change-id}
+     Title: {title from proposal.md}
+
+   Proceed with archiving? [yes/no]
+   ```
+
+   Stop if the user does not confirm.
+
+4. **Archive the change**
+
+   ```bash
+   git checkout -b archive/{change-id}
+   ```
+
+   Load `@openspec-archive-change` skill and follow it to archive the change.
+
+5. **Update docs**
+
+   Compare the archived change's specs against `ARCHITECTURE.md` and `DESIGN.md`. If updates are needed, show them and get user approval before applying.
+
+6. **Commit the archive**
+
+   ```bash
+   # Stage specific paths only: a shared tree may hold another agent's or a
+   # person's edits, and -A commits them under this message.
+   git add openspec/changes/   # plus ARCHITECTURE.md / DESIGN.md if step 5 updated them
+   git commit -m "archive: {title} ({change-id})"
+   ```
+
+   No PR is created in this mode. Leave the `archive/{change-id}` branch for the user to merge or push manually if they choose.
+
+   If work was stashed in step 1, restore it after the commit unless the user opts out.
+
+7. **Report**
+
+   Display:
+
+   ```text
+   Archive complete
+
+     Change ID: {change-id}
+     Title: {title}
+     Archive branch: archive/{change-id}
+
+     Documentation updates:
+     - ARCHITECTURE.md: {count} changes applied
+     - DESIGN.md: {count} changes applied
+   ```
+
+## Rules
+
+- All OpenSpec paths resolve from `git rev-parse --show-toplevel`. Never use `/openspec/...`.
+- Only process top-level directories in `$REPO_ROOT/openspec/changes/`; exclude `archive/`.
+- Use change ID and slug only as search hints; do not assume the source branch name.
+- The oldest unarchived change is the only candidate: never ask the user which change to archive.
+- This mode has no GitHub or Azure DevOps integration. Never call `gh` or `az`, and never use browser tools or direct web requests for PR/work-item lookups.
+- Never invent or guess PR, branch, or merge metadata.

package/cli/fragments/guardrails/codegraph.md

@@ -1,5 +1,5 @@
-## CodeGraph
-
-- `codegraph_explore` replaces grep, glob and read for anything indexed: one call returns the relevant symbols' verbatim, line-numbered source plus the call paths between them, where finding the same thing by hand takes a dozen. Give it a symbol name, a file path, or a plain question.
-- Fall back to grep, glob and read when it returns nothing, or for what it does not index: config files, plain-text docs, `.env` patterns, raw string searches. Say that it returned nothing when you do.
-- It is an MCP server, not a CLI. Never run `codegraph` in bash.
+## CodeGraph
+
+- `codegraph_explore` replaces grep, glob and read for anything indexed: one call returns the relevant symbols' verbatim, line-numbered source plus the call paths between them, where finding the same thing by hand takes a dozen. Give it a symbol name, a file path, or a plain question.
+- Fall back to grep, glob and read when it returns nothing, or for what it does not index: config files, plain-text docs, `.env` patterns, raw string searches. Say that it returned nothing when you do.
+- It is an MCP server, not a CLI. Never run `codegraph` in bash.

package/cli/fragments/guardrails/humanizer.md

@@ -1,4 +1,4 @@
-## Humanizer (optimization skill)
-
-- Load `skill("humanizer")` before writing prose (commit messages, PR descriptions, docs, proposals); unhumanized prose reads as machine-written. Editing, shell and spawning stay blocked until it is loaded (pc-system-reminders).
-- Never apply it to code, config files, or terminal output: prose only.
+## Humanizer (optimization skill)
+
+- Load `skill("humanizer")` before writing prose (commit messages, PR descriptions, docs, proposals); unhumanized prose reads as machine-written. Editing, shell and spawning stay blocked until it is loaded (pc-system-reminders).
+- Never apply it to code, config files, or terminal output: prose only.

package/cli/fragments/guardrails/memory.md

@@ -1,4 +1,4 @@
-## Agentmemory
-
-- Cross-session context lives in the agentmemory MCP tools: `memory_smart_search` for prior decisions before working somewhere unfamiliar, `memory_save` for architecture decisions and anything the next agent will need, plus `memory_sessions` and `memory_governance_delete`.
-- It is an MCP server, not a CLI. Never run `agentmemory` in bash; start it with `agentmemory` in a separate terminal and use the tools.
+## Agentmemory
+
+- Cross-session context lives in the agentmemory MCP tools: `memory_smart_search` for prior decisions before working somewhere unfamiliar, `memory_save` for architecture decisions and anything the next agent will need, plus `memory_sessions` and `memory_governance_delete`.
+- It is an MCP server, not a CLI. Never run `agentmemory` in bash; start it with `agentmemory` in a separate terminal and use the tools.

package/cli/fragments/guardrails/rtk.md

@@ -1,3 +1,3 @@
-## RTK
-
-- Prefix CLI commands with `rtk` (`rtk git diff`, `rtk pnpm test`); it strips the output down to what matters. Read-only commands like `cat`, `ls` and `Get-Content` are exempt.
+## RTK
+
+- Prefix CLI commands with `rtk` (`rtk git diff`, `rtk pnpm test`); it strips the output down to what matters. Read-only commands like `cat`, `ls` and `Get-Content` are exempt.

package/cli/fragments/guardrails/simple-english.md

@@ -1,4 +1,4 @@
-## Simple English (optimization skill)
-
-- Apply Simplified Technical English to all prose: `skill("simple-english")`. Editing, shell and spawning stay blocked until it is loaded (pc-system-reminders).
-- Keep code blocks, identifiers, CLI commands, file paths, quoted errors, and product names exact.
+## Simple English (optimization skill)
+
+- Apply Simplified Technical English to all prose: `skill("simple-english")`. Editing, shell and spawning stay blocked until it is loaded (pc-system-reminders).
+- Keep code blocks, identifiers, CLI commands, file paths, quoted errors, and product names exact.

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

@@ -1,82 +1,82 @@
-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"
-}
-```
-
+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/presets/agents-content.json

@@ -1,34 +1,34 @@
-{
-  "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)."
-    }
-  }
-}
+{
+  "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)."
+    }
+  }
+}