@plainconceptsplatform/agent-harness 3.8.3 → 3.9.0-alpha.1

package/skills/pc-make-merge-risk-assess/SKILL.md

@@ -1,70 +1,70 @@
----
-name: pc-make-merge-risk-assess
-description: Generate or update the pc-merge-risk-assess skill from project guardrails and architecture. Produces a PR-level risk assessment that loop recipes can gate automerge on. Invoked by the /make-merge-risk-assess command and the repo-initialize flow.
-license: MIT
----
-
-# Make Merge Risk Assess
-
-Analyze `ARCHITECTURE.md`, the project guardrails skill, and other project files to generate or update an `pc-merge-risk-assess` skill: a checklist of risk indicators that an AI agent evaluates before auto-merging a pull request. When any indicator matches, the agent blocks automerge and leaves the PR for human review with an explanation.
-
-## Steps
-
-1. **Check current state**
-
-   Read `.agents/skills/pc-merge-risk-assess/SKILL.md`. Determine which mode to use:
-   - Does not exist: Generate mode. Create from scratch.
-   - Exists and has a `<!-- Last updated:` footer: Update mode. Incrementally update.
-   - Exists but no timestamp: proceed in Generate mode (full regeneration).
-
-2a. **Generate mode: read source documents**
-
-   Read ALL of the following that exist:
-   - `.agents/skills/pc-guardrails-project/SKILL.md` (primary source — project-specific constraints)
-   - `.agents/skills/pc-guardrails-generic/SKILL.md` (generic safety rules)
-   - `ARCHITECTURE.md` (architecture boundaries, critical paths)
-   - `AGENTS.md` (non-negotiable constraints, verification rules)
-   - `.opencode/harness.json` (platform, concurrency)
-   - CI/CD workflows: `.github/workflows/*`, `azure-pipelines.yml`: whatever exists
-   - Loop recipes: `.loops/recipes/*-loop.yaml` (understand the automerge flow)
-
-   Use file tools to discover risk-critical code paths: `grep` for calculation engines, audit appenders, auth middleware, schema migrations, permission checks, and other sensitive areas.
-
-2b. **Update mode: incremental analysis**
-
-   Extract the `<!-- Last updated: <ISO date> -->` timestamp from the existing skill file. Then:
-   - Read `.agents/skills/pc-guardrails-project/SKILL.md` and check its `<!-- Last updated:` timestamp. If the guardrails haven't changed and ARCHITECTURE.md hasn't changed since the risk skill was last generated, report "Merge risk assessment up to date" and stop.
-   - Run `git log --oneline --since="<date>" -- <relevant config and architecture files>` to find what changed.
-   - If nothing changed: report "Merge risk assessment up to date" and stop.
-   - Update only the affected risk categories. Preserve manually-added risk indicators in unchanged categories.
-   - If changes are pervasive, fall back to Generate mode.
-
-3. **Extract risk indicators**
-
-   From the documents and code analysis, extract concrete, testable risk indicators. Follow the [category reference](category-reference.md) for the full list of categories, indicator quality standards, and the skill file template.
-
-   Each risk indicator must identify a code path or change pattern that, when touched, makes a PR too dangerous to auto-merge. The indicator must be something an AI agent can detect by reading the PR diff.
-
-4. **Write the skill**
-
-   Write (or update) `.agents/skills/pc-merge-risk-assess/SKILL.md` using the template from the [category reference](category-reference.md). Only include sections that have real indicators. Omit empty sections.
-
-5. **Update agents**
-
-   For every `*-engineer.md` in `.opencode/agents/`, add `@pc-merge-risk-assess` to the Agent Workflow ability group (skip if already present). This ensures every engineer can evaluate risk before merge. Use this pattern:
-   ```markdown
-   ## Abilities
-   - Guardrails: @pc-guardrails-generic, @pc-guardrails-project[, ...existing entries unchanged]
-   ...
-   - Development, Agent Workflow: @pc-merge-risk-assess[, ...existing entries unchanged]
-   ```
-
-   If no "Development, Agent Workflow" line exists, create it. Exclude tier variant files (`*-engineer.build.md`, `*-engineer.fast.md`, `*-engineer.plan.md`): they are generated copies; only update the base templates.
-
-6. **Report**
-
-   Tell the user:
-   - Whether the skill was generated or updated (and which categories changed)
-   - Number of risk indicators extracted per category
-   - Number of agent files updated
-   - Tip: "Rerun `/make-merge-risk-assess` any time the architecture or project guardrails change significantly."
+---
+name: pc-make-merge-risk-assess
+description: Generate or update the pc-merge-risk-assess skill from project guardrails and architecture. Produces a PR-level risk assessment that loop recipes can gate automerge on. Invoked by the /make-merge-risk-assess command and the repo-initialize flow.
+license: MIT
+---
+
+# Make Merge Risk Assess
+
+Analyze `ARCHITECTURE.md`, the project guardrails skill, and other project files to generate or update an `pc-merge-risk-assess` skill: a checklist of risk indicators that an AI agent evaluates before auto-merging a pull request. When any indicator matches, the agent blocks automerge and leaves the PR for human review with an explanation.
+
+## Steps
+
+1. **Check current state**
+
+   Read `.agents/skills/pc-merge-risk-assess/SKILL.md`. Determine which mode to use:
+   - Does not exist: Generate mode. Create from scratch.
+   - Exists and has a `<!-- Last updated:` footer: Update mode. Incrementally update.
+   - Exists but no timestamp: proceed in Generate mode (full regeneration).
+
+2a. **Generate mode: read source documents**
+
+   Read ALL of the following that exist:
+   - `.agents/skills/pc-guardrails-project/SKILL.md` (primary source — project-specific constraints)
+   - `.agents/skills/pc-guardrails-generic/SKILL.md` (generic safety rules)
+   - `ARCHITECTURE.md` (architecture boundaries, critical paths)
+   - `AGENTS.md` (non-negotiable constraints, verification rules)
+   - `.opencode/harness.json` (platform, concurrency)
+   - CI/CD workflows: `.github/workflows/*`, `azure-pipelines.yml`: whatever exists
+   - Loop recipes: `.loops/recipes/*-loop.yaml` (understand the automerge flow)
+
+   Use file tools to discover risk-critical code paths: `grep` for calculation engines, audit appenders, auth middleware, schema migrations, permission checks, and other sensitive areas.
+
+2b. **Update mode: incremental analysis**
+
+   Extract the `<!-- Last updated: <ISO date> -->` timestamp from the existing skill file. Then:
+   - Read `.agents/skills/pc-guardrails-project/SKILL.md` and check its `<!-- Last updated:` timestamp. If the guardrails haven't changed and ARCHITECTURE.md hasn't changed since the risk skill was last generated, report "Merge risk assessment up to date" and stop.
+   - Run `git log --oneline --since="<date>" -- <relevant config and architecture files>` to find what changed.
+   - If nothing changed: report "Merge risk assessment up to date" and stop.
+   - Update only the affected risk categories. Preserve manually-added risk indicators in unchanged categories.
+   - If changes are pervasive, fall back to Generate mode.
+
+3. **Extract risk indicators**
+
+   From the documents and code analysis, extract concrete, testable risk indicators. Follow the [category reference](category-reference.md) for the full list of categories, indicator quality standards, and the skill file template.
+
+   Each risk indicator must identify a code path or change pattern that, when touched, makes a PR too dangerous to auto-merge. The indicator must be something an AI agent can detect by reading the PR diff.
+
+4. **Write the skill**
+
+   Write (or update) `.agents/skills/pc-merge-risk-assess/SKILL.md` using the template from the [category reference](category-reference.md). Only include sections that have real indicators. Omit empty sections.
+
+5. **Update agents**
+
+   For every `*-engineer.md` in `.opencode/agents/`, add `@pc-merge-risk-assess` to the Agent Workflow ability group (skip if already present). This ensures every engineer can evaluate risk before merge. Use this pattern:
+   ```markdown
+   ## Abilities
+   - Guardrails: @pc-guardrails-generic, @pc-guardrails-project[, ...existing entries unchanged]
+   ...
+   - Development, Agent Workflow: @pc-merge-risk-assess[, ...existing entries unchanged]
+   ```
+
+   If no "Development, Agent Workflow" line exists, create it. Exclude tier variant files (`*-engineer.build.md`, `*-engineer.fast.md`, `*-engineer.plan.md`): they are generated copies; only update the base templates.
+
+6. **Report**
+
+   Tell the user:
+   - Whether the skill was generated or updated (and which categories changed)
+   - Number of risk indicators extracted per category
+   - Number of agent files updated
+   - Tip: "Rerun `/make-merge-risk-assess` any time the architecture or project guardrails change significantly."

package/skills/pc-make-merge-risk-assess/category-reference.md

@@ -1,114 +1,114 @@
-# Merge risk assessment category reference
-
-From the project guardrails, architecture, and code analysis, extract concrete, testable risk indicators in these categories. Only include a category if you found real evidence for it.
-
-- **Calculation integrity**: changes to whatever this project computes and cannot get wrong — an engine, its formula inputs, its reference tables, its assumptions. Any file under that namespace is an indicator. See the worked example below for the shape.
-- **Audit & compliance**: modifications to audit appenders, audit log storage, hash-chaining, or tamper-evident mechanisms. Any change that could affect regulatory traceability.
-- **Authentication & authorization**: changes to auth middleware, permission checks, role definitions, token issuance, or session management. Changes to `.RequirePermission()` calls or permission seed data.
-- **Data schema & migration**: EF Core entity changes, new migrations, column type changes, constraint additions/removals, or seed data modifications. Schema changes are always risky because they affect production data.
-- **Reference data versioning**: changes to effective-dated configuration, rate or band tables, assumptions, or any constant an output depends on. Changes to versioning or snapshot logic.
-- **Cross-boundary violations**: imports that break the layering direction (e.g. Domain referencing Application, Application referencing ASP.NET), cross-context data access bypassing ports.
-- **Security surface**: new endpoints without authorization, input validation removal, secrets exposure, dependency version downgrades, or changes to security scanning configuration.
-- **Financial correctness**: where the project handles money, any change that could produce a wrong amount — tax, currency, precision, rounding, or the type money is stored in.
-- **State machine transitions**: modifications to entity lifecycle transitions (e.g. quote status flow, approval gates, sign-off logic). Breaking a state machine can leave data in unrecoverable states.
-- **Integration contracts**: changes to external API contracts, webhook payloads, or CRM integration ports. Breaking integrations can cascade to downstream systems.
-
-Each indicator must be:
-
-- **Concrete**: name the type, method or path — "Changes to `OrderTotal.Calculate`" not "Changes to important calculations".
-- **Evidence-based**: derived from the project guardrails, the architecture, and actual code paths.
-- **Detectable**: findable by reading the PR diff alone — file paths, class names, method names, import changes.
-- **Exclusive**: each indicator belongs to one category. Never repeat it in a second.
-- **Not enforced elsewhere.** Skip anything CI already fails the build on. An indicator that duplicates a required check adds a human review the pipeline did not need.
-
-**At most 40 indicators, across all categories.** Rank by what a missed regression costs and cut from the bottom. A file this size is read on every merge decision, and past roughly this many, compliance drops regardless of how good each line is — so an indicator that will not change a verdict is worse than absent.
-
-## Worked example
-
-One project's calculation-integrity indicator, for shape only. Replace it with this repository's own: edits between the `PC-PROJECT-EXAMPLE` markers are carried over when the harness updates, and anything outside them is replaced by the shipped version.
-
-<!-- PC-PROJECT-EXAMPLE-START -->
-```markdown
-### Calculation Integrity
-- Any change under `src/pricing/engine/` — `RateEngine.Compute` is static and deterministic, and every change to it needs a golden vector in `PricingParityTests`. A wrong number here is invisible in review and correct-looking in production.
-- Any change to a rate table, band, or assumption constant, including its effective dates. The engine reads them by date, so an edit silently rewrites past outputs.
-```
-<!-- PC-PROJECT-EXAMPLE-END -->
-
-## Skill template
-
-Write (or update) `.agents/skills/pc-merge-risk-assess/SKILL.md`:
-
-```markdown
----
-name: pc-merge-risk-assess
-description: Evaluate a pull request for merge risk. Load when a loop recipe or agent needs to decide whether a PR is safe to auto-merge or requires human review. Produces a structured risk assessment with a binary outcome and reasoning.
-license: MIT
----
-
-# Merge Risk Assessment
-
-> Auto-generated by `/make-merge-risk-assess`. Regenerate when architecture or guardrails change.
-
-## Purpose
-
-Determine whether a pull request is safe to auto-merge or requires human review. This skill is loaded by AI agents in loop recipes (e.g. `dev-assess-risk`) before merging. The agent inspects the PR diff and evaluates each risk indicator below.
-
-## Output contract
-
-On completion, produce a single JSON object on stdout:
-
-```json
-{"riskLevel":"safe"|"risky","reason":"<one-sentence explanation if risky, or 'No risk indicators detected' if safe>"}
-```
-
-- `riskLevel: "risky"` → exit non-zero. The loop recipe routes to the "leave for human review" path.
-- `riskLevel: "safe"` → exit zero. The loop recipe routes to the automerge path.
-
-## Risk indicators
-
-### Calculation Integrity
-- <indicator: file path, class, or method pattern>
-- <indicator>
-
-### Audit & Compliance
-- <indicator>
-
-### Authentication & Authorization
-- <indicator>
-
-### Data Schema & Migration
-- <indicator>
-
-### Reference Data Versioning
-- <indicator>
-
-### Cross-Boundary Violations
-- <indicator>
-
-### Security Surface
-- <indicator>
-
-### Financial Correctness
-- <indicator>
-
-### State Machine Transitions
-- <indicator>
-
-### Integration Contracts
-- <indicator>
-
-## Evaluation rules
-
-1. **Load `@pc-guardrails-project` first.** Every non-negotiable constraint in the project guardrails is a potential risk indicator. If a change violates or weakens any guardrail, the outcome is `risky`.
-2. **Inspect the full PR diff** using `gh pr diff <url>`. Do not guess based on the PR title or description alone.
-3. **Check each risk indicator** against the diff. A single matching indicator is sufficient to flag as `risky`.
-4. **When risky, explain why.** The `reason` field must name the specific indicator that matched and the files involved. Do not give vague explanations.
-5. **Do not second-guess the developer.** If the changes look intentional and no indicator matches, classify as `safe`. The purpose is to catch dangerous changes, not to block all non-trivial work.
-6. **Pure additions are lower risk.** New files, new endpoints with authorization, new tests, new UI components that don't touch existing critical paths are generally safe unless they introduce schema changes or cross-boundary imports.
-7. **Refactors within a single layer are generally safe.** Renaming, extracting methods, or reorganizing within the same bounded context and same architectural layer rarely triggers a risk indicator unless the refactor changes behavior.
-
-<!-- Last updated: <current ISO timestamp> -->
-```
-
-Only include sections that have real indicators. Omit empty sections and their headers.
+# Merge risk assessment category reference
+
+From the project guardrails, architecture, and code analysis, extract concrete, testable risk indicators in these categories. Only include a category if you found real evidence for it.
+
+- **Calculation integrity**: changes to whatever this project computes and cannot get wrong — an engine, its formula inputs, its reference tables, its assumptions. Any file under that namespace is an indicator. See the worked example below for the shape.
+- **Audit & compliance**: modifications to audit appenders, audit log storage, hash-chaining, or tamper-evident mechanisms. Any change that could affect regulatory traceability.
+- **Authentication & authorization**: changes to auth middleware, permission checks, role definitions, token issuance, or session management. Changes to `.RequirePermission()` calls or permission seed data.
+- **Data schema & migration**: EF Core entity changes, new migrations, column type changes, constraint additions/removals, or seed data modifications. Schema changes are always risky because they affect production data.
+- **Reference data versioning**: changes to effective-dated configuration, rate or band tables, assumptions, or any constant an output depends on. Changes to versioning or snapshot logic.
+- **Cross-boundary violations**: imports that break the layering direction (e.g. Domain referencing Application, Application referencing ASP.NET), cross-context data access bypassing ports.
+- **Security surface**: new endpoints without authorization, input validation removal, secrets exposure, dependency version downgrades, or changes to security scanning configuration.
+- **Financial correctness**: where the project handles money, any change that could produce a wrong amount — tax, currency, precision, rounding, or the type money is stored in.
+- **State machine transitions**: modifications to entity lifecycle transitions (e.g. quote status flow, approval gates, sign-off logic). Breaking a state machine can leave data in unrecoverable states.
+- **Integration contracts**: changes to external API contracts, webhook payloads, or CRM integration ports. Breaking integrations can cascade to downstream systems.
+
+Each indicator must be:
+
+- **Concrete**: name the type, method or path — "Changes to `OrderTotal.Calculate`" not "Changes to important calculations".
+- **Evidence-based**: derived from the project guardrails, the architecture, and actual code paths.
+- **Detectable**: findable by reading the PR diff alone — file paths, class names, method names, import changes.
+- **Exclusive**: each indicator belongs to one category. Never repeat it in a second.
+- **Not enforced elsewhere.** Skip anything CI already fails the build on. An indicator that duplicates a required check adds a human review the pipeline did not need.
+
+**At most 40 indicators, across all categories.** Rank by what a missed regression costs and cut from the bottom. A file this size is read on every merge decision, and past roughly this many, compliance drops regardless of how good each line is — so an indicator that will not change a verdict is worse than absent.
+
+## Worked example
+
+One project's calculation-integrity indicator, for shape only. Replace it with this repository's own: edits between the `PC-PROJECT-EXAMPLE` markers are carried over when the harness updates, and anything outside them is replaced by the shipped version.
+
+<!-- PC-PROJECT-EXAMPLE-START -->
+```markdown
+### Calculation Integrity
+- Any change under `src/pricing/engine/` — `RateEngine.Compute` is static and deterministic, and every change to it needs a golden vector in `PricingParityTests`. A wrong number here is invisible in review and correct-looking in production.
+- Any change to a rate table, band, or assumption constant, including its effective dates. The engine reads them by date, so an edit silently rewrites past outputs.
+```
+<!-- PC-PROJECT-EXAMPLE-END -->
+
+## Skill template
+
+Write (or update) `.agents/skills/pc-merge-risk-assess/SKILL.md`:
+
+```markdown
+---
+name: pc-merge-risk-assess
+description: Evaluate a pull request for merge risk. Load when a loop recipe or agent needs to decide whether a PR is safe to auto-merge or requires human review. Produces a structured risk assessment with a binary outcome and reasoning.
+license: MIT
+---
+
+# Merge Risk Assessment
+
+> Auto-generated by `/make-merge-risk-assess`. Regenerate when architecture or guardrails change.
+
+## Purpose
+
+Determine whether a pull request is safe to auto-merge or requires human review. This skill is loaded by AI agents in loop recipes (e.g. `dev-assess-risk`) before merging. The agent inspects the PR diff and evaluates each risk indicator below.
+
+## Output contract
+
+On completion, produce a single JSON object on stdout:
+
+```json
+{"riskLevel":"safe"|"risky","reason":"<one-sentence explanation if risky, or 'No risk indicators detected' if safe>"}
+```
+
+- `riskLevel: "risky"` → exit non-zero. The loop recipe routes to the "leave for human review" path.
+- `riskLevel: "safe"` → exit zero. The loop recipe routes to the automerge path.
+
+## Risk indicators
+
+### Calculation Integrity
+- <indicator: file path, class, or method pattern>
+- <indicator>
+
+### Audit & Compliance
+- <indicator>
+
+### Authentication & Authorization
+- <indicator>
+
+### Data Schema & Migration
+- <indicator>
+
+### Reference Data Versioning
+- <indicator>
+
+### Cross-Boundary Violations
+- <indicator>
+
+### Security Surface
+- <indicator>
+
+### Financial Correctness
+- <indicator>
+
+### State Machine Transitions
+- <indicator>
+
+### Integration Contracts
+- <indicator>
+
+## Evaluation rules
+
+1. **Load `@pc-guardrails-project` first.** Every non-negotiable constraint in the project guardrails is a potential risk indicator. If a change violates or weakens any guardrail, the outcome is `risky`.
+2. **Inspect the full PR diff** using `gh pr diff <url>`. Do not guess based on the PR title or description alone.
+3. **Check each risk indicator** against the diff. A single matching indicator is sufficient to flag as `risky`.
+4. **When risky, explain why.** The `reason` field must name the specific indicator that matched and the files involved. Do not give vague explanations.
+5. **Do not second-guess the developer.** If the changes look intentional and no indicator matches, classify as `safe`. The purpose is to catch dangerous changes, not to block all non-trivial work.
+6. **Pure additions are lower risk.** New files, new endpoints with authorization, new tests, new UI components that don't touch existing critical paths are generally safe unless they introduce schema changes or cross-boundary imports.
+7. **Refactors within a single layer are generally safe.** Renaming, extracting methods, or reorganizing within the same bounded context and same architectural layer rarely triggers a risk indicator unless the refactor changes behavior.
+
+<!-- Last updated: <current ISO timestamp> -->
+```
+
+Only include sections that have real indicators. Omit empty sections and their headers.

package/skills/pc-make-user-model/SKILL.md

@@ -1,56 +1,56 @@
----
-name: pc-make-user-model
-description: Set the model for a tier (plan, build, or fast). Team-wide or user-local override. Invoked by the /make-user-model command.
-license: MIT
----
-
-Point one tier at one model, in the team config or in a machine-local override.
-
-## Rules
-
-- Only `models.<tier>` in `.opencode/harness.json` or `.opencode/harness.user.json` changes. Agent files, `opencode.jsonc` and `tasks.md` are not this command's business, and tier variants are rebuilt from these configs at startup anyway.
-- Never guess the id behind `current`: read it from the status line. A guessed id writes a model that does not exist into the team's config.
-- Never write anything when the arguments do not parse. Print the usage and stop.
-- Preserve the file's other fields and its 2-space formatting.
-
-## Contract
-
-```
-/make-user-model <tier> <model>
-/make-user-model user <tier> <model>
-```
-
-`user` writes `.opencode/harness.user.json`, which is gitignored and wins on this machine only; without it the target is `.opencode/harness.json`, which is shared. `<tier>` is exactly `plan`, `build` or `fast`. `<model>` is a fully-qualified id (`opencode/big-pickle`) or `current` for the model this session is running.
-
-No arguments means show the `models` block from both files, team first, then the usage. Change nothing.
-
-A team config that does not exist yet is a stop: onboarding has not run. A missing user config is created as `{ "models": {} }`.
-
-An id with no `/` in it is malformed; confirm before writing it:
-
-```json
-{
-  "questions": [
-    {
-      "header": "Malformed model id",
-      "question": "\"<model>\" doesn't look like a valid model id (expected provider/model-id). Write it anyway?",
-      "options": [
-        { "label": "yes", "description": "Write the value as-is to the config file." },
-        { "label": "no", "description": "Cancel. Do not write anything." }
-      ]
-    }
-  ]
-}
-```
-
-## Report
-
-```
-<team|user> config updated
-  <tier> model -> <resolved-id>
-  file: <path written>
-```
-
-The change lands on the next opencode start, when `pc-subagent-tiers` reads the configs and rebuilds the tier variants.
-
-Arguments: `$ARGUMENTS`
+---
+name: pc-make-user-model
+description: Set the model for a tier (plan, build, or fast). Team-wide or user-local override. Invoked by the /make-user-model command.
+license: MIT
+---
+
+Point one tier at one model, in the team config or in a machine-local override.
+
+## Rules
+
+- Only `models.<tier>` in `.opencode/harness.json` or `.opencode/harness.user.json` changes. Agent files, `opencode.jsonc` and `tasks.md` are not this command's business, and tier variants are rebuilt from these configs at startup anyway.
+- Never guess the id behind `current`: read it from the status line. A guessed id writes a model that does not exist into the team's config.
+- Never write anything when the arguments do not parse. Print the usage and stop.
+- Preserve the file's other fields and its 2-space formatting.
+
+## Contract
+
+```
+/make-user-model <tier> <model>
+/make-user-model user <tier> <model>
+```
+
+`user` writes `.opencode/harness.user.json`, which is gitignored and wins on this machine only; without it the target is `.opencode/harness.json`, which is shared. `<tier>` is exactly `plan`, `build` or `fast`. `<model>` is a fully-qualified id (`opencode/big-pickle`) or `current` for the model this session is running.
+
+No arguments means show the `models` block from both files, team first, then the usage. Change nothing.
+
+A team config that does not exist yet is a stop: onboarding has not run. A missing user config is created as `{ "models": {} }`.
+
+An id with no `/` in it is malformed; confirm before writing it:
+
+```json
+{
+  "questions": [
+    {
+      "header": "Malformed model id",
+      "question": "\"<model>\" doesn't look like a valid model id (expected provider/model-id). Write it anyway?",
+      "options": [
+        { "label": "yes", "description": "Write the value as-is to the config file." },
+        { "label": "no", "description": "Cancel. Do not write anything." }
+      ]
+    }
+  ]
+}
+```
+
+## Report
+
+```
+<team|user> config updated
+  <tier> model -> <resolved-id>
+  file: <path written>
+```
+
+The change lands on the next opencode start, when `pc-subagent-tiers` reads the configs and rebuilds the tier variants. For CI or a non-interactive run, `node .opencode/scripts/sync-agents.mjs` rebuilds the agents and `.opencode/harness-models.json`; `node .opencode/scripts/harness-doctor.mjs --strict` prints and validates the effective routing.
+
+Arguments: `$ARGUMENTS`

package/skills/pc-ops-ship/SKILL.md

@@ -1,22 +1,22 @@
----
-name: pc-ops-ship
-description: Create a pull request for the current feature branch, with screenshots if UI changed. Load when shipping a finished feature branch. Invoked by the /ops-ship command and the plan-goal pipeline (pr mode).
-license: MIT
----
-
-# Ops Ship
-
-## Input
-
-The caller provides (all optional):
-- PR title and body. When absent, derive them from the change context (change id, tasks completed, commit list).
-- The base branch. When absent, resolve the default branch as shown in the platform steps below.
-
-## Before opening
-
-Run the project's verification (`pnpm verify` when package.json defines it) and `node .opencode/scripts/check-diff.mjs` on the branch as it will be pushed. If any commit landed after the last passing run, run both again. Do not open the pull request while either fails, and paste the verification summary into the body: a body that says "lint clean" without the output is how a formatting error reached CI.
-
-Repo platform is set in `.opencode/harness.json` `platform.repo`. The platform-specific content below is injected by the CLI during onboarding.
-
-<!-- PC-PLATFORM-SHIP-START -->
-<!-- PC-PLATFORM-SHIP-END -->
+---
+name: pc-ops-ship
+description: Create a pull request for the current feature branch, with screenshots if UI changed. Load when shipping a finished feature branch. Invoked by the /ops-ship command and the plan-goal pipeline (pr mode).
+license: MIT
+---
+
+# Ops Ship
+
+## Input
+
+The caller provides (all optional):
+- PR title and body. When absent, derive them from the change context (change id, tasks completed, commit list).
+- The base branch. When absent, resolve the default branch as shown in the platform steps below.
+
+## Before opening
+
+Run the project's verification (`pnpm verify` when package.json defines it) and `node .opencode/scripts/check-diff.mjs` on the branch as it will be pushed. If any commit landed after the last passing run, run both again. Do not open the pull request while either fails, and paste the verification summary into the body: a body that says "lint clean" without the output is how a formatting error reached CI.
+
+Repo platform is set in `.opencode/harness.json` `platform.repo`. The platform-specific content below is injected by the CLI during onboarding.
+
+<!-- PC-PLATFORM-SHIP-START -->
+<!-- PC-PLATFORM-SHIP-END -->