@plainconceptsplatform/agent-harness 3.5.0 → 3.7.0

package/skills/agent-harness-cli/SKILL.md

@@ -1,86 +1,86 @@
----
-name: agent-harness-cli
-description: Drive the agent-harness CLI - install the Plain Concepts Platform Harness into a repository, bring an existing one up to date, set up a teammate's machine, or rerun a single step. Load when asked to install, update, or repair the Platform Harness, when a repo needs AI/agent scaffolding set up, or when a command like `npx @plainconceptsplatform/agent-harness` fails and needs diagnosing.
-license: MIT
----
-
-# agent-harness CLI
-
-`agent-harness` installs the **Plain Concepts Platform Harness** into a repository and keeps it up to date. The harness is Plain Concepts' own, and it is the set of files agents work from: slash commands, `pc-*` skills (the `pc-` is Plain Concepts), an agent team, OpenCode plugins, an OpenSpec workspace, and generated `ARCHITECTURE.md` and `DESIGN.md`.
-
-Everything runs against the **current working directory**. `cd` into the target repository first; there is no `--path` flag.
-
-## Pick the right verb
-
-Read the repo before running anything. `.opencode/harness.json` is the marker for "harness already installed".
-
-| Situation | Command |
-| --- | --- |
-| No `.opencode/harness.json` | `npx @plainconceptsplatform/agent-harness@latest` (the install wizard) |
-| Harness present, want the latest release's files | `npx @plainconceptsplatform/agent-harness@latest update` |
-| Harness present, new machine or new teammate | `npx @plainconceptsplatform/agent-harness join` |
-| One specific thing needs redoing | a single step command, see below |
-
-Requires Node.js 18+.
-
-## The install wizard is interactive
-
-The wizard asks about source scope, backlog and repository platform, three models, and optional token-optimization tools. **Do not run it in a non-interactive shell.** It will hang or abort. If you cannot present prompts to a human, say so and hand the command to the user rather than trying to drive it.
-
-Everything else (`update`, and the single-step commands other than `platform`, `models`, `optimization`) runs without prompts.
-
-## Single-step commands
-
-Run one step without the full wizard. Each reuses context from `.opencode/harness.json` when it needs to.
-
-```
-clean           Remove pre-existing AI files (AGENTS.md, .cursorrules, CLAUDE.md, ...)
-platform        Choose backlog + repository platform
-copy            Copy agents, skills, commands, docs into the repo
-openspec        Initialize the OpenSpec workspace
-models          Choose plan / build / fast models
-optimization    Configure RTK, quota, Simple English, codegraph, agentmemory, humanizer
-browser         Install agent-browser (npm package + its Chrome for Testing)
-metadata        Rewrite .opencode/harness.json
-```
-
-`metadata` last if you ran several, because it refreshes the config the others read.
-
-## What lands in the repo
-
-```
-.opencode/
-  harness.json            harness config: platform, models, agents.maxConcurrent
-  harness-managed.json    hash per managed file, so update spares your edits
-  harness.user.json       per-developer model override (gitignored)
-  harness-run.json        live subagent wave state (gitignored)
-  commands/               slash commands
-  plugins/                pc-subagent-monitor, pc-subagent-tiers, pc-system-reminders
-  agents/                 fullstack-engineer + user-created *-engineer files
-.agents/skills/           pc-* skills
-AGENTS.md ARCHITECTURE.md DESIGN.md
-```
-
-After a fresh install, the next move is `/repo-initialize` inside OpenCode. That is what generates real `ARCHITECTURE.md` and `DESIGN.md` and activates the agent team. Installing the harness alone does not do it.
-
-## `update` is edit-safe
-
-`update` compares each managed file against the hash recorded in `.opencode/harness-managed.json`. Files you changed by hand are left alone and reported as preserved. Generated skills (`pc-guardrails-project`, `pc-merge-risk-assess`) are never overwritten once populated. So `update` is safe to run repeatedly, and a second consecutive run should report no changes.
-
-## Diagnosing failures
-
-**"This project was set up by opencode-onboard v1".** The repo has v1 state files or `ob-*` skills. v2 renamed both and does not migrate. Re-onboard on a clean branch; do not try to rename the files by hand, because the marker comments inside the installed skills changed too.
-
-**"No config found. Run the wizard first."** `update` or a step needs `.opencode/harness.json` and it is absent. Run the wizard.
-
-**A platform step reports nothing and changes nothing.** Platform content is injected into `<!-- PC-PLATFORM-*-START/END -->` marker pairs. If a marker pair is missing from the target file, injection is skipped silently. Check the markers exist before concluding the step worked.
-
-**Skills missing after install.** Skill installation ends with `npx skills experimental_install --yes`, run once at the end of the optimization step. If it failed, rerun it directly in the repo.
-
-**Platform CLI warnings.** The harness expects `gh` (GitHub), `az` + azure-devops extension (Azure DevOps), `acli` (Jira), `glab` (GitLab), each authenticated. These are warnings, not fatal; the harness installs, but the matching `/ops-*` flows will not work until the CLI is present.
-
-## Rules
-
-- Never edit `.opencode/harness.json` by hand to change models. Use `/make-user-model <tier> <model>` inside OpenCode, or the `models` step.
-- Never commit `harness.user.json` or `harness-run.json`. Both belong in `.opencode/.gitignore`, which `join` verifies.
-- `clean` deletes files. Confirm with the user before running it on a repo that already has AI configuration worth keeping.
+---
+name: agent-harness-cli
+description: Drive the agent-harness CLI - install the Plain Concepts Platform Harness into a repository, bring an existing one up to date, set up a teammate's machine, or rerun a single step. Load when asked to install, update, or repair the Platform Harness, when a repo needs AI/agent scaffolding set up, or when a command like `npx @plainconceptsplatform/agent-harness` fails and needs diagnosing.
+license: MIT
+---
+
+# agent-harness CLI
+
+`agent-harness` installs the **Plain Concepts Platform Harness** into a repository and keeps it up to date. The harness is Plain Concepts' own, and it is the set of files agents work from: slash commands, `pc-*` skills (the `pc-` is Plain Concepts), an agent team, OpenCode plugins, an OpenSpec workspace, and generated `ARCHITECTURE.md` and `DESIGN.md`.
+
+Everything runs against the **current working directory**. `cd` into the target repository first; there is no `--path` flag.
+
+## Pick the right verb
+
+Read the repo before running anything. `.opencode/harness.json` is the marker for "harness already installed".
+
+| Situation | Command |
+| --- | --- |
+| No `.opencode/harness.json` | `npx @plainconceptsplatform/agent-harness@latest` (the install wizard) |
+| Harness present, want the latest release's files | `npx @plainconceptsplatform/agent-harness@latest update` |
+| Harness present, new machine or new teammate | `npx @plainconceptsplatform/agent-harness join` |
+| One specific thing needs redoing | a single step command, see below |
+
+Requires Node.js 18+.
+
+## The install wizard is interactive
+
+The wizard asks about source scope, backlog and repository platform, three models, and optional token-optimization tools. **Do not run it in a non-interactive shell.** It will hang or abort. If you cannot present prompts to a human, say so and hand the command to the user rather than trying to drive it.
+
+Everything else (`update`, and the single-step commands other than `platform`, `models`, `optimization`) runs without prompts.
+
+## Single-step commands
+
+Run one step without the full wizard. Each reuses context from `.opencode/harness.json` when it needs to.
+
+```
+clean           Remove pre-existing AI files (AGENTS.md, .cursorrules, CLAUDE.md, ...)
+platform        Choose backlog + repository platform
+copy            Copy agents, skills, commands, docs into the repo
+openspec        Initialize the OpenSpec workspace
+models          Choose plan / build / fast models
+optimization    Configure RTK, quota, Simple English, codegraph, agentmemory, humanizer
+browser         Install agent-browser (npm package + its Chrome for Testing)
+metadata        Rewrite .opencode/harness.json
+```
+
+`metadata` last if you ran several, because it refreshes the config the others read.
+
+## What lands in the repo
+
+```
+.opencode/
+  harness.json            harness config: platform, models, agents.maxConcurrent
+  harness-managed.json    hash per managed file, so update spares your edits
+  harness.user.json       per-developer model override (gitignored)
+  harness-run.json        live subagent wave state (gitignored)
+  commands/               slash commands
+  plugins/                pc-commit-coauthor, pc-subagent-monitor, pc-subagent-tiers, pc-system-reminders
+  agents/                 fullstack-engineer + user-created *-engineer files
+.agents/skills/           pc-* skills
+AGENTS.md ARCHITECTURE.md DESIGN.md
+```
+
+After a fresh install, the next move is `/repo-initialize` inside OpenCode. That is what generates real `ARCHITECTURE.md` and `DESIGN.md` and activates the agent team. Installing the harness alone does not do it.
+
+## `update` is edit-safe
+
+`update` compares each managed file against the hash recorded in `.opencode/harness-managed.json`. Files you changed by hand are left alone and reported as preserved. Generated skills (`pc-guardrails-project`, `pc-merge-risk-assess`) are never overwritten once populated. So `update` is safe to run repeatedly, and a second consecutive run should report no changes.
+
+## Diagnosing failures
+
+**"This project was set up by opencode-onboard v1".** The repo has v1 state files or `ob-*` skills. v2 renamed both and does not migrate. Re-onboard on a clean branch; do not try to rename the files by hand, because the marker comments inside the installed skills changed too.
+
+**"No config found. Run the wizard first."** `update` or a step needs `.opencode/harness.json` and it is absent. Run the wizard.
+
+**A platform step reports nothing and changes nothing.** Platform content is injected into `<!-- PC-PLATFORM-*-START/END -->` marker pairs. If a marker pair is missing from the target file, injection is skipped silently. Check the markers exist before concluding the step worked.
+
+**Skills missing after install.** Skill installation ends with `npx skills experimental_install --yes`, run once at the end of the optimization step. If it failed, rerun it directly in the repo.
+
+**Platform CLI warnings.** The harness expects `gh` (GitHub), `az` + azure-devops extension (Azure DevOps), `acli` (Jira), `glab` (GitLab), each authenticated. These are warnings, not fatal; the harness installs, but the matching `/ops-*` flows will not work until the CLI is present.
+
+## Rules
+
+- Never edit `.opencode/harness.json` by hand to change models. Use `/make-user-model <tier> <model>` inside OpenCode, or the `models` step.
+- Never commit `harness.user.json` or `harness-run.json`. Both belong in `.opencode/.gitignore`, which `join` verifies.
+- `clean` deletes files. Confirm with the user before running it on a repo that already has AI configuration worth keeping.

package/skills/browser-automation/SKILL.md

@@ -1,72 +1,72 @@
----
-name: browser-automation
-description: Reliable, composable browser automation using agent-browser. Use when capturing screenshots of a locally running app, clicking UI elements, reading page content, or automating browser interactions on localhost.
-license: MIT
-compatibility: Requires agent-browser CLI installed (Rust binary) and running.
-metadata:
-  author: copilots
-  version: "2.0"
----
-
-This skill operates on `localhost` URLs only. Screenshots, clicks, typing, scrolling, and reads on locally running apps are in scope. External services (github.com, dev.azure.com, npmjs.com, etc.) are out of scope for browser tools.
-
-The only exception: when the user selects "Others (Browser)" as their backlog platform during onboarding, the `pc-userstory` skill may navigate to work item URLs the user explicitly provides. That is the sole case where external navigation is permitted, and only to URLs the user explicitly gives you.
-
-## Best-practice workflow
-
-1. Open the page: `agent-browser open <url>` (launches its own Chrome; reuses the running daemon)
-2. Take a snapshot: `agent-browser snapshot` to get the accessibility tree with `@ref` handles
-3. Interact by ref: `agent-browser click @e2`, `agent-browser fill @e3 "text"`
-4. Wait when needed: `agent-browser wait --load networkidle` or `agent-browser wait <selector>`
-5. Confirm the result with a fresh `snapshot`, `get text`, or `screenshot`
-
-Refs like `@e2` come from the last snapshot and go stale after page changes: retake the snapshot after navigation or dynamic updates before reusing them. When a click fails because another element covers the target (consent banner, modal), dismiss or interact with the covering element, then take a fresh snapshot before retrying.
-
-## Tool access
-
-- MCP tools (inside OpenCode): `agent_browser_open`, `agent_browser_snapshot`, `agent_browser_click`, `agent_browser_fill`, `agent_browser_type`, `agent_browser_wait_for_selector`, `agent_browser_screenshot`, `agent_browser_eval`, `agent_browser_close` — configured in `opencode.jsonc` with `--tools core`
-- CLI (any agent, any host): every command below works identically via bash
-- Diagnose the install: `agent-browser doctor`
-
-## Selecting elements
-
-- Prefer refs from `snapshot` (`@e1`, `@e2`, ...) over CSS selectors
-- CSS selectors also work: `agent-browser click "#submit"`, `agent-browser fill "#email" "text"`
-- Semantic locators: `agent-browser find role button click --name "Submit"`, `find text "Sign In" click`, `find label "Email" fill "value"`, `find testid <id> click`
-- Native selects: `agent-browser select <sel> <value>`
-
-## Reading state
-
-- `agent-browser get text <sel>` — text content of an element
-- `agent-browser get value <sel>` — input value
-- `agent-browser snapshot` — structured accessibility tree (preferred for parsing)
-- `agent-browser screenshot [path]` — `--full` for full page, `--annotate` for numbered labels
-- `agent-browser read` — agent-readable markdown of the active tab (no Chrome launch for URL reads)
-
-## Tabs and sessions
-
-- `agent-browser tab` lists tabs with stable `t1`, `t2` ids; `tab new --label <name>` and `tab <label>` switch
-- `agent-browser close` closes the browser; `close --all` closes every session
-
-## CLI-first debugging
-
-- `agent-browser doctor` — diagnose install, Chrome, and daemon state
-- `agent-browser console` — view console messages; `agent-browser errors` — uncaught exceptions
-- `agent-browser eval "<js>"` — run JavaScript in the page
-- `agent-browser network requests --filter api` — inspect tracked requests
-
-## Troubleshooting
-
-- Stale ref: take a fresh `snapshot` after any navigation or DOM change
-- Covered click: the error names the covering element; dismiss it, re-snapshot, retry
-- Selector fails: confirm the content exists with `agent-browser get text` or a snapshot before retrying
-- Daemon or Chrome issues: run `agent-browser doctor`
-
-## Scope
-
-- Screenshots of locally running app on `localhost` URLs: in scope
-- Click, type, scroll, read on `localhost` pages: in scope
-- Navigate to work item URLs the user explicitly provides (when backlog platform is "Others (Browser)"): in scope
-- Navigate to external services for non-work-item purposes: out of scope
-- DevOps or GitHub CLI operations via browser tools: out of scope
-- Reading or modifying production systems via browser tools: out of scope
+---
+name: browser-automation
+description: Reliable, composable browser automation using agent-browser. Use when capturing screenshots of a locally running app, clicking UI elements, reading page content, or automating browser interactions on localhost.
+license: MIT
+compatibility: Requires agent-browser CLI installed (Rust binary) and running.
+metadata:
+  author: copilots
+  version: "2.0"
+---
+
+This skill operates on `localhost` URLs only. Screenshots, clicks, typing, scrolling, and reads on locally running apps are in scope. External services (github.com, dev.azure.com, npmjs.com, etc.) are out of scope for browser tools.
+
+The only exception: when the user selects "Others (Browser)" as their backlog platform during onboarding, the `pc-userstory` skill may navigate to work item URLs the user explicitly provides. That is the sole case where external navigation is permitted, and only to URLs the user explicitly gives you.
+
+## Best-practice workflow
+
+1. Open the page: `agent-browser open <url>` (launches its own Chrome; reuses the running daemon)
+2. Take a snapshot: `agent-browser snapshot` to get the accessibility tree with `@ref` handles
+3. Interact by ref: `agent-browser click @e2`, `agent-browser fill @e3 "text"`
+4. Wait when needed: `agent-browser wait --load networkidle` or `agent-browser wait <selector>`
+5. Confirm the result with a fresh `snapshot`, `get text`, or `screenshot`
+
+Refs like `@e2` come from the last snapshot and go stale after page changes: retake the snapshot after navigation or dynamic updates before reusing them. When a click fails because another element covers the target (consent banner, modal), dismiss or interact with the covering element, then take a fresh snapshot before retrying.
+
+## Tool access
+
+- MCP tools (inside OpenCode): `agent_browser_open`, `agent_browser_snapshot`, `agent_browser_click`, `agent_browser_fill`, `agent_browser_type`, `agent_browser_wait_for_selector`, `agent_browser_screenshot`, `agent_browser_eval`, `agent_browser_close` — configured in `opencode.jsonc` with `--tools core`
+- CLI (any agent, any host): every command below works identically via bash
+- Diagnose the install: `agent-browser doctor`
+
+## Selecting elements
+
+- Prefer refs from `snapshot` (`@e1`, `@e2`, ...) over CSS selectors
+- CSS selectors also work: `agent-browser click "#submit"`, `agent-browser fill "#email" "text"`
+- Semantic locators: `agent-browser find role button click --name "Submit"`, `find text "Sign In" click`, `find label "Email" fill "value"`, `find testid <id> click`
+- Native selects: `agent-browser select <sel> <value>`
+
+## Reading state
+
+- `agent-browser get text <sel>` — text content of an element
+- `agent-browser get value <sel>` — input value
+- `agent-browser snapshot` — structured accessibility tree (preferred for parsing)
+- `agent-browser screenshot [path]` — `--full` for full page, `--annotate` for numbered labels
+- `agent-browser read` — agent-readable markdown of the active tab (no Chrome launch for URL reads)
+
+## Tabs and sessions
+
+- `agent-browser tab` lists tabs with stable `t1`, `t2` ids; `tab new --label <name>` and `tab <label>` switch
+- `agent-browser close` closes the browser; `close --all` closes every session
+
+## CLI-first debugging
+
+- `agent-browser doctor` — diagnose install, Chrome, and daemon state
+- `agent-browser console` — view console messages; `agent-browser errors` — uncaught exceptions
+- `agent-browser eval "<js>"` — run JavaScript in the page
+- `agent-browser network requests --filter api` — inspect tracked requests
+
+## Troubleshooting
+
+- Stale ref: take a fresh `snapshot` after any navigation or DOM change
+- Covered click: the error names the covering element; dismiss it, re-snapshot, retry
+- Selector fails: confirm the content exists with `agent-browser get text` or a snapshot before retrying
+- Daemon or Chrome issues: run `agent-browser doctor`
+
+## Scope
+
+- Screenshots of locally running app on `localhost` URLs: in scope
+- Click, type, scroll, read on `localhost` pages: in scope
+- Navigate to work item URLs the user explicitly provides (when backlog platform is "Others (Browser)"): in scope
+- Navigate to external services for non-work-item purposes: out of scope
+- DevOps or GitHub CLI operations via browser tools: out of scope
+- Reading or modifying production systems via browser tools: out of scope

package/skills/pc-guardrails-generic/SKILL.md

@@ -1,53 +1,53 @@
----
-name: pc-guardrails-generic
-description: Generic guardrails, foundational rules that all agents follow. Users add specialized guardrails skills for specific concerns. Covers secrets, code quality, security, tool usage, and engineer workflow.
-license: MIT
----
-
-## Transitive loads (optimization skills)
-
-The marker sections below name the optimization skills this project selected. Load each before doing any work.
-
-## Secrets
-
-- Treat `.env` files as write-only: write to them when configuring, read credentials at runtime from the environment or secret store.
-- Never put a credential, API key, or token in a log line, output, or commit in anything but encrypted or template form.
-
-## Code
-
-- Zero comments by default. Write one only for what the code cannot show and we do not control: a vendor bug, an external contract, a legal rule. Leave every file you touch with no comment slop, old or new.
-- Never add a file that collects unrelated things — `constants.js`, `types.ts`, `utils.ts`. One responsibility per file, split by domain. A file importing from many unrelated modules is already the symptom.
-
-## Temporary files
-
-- Never write outside `$REPO_ROOT` or an OS temp directory: the next agent cannot see it and nobody cleans it up. Scratch goes under `$REPO_ROOT/.opencode/.tmp/` (enforced by pc-system-reminders).
-- Never report a `.tmp/` path as a deliverable. Copy or move the artifact to its repository path first. Never leave scratch files behind unless they are evidence for a failure you are reporting.
-
-## Tests
-
-- Never write more tests than the change requires. A bug fix gets one regression test. A new function gets tests for its public contract, not every internal branch. Never aim for a coverage number.
-- Never test framework or library internals. Test your code's contract, not that EF Core saves a tracked entity.
-- Never generate integration, e2e, or snapshot tests unless explicitly asked. Mock nothing you do not own — use a fake that records state. Never add a test that duplicates a type-check or linter rule.
-- `node .opencode/scripts/check-diff.mjs` enforces the comment and test rules on the diff and must exit 0.
-
-<!-- PC-GUARDRAILS-RTK-START -->
-<!-- PC-GUARDRAILS-RTK-END -->
-
-<!-- PC-GUARDRAILS-CODEGRAPH-START -->
-<!-- PC-GUARDRAILS-CODEGRAPH-END -->
-
-<!-- PC-GUARDRAILS-MEMORY-START -->
-<!-- PC-GUARDRAILS-MEMORY-END -->
-
-<!-- PC-GUARDRAILS-SIMPLE-ENGLISH-START -->
-<!-- PC-GUARDRAILS-SIMPLE-ENGLISH-END -->
-
-<!-- PC-GUARDRAILS-HUMANIZER-START -->
-<!-- PC-GUARDRAILS-HUMANIZER-END -->
-
-## Engineer workflow (when spawned)
-
-The lead puts your task IDs and their text in your prompt. Two things about that are not up to you:
-
-- Load every skill under your `## Abilities` before you start, guardrails first, one `skill` call per `@skill-name`. Editing, shell and spawning are blocked until you have (pc-system-reminders).
-- Edit only files in your assigned scope, then return: task IDs done, files changed, tests and lint result, decisions made. Then exit. Never poll for more work or claim a task the lead did not give you.
+---
+name: pc-guardrails-generic
+description: Generic guardrails, foundational rules that all agents follow. Users add specialized guardrails skills for specific concerns. Covers secrets, code quality, security, tool usage, and engineer workflow.
+license: MIT
+---
+
+## Transitive loads (optimization skills)
+
+The marker sections below name the optimization skills this project selected. Load each before doing any work.
+
+## Secrets
+
+- Treat `.env` files as write-only: write to them when configuring, read credentials at runtime from the environment or secret store.
+- Never put a credential, API key, or token in a log line, output, or commit in anything but encrypted or template form.
+
+## Code
+
+- Zero comments by default. Write one only for what the code cannot show and we do not control: a vendor bug, an external contract, a legal rule. Leave every file you touch with no comment slop, old or new.
+- Never add a file that collects unrelated things — `constants.js`, `types.ts`, `utils.ts`. One responsibility per file, split by domain. A file importing from many unrelated modules is already the symptom.
+
+## Temporary files
+
+- Never write outside `$REPO_ROOT` or an OS temp directory: the next agent cannot see it and nobody cleans it up. Scratch goes under `$REPO_ROOT/.opencode/.tmp/` (enforced by pc-system-reminders).
+- Never report a `.tmp/` path as a deliverable. Copy or move the artifact to its repository path first. Never leave scratch files behind unless they are evidence for a failure you are reporting.
+
+## Tests
+
+- Never write more tests than the change requires. A bug fix gets one regression test. A new function gets tests for its public contract, not every internal branch. Never aim for a coverage number.
+- Never test framework or library internals. Test your code's contract, not that EF Core saves a tracked entity.
+- Never generate integration, e2e, or snapshot tests unless explicitly asked. Mock nothing you do not own — use a fake that records state. Never add a test that duplicates a type-check or linter rule.
+- `node .opencode/scripts/check-diff.mjs` enforces the comment and test rules on the diff and must exit 0.
+
+<!-- PC-GUARDRAILS-RTK-START -->
+<!-- PC-GUARDRAILS-RTK-END -->
+
+<!-- PC-GUARDRAILS-CODEGRAPH-START -->
+<!-- PC-GUARDRAILS-CODEGRAPH-END -->
+
+<!-- PC-GUARDRAILS-MEMORY-START -->
+<!-- PC-GUARDRAILS-MEMORY-END -->
+
+<!-- PC-GUARDRAILS-SIMPLE-ENGLISH-START -->
+<!-- PC-GUARDRAILS-SIMPLE-ENGLISH-END -->
+
+<!-- PC-GUARDRAILS-HUMANIZER-START -->
+<!-- PC-GUARDRAILS-HUMANIZER-END -->
+
+## Engineer workflow (when spawned)
+
+The lead puts your task IDs and their text in your prompt. Two things about that are not up to you:
+
+- Load every skill under your `## Abilities` before you start, guardrails first, one `skill` call per `@skill-name`. Editing, shell and spawning are blocked until you have (pc-system-reminders).
+- Edit only files in your assigned scope, then return: task IDs done, files changed, tests and lint result, decisions made. Then exit. Never poll for more work or claim a task the lead did not give you.

package/skills/pc-guardrails-project/SKILL.md

@@ -1,8 +1,8 @@
----
-name: pc-guardrails-project
-description: Project-specific guardrails extracted from ARCHITECTURE.md and project config files. Populated by /make-guardrails. Load this skill before implementing any change to understand boundaries, conventions, and constraints for this codebase.
-license: MIT
----
-
-<!-- This skill is a placeholder until /make-guardrails is run. -->
-<!-- /make-guardrails will populate this file with project-specific rules. -->
+---
+name: pc-guardrails-project
+description: Project-specific guardrails extracted from ARCHITECTURE.md and project config files. Populated by /make-guardrails. Load this skill before implementing any change to understand boundaries, conventions, and constraints for this codebase.
+license: MIT
+---
+
+<!-- This skill is a placeholder until /make-guardrails is run. -->
+<!-- /make-guardrails will populate this file with project-specific rules. -->

package/skills/pc-make-architecture/SKILL.md

@@ -1,32 +1,33 @@
----
-name: pc-make-architecture
-description: Generate or update ARCHITECTURE.md by analyzing the codebase structure. Safe to run at any time. Invoked by the /make-architecture command and the repo-initialize flow.
-license: MIT
----
-
-# Make Architecture
-
-Write `ARCHITECTURE.md` in the project root from what the codebase actually contains, following the [structure template](structure-template.md).
-
-## Rules
-
-- Never regenerate over a file that carries a `<!-- Last updated:` footer. That footer is what makes the next run incremental, and a full rewrite silently drops whatever a human added by hand. Read the file first and pick the mode.
-- Never analyze outside `.opencode/source-roots.json` when it exists, plus this repo's own docs and config.
-- The footer is the file's last line, and it is the run's own ISO timestamp: `<!-- Last updated: <ISO date> -->`.
-- Follow the writing rules and self-check defined in the [structure template](structure-template.md). After generating, re-read each section: if a section only describes what exists without stating what breaks when its constraints are violated, rewrite it as constraint-embedded prose or cut it. The file is not written until the self-check passes.
-
-## Modes
-
-| The existing file | Mode |
-|---|---|
-| Missing, or a placeholder with no real content | Generate |
-| Has content and a `<!-- Last updated:` footer | Update |
-| Has content but no footer | Warn the user, then Generate |
-
-**Generate.** Discover the architecture with the file tools: `glob` for structure, `grep` for routes, models and schemas, `read` for config, CI workflows, Dockerfiles, README, changelogs and ADRs.
-
-**Update.** `git log --oneline --since="<footer date>" -- <source roots>` says what moved. Nothing changed means nothing to write: say "Architecture unchanged since last update" and stop. Otherwise rewrite only the affected sections and leave the rest, including anything hand-written, as it stands. Past roughly 40% of sections affected, fall back to Generate.
-
-## Report
-
-Whether the file was generated or updated and which sections changed, the top-level components found, and that `/make-architecture` can be re-run whenever the architecture moves.
+---
+name: pc-make-architecture
+description: Generate or update ARCHITECTURE.md by analyzing the codebase structure. Safe to run at any time. Invoked by the /make-architecture command and the repo-initialize flow.
+license: MIT
+---
+
+# Make Architecture
+
+Write `ARCHITECTURE.md` in the project root from what the codebase actually contains, following the [structure template](structure-template.md).
+
+## Rules
+
+- Never regenerate over a file that carries a `<!-- Last updated:` footer. That footer is what makes the next run incremental, and a full rewrite silently drops whatever a human added by hand. Read the file first and pick the mode.
+- Never analyze outside `.opencode/source-roots.json` when it exists, plus this repo's own docs and config.
+- When `docs/platform/` exists, the Kitchen-Sink template owns the platform code it documents (session and auth, permissions, audit, feature flags, errors, security headers, API surfaces, web shell). For those topics link to the page in `docs/platform/` instead of describing them again: a second description drifts on the next template update.
+- The footer is the file's last line, and it is the run's own ISO timestamp: `<!-- Last updated: <ISO date> -->`.
+- Follow the writing rules and self-check defined in the [structure template](structure-template.md). After generating, re-read each section: if a section only describes what exists without stating what breaks when its constraints are violated, rewrite it as constraint-embedded prose or cut it. The file is not written until the self-check passes.
+
+## Modes
+
+| The existing file | Mode |
+|---|---|
+| Missing, or a placeholder with no real content | Generate |
+| Has content and a `<!-- Last updated:` footer | Update |
+| Has content but no footer | Warn the user, then Generate |
+
+**Generate.** Discover the architecture with the file tools: `glob` for structure, `grep` for routes, models and schemas, `read` for config, CI workflows, Dockerfiles, README, changelogs and ADRs.
+
+**Update.** `git log --oneline --since="<footer date>" -- <source roots>` says what moved. Nothing changed means nothing to write: say "Architecture unchanged since last update" and stop. Otherwise rewrite only the affected sections and leave the rest, including anything hand-written, as it stands. Past roughly 40% of sections affected, fall back to Generate.
+
+## Report
+
+Whether the file was generated or updated and which sections changed, the top-level components found, and that `/make-architecture` can be re-run whenever the architecture moves.