@plainconceptsplatform/agent-harness 2.4.1 → 2.5.1

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

@@ -1,91 +1,89 @@
----
-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.
-
-**`/ops-evidence`**: Produce evidence a completed change works and publish it to the originating issue/PR. Uses `playwright-cli` (headless) and `pnpm run dev` to capture screenshots at desktop and mobile viewports, writes `evidence/evidence.json` (passed/skipped/failed/blocked), and upserts an idempotent verified comment. Best-effort; `/plan-goal` runs it automatically. Works inside CI containers.
-
-**`/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-evidence-scaffold`**: DEPRECATED. Evidence is now built into `/ops-evidence` using `playwright-cli` + `pnpm run dev`. No per-project scaffold needed.
-
-**`/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`**: Verify the current branch against applicable guardrails and project checks. Runs immutable dependency installs/restores, configured builds, and tests for every discovered project, repairs relevant failures, checks dependency/lockfile consistency, and reports `VERIFIED` only when every required check passes. It 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.
+
+**`/ops-evidence`**: Produce evidence a completed change works and publish it to the originating issue/PR. Uses `playwright-cli` (headless) and `pnpm run dev` to capture screenshots at desktop and mobile viewports, writes `evidence/evidence.json` (passed/skipped/failed/blocked), and upserts an idempotent verified comment. Best-effort. Run it yourself after a change lands; `/plan-goal` does not run it. Works inside CI containers.
+
+**`/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`**: Verify the current branch against applicable guardrails and project checks. Runs immutable dependency installs/restores, configured builds, and tests for every discovered project, repairs relevant failures, checks dependency/lockfile consistency, and reports `VERIFIED` only when every required check passes. It 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/harness/.agents/skills/pc-repo-initialize/SKILL.md

