@plainconceptsplatform/agent-harness 3.5.0 → 3.7.0

package/skills/pc-repo-audit/SKILL.md

@@ -1,44 +1,44 @@
----
-name: pc-repo-audit
-description: Audit every configured repository source root against the fullstack engineer's abilities and guardrails. Read-only. Invoked by the /repo-audit command.
-license: MIT
----
-
-# Repo Audit
-
-Audit the repository without modifying files, installing dependencies, creating backlog items, pushing, or contacting external platforms.
-
-## Step 1: Load the audit rules
-
-1. Read `.opencode/agents/fullstack-engineer.md`.
-2. Parse every `@skill-name` in its `## Abilities` section.
-3. Load every listed skill, guardrails first. If a referenced skill is missing, record it as a finding and continue with the installed abilities.
-
-## Step 2: Establish scope
-
-1. Read `.opencode/source-roots.json` when it exists. Use its non-empty `roots` array; otherwise use the repository root.
-2. Inventory every root before judging it. Identify applications, services, libraries, tests, frontend or website projects, infrastructure, CI, package manifests, lockfiles, and generated-output rules.
-3. Keep every read and command inside a configured source root or the repository root.
-
-## Step 3: Audit every project
-
-Apply the loaded abilities and guardrails to each discovered project. Assess:
-
-- Architecture, module boundaries, naming, and duplicated responsibilities.
-- Tests, linting, type checks, builds, CI, and whether their configured commands match the project.
-- Dependency manifests, lockfiles, package-manager declarations, runtime versions, and workspace configuration.
-- Security and repository hygiene, including generated files, ignored artifacts, and likely secrets in tracked files.
-- Documentation and configuration drift across `AGENTS.md`, architecture/design documents, project scripts, and CI.
-
-For dependency findings, identify the exact manifest and lockfile involved. State the repository-defined remediation and immutable dependency validation command; never run a mutation-capable install during this audit.
-
-## Step 4: Report
-
-Deduplicate findings across roots and report them grouped by project. Every finding must include:
-
-- Severity: critical, high, medium, or low.
-- Affected root and path.
-- Evidence and the applicable guardrail or ability, when one exists.
-- Impact and a concrete remediation or verification command.
-
-End with the projects audited, checks that could not run and why, and a short prioritized remediation list. If no findings exist, state that explicitly and list residual verification gaps.
+---
+name: pc-repo-audit
+description: Audit every configured repository source root against the fullstack engineer's abilities and guardrails. Read-only. Invoked by the /repo-audit command.
+license: MIT
+---
+
+# Repo Audit
+
+Audit the repository without modifying files, installing dependencies, creating backlog items, pushing, or contacting external platforms.
+
+## Step 1: Load the audit rules
+
+1. Read `.opencode/agents/fullstack-engineer.md`.
+2. Parse every `@skill-name` in its `## Abilities` section.
+3. Load every listed skill, guardrails first. If a referenced skill is missing, record it as a finding and continue with the installed abilities.
+
+## Step 2: Establish scope
+
+1. Read `.opencode/source-roots.json` when it exists. Use its non-empty `roots` array; otherwise use the repository root.
+2. Inventory every root before judging it. Identify applications, services, libraries, tests, frontend or website projects, infrastructure, CI, package manifests, lockfiles, and generated-output rules.
+3. Keep every read and command inside a configured source root or the repository root.
+
+## Step 3: Audit every project
+
+Apply the loaded abilities and guardrails to each discovered project. Assess:
+
+- Architecture, module boundaries, naming, and duplicated responsibilities.
+- Tests, linting, type checks, builds, CI, and whether their configured commands match the project.
+- Dependency manifests, lockfiles, package-manager declarations, runtime versions, and workspace configuration.
+- Security and repository hygiene, including generated files, ignored artifacts, and likely secrets in tracked files.
+- Documentation and configuration drift across `AGENTS.md`, architecture/design documents, project scripts, and CI.
+
+For dependency findings, identify the exact manifest and lockfile involved. State the repository-defined remediation and immutable dependency validation command; never run a mutation-capable install during this audit.
+
+## Step 4: Report
+
+Deduplicate findings across roots and report them grouped by project. Every finding must include:
+
+- Severity: critical, high, medium, or low.
+- Affected root and path.
+- Evidence and the applicable guardrail or ability, when one exists.
+- Impact and a concrete remediation or verification command.
+
+End with the projects audited, checks that could not run and why, and a short prioritized remediation list. If no findings exist, state that explicitly and list residual verification gaps.

package/skills/pc-repo-help/SKILL.md

@@ -1,87 +1,87 @@
----
-name: pc-repo-help
-description: The full command reference for this project - every /command with when to use it and the typical workflows. Load when the user asks for help, the command list, or at the end of repo initialization. Invoked by the /repo-help command and the repo-initialize flow.
-license: MIT
----
-
-# Repo Help
-
-Display the following reference to the user exactly as written. Do not summarize.
-
-## Commands
-
-### Not sure where to start?
-
-**`/init`** (alias: `/repo-initialize`): Initialize the project. Presents a single form with all setup questions (project type, history, architecture, design, evidence), then executes the selected steps.
-
-**`/repo-onboard`**: Guided tour of the project and its agentic infrastructure. Explains agents, commands, skills, OpenSpec workflow, and configuration. Read-only: no files modified.
-
-**`/repo-audit`**: Read-only health audit of every configured source root. Loads the fullstack engineer's abilities, checks guardrails, architecture, tooling, dependencies, lockfiles, tests, and CI, then reports prioritized findings.
-
-**`/plan-explore`**: Your backlog is unclear, you have a half-formed idea, or you need to think through a problem before committing to a plan. This is a thinking partner, not an executor.
-
-**`/plan-story <feature or need>`**: Write a detailed, repo-aware user story from a feature idea. Loads the `@user-story` skill (Mike Cohn format + Gherkin acceptance criteria), analyzes your codebase for concrete context, and produces a development-ready story with specific personas, real outcomes, and testable criteria grounded in your actual file paths, component names, and data models. No files written — just the story.
-
-**`/plan-propose <url or idea>`**: You have a work item URL, or a clear idea and you want to turn it into a structured plan (proposal, specs, tasks). Enriches each task with the best matching agent and model before showing you the plan. Nothing is implemented until you confirm.
-
----
-
-### Ready to implement?
-
-**`/plan-quick <task>`**: Quick plan for focused changes. Reads the codebase, creates a task checklist in the Todo pane. No files, no OpenSpec. Then you decide: `/plan-apply` to implement, or `/plan-propose` for a full OpenSpec plan.
-
-**`/plan-apply`**: Implement a plan. Detects the source automatically: OpenSpec-annotated tasks (from `/plan-propose`) run as parallel subagent waves; Todo pane tasks (from `/plan-quick`) run sequentially in-session.
-
-**`/plan-goal <feature or URL>`**: Fully autonomous, no confirmations. Branches off `main`, then runs propose → apply → archive on that branch (each phase its own commit). Default: merges to `main` and deletes the branch. Add `push` keyword to push the branch only. Add `pr` keyword to push + create a PR. Built for loop-engineering / unattended runs. Stops only on a hard failure, leaving the branch unmerged.
-
----
-
-### Done implementing?
-
-**`/ops-ship`**: Create a PR for the current feature branch with screenshots if UI changed.
-
-**`/ops-review`**: Read and triage PR review feedback. If you share a PR URL or say "I've added comments to the PR", it reads and classifies the review comments so you know what to fix. Fixing is done via `/plan-apply`.
-
-**`/ops-backlog`**: Create an issue in the backlog platform (GitHub, Azure DevOps, Jira) from a description.
-
-**`/plan-archive`**: Mark a completed change as archived in OpenSpec. Run this after the PR is merged.
-
----
-
-### Maintaining the project?
-
-**`/make-engineer`**: Add a custom specialist engineer to the team. Interactive persona-driven form: pick a persona, then confirm an inspected-and-recommended set of skills (architecture/patterns like FSD or design patterns, framework, testing, infra) before anything installs. Future `/plan-apply` runs will prefer it when its domain matches.
-
-**`/make-architecture`**: Regenerate `ARCHITECTURE.md` from the current codebase. Safe to rerun any time the architecture evolves.
-
-**`/make-design`**: Regenerate `DESIGN.md` from the design system (Tailwind, CSS vars, tokens, etc.).
-
-**`/make-guardrails`**: Generate a `pc-guardrails-project` skill from `ARCHITECTURE.md` and project config files. Extracts concrete rules (architecture boundaries, naming, code style, testing, git workflow) that all agents must follow. Updates every `*-engineer.md` to load the skill.
-
-**`/repo-verify`**: Write the verification plan for the current branch's change: a journey through the new functionality as a fenced YAML block in `verification-plan.md`, stored with the change. The evidence workflow from `@plainconceptsplatform/workflows` replays it in headless Chromium when the pull request merges and archives one screenshot per waypoint in an `evidence/` folder beside the plan. Backend-only changes are traced through to the frontend when their contract is consumed there; a `not-applicable` stub is written when no UI surface is reachable. Does not run checks or take screenshots. Runs automatically in `/plan-goal`.
-
-**`/make-user-model <tier> <model>`**: Set the model for a tier (`plan`, `build`, or `fast`). Writes to `.opencode/harness.json` (`models`). Use `user` prefix for a personal override: `/make-user-model user fast opencode/big-pickle`. Use a model id or `current` for the active session model. Restart opencode for the `pc-subagent-tiers` plugin to rebuild tier agents.
-
----
-
-### Typical workflows
-
-**Complex change:**
-```
-/plan-explore   ← optional: think it through first
-/plan-propose   ← create the plan
-/plan-apply     ← implement with the team
-/ops-ship        ← ship
-/plan-archive   ← close out
-```
-
-**Quick change:**
-```
-/plan-quick     ← create a focused task list
-/plan-apply     ← implement
-```
-
-**Unattended / loop-engineering:**
-```
-/plan-goal <description>  ← full pipeline, no interaction
-```
+---
+name: pc-repo-help
+description: The full command reference for this project - every /command with when to use it and the typical workflows. Load when the user asks for help, the command list, or at the end of repo initialization. Invoked by the /repo-help command and the repo-initialize flow.
+license: MIT
+---
+
+# Repo Help
+
+Display the following reference to the user exactly as written. Do not summarize.
+
+## Commands
+
+### Not sure where to start?
+
+**`/init`** (alias: `/repo-initialize`): Initialize the project. Presents a single form with all setup questions (project type, history, architecture, design, evidence), then executes the selected steps.
+
+**`/repo-onboard`**: Guided tour of the project and its agentic infrastructure. Explains agents, commands, skills, OpenSpec workflow, and configuration. Read-only: no files modified.
+
+**`/repo-audit`**: Read-only health audit of every configured source root. Loads the fullstack engineer's abilities, checks guardrails, architecture, tooling, dependencies, lockfiles, tests, and CI, then reports prioritized findings.
+
+**`/plan-explore`**: Your backlog is unclear, you have a half-formed idea, or you need to think through a problem before committing to a plan. This is a thinking partner, not an executor.
+
+**`/plan-story <feature or need>`**: Write a detailed, repo-aware user story from a feature idea. Loads the `@user-story` skill (Mike Cohn format + Gherkin acceptance criteria), analyzes your codebase for concrete context, and produces a development-ready story with specific personas, real outcomes, and testable criteria grounded in your actual file paths, component names, and data models. No files written — just the story.
+
+**`/plan-propose <url or idea>`**: You have a work item URL, or a clear idea and you want to turn it into a structured plan (proposal, specs, tasks). Enriches each task with the best matching agent and model before showing you the plan. Nothing is implemented until you confirm.
+
+---
+
+### Ready to implement?
+
+**`/plan-quick <task>`**: Quick plan for focused changes. Reads the codebase, creates a task checklist in the Todo pane. No files, no OpenSpec. Then you decide: `/plan-apply` to implement, or `/plan-propose` for a full OpenSpec plan.
+
+**`/plan-apply`**: Implement a plan. Detects the source automatically: OpenSpec-annotated tasks (from `/plan-propose`) run as parallel subagent waves; Todo pane tasks (from `/plan-quick`) run sequentially in-session.
+
+**`/plan-goal <feature or URL>`**: Fully autonomous, no confirmations. Branches off `main`, then runs propose → apply → archive on that branch (each phase its own commit). Default: merges to `main` and deletes the branch. Add `push` keyword to push the branch only. Add `pr` keyword to push + create a PR. Built for loop-engineering / unattended runs. Stops only on a hard failure, leaving the branch unmerged.
+
+---
+
+### Done implementing?
+
+**`/ops-ship`**: Create a PR for the current feature branch with screenshots if UI changed.
+
+**`/ops-review`**: Read and triage PR review feedback. If you share a PR URL or say "I've added comments to the PR", it reads and classifies the review comments so you know what to fix. Fixing is done via `/plan-apply`.
+
+**`/ops-backlog`**: Create an issue in the backlog platform (GitHub, Azure DevOps, Jira) from a description.
+
+**`/plan-archive`**: Mark a completed change as archived in OpenSpec. Run this after the PR is merged.
+
+---
+
+### Maintaining the project?
+
+**`/make-engineer`**: Add a custom specialist engineer to the team. Interactive persona-driven form: pick a persona, then confirm an inspected-and-recommended set of skills (architecture/patterns like FSD or design patterns, framework, testing, infra) before anything installs. Future `/plan-apply` runs will prefer it when its domain matches.
+
+**`/make-architecture`**: Regenerate `ARCHITECTURE.md` from the current codebase. Safe to rerun any time the architecture evolves.
+
+**`/make-design`**: Regenerate `DESIGN.md` from the design system (Tailwind, CSS vars, tokens, etc.).
+
+**`/make-guardrails`**: Generate a `pc-guardrails-project` skill from `ARCHITECTURE.md` and project config files. Extracts concrete rules (architecture boundaries, naming, code style, testing, git workflow) that all agents must follow. Updates every `*-engineer.md` to load the skill.
+
+**`/repo-verify`**: Write the verification plan for the current branch's change: a journey through the new functionality as a fenced YAML block in `verification-plan.md`, stored with the change. The evidence workflow from `@plainconceptsplatform/workflows` replays it in headless Chromium when the pull request merges and archives one screenshot per waypoint in an `evidence/` folder beside the plan. Backend-only changes are traced through to the frontend when their contract is consumed there; a `not-applicable` stub is written when no UI surface is reachable. Does not run checks or take screenshots. Runs automatically in `/plan-goal`.
+
+**`/make-user-model <tier> <model>`**: Set the model for a tier (`plan`, `build`, or `fast`). Writes to `.opencode/harness.json` (`models`). Use `user` prefix for a personal override: `/make-user-model user fast opencode/big-pickle`. Use a model id or `current` for the active session model. Restart opencode for the `pc-subagent-tiers` plugin to rebuild tier agents.
+
+---
+
+### Typical workflows
+
+**Complex change:**
+```
+/plan-explore   ← optional: think it through first
+/plan-propose   ← create the plan
+/plan-apply     ← implement with the team
+/ops-ship        ← ship
+/plan-archive   ← close out
+```
+
+**Quick change:**
+```
+/plan-quick     ← create a focused task list
+/plan-apply     ← implement
+```
+
+**Unattended / loop-engineering:**
+```
+/plan-goal <description>  ← full pipeline, no interaction
+```

package/skills/pc-repo-initialize/SKILL.md

@@ -1,119 +1,119 @@
----
-name: pc-repo-initialize
-description: "Initialize the project. Presents a single form with all setup questions, then executes selected steps. Invoked by the /init command (alias: /repo-initialize)."
-license: MIT
----
-
-First read `AGENTS.md`. Without the `<!-- PC-NOT-INITIALIZED -->` marker the project is already initialized: say so, and point at `/make-architecture` or `/make-design` for a refresh. With it, run the sequence below.
-
-## Rules
-
-- Write only to `ARCHITECTURE.md`, `DESIGN.md`, `AGENTS.md`, `openspec/` and `.agents/skills/`. Source files are read for analysis, never edited: init sets a project up, it does not implement anything, and it creates no branches or pull requests.
-- Ask the five questions in one `question` call. Five separate prompts is five chances for the user to walk away from a setup that does nothing until it finishes.
-- A step whose answer was No is skipped, not approximated.
-
-## Step 1, Ask everything at once
-
-```json
-{
-  "questions": [
-    {
-      "header": "Type",
-      "question": "What type of project is this?",
-      "options": [
-        { "label": "brownfield", "description": "Existing codebase. Generate docs from your code." },
-        { "label": "greenfield", "description": "Starting from scratch, little or no existing code." }
-      ]
-    },
-    {
-      "header": "History",
-      "question": "Archive project history into OpenSpec?",
-      "options": [
-        { "label": "Yes", "description": "Scan codebase for existing docs, changelogs, decisions and archive them." },
-        { "label": "No", "description": "Skip history archival." }
-      ]
-    },
-    {
-      "header": "Architecture",
-      "question": "Generate ARCHITECTURE.md from the codebase?",
-      "options": [
-        { "label": "Yes", "description": "Analyze project structure and generate architecture documentation." },
-        { "label": "No", "description": "Skip, leave as placeholder." }
-      ]
-    },
-    {
-      "header": "Design",
-      "question": "Generate DESIGN.md from the design system?",
-      "options": [
-        { "label": "Yes", "description": "Analyze Tailwind, CSS vars, tokens and generate design documentation." },
-        { "label": "No", "description": "Skip, leave as placeholder." }
-      ]
-    },
-    {
-      "header": "Evidence",
-      "question": "Record how the app starts and how a person signs in locally, so merged changes get screenshots?",
-      "options": [
-        { "label": "Yes", "description": "Fill the project environment in pc-repo-verify: start command, URL, local sign-in, seeded data." },
-        { "label": "No", "description": "Skip; the verification plans will look for the sign-in themselves." }
-      ]
-    }
-  ]
-}
-```
-
-## Step 2, Sync skills
-
-Always. `npx skills experimental_install --yes` in the project root installs what onboarding queued in `skills-lock.json`. A failure here is a warning, not a stop: the optional ones can be added later.
-
-## Step 3, Archive project history
-
-If Yes. Scan the roots in `.opencode/source-roots.json` (plus this repo's own docs and config) for documentation, changelogs, ADRs, READMEs and anything else that records how the project got here. Then:
-
-```bash
-openspec new change "project-history"
-```
-
-Write a `proposal.md` in it covering what the project is, the decisions already taken, the tech debt and constraints the code shows, and where things stand. Archive it immediately, with `-y` so it cannot block:
-
-```bash
-openspec archive "project-history" -y
-```
-
-## Step 4, Generate ARCHITECTURE.md
-
-If Yes. Load `pc-make-architecture`.
-
-## Step 5, Generate DESIGN.md
-
-If Yes. Load `pc-make-design`.
-
-## Step 6, Generate guardrails
-
-Always. Load `pc-make-guardrails`.
-
-## Step 7, Visual evidence
-
-If Yes. Every change's verification plan (`pc-repo-verify`) is replayed in headless Chromium by the evidence workflow when its pull request merges, from a freshly started app with nothing in the browser. Find in the source, and confirm by reading the root `package.json`, `.env.example` and the local auth setup:
-
-- the command that starts the whole stack with mock authentication (normally `pnpm run dev` at the root),
-- the URL the web app answers on,
-- the local sign-in: the exact steps and visible labels of the mock account picker or dev login,
-- the data a fresh start seeds (accounts, records) that a journey can rely on.
-
-Write them as the bullet list between `<!-- PC-PROJECT-ENVIRONMENT-START -->` and `<!-- PC-PROJECT-ENVIRONMENT-END -->` in `.agents/skills/pc-repo-verify/SKILL.md`, replacing the placeholder bullets. Only that slot: the rest of the file is the harness's, and an update keeps only the slot.
-
-## Step 8, Show help
-
-Load `pc-repo-help` and display the command reference as written.
-
-## Step 9, Confirm
-
-```
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-  Initialization complete.
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-
-Restart OpenCode now.
-Nothing will work correctly until you do.
-After restarting you are ready to work.
-```
+---
+name: pc-repo-initialize
+description: "Initialize the project. Presents a single form with all setup questions, then executes selected steps. Invoked by the /init command (alias: /repo-initialize)."
+license: MIT
+---
+
+First read `AGENTS.md`. Without the `<!-- PC-NOT-INITIALIZED -->` marker the project is already initialized: say so, and point at `/make-architecture` or `/make-design` for a refresh. With it, run the sequence below.
+
+## Rules
+
+- Write only to `ARCHITECTURE.md`, `DESIGN.md`, `AGENTS.md`, `openspec/` and `.agents/skills/`. Source files are read for analysis, never edited: init sets a project up, it does not implement anything, and it creates no branches or pull requests.
+- Ask the five questions in one `question` call. Five separate prompts is five chances for the user to walk away from a setup that does nothing until it finishes.
+- A step whose answer was No is skipped, not approximated.
+
+## Step 1, Ask everything at once
+
+```json
+{
+  "questions": [
+    {
+      "header": "Type",
+      "question": "What type of project is this?",
+      "options": [
+        { "label": "brownfield", "description": "Existing codebase. Generate docs from your code." },
+        { "label": "greenfield", "description": "Starting from scratch, little or no existing code." }
+      ]
+    },
+    {
+      "header": "History",
+      "question": "Archive project history into OpenSpec?",
+      "options": [
+        { "label": "Yes", "description": "Scan codebase for existing docs, changelogs, decisions and archive them." },
+        { "label": "No", "description": "Skip history archival." }
+      ]
+    },
+    {
+      "header": "Architecture",
+      "question": "Generate ARCHITECTURE.md from the codebase?",
+      "options": [
+        { "label": "Yes", "description": "Analyze project structure and generate architecture documentation." },
+        { "label": "No", "description": "Skip, leave as placeholder." }
+      ]
+    },
+    {
+      "header": "Design",
+      "question": "Generate DESIGN.md from the design system?",
+      "options": [
+        { "label": "Yes", "description": "Analyze Tailwind, CSS vars, tokens and generate design documentation." },
+        { "label": "No", "description": "Skip, leave as placeholder." }
+      ]
+    },
+    {
+      "header": "Evidence",
+      "question": "Record how the app starts and how a person signs in locally, so merged changes get screenshots?",
+      "options": [
+        { "label": "Yes", "description": "Fill the project environment in pc-repo-verify: start command, URL, local sign-in, seeded data." },
+        { "label": "No", "description": "Skip; the verification plans will look for the sign-in themselves." }
+      ]
+    }
+  ]
+}
+```
+
+## Step 2, Sync skills
+
+Always. `npx skills experimental_install --yes` in the project root installs what onboarding queued in `skills-lock.json`. A failure here is a warning, not a stop: the optional ones can be added later.
+
+## Step 3, Archive project history
+
+If Yes. Scan the roots in `.opencode/source-roots.json` (plus this repo's own docs and config) for documentation, changelogs, ADRs, READMEs and anything else that records how the project got here. Then:
+
+```bash
+openspec new change "project-history"
+```
+
+Write a `proposal.md` in it covering what the project is, the decisions already taken, the tech debt and constraints the code shows, and where things stand. Archive it immediately, with `-y` so it cannot block:
+
+```bash
+openspec archive "project-history" -y
+```
+
+## Step 4, Generate ARCHITECTURE.md
+
+If Yes. Load `pc-make-architecture`.
+
+## Step 5, Generate DESIGN.md
+
+If Yes. Load `pc-make-design`.
+
+## Step 6, Generate guardrails
+
+Always. Load `pc-make-guardrails`.
+
+## Step 7, Visual evidence
+
+If Yes. Every change's verification plan (`pc-repo-verify`) is replayed in headless Chromium by the evidence workflow when its pull request merges, from a freshly started app with nothing in the browser. Find in the source, and confirm by reading the root `package.json`, `.env.example` and the local auth setup:
+
+- the command that starts the whole stack with mock authentication (normally `pnpm run dev` at the root),
+- the URL the web app answers on,
+- the local sign-in: the exact steps and visible labels of the mock account picker or dev login,
+- the data a fresh start seeds (accounts, records) that a journey can rely on.
+
+Write them as the bullet list between `<!-- PC-PROJECT-ENVIRONMENT-START -->` and `<!-- PC-PROJECT-ENVIRONMENT-END -->` in `.agents/skills/pc-repo-verify/SKILL.md`, replacing the placeholder bullets. Only that slot: the rest of the file is the harness's, and an update keeps only the slot.
+
+## Step 8, Show help
+
+Load `pc-repo-help` and display the command reference as written.
+
+## Step 9, Confirm
+
+```
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+  Initialization complete.
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+Restart OpenCode now.
+Nothing will work correctly until you do.
+After restarting you are ready to work.
+```

package/skills/pc-repo-onboard/SKILL.md

@@ -1,32 +1,32 @@
----
-name: pc-repo-onboard
-description: Walk the user through the project and its agentic infrastructure. Explains what exists, how agents work, and how to use the system. Invoked by the /repo-onboard command.
-license: MIT
----
-
-A guided tour of this repository and the harness installed in it, for somebody who has just arrived. Read and explain; change nothing.
-
-## Rules
-
-- Never write, edit, or create a file, and never run a command from the tour to demonstrate it. The output is the explanation.
-- Never describe an agent, command, skill or setting that is not in this repository. The tour is worth having because it is specific: read `.opencode/agents/`, `.opencode/commands/`, `.agents/skills/`, `.opencode/harness.json`, `AGENTS.md`, `ARCHITECTURE.md` and `DESIGN.md` and report what is actually there.
-
-## Cover, in this order
-
-1. **The project.** Three to five bullets: what it is, the stack, the directories that matter.
-2. **The agents.** One table row per file in `.opencode/agents/`, with its tier and purpose. Then the selection model: `build` and `plan` are the only two a human picks and both run the `fullstack-engineer` body, `plan` can neither edit nor spawn, everything else is `mode: subagent` and reached through `task()`, and a missing specialist is made with `/make-engineer`.
-3. **The commands**, grouped by what they are for:
-
-   | Group | Commands |
-   |---|---|
-   | Planning | `/plan-explore`, `/plan-story`, `/plan-propose`, `/plan-quick`, `/plan-goal` |
-   | Implementation | `/plan-apply`, `/plan-archive` |
-   | Maintenance | `/make-architecture`, `/make-design`, `/make-engineer`, `/make-guardrails` |
-   | Shipping | `/ops-ship`, `/ops-review`, `/ops-backlog` |
-   | Quality | `/repo-audit` (read-only), `/repo-verify` (writes the verification plan) |
-   | Setup | `/init`, `/make-user-model`, `/repo-help` |
-
-4. **The skills** installed in `.agents/skills/`, one line each, marking which are platform-specific.
-5. **The OpenSpec lifecycle**: explore, propose, apply, archive, and what `openspec/config.yaml` controls.
-6. **The configuration** in `.opencode/harness.json`: what each section governs, that `/make-user-model` changes a tier's model, and what `agents.maxConcurrent` caps.
-7. **Where to start.** `/plan-goal` with a description of the work, `/repo-help` for everything else, and `npx @plainconceptsplatform/agent-harness` to refresh the harness after changing config.
+---
+name: pc-repo-onboard
+description: Walk the user through the project and its agentic infrastructure. Explains what exists, how agents work, and how to use the system. Invoked by the /repo-onboard command.
+license: MIT
+---
+
+A guided tour of this repository and the harness installed in it, for somebody who has just arrived. Read and explain; change nothing.
+
+## Rules
+
+- Never write, edit, or create a file, and never run a command from the tour to demonstrate it. The output is the explanation.
+- Never describe an agent, command, skill or setting that is not in this repository. The tour is worth having because it is specific: read `.opencode/agents/`, `.opencode/commands/`, `.agents/skills/`, `.opencode/harness.json`, `AGENTS.md`, `ARCHITECTURE.md` and `DESIGN.md` and report what is actually there.
+
+## Cover, in this order
+
+1. **The project.** Three to five bullets: what it is, the stack, the directories that matter.
+2. **The agents.** One table row per file in `.opencode/agents/`, with its tier and purpose. Then the selection model: `build` and `plan` are the only two a human picks and both run the `fullstack-engineer` body, `plan` can neither edit nor spawn, everything else is `mode: subagent` and reached through `task()`, and a missing specialist is made with `/make-engineer`.
+3. **The commands**, grouped by what they are for:
+
+   | Group | Commands |
+   |---|---|
+   | Planning | `/plan-explore`, `/plan-story`, `/plan-propose`, `/plan-quick`, `/plan-goal` |
+   | Implementation | `/plan-apply`, `/plan-archive` |
+   | Maintenance | `/make-architecture`, `/make-design`, `/make-engineer`, `/make-guardrails` |
+   | Shipping | `/ops-ship`, `/ops-review`, `/ops-backlog` |
+   | Quality | `/repo-audit` (read-only), `/repo-verify` (writes the verification plan) |
+   | Setup | `/init`, `/make-user-model`, `/repo-help` |
+
+4. **The skills** installed in `.agents/skills/`, one line each, marking which are platform-specific.
+5. **The OpenSpec lifecycle**: explore, propose, apply, archive, and what `openspec/config.yaml` controls.
+6. **The configuration** in `.opencode/harness.json`: what each section governs, that `/make-user-model` changes a tier's model, and what `agents.maxConcurrent` caps.
+7. **Where to start.** `/plan-goal` with a description of the work, `/repo-help` for everything else, and `npx @plainconceptsplatform/agent-harness` to refresh the harness after changing config.