@@ -1,130 +1,112 @@
----
-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
----
-Check if `AGENTS.md` contains the `<!-- PC-NOT-INITIALIZED -->` marker.
-
-- If no: tell the user the project is already initialized. Suggest running `/make-architecture` or `/make-design` if they want to refresh those docs.
-- If yes: run the sequence below.
-
-## Step 1: Ask everything at once
-
-Call the `question` tool with all five questions in a single batch (do not ask them one at a time). Use exactly these fields:
-
-```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": "Enable visual evidence capture for this project? (playwright-cli + pnpm run dev; no per-project scaffold needed)",
-      "options": [
-        { "label": "Yes", "description": "Evidence will be captured automatically by /plan-goal using playwright-cli + pnpm run dev." },
-        { "label": "No", "description": "Skip evidence capture." }
-      ]
-    }
-  ]
-}
-```
-
-## Step 2: Execute selected steps
-
-Based on the user's answers, run the selected steps in order:
-
-### Sync skills (always)
-
-Ensure all skills listed in `skills-lock.json` are installed. Run `npx skills experimental_install --yes` in the project root. This installs the core and selected optional skills queued by onboarding. If the command fails or is unavailable, warn the user but continue because optional skills can be installed manually later.
-
-### Archive project history (if Yes)
-
-Scan the codebase for existing documentation, changelogs, ADRs, README files, or notable history. Create an OpenSpec archive entry that captures this history.
-
-Before scanning, load source roots from `.opencode/source-roots.json` when present. Only scan those roots plus this repo's docs/config files.
-
-```bash
-openspec new change "project-history"
-```
-
-Write a `proposal.md` inside that change summarizing:
-- What this project is
-- Key decisions already made (inferred from code and docs)
-- Known tech debt or constraints visible in the codebase
-- Current state of the project
-
-Then archive it immediately (`-y` skips the confirmation prompt so this never blocks):
-
-```bash
-openspec archive "project-history" -y
-```
-
-### Generate ARCHITECTURE.md (if Yes)
-
-Load the `pc-make-architecture` skill now. Follow every step defined in it.
-
-### Generate DESIGN.md (if Yes)
-
-Load the `pc-make-design` skill now. Follow every step defined in it.
-
-### Generate guardrails (always)
-
-Load the `pc-make-guardrails` skill now. Follow every step defined in it.
-
-### Visual evidence (if Yes)
-
-Evidence is built into the `pc-ops-evidence` skill using `playwright-cli` + `pnpm run dev`. No scaffold is needed — it works out of the box as long as the project has a root `pnpm run dev` script that starts the full app stack with mock auth. Ensure `playwright-cli` is installed (handled by `opencode-ci.md` in CI).
-
-## Step 3: Show help
-
-Load the `pc-repo-help` skill and display the full command reference exactly as written.
-
-## Step 4: Confirm
-
-Tell the user:
-
-```
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-  Initialization complete.
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-
-Restart OpenCode now.
-Nothing will work correctly until you do.
-After restarting you are ready to work.
-```
-
-If the user answered Yes to Question 5 (Evidence), no post-init step is needed. Evidence works automatically via `pc-ops-evidence` using `playwright-cli` + `pnpm run dev`.
-
-## Init scope
-
-During init, write only to: ARCHITECTURE.md, DESIGN.md, AGENTS.md, openspec/, .agents/skills/. Read source files for analysis. Feature implementation, branches, PRs, and project source file modification are outside init's scope.
+---
+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": "Enable visual evidence capture for this project? (playwright-cli + pnpm run dev; no per-project scaffold needed)",
+      "options": [
+        { "label": "Yes", "description": "Evidence will be captured automatically by /plan-goal using playwright-cli + pnpm run dev." },
+        { "label": "No", "description": "Skip evidence capture." }
+      ]
+    }
+  ]
+}
+```
+
+## 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, there is nothing to scaffold: `pc-ops-evidence` drives `playwright-cli` against the project's root `pnpm run dev`, which has to start the full stack with mock auth. CI installs `playwright-cli` itself.
+
+## 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/harness/.agents/skills/pc-repo-onboard/SKILL.md

@@ -1,87 +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
----
-
-This command is a guided tour. Read and explain only.
-
-## Step 1: Project overview
-
-Read `AGENTS.md`, `ARCHITECTURE.md`, and `DESIGN.md`. Summarize:
-
-- What this project is (name, purpose, domain)
-- Tech stack (languages, frameworks, build system)
-- Project structure (key directories and what they contain)
-
-Keep it to 3 to 5 bullet points. Focus on what a new contributor needs to know.
-
-## Step 2: Agent infrastructure
-
-Inspect `.opencode/agents/` and list every agent file. For each agent, read its frontmatter and summarize:
-
-- Agent name and role (primary, subagent, or specialist)
-- Model tier it uses (plan, build, or fast)
-- Key abilities: what it can do
-
-Present as a table:
-
-| Agent | Role | Tier | Purpose |
-|---|---|---|---|
-| ... | ... | ... | ... |
-
-Then explain the agent selection model:
-- Primary agents appear in Tab and handle direct user interaction
-- Subagent engineers are spawned by the lead for parallel implementation waves
-- Specialist engineers are preferred when their domain matches the task. `build` and `plan` are the only agents the user selects, and both run the `fullstack-engineer` body; `plan` cannot edit files. Everything else is `mode: subagent` and spawned. If no specialist matches, create one with `/make-engineer`.
-
-## Step 3: Command reference
-
-Read every `.md` file in `.opencode/commands/`. List each command with its name and description:
-
-| Command | What it does |
-|---|---|
-| ... | ... |
-
-Group them by workflow phase if possible:
-- 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, make-evidence-scaffold
-- Shipping: ops-ship, ops-review, ops-backlog, ops-evidence
-- Quality: repo-audit, repo-verify
-- Setup: init, make-user-model, repo-help
-
-## Step 4: Skills
-
-Inspect `.agents/skills/` (if present). List installed skills with a one-line description each. Note which are platform-specific (userstory, pullrequest) vs general-purpose, and identify `pc-repo-audit` as read-only and `pc-repo-verify` as the current-branch verification gate.
-
-## Step 5: OpenSpec workflow
-
-Explain the OpenSpec change lifecycle:
-
-1. Explore (`/plan-explore`): investigate and discuss, no files created
-2. Propose (`/plan-propose`): structured plan, saved to `openspec/changes/`
-3. Apply (`/plan-apply`): implement tasks via parallel subagent waves
-4. Archive (`/plan-archive`): finalize and clean up
-
-Explain `openspec/config.yaml`: what it contains and why it matters.
-
-## Step 6: Configuration
-
-Explain `harness.json`:
-- What each field controls (platform, models, agents, tools, source)
-- How to change the model for a tier (`/make-user-model`)
-- What `agents.maxConcurrent` does
-
-## Step 7: Quick tips
-
-End with 3 to 5 practical tips:
-
-- How to start working: "Run `/plan-goal` with a description of what you want to build"
-- How to add a specialist: "Run `/make-engineer`"
-- How to regenerate docs: "Run `/make-architecture` or `/make-design`"
-- How to audit the whole repository: "Run `/repo-audit`"
-- How to verify an active branch: "Run `/repo-verify`"
-- How to set up visual evidence: "Run `/make-evidence-scaffold` (UI projects) so `/plan-goal` can prove changes with screenshots"
-- How to see all commands: "Run `/repo-help`"
-- How to refresh config after changes: "Re-run `npx @plainconceptsplatform/agent-harness` in the terminal"
+---
+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`, `/ops-evidence` |
+   | Quality | `/repo-audit` (read-only), `/repo-verify` (the branch gate) |
+   | 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.

package/harness/.agents/skills/pc-repo-verify/SKILL.md

@@ -29,6 +29,8 @@ When a dependency manifest changes, require its ecosystem lockfile to change whe
 
 When a check fails, repair only the current branch's relevant files and rerun the failed check. Continue until every applicable check passes or a hard blocker prevents progress. Never hide a failure by deleting tests, weakening checks, or reverting requested work.
 
+Once every check passes, run the project's lint fix command over the files you changed (`pnpm lint:fix`, `pnpm exec biome check --write <changed-files>`, or its equivalent). Formatting is not a review comment worth anybody's turn, and a branch that fails lint on arrival gets sent back for it. Where no fix command exists, run lint and correct what it reports.
+
 ## Step 4: Result
 
 Report a check matrix with command, affected project, result, and skip reason where applicable. Report `VERIFIED` only when every applicable check passed, every dependency change has consistent lockfiles, and no required ability is missing. Otherwise report `NOT VERIFIED`, the blockers, and the exact next command.