@plainconceptsplatform/agent-harness 2.5.2 → 2.7.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/README.md CHANGED
@@ -1,435 +1,432 @@
1
- <div align="center">
2
-
3
- <img src="https://raw.githubusercontent.com/PlainConceptsPlatform/agent-harness/refs/heads/main/docs/public/assets/logo.png" alt="agent-harness" width="160" />
4
-
5
- # 🧰 agent-harness
6
-
7
- **Installs the Plain Concepts Platform Harness into any codebase, and keeps it up to date. Wires [OpenCode](https://opencode.ai), [OpenSpec](https://github.com/fission-ai/openspec), [codegraph](https://github.com/colbymchenry/codegraph), and [agentmemory](https://github.com/rohitg00/agentmemory) into a multi-agent workflow that runs on native parallel subagents.**
8
-
9
- GitHub, Azure DevOps, Jira, GitLab, browser-based backlog, or combinations (for example, Jira backlog plus GitHub repository, or browser backlog plus GitLab repository).
10
-
11
- **[plainconceptsplatform.github.io/agent-harness](https://plainconceptsplatform.github.io/agent-harness)**
12
-
13
- [![npm version](https://img.shields.io/npm/v/@plainconceptsplatform/agent-harness?style=flat-square&color=black)](https://www.npmjs.com/package/@plainconceptsplatform/agent-harness)
14
- [![npm downloads](https://img.shields.io/npm/dm/@plainconceptsplatform/agent-harness?style=flat-square&color=black)](https://www.npmjs.com/package/@plainconceptsplatform/agent-harness)
15
- [![license](https://img.shields.io/npm/l/@plainconceptsplatform/agent-harness?style=flat-square&color=black)](./LICENSE)
16
- [![node](https://img.shields.io/node/v/@plainconceptsplatform/agent-harness?style=flat-square&color=black)](https://nodejs.org)
17
-
18
- </div>
19
-
20
- ## What is this?
21
-
22
- Most codebases have no `AGENTS.md`, no architecture documentation an agent can read, and no defined workflow for picking up a task. So agents improvise, and you get a different answer every run.
23
-
24
- **agent-harness** is the CLI that installs the **Plain Concepts Platform Harness** into a repository and keeps it up to date.
25
-
26
- The harness is ours. We build it, our projects run on it, and this CLI is how it gets into a codebase. 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`.
27
-
28
- Underneath, it wires OpenCode to OpenSpec for change management, native subagent waves for parallel work, codegraph for code intelligence, and agentmemory for context that survives between sessions.
29
-
30
- The CLI has three jobs:
31
-
32
- | Command | What it does |
33
- | --- | --- |
34
- | `npx @plainconceptsplatform/agent-harness` | Installs the harness. A wizard runs once and saves your answers to `.opencode/harness.json`. |
35
- | `npx @plainconceptsplatform/agent-harness update` | Reinstalls the harness from those saved answers, no questions asked. Keeps files you edited. |
36
- | `npx @plainconceptsplatform/agent-harness join` | Sets up a teammate's machine. Touches no committed file. |
37
-
38
- You run the first one once per repository, and the second whenever we ship a release.
39
-
40
- <div align="center">
41
- <img src="https://raw.githubusercontent.com/PlainConceptsPlatform/agent-harness/refs/heads/main/docs/public/assets/demo.gif" alt="agent-harness demo" width="700" />
42
- </div>
43
-
44
- ## Quick start
45
-
46
- ```bash
47
- npx @plainconceptsplatform/agent-harness@latest
48
- ```
49
-
50
- Requires **Node.js 18 or higher**.
51
-
52
- ### Run specific steps
53
-
54
- You can run individual setup or maintenance steps without running the full wizard:
55
-
56
- ```bash
57
- # Run one step directly
58
- npx @plainconceptsplatform/agent-harness clean
59
- npx @plainconceptsplatform/agent-harness platform
60
- npx @plainconceptsplatform/agent-harness copy
61
- npx @plainconceptsplatform/agent-harness openspec
62
- npx @plainconceptsplatform/agent-harness models
63
- npx @plainconceptsplatform/agent-harness optimization
64
- npx @plainconceptsplatform/agent-harness browser
65
- npx @plainconceptsplatform/agent-harness metadata
66
- npx @plainconceptsplatform/agent-harness join
67
-
68
- # Show CLI help and all commands
69
- npx @plainconceptsplatform/agent-harness --help
70
- npx @plainconceptsplatform/agent-harness -h
71
- ```
72
-
73
- When available, step commands reuse context from `.opencode/harness.json`.
74
-
75
- ### Keeping the harness current
76
-
77
- A new release of agent-harness ships new commands, skills and plugins. To pull them into a project that already has the harness:
78
-
79
- ```bash
80
- npx @plainconceptsplatform/agent-harness@latest update
81
- ```
82
-
83
- `update` re-runs every file patch from `.opencode/harness.json` and asks nothing. It keeps a hash of each file it manages in `.opencode/harness-managed.json`, so it leaves your hand edits alone and reports them as preserved. It also skips generated skills like `pc-guardrails-project`, whose contents came from a `/make-*` command rather than from us.
84
-
85
- Reach for individual steps when you want something narrower:
86
-
87
- - `clean` to reset old AI files
88
- - `copy` if templates or skills changed in a new agent-harness release
89
- - `optimization` to reconfigure RTK, quota, Simple English, codegraph, agentmemory, or humanizer, and the guardrails optimization markers
90
- - `metadata` last, to refresh `.opencode/harness.json`
91
- - `join` if you are new to a project that already has the harness and want the local tooling it expects
92
-
93
- > **Upgrading from `opencode-onboard` v1?** v2 renamed the config files and the skill prefix (`ob-` became `pc-`), and it does not migrate v1 projects. The CLI detects one and refuses to run rather than half-patching it. Re-onboard on a clean branch: remove `.opencode/` and `.agents/skills/ob-*`, then run the wizard again.
94
-
95
- > **Browser tooling changed in v2.4.** The `@different-ai/opencode-browser` plugin (and its Chrome extension) was replaced by [`agent-browser`](https://github.com/vercel-labs/agent-browser), wired in as an MCP server in `opencode.jsonc`. Running `update` strips the old plugin entry, adds the MCP block, and installs the new binary — no manual unloading of the extension is needed, though you can remove it from `chrome://extensions` yourself. Skills you wrote that call `browser_*` tools directly must switch to the `agent-browser` CLI or the `agent_browser_*` MCP tools. Backlog-browser users: agent-browser runs its own Chrome, so log in once per project using the `--session backlog --restore` flow described in `pc-userstory-browser`.
96
-
97
- ---
98
-
99
- ## Installing the harness
100
-
101
- The first run is a 10-step wizard. It keeps the current step visible, plus the last two completed steps, so progress is always clear.
102
-
103
- | Step | What happens |
104
- | --- | --- |
105
- | **1. Source scope** | Choose current repository or sibling source roots for code analysis |
106
- | **2. Clean AI files** | Detects existing `AGENTS.md`, `.cursorrules`, `CLAUDE.md`, `.agents/` and so on, then removes them. Preserves your `.agents/skills/` directory. |
107
- | **3. Choose platform** | Backlog (GitHub, Azure DevOps, Jira, browser-based, or None) plus repository (GitHub, Azure DevOps, GitLab, or None). Supports mixed platforms, for example browser backlog plus GitHub repository, or Jira backlog plus GitLab repository. |
108
- | **4. Check platform CLI** | Verifies `gh` (GitHub), or `az` plus `azure-devops` extension (Azure DevOps), or `acli` (Jira), or `glab` (GitLab). Skips CLI checks for browser-based or None platforms. |
109
- | **5. Copy scaffolding** | Copies agents, built-in skills, bootstrap documentation, writes source-roots metadata, applies AGENTS bootstrap patching, copies `skills-lock.json`, then runs `npx skills` |
110
- | **6. Initialize OpenSpec** | Runs `npx @fission-ai/openspec init` silently for structured change management |
111
- | **7. Choose models** | Fetches live model list from [models.dev](https://models.dev), lets you pick plan, build, and fast models with cost indicators and canonical pricing |
112
- | **8. Token optimization tools** | Optional and recommended. One checklist step for RTK check, opencode-quota setup, Simple English install, codegraph install, agentmemory install, humanizer install, and token-optimization rule injection into guardrails |
113
- | **9. Install browser tooling** | Installs `agent-browser` globally and downloads its Chrome for Testing binary |
114
- | **10. Write onboarding metadata** | Writes `.opencode/harness.json` with selected setup details |
115
-
116
- When it finishes, open OpenCode in your project and type:
117
-
118
- ```
119
- /repo-initialize
120
- ```
121
-
122
- OpenCode asks if this is a greenfield or brownfield project. For brownfield projects it generates `ARCHITECTURE.md` and `DESIGN.md` from your actual codebase, archives project history, then activates the full agent team. For greenfield projects it skips documentation generation and leaves placeholder files you can populate later with `/make-architecture` and `/make-design`.
123
-
124
- ---
125
-
126
- ## Commands
127
-
128
- Custom slash commands are installed into `.opencode/commands/` and are available directly in OpenCode.
129
-
130
- Commands that other commands (or agents) need to execute are thin wrappers around `pc-*` skills in `.agents/skills/`. The command handles user invocation and arguments, and the skill holds the procedure. OpenCode has no mechanism for a command to run another command, but any agent can load a skill mid-conversation, which is what makes pipelines like `/plan-goal` composable.
131
-
132
- | Command | Description |
133
- | ------- | ----------- |
134
- | `/repo-help` | Show all commands and when to use each one. Start here if you are unsure. |
135
- | `/repo-onboard` | Guided tour of the project and its agentic infrastructure. Explains agents, commands, skills, OpenSpec workflow, and configuration. Read-only. |
136
- | `/repo-audit` | Read-only audit of every configured source root against fullstack abilities and guardrails. Reports prioritized architecture, quality, dependency, lockfile, tooling, and CI findings. |
137
- | `/repo-initialize` | Initialize the project. Asks greenfield versus brownfield, then activates the agent team. |
138
- | `/plan-explore` | Think through an idea or investigate a problem before committing to a plan. |
139
- | `/plan-propose <url or idea>` | Parse a GitHub Issue, Azure DevOps, Jira, or browser URL, or a direct idea, into a structured plan (proposal, specs, tasks). Enriches each task with agent and model assignments. |
140
- | `/plan-quick <task>` | Quick plan for focused changes. Reads the codebase, creates a task checklist in the Todo pane, and stops. No OpenSpec, no proposals, no specs. |
141
- | `/plan-apply` | Implement tasks from the current plan. Detects format automatically: OpenSpec-annotated tasks run as parallel subagent waves; plain checkboxes run sequentially in-session. |
142
- | `/ops-ship` | Create a pull request for the current branch with screenshots if the user interface changed. |
143
- | `/ops-review` | Read and triage pull request review feedback. Reports what needs fixing. |
144
- | `/ops-backlog` | Create an issue in the backlog platform (GitHub, Azure DevOps, or Jira) from a description. |
145
- | `/ops-evidence` | Produce evidence a change works (delegating to a project harness if present, else a screenshot), write `evidence/evidence.json`, and publish an idempotent comment on the issue/PR. Best-effort. |
146
- | `/plan-archive` | Archive a completed OpenSpec change. |
147
- | `/plan-goal <feature or URL>` | Autonomous, no-confirmation pipeline: branch off main, then explore, propose, apply, archive (one commit per phase). Default mode: merge to main and delete the feature branch. Add `branch` to keep the feature branch without merging or pushing. `push` pushes the branch; `pr` pushes and opens a PR. For loop-engineering. |
148
- | `/make-engineer` | Interactive persona-driven form to add a custom specialist engineer. Pick a persona, then confirm an inspected-and-recommended skill set (architecture/patterns like FSD or design patterns, framework, testing, infra) before it installs. |
149
- | `/make-architecture` | Generate or regenerate `ARCHITECTURE.md` from the codebase. |
150
- | `/make-design` | Generate or regenerate `DESIGN.md` from the design system. |
151
- | `/make-guardrails` | Generate a `pc-guardrails-project` skill from `ARCHITECTURE.md` and project config files. Extracts architecture boundaries, naming, code style, testing, and git workflow rules. Updates all `*-engineer.md` to load the skill. |
152
- | `/repo-verify` | Verify and repair current-branch changes against applicable fullstack abilities and dependency/lockfile rules, while always running immutable dependency installs/restores, configured builds, and tests for every discovered project. Runs automatically in `/plan-goal`. |
153
- | `/make-user-model [user] <tier> <model>` | Set the model for a tier (`plan`, `build`, `fast`). Writes to `harness.json` (team) or `harness.user.json` (user override, gitignored) when `user` prefix is used. Restart to pick up changes: the `pc-subagent-tiers` plugin rebuilds tier agents at startup. Pass a model id or `current` for the active session model. |
154
-
155
- ---
156
-
157
- ## Agents and Skills
158
-
159
- agent-harness draws a hard line between two concepts:
160
-
161
- ### Agents, universal behaviors
162
-
163
- Agents define _how to work_. They are universal personas (same behavior across projects and stacks).
164
-
165
- Current baseline uses a generic execution model:
166
-
167
- ```
168
- build primary. Implements. Full write access. The default.
169
- plan primary. Same body as build, but cannot edit or spawn.
170
- fullstack-engineer subagent. The body build and plan share, and the fallback worker.
171
- *-engineer subagent. User-created specialists, spawned for parallel implementation.
172
- *-engineer.<tier> subagent. The same specialist pinned to a plan/build/fast model.
173
- ```
174
-
175
- `build` and `plan` are the only agents a human selects, and they are overrides of opencode's own two primaries rather than new names. The `pc-subagent-tiers` plugin regenerates both from `fullstack-engineer.md` on every startup, so they always carry the current abilities, each on its own tier model. `plan` differs from `build` in two frontmatter lines: `edit: deny` and `task: deny`; spawning is denied because a plan session that can call `task()` can have a build worker make the change for it. It keeps `bash` so planning can read git and openspec state, and `pc-system-reminders` holds that shell to inspection commands. Everything else is `mode: subagent` and reached through `task()`, never picked from the agent list. Project-specific specialization comes from user-created engineers via `/make-engineer`. During `/plan-apply` the lead inspects the engineers that actually exist in `.opencode/agents/` and spawns matching specialists. Prefer a specialist over `fullstack-engineer`; if none matches, create one.
176
-
177
- ### Skills, platform knowledge
178
-
179
- Skills define _what to know_. They provide project rules, platform behavior, and task-specific execution guidance. Agents auto-detect and load relevant skills; **you do not manually choose skills per prompt**.
180
-
181
- If you choose backlog platform `None`, no userstory skills are injected into the workflow. The project works from direct conversation, local repository context, and optional OpenSpec artifacts only. If you choose repository platform `None`, no pull request skills are injected.
182
-
183
- Current loading model:
184
-
185
- - `pc-guardrails-generic` is mandatory baseline for every agent (git, secrets, quality rules, plus the engineer workflow)
186
- - Baseline context rules and token-optimization guidance live in `AGENTS.md` (always in context), not in a skill
187
-
188
- Default `fullstack-engineer` abilities:
189
-
190
- ```
191
- ## Abilities
192
- - Guardrails: @pc-guardrails-generic, @pc-guardrails-project
193
- ```
194
-
195
- Users are expected to create additional skills and map them into abilities over time.
196
-
197
- Built-in skills (`pc-` prefix) shipped with agent-harness:
198
-
199
- | Skill | Purpose |
200
- | ----- | ------- |
201
- | `pc-guardrails-generic` | Foundation for user guardrails skills |
202
- | `pc-guardrails-project` | Project-specific guardrails, populated by `/make-guardrails` |
203
- | `pc-userstory-gh` | Parse a GitHub Issue URL into a structured work item |
204
- | `pc-userstory-az` | Parse an Azure DevOps work item URL |
205
- | `pc-userstory-jira` | Parse a Jira issue URL via `acli` CLI |
206
- | `pc-userstory-browser` | Parse work item from any URL via browser automation (Linear, Trello, and so on) |
207
- | `browser-automation` | Browser control via `agent-browser` (localhost and browser backlog exception) |
208
- | `pc-plan-explore` | Read-only exploration procedure behind `/plan-explore`; autonomous mode used by `/plan-goal` |
209
- | `pc-plan-propose` | Proposal + task-enrichment procedure behind `/plan-propose`; autonomous mode used by `/plan-goal` |
210
- | `pc-plan-apply` | Wave-implementation procedure behind `/plan-apply`; autonomous mode used by `/plan-goal` |
211
- | `pc-plan-archive` | Archive procedure behind `/plan-archive` (platform flow injected at onboarding); autonomous mode used by `/plan-goal` |
212
- | `pc-ops-ship` | PR-creation procedure behind `/ops-ship` (platform flow injected at onboarding); used by `/plan-goal` pr mode |
213
- | `pc-ops-evidence` | Evidence of a change → `evidence/evidence.json` (passed/skipped/failed/blocked) + idempotent verified issue/PR comment; delegates to a project harness if present, else screenshots; used by `/ops-evidence` |
214
- | `pc-make-architecture` | ARCHITECTURE.md generation behind `/make-architecture`; used by `/repo-initialize` |
215
- | `pc-make-design` | DESIGN.md generation behind `/make-design`; used by `/repo-initialize` |
216
- | `pc-make-guardrails` | Guardrails generation behind `/make-guardrails`; used by `/repo-initialize` |
217
- | `pc-make-engineer` | Custom engineer creation behind `/make-engineer` |
218
- | `pc-make-user-model` | Tier model configuration behind `/make-user-model` |
219
- | `pc-plan-goal` | Autonomous full-lifecycle pipeline behind `/plan-goal` |
220
- | `pc-plan-quick` | Quick task checklist behind `/plan-quick` |
221
- | `pc-repo-audit` | Read-only health audit across configured source roots and fullstack abilities |
222
- | `pc-repo-verify` | Current-branch verification and repair gate used by `/repo-verify` and `/plan-goal` |
223
- | `pc-repo-initialize` | Project initialization behind `/repo-initialize` |
224
- | `pc-repo-onboard` | Guided project tour behind `/repo-onboard` |
225
- | `pc-repo-help` | The command reference displayed by `/repo-help`; used by `/repo-initialize` |
226
-
227
- Platform operations are injected during onboarding: pull request creation into the `pc-ops-ship` skill (loaded by `/ops-ship`, and by `/plan-goal` in `pr` mode), archive PR flow into the `pc-plan-archive` skill, issue/work-item evidence comments into the `pc-ops-evidence` skill (backlog platform), and pull request review / issue creation directly into the `/ops-review` and `/ops-backlog` command files.
228
-
229
- Skills live in `.agents/skills/`. Any `SKILL.md` file in a subdirectory is automatically discoverable. Write your own and agents will pick them up.
230
-
231
- ### Models, plan / build / fast
232
-
233
- During onboarding you pick three models:
234
-
235
- | Role | Used by | Pick |
236
- | ---- | ------- | ---- |
237
- | **plan** | Main OpenCode session (the lead) | Something capable with strong reasoning |
238
- | **build** | Specialist engineers (default tier) | Something capable for implementation |
239
- | **fast** | Light helpers (fast tier) | Something fast and cheap |
240
-
241
- Models are fetched live from [models.dev](https://models.dev) (3000+ models, cached weekly). Cost tiers `[$]` `[$$]` `[$$$]` always reflect the canonical provider price, so `github-copilot/claude-opus-4.7` shows `[$$]` not `[$]`.
242
-
243
- ---
244
-
245
- ## The pipeline
246
-
247
- When you give the lead agent a work item URL, execution follows this pipeline. If backlog platform is `None`, skip the work item stage. If repository platform is `None`, skip the pull request stage:
248
-
249
- ```
250
- lead
251
- ↓
252
- parse work item via userstory skill
253
- ↓
254
- plan-propose
255
- proposal + specs + tasks
256
- ↓
257
- [confirm with user]
258
- ↓
259
- wave of subagents (*-engineer, per-tier model)
260
- each implements its assigned tasks → returns result → lead commits group
261
- ↓
262
- verify (tests, build, lint as needed)
263
- ↓
264
- lead (ship mode, if configured)
265
- commit → push → pull request → feedback loop
266
- ```
267
-
268
- 1. Load the platform userstory skill (installed as `pc-userstory`, from the variant matching your backlog platform)
269
- 2. Run `/plan-propose` to produce `proposal.md`, specs, and `tasks.md`
270
- 3. Confirm with user before implementation
271
- 4. Run `/plan-apply` to orchestrate implementation in waves
272
- 5. Each wave spawns engineers in parallel (custom `*-engineer` specialists, each carrying its own tier model), capped at `agents.maxConcurrent`
273
- 6. Each subagent receives its task IDs in its prompt, loads relevant abilities, implements, and returns; the lead commits each group
274
- 7. Verify with tests, build, and lint according to task scope
275
- 8. Ship or update pull request via lead flow
276
-
277
- For unattended Loop Task runs, keep a concrete shell verification task as the final exit-code gate. `/repo-verify` runs inside `/plan-goal` first, applying fullstack abilities, every discovered project's immutable dependency install or restore, configured build and test commands, and change-aware repair checks; the shell task independently proves the critical commands passed before commit or pull request actions.
278
-
279
- Agents run as native OpenCode subagents in parallel waves: no external plugin, no git worktrees. The lead's Todo pane is the live board, and the `pc-subagent-monitor` plugin mirrors state to `.opencode/harness-run.json`. Navigate into any running subagent with `ctrl+x ↓` then `←`/`→`.
280
-
281
- ---
282
-
283
- ## What gets installed
284
-
285
- ```
286
- your-project/
287
- ├── AGENTS.md ← bootstrap mode, replaced after first "/repo-initialize"
288
- ├── ARCHITECTURE.md ← prompt for agents to fill in from your codebase
289
- ├── DESIGN.md ← prompt for agents to fill in from your codebase
290
- ├── .opencode/
291
- │ ├── opencode.json ← default model + plugin config
292
- │ ├── harness.json ← harness config: platform, models, maxConcurrentAgents
293
- │ ├── harness-managed.json ← hashes of every managed file, so "update" spares your edits
294
- │ ├── agents/ ← build.md + plan.md (generated primaries), fullstack-engineer,
295
- │ │ and user-created *-engineer files (all subagents)
296
- │ ├── tui.json ← registers the Subagents sidebar panel
297
- │ ├── tui/
298
- │ │ └── pc-subagents.tsx ← TUI plugin: live Subagents panel in the sidebar
299
- │ └── plugins/
300
- │ ├── pc-subagent-monitor.js ← server plugin: subagent state → .opencode/harness-run.json, and the wave cap
301
- │ └── pc-system-reminders.js ← server plugin: gates work on the agent's abilities, denies the never-rules
302
- └── .agents/
303
- └── skills/
304
- ├── pc-guardrails-generic/ ← foundation for user guardrails
305
- ├── pc-guardrails-project/ ← populated by /make-guardrails
306
- ├── pc-userstory/ ← the variant matching your backlog platform, renamed on install
307
- └── browser-automation/
308
- ```
309
-
310
- Platform skills ship as suffixed variants (`pc-userstory-gh`, `pc-userstory-az`, `pc-userstory-jira`, `pc-userstory-browser`) and the installer copies only the matching one, renamed to its generic name. Platform operations (ship, review, backlog) are injected directly into the `/ops-*` command files from `cli/fragments/ops-*/` during onboarding. Source-roots metadata lands in `.opencode/source-roots.json`. The always-shipped reminder plugin holds editing, shell and spawning until every ability under the agent's `## Abilities` is loaded, guardrails first, and re-arms after compaction. Token-optimization guidance is injected into `pc-guardrails-generic` marker blocks during onboarding.
311
-
312
- ---
313
-
314
- ## The bootstrap sequence
315
-
316
- The first time you type `init` in OpenCode after onboarding, the agent asks whether this is a **greenfield** or **brownfield** project:
317
-
318
- ### Brownfield (existing codebase)
319
-
320
- 1. Bootstrap-mode `AGENTS.md` triggers the initialization workflow
321
- 2. OpenCode archives existing project context into OpenSpec (`project-history`)
322
- 3. OpenCode runs `/make-architecture` to generate real `ARCHITECTURE.md` from your codebase
323
- 4. OpenCode runs `/make-design` to generate real `DESIGN.md` from your design system
324
- 5. OpenSpec `config.yaml` is populated with discovered tech stack and domain context
325
- 6. Bootstrap `AGENTS.md` is replaced with production guidance
326
- 7. Team workflows become fully active for normal implementation tasks
327
-
328
- ### Greenfield (new project, little or no existing code)
329
-
330
- 1. Bootstrap-mode `AGENTS.md` triggers the initialization workflow
331
- 2. OpenSpec `config.yaml` is populated with what is known (intended stack, domain)
332
- 3. Bootstrap `AGENTS.md` is replaced with production guidance
333
- 4. `ARCHITECTURE.md` and `DESIGN.md` are left as placeholder files
334
-
335
- Once your codebase has meaningful content, run:
336
- - `/make-architecture` to generate architecture documentation
337
- - `/make-design` to generate design system documentation
338
-
339
- Both commands are safe to rerun at any time as the project evolves.
340
-
341
- ---
342
-
343
- ## Token Budget Controls
344
-
345
- Long unattended agent sessions can consume significant tokens. Set these controls up **before** first use:
346
-
347
- 1. **Set provider-side limits first**: monthly soft-limit plus hard usage cap in your provider dashboard:
348
- - OpenAI: [platform.openai.com/account/limits](https://platform.openai.com/account/limits)
349
- - Anthropic: [console.anthropic.com](https://console.anthropic.com)
350
- - Google AI Studio: [aistudio.google.com/app/usage](https://aistudio.google.com/app/usage)
351
-
352
- 2. **Route models by task type**: use a fast and cheap model (for example `haiku`, `gpt-4o-mini`) for orchestration and status loops; reserve expensive models (for example `sonnet`, `opus`, `gpt-4o`) for implementation tasks only.
353
-
354
- 3. **Install the quota plugin**: the [`@slkiser/opencode-quota`](https://www.npmjs.com/package/@slkiser/opencode-quota) plugin adds `/quota` and `/quota_status` commands that surface real-time token usage inside OpenCode sessions.
355
-
356
- 4. **Use `/quota` checkpoints**: run `/quota` before starting any `/plan-apply` session and after each agent wave. Pause at 75 percent consumed; stop at 90 percent.
357
-
358
- 5. **Confirm before large runs**: the onboarded `/plan-apply` workflow will ask for your confirmation before spawning agents for Medium (4 to 7 tasks) or High (8 or more tasks) scope sessions.
359
-
360
- ---
361
-
362
- ## Prerequisites
363
-
364
- | Requirement | Notes |
365
- | ----------- | ----- |
366
- | **Node.js 18 or higher** | Required |
367
- | **[OpenCode](https://opencode.ai)** | The agent runtime |
368
- | **[gh CLI](https://cli.github.com)** | GitHub platform, must be authenticated |
369
- | **[az CLI](https://learn.microsoft.com/en-us/cli/azure/install-azure-cli)** plus azure-devops extension | Azure DevOps platform |
370
- | **[acli](https://developer.atlassian.com/cloud/acli/guides/install-acli/)** | Jira (Atlassian) backlog platform, must be authenticated |
371
- | **[glab](https://gitlab.com/gitlab-org/cli/#installation)** | GitLab repository platform, must be authenticated |
372
-
373
- ---
374
-
375
- ## Development
376
-
377
- The repository splits along one line: **`harness/` is the product, `cli/` is the machinery that installs it.**
378
-
379
- ```
380
- harness/ what lands in your repository, copied verbatim
381
- cli/ the installer: commands, wizard steps, presets, fragments
382
- skills/ skills about this CLI, for agents that operate it
383
- docs/ the documentation site
384
- ```
385
-
386
- Browse `harness/` to see what the Plain Concepts Platform Harness actually is, without reading a line of installer code.
387
-
388
- Inside `cli/`, the layout follows the ten wizard steps: one directory per step under `cli/steps/`, each owning its prompts and its file writes, with `cli/commands/` holding the top-level entry points (`wizard`, `update`, `join`, `migrate`, `single`).
389
-
390
- Data the CLI reads lives in two places, split by kind:
391
-
392
- **`cli/presets/`** holds JSON that shapes the wizard's questions and defaults:
393
-
394
- - `source.json` controls source-scope prompt options
395
- - `platforms.json` controls platform labels, CLI checks, and backlog-only flags
396
- - `clean.json` controls AI file detection and preservation
397
- - `models.json` controls model role prompts and agent assignments
398
- - `optimization.json` controls RTK, quota, Simple English, codegraph, agentmemory, and humanizer checklist defaults
399
- - `quota.json` controls opencode-quota defaults
400
- - `browser.json` controls the agent-browser installer (npm package + Chrome setup)
401
-
402
- **`cli/fragments/`** holds Markdown injected into the installed harness, one directory per marker family: `archive/`, `guardrails/`, `ops-backlog/`, `ops-evidence/`, `ops-review/`, `ops-ship/`. Each file is the platform-specific body that replaces a `<!-- PC-PLATFORM-*-START -->` block.
403
-
404
- Every filename the harness writes into a project is declared once in `cli/utils/paths.js`. Change it there, and remember the OpenCode plugins under `harness/.opencode/plugins/` read those same names at runtime.
405
-
406
- `skills/` holds skills *about this CLI*, for agents that have to operate it. See [skills/README.md](./skills/README.md). They are not published to npm, and they are separate from the `pc-*` skills in `harness/` that get installed into your project.
407
-
408
- ```bash
409
- git clone https://github.com/PlainConceptsPlatform/agent-harness.git
410
- cd agent-harness
411
- pnpm install
412
-
413
- # Run the CLI locally
414
- node cli/index.js
415
-
416
- # Run tests
417
- pnpm test
418
-
419
- # Run linting
420
- pnpm lint
421
-
422
- # Fix auto-fixable lint issues
423
- pnpm lint:fix
424
-
425
- # Watch mode
426
- pnpm test:watch
427
- ```
428
-
429
- Tests are written with [Vitest](https://vitest.dev). Linting uses ESLint flat config with Node ESM defaults and stricter correctness rules.
430
-
431
- ---
432
-
433
- ## License
434
-
435
- MIT © [Plain Concepts](https://github.com/PlainConceptsPlatform)
1
+ <div align="center">
2
+
3
+ <img src="https://raw.githubusercontent.com/PlainConceptsPlatform/agent-harness/refs/heads/main/docs/public/assets/logo.png" alt="agent-harness" width="160" />
4
+
5
+ # 🧰 agent-harness
6
+
7
+ **Installs the Plain Concepts Platform Harness into any codebase, and keeps it up to date. Wires [OpenCode](https://opencode.ai), [OpenSpec](https://github.com/fission-ai/openspec), [codegraph](https://github.com/colbymchenry/codegraph), and [agentmemory](https://github.com/rohitg00/agentmemory) into a multi-agent workflow that runs on native parallel subagents.**
8
+
9
+ GitHub, Azure DevOps, Jira, GitLab, browser-based backlog, or combinations (for example, Jira backlog plus GitHub repository, or browser backlog plus GitLab repository).
10
+
11
+ **[plainconceptsplatform.github.io/agent-harness](https://plainconceptsplatform.github.io/agent-harness)**
12
+
13
+ [![npm version](https://img.shields.io/npm/v/@plainconceptsplatform/agent-harness?style=flat-square&color=black)](https://www.npmjs.com/package/@plainconceptsplatform/agent-harness) [![npm downloads](https://img.shields.io/npm/dm/@plainconceptsplatform/agent-harness?style=flat-square&color=black)](https://www.npmjs.com/package/@plainconceptsplatform/agent-harness) [![license](https://img.shields.io/npm/l/@plainconceptsplatform/agent-harness?style=flat-square&color=black)](./LICENSE) [![node](https://img.shields.io/node/v/@plainconceptsplatform/agent-harness?style=flat-square&color=black)](https://nodejs.org)
14
+
15
+ </div>
16
+
17
+ ## What is this?
18
+
19
+ Most codebases have no `AGENTS.md`, no architecture documentation an agent can read, and no defined workflow for picking up a task. So agents improvise, and you get a different answer every run.
20
+
21
+ **agent-harness** is the CLI that installs the **Plain Concepts Platform Harness** into a repository and keeps it up to date.
22
+
23
+ The harness is ours. We build it, our projects run on it, and this CLI is how it gets into a codebase. 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`.
24
+
25
+ Underneath, it wires OpenCode to OpenSpec for change management, native subagent waves for parallel work, codegraph for code intelligence, and agentmemory for context that survives between sessions.
26
+
27
+ The CLI has three jobs:
28
+
29
+ | Command | What it does |
30
+ | --- | --- |
31
+ | `npx @plainconceptsplatform/agent-harness` | Installs the harness. A wizard runs once and saves your answers to `.opencode/harness.json`. |
32
+ | `npx @plainconceptsplatform/agent-harness update` | Reinstalls the harness from those saved answers, no questions asked. Keeps files you edited. |
33
+ | `npx @plainconceptsplatform/agent-harness join` | Sets up a teammate's machine. Touches no committed file. |
34
+
35
+ You run the first one once per repository, and the second whenever we ship a release.
36
+
37
+ <div align="center">
38
+ <img src="https://raw.githubusercontent.com/PlainConceptsPlatform/agent-harness/refs/heads/main/docs/public/assets/demo.gif" alt="agent-harness demo" width="700" />
39
+ </div>
40
+
41
+ ## Quick start
42
+
43
+ ```bash
44
+ npx @plainconceptsplatform/agent-harness@latest
45
+ ```
46
+
47
+ Requires **Node.js 18 or higher**.
48
+
49
+ ### Run specific steps
50
+
51
+ You can run individual setup or maintenance steps without running the full wizard:
52
+
53
+ ```bash
54
+ # Run one step directly
55
+ npx @plainconceptsplatform/agent-harness clean
56
+ npx @plainconceptsplatform/agent-harness platform
57
+ npx @plainconceptsplatform/agent-harness copy
58
+ npx @plainconceptsplatform/agent-harness openspec
59
+ npx @plainconceptsplatform/agent-harness models
60
+ npx @plainconceptsplatform/agent-harness optimization
61
+ npx @plainconceptsplatform/agent-harness browser
62
+ npx @plainconceptsplatform/agent-harness metadata
63
+ npx @plainconceptsplatform/agent-harness join
64
+
65
+ # Show CLI help and all commands
66
+ npx @plainconceptsplatform/agent-harness --help
67
+ npx @plainconceptsplatform/agent-harness -h
68
+ ```
69
+
70
+ When available, step commands reuse context from `.opencode/harness.json`.
71
+
72
+ ### Keeping the harness current
73
+
74
+ A new release of agent-harness ships new commands, skills and plugins. To pull them into a project that already has the harness:
75
+
76
+ ```bash
77
+ npx @plainconceptsplatform/agent-harness@latest update
78
+ ```
79
+
80
+ `update` re-runs every file patch from `.opencode/harness.json` and asks nothing. It keeps a hash of each file it manages in `.opencode/harness-managed.json`, so it leaves your hand edits alone and reports them as preserved. It also skips generated skills like `pc-guardrails-project`, whose contents came from a `/make-*` command rather than from us.
81
+
82
+ Reach for individual steps when you want something narrower:
83
+
84
+ - `clean` to reset old AI files
85
+ - `copy` if templates or skills changed in a new agent-harness release
86
+ - `optimization` to reconfigure RTK, quota, Simple English, codegraph, agentmemory, or humanizer, and the guardrails optimization markers
87
+ - `metadata` last, to refresh `.opencode/harness.json`
88
+ - `join` if you are new to a project that already has the harness and want the local tooling it expects
89
+
90
+ > **Upgrading from `opencode-onboard` v1?** v2 renamed the config files and the skill prefix (`ob-` became `pc-`), and it does not migrate v1 projects. The CLI detects one and refuses to run rather than half-patching it. Re-onboard on a clean branch: remove `.opencode/` and `.agents/skills/ob-*`, then run the wizard again.
91
+
92
+ > **Browser tooling changed in v2.4.** The `@different-ai/opencode-browser` plugin (and its Chrome extension) was replaced by [`agent-browser`](https://github.com/vercel-labs/agent-browser), wired in as an MCP server in `opencode.jsonc`. Running `update` strips the old plugin entry, adds the MCP block, and installs the new binary — no manual unloading of the extension is needed, though you can remove it from `chrome://extensions` yourself. Skills you wrote that call `browser_*` tools directly must switch to the `agent-browser` CLI or the `agent_browser_*` MCP tools. Backlog-browser users: agent-browser runs its own Chrome, so log in once per project using the `--session backlog --restore` flow described in `pc-userstory-browser`.
93
+
94
+ ---
95
+
96
+ ## Installing the harness
97
+
98
+ The first run is a 10-step wizard. It keeps the current step visible, plus the last two completed steps, so progress is always clear.
99
+
100
+ | Step | What happens |
101
+ | --- | --- |
102
+ | **1. Source scope** | Choose current repository or sibling source roots for code analysis |
103
+ | **2. Clean AI files** | Detects existing `AGENTS.md`, `.cursorrules`, `CLAUDE.md`, `.agents/` and so on, then removes them. Preserves your `.agents/skills/` directory. |
104
+ | **3. Choose platform** | Backlog (GitHub, Azure DevOps, Jira, browser-based, or None) plus repository (GitHub, Azure DevOps, GitLab, or None). Supports mixed platforms, for example browser backlog plus GitHub repository, or Jira backlog plus GitLab repository. |
105
+ | **4. Check platform CLI** | Verifies `gh` (GitHub), or `az` plus `azure-devops` extension (Azure DevOps), or `acli` (Jira), or `glab` (GitLab). Skips CLI checks for browser-based or None platforms. |
106
+ | **5. Copy scaffolding** | Copies agents, built-in skills, bootstrap documentation, writes source-roots metadata, applies AGENTS bootstrap patching, copies `skills-lock.json`, then runs `npx skills` |
107
+ | **6. Initialize OpenSpec** | Runs `npx @fission-ai/openspec init` silently for structured change management |
108
+ | **7. Choose models** | Fetches live model list from [models.dev](https://models.dev), lets you pick plan, build, and fast models with cost indicators and canonical pricing |
109
+ | **8. Token optimization tools** | Optional and recommended. One checklist step for RTK check, opencode-quota setup, Simple English install, codegraph install, agentmemory install, humanizer install, and token-optimization rule injection into guardrails |
110
+ | **9. Install browser tooling** | Installs `agent-browser` globally and downloads its Chrome for Testing binary |
111
+ | **10. Write onboarding metadata** | Writes `.opencode/harness.json` with selected setup details |
112
+
113
+ When it finishes, open OpenCode in your project and type:
114
+
115
+ ```
116
+ /repo-initialize
117
+ ```
118
+
119
+ OpenCode asks if this is a greenfield or brownfield project. For brownfield projects it generates `ARCHITECTURE.md` and `DESIGN.md` from your actual codebase, archives project history, then activates the full agent team. For greenfield projects it skips documentation generation and leaves placeholder files you can populate later with `/make-architecture` and `/make-design`.
120
+
121
+ ---
122
+
123
+ ## Commands
124
+
125
+ Custom slash commands are installed into `.opencode/commands/` and are available directly in OpenCode.
126
+
127
+ Commands that other commands (or agents) need to execute are thin wrappers around `pc-*` skills in `.agents/skills/`. The command handles user invocation and arguments, and the skill holds the procedure. OpenCode has no mechanism for a command to run another command, but any agent can load a skill mid-conversation, which is what makes pipelines like `/plan-goal` composable.
128
+
129
+ | Command | Description |
130
+ | ------- | ----------- |
131
+ | `/repo-help` | Show all commands and when to use each one. Start here if you are unsure. |
132
+ | `/repo-onboard` | Guided tour of the project and its agentic infrastructure. Explains agents, commands, skills, OpenSpec workflow, and configuration. Read-only. |
133
+ | `/repo-audit` | Read-only audit of every configured source root against fullstack abilities and guardrails. Reports prioritized architecture, quality, dependency, lockfile, tooling, and CI findings. |
134
+ | `/repo-initialize` | Initialize the project. Asks greenfield versus brownfield, then activates the agent team. |
135
+ | `/plan-explore` | Think through an idea or investigate a problem before committing to a plan. |
136
+ | `/plan-propose <url or idea>` | Parse a GitHub Issue, Azure DevOps, Jira, or browser URL, or a direct idea, into a structured plan (proposal, specs, tasks). Enriches each task with agent and model assignments. |
137
+ | `/plan-quick <task>` | Quick plan for focused changes. Reads the codebase, creates a task checklist in the Todo pane, and stops. No OpenSpec, no proposals, no specs. |
138
+ | `/plan-apply` | Implement tasks from the current plan. Detects format automatically: OpenSpec-annotated tasks run as parallel subagent waves; plain checkboxes run sequentially in-session. |
139
+ | `/ops-ship` | Create a pull request for the current branch with screenshots if the user interface changed. |
140
+ | `/ops-review` | Read and triage pull request review feedback. Reports what needs fixing. |
141
+ | `/ops-backlog` | Create an issue in the backlog platform (GitHub, Azure DevOps, or Jira) from a description. |
142
+ | `/ops-evidence` | Produce evidence a change works (delegating to a project harness if present, else a screenshot), write `evidence/evidence.json`, and publish an idempotent comment on the issue/PR. Best-effort. |
143
+ | `/plan-archive` | Archive a completed OpenSpec change. |
144
+ | `/plan-goal <feature or URL>` | Autonomous, no-confirmation pipeline: branch off main, then explore, propose, apply, archive (one commit per phase). Default mode: merge to main and delete the feature branch. Add `branch` to keep the feature branch without merging or pushing. `push` pushes the branch; `pr` pushes and opens a PR. For loop-engineering. |
145
+ | `/make-engineer` | Interactive persona-driven form to add a custom specialist engineer. Pick a persona, then confirm an inspected-and-recommended skill set (architecture/patterns like FSD or design patterns, framework, testing, infra) before it installs. |
146
+ | `/make-architecture` | Generate or regenerate `ARCHITECTURE.md` from the codebase. |
147
+ | `/make-design` | Generate or regenerate `DESIGN.md` from the design system. |
148
+ | `/make-guardrails` | Generate a `pc-guardrails-project` skill from `ARCHITECTURE.md` and project config files. Extracts architecture boundaries, naming, code style, testing, and git workflow rules. Updates all `*-engineer.md` to load the skill. |
149
+ | `/repo-verify` | Write a reproduction plan for the current branch's change as a journey of agent-browser waypoints, stored in `verification-plan.md` with the change. 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 — the checks gate lives in `/plan-apply`, and the plan is executed later by a separate agent-browser skill. Runs automatically in `/plan-goal`. |
150
+ | `/make-user-model [user] <tier> <model>` | Set the model for a tier (`plan`, `build`, `fast`). Writes to `harness.json` (team) or `harness.user.json` (user override, gitignored) when `user` prefix is used. Restart to pick up changes: the `pc-subagent-tiers` plugin rebuilds tier agents at startup. Pass a model id or `current` for the active session model. |
151
+
152
+ ---
153
+
154
+ ## Agents and Skills
155
+
156
+ agent-harness draws a hard line between two concepts:
157
+
158
+ ### Agents, universal behaviors
159
+
160
+ Agents define _how to work_. They are universal personas (same behavior across projects and stacks).
161
+
162
+ Current baseline uses a generic execution model:
163
+
164
+ ```
165
+ build primary. Implements. Full write access. The default.
166
+ plan primary. Same body as build, but cannot edit or spawn.
167
+ fullstack-engineer subagent. The body build and plan share, and the fallback worker.
168
+ *-engineer subagent. User-created specialists, spawned for parallel implementation.
169
+ *-engineer.<tier> subagent. The same specialist pinned to a plan/build/fast model.
170
+ ```
171
+
172
+ `build` and `plan` are the only agents a human selects, and they are overrides of opencode's own two primaries rather than new names. The `pc-subagent-tiers` plugin regenerates both from `fullstack-engineer.md` on every startup, so they always carry the current abilities, each on its own tier model. `plan` differs from `build` in two frontmatter lines: `edit: deny` and `task: deny`; spawning is denied because a plan session that can call `task()` can have a build worker make the change for it. It keeps `bash` so planning can read git and openspec state, and `pc-system-reminders` holds that shell to inspection commands. Everything else is `mode: subagent` and reached through `task()`, never picked from the agent list. Project-specific specialization comes from user-created engineers via `/make-engineer`. During `/plan-apply` the lead inspects the engineers that actually exist in `.opencode/agents/` and spawns matching specialists. Prefer a specialist over `fullstack-engineer`; if none matches, create one.
173
+
174
+ ### Skills, platform knowledge
175
+
176
+ Skills define _what to know_. They provide project rules, platform behavior, and task-specific execution guidance. Agents auto-detect and load relevant skills; **you do not manually choose skills per prompt**.
177
+
178
+ If you choose backlog platform `None`, no userstory skills are injected into the workflow. The project works from direct conversation, local repository context, and optional OpenSpec artifacts only. If you choose repository platform `None`, no pull request skills are injected.
179
+
180
+ Current loading model:
181
+
182
+ - `pc-guardrails-generic` is mandatory baseline for every agent (git, secrets, quality rules, plus the engineer workflow)
183
+ - Baseline context rules and token-optimization guidance live in `AGENTS.md` (always in context), not in a skill
184
+
185
+ Default `fullstack-engineer` abilities:
186
+
187
+ ```
188
+ ## Abilities
189
+ - Guardrails: @pc-guardrails-generic, @pc-guardrails-project
190
+ ```
191
+
192
+ Users are expected to create additional skills and map them into abilities over time.
193
+
194
+ Built-in skills (`pc-` prefix) shipped with agent-harness:
195
+
196
+ | Skill | Purpose |
197
+ | ----- | ------- |
198
+ | `pc-guardrails-generic` | Foundation for user guardrails skills |
199
+ | `pc-guardrails-project` | Project-specific guardrails, populated by `/make-guardrails` |
200
+ | `pc-userstory-gh` | Parse a GitHub Issue URL into a structured work item |
201
+ | `pc-userstory-az` | Parse an Azure DevOps work item URL |
202
+ | `pc-userstory-jira` | Parse a Jira issue URL via `acli` CLI |
203
+ | `pc-userstory-browser` | Parse work item from any URL via browser automation (Linear, Trello, and so on) |
204
+ | `browser-automation` | Browser control via `agent-browser` (localhost and browser backlog exception) |
205
+ | `pc-plan-explore` | Read-only exploration procedure behind `/plan-explore`; autonomous mode used by `/plan-goal` |
206
+ | `pc-plan-propose` | Proposal + task-enrichment procedure behind `/plan-propose`; autonomous mode used by `/plan-goal` |
207
+ | `pc-plan-apply` | Wave-implementation procedure behind `/plan-apply`; autonomous mode used by `/plan-goal` |
208
+ | `pc-plan-archive` | Archive procedure behind `/plan-archive` (platform flow injected at onboarding); autonomous mode used by `/plan-goal` |
209
+ | `pc-ops-ship` | PR-creation procedure behind `/ops-ship` (platform flow injected at onboarding); used by `/plan-goal` pr mode |
210
+ | `pc-ops-evidence` | Evidence of a change → `evidence/evidence.json` (passed/skipped/failed/blocked) + idempotent verified issue/PR comment; delegates to a project harness if present, else screenshots; used by `/ops-evidence` |
211
+ | `pc-make-architecture` | ARCHITECTURE.md generation behind `/make-architecture`; used by `/repo-initialize` |
212
+ | `pc-make-design` | DESIGN.md generation behind `/make-design`; used by `/repo-initialize` |
213
+ | `pc-make-guardrails` | Guardrails generation behind `/make-guardrails`; used by `/repo-initialize` |
214
+ | `pc-make-engineer` | Custom engineer creation behind `/make-engineer` |
215
+ | `pc-make-user-model` | Tier model configuration behind `/make-user-model` |
216
+ | `pc-plan-goal` | Autonomous full-lifecycle pipeline behind `/plan-goal` |
217
+ | `pc-plan-quick` | Quick task checklist behind `/plan-quick` |
218
+ | `pc-repo-audit` | Read-only health audit across configured source roots and fullstack abilities |
219
+ | `pc-repo-verify` | Writes the verification plan (`verification-plan.md`): a reproduction journey of agent-browser waypoints, stored with the change archive. Used by `/repo-verify` and `/plan-goal` |
220
+ | `pc-repo-initialize` | Project initialization behind `/repo-initialize` |
221
+ | `pc-repo-onboard` | Guided project tour behind `/repo-onboard` |
222
+ | `pc-repo-help` | The command reference displayed by `/repo-help`; used by `/repo-initialize` |
223
+
224
+ Platform operations are injected during onboarding: pull request creation into the `pc-ops-ship` skill (loaded by `/ops-ship`, and by `/plan-goal` in `pr` mode), archive PR flow into the `pc-plan-archive` skill, issue/work-item evidence comments into the `pc-ops-evidence` skill (backlog platform), and pull request review / issue creation directly into the `/ops-review` and `/ops-backlog` command files.
225
+
226
+ Skills live in `.agents/skills/`. Any `SKILL.md` file in a subdirectory is automatically discoverable. Write your own and agents will pick them up.
227
+
228
+ ### Models, plan / build / fast
229
+
230
+ During onboarding you pick three models:
231
+
232
+ | Role | Used by | Pick |
233
+ | ---- | ------- | ---- |
234
+ | **plan** | Main OpenCode session (the lead) | Something capable with strong reasoning |
235
+ | **build** | Specialist engineers (default tier) | Something capable for implementation |
236
+ | **fast** | Light helpers (fast tier) | Something fast and cheap |
237
+
238
+ Models are fetched live from [models.dev](https://models.dev) (3000+ models, cached weekly). Cost tiers `[$]` `[$$]` `[$$$]` always reflect the canonical provider price, so `github-copilot/claude-opus-4.7` shows `[$$]` not `[$]`.
239
+
240
+ ---
241
+
242
+ ## The pipeline
243
+
244
+ When you give the lead agent a work item URL, execution follows this pipeline. If backlog platform is `None`, skip the work item stage. If repository platform is `None`, skip the pull request stage:
245
+
246
+ ```
247
+ lead
248
+ ↓
249
+ parse work item via userstory skill
250
+ ↓
251
+ plan-propose
252
+ proposal + specs + tasks
253
+ ↓
254
+ [confirm with user]
255
+ ↓
256
+ wave of subagents (*-engineer, per-tier model)
257
+ each implements its assigned tasks → returns result → lead commits group
258
+ ↓
259
+ verify (tests, build, lint as needed)
260
+ ↓
261
+ lead (ship mode, if configured)
262
+ commit → push → pull request → feedback loop
263
+ ```
264
+
265
+ 1. Load the platform userstory skill (installed as `pc-userstory`, from the variant matching your backlog platform)
266
+ 2. Run `/plan-propose` to produce `proposal.md`, specs, and `tasks.md`
267
+ 3. Confirm with user before implementation
268
+ 4. Run `/plan-apply` to orchestrate implementation in waves
269
+ 5. Each wave spawns engineers in parallel (custom `*-engineer` specialists, each carrying its own tier model), capped at `agents.maxConcurrent`
270
+ 6. Each subagent receives its task IDs in its prompt, loads relevant abilities, implements, and returns; the lead commits each group
271
+ 7. Verify with tests, build, and lint according to task scope
272
+ 8. Ship or update pull request via lead flow
273
+
274
+ For unattended Loop Task runs, keep a concrete shell verification task as the final exit-code gate. Inside `/plan-goal`, `/plan-apply` step 10 runs lint, typecheck, test, and build commands and is the checks gate; `/repo-verify` then writes `verification-plan.md` (a reproduction journey for a later agent-browser executor). The final shell task independently proves the critical commands passed before commit or pull request actions.
275
+
276
+ Agents run as native OpenCode subagents in parallel waves: no external plugin, no git worktrees. The lead's Todo pane is the live board, and the `pc-subagent-monitor` plugin mirrors state to `.opencode/harness-run.json`. Navigate into any running subagent with `ctrl+x ↓` then `←`/`→`.
277
+
278
+ ---
279
+
280
+ ## What gets installed
281
+
282
+ ```
283
+ your-project/
284
+ ├── AGENTS.md ← bootstrap mode, replaced after first "/repo-initialize"
285
+ ├── ARCHITECTURE.md ← prompt for agents to fill in from your codebase
286
+ ├── DESIGN.md ← prompt for agents to fill in from your codebase
287
+ ├── .opencode/
288
+ │ ├── opencode.json ← default model + plugin config
289
+ │ ├── harness.json ← harness config: platform, models, maxConcurrentAgents
290
+ │ ├── harness-managed.json ← hashes of every managed file, so "update" spares your edits
291
+ │ ├── agents/ ← build.md + plan.md (generated primaries), fullstack-engineer,
292
+ │ │ and user-created *-engineer files (all subagents)
293
+ │ ├── tui.json ← registers the Subagents sidebar panel
294
+ │ ├── tui/
295
+ │ │ └── pc-subagents.tsx ← TUI plugin: live Subagents panel in the sidebar
296
+ │ └── plugins/
297
+ │ ├── pc-subagent-monitor.js ← server plugin: subagent state → .opencode/harness-run.json, and the wave cap
298
+ │ └── pc-system-reminders.js ← server plugin: gates work on the agent's abilities, denies the never-rules
299
+ └── .agents/
300
+ └── skills/
301
+ ├── pc-guardrails-generic/ ← foundation for user guardrails
302
+ ├── pc-guardrails-project/ ← populated by /make-guardrails
303
+ ├── pc-userstory/ ← the variant matching your backlog platform, renamed on install
304
+ └── browser-automation/
305
+ ```
306
+
307
+ Platform skills ship as suffixed variants (`pc-userstory-gh`, `pc-userstory-az`, `pc-userstory-jira`, `pc-userstory-browser`) and the installer copies only the matching one, renamed to its generic name. Platform operations (ship, review, backlog) are injected directly into the `/ops-*` command files from `cli/fragments/ops-*/` during onboarding. Source-roots metadata lands in `.opencode/source-roots.json`. The always-shipped reminder plugin holds editing, shell and spawning until every ability under the agent's `## Abilities` is loaded, guardrails first, and re-arms after compaction. Token-optimization guidance is injected into `pc-guardrails-generic` marker blocks during onboarding.
308
+
309
+ ---
310
+
311
+ ## The bootstrap sequence
312
+
313
+ The first time you type `init` in OpenCode after onboarding, the agent asks whether this is a **greenfield** or **brownfield** project:
314
+
315
+ ### Brownfield (existing codebase)
316
+
317
+ 1. Bootstrap-mode `AGENTS.md` triggers the initialization workflow
318
+ 2. OpenCode archives existing project context into OpenSpec (`project-history`)
319
+ 3. OpenCode runs `/make-architecture` to generate real `ARCHITECTURE.md` from your codebase
320
+ 4. OpenCode runs `/make-design` to generate real `DESIGN.md` from your design system
321
+ 5. OpenSpec `config.yaml` is populated with discovered tech stack and domain context
322
+ 6. Bootstrap `AGENTS.md` is replaced with production guidance
323
+ 7. Team workflows become fully active for normal implementation tasks
324
+
325
+ ### Greenfield (new project, little or no existing code)
326
+
327
+ 1. Bootstrap-mode `AGENTS.md` triggers the initialization workflow
328
+ 2. OpenSpec `config.yaml` is populated with what is known (intended stack, domain)
329
+ 3. Bootstrap `AGENTS.md` is replaced with production guidance
330
+ 4. `ARCHITECTURE.md` and `DESIGN.md` are left as placeholder files
331
+
332
+ Once your codebase has meaningful content, run:
333
+ - `/make-architecture` to generate architecture documentation
334
+ - `/make-design` to generate design system documentation
335
+
336
+ Both commands are safe to rerun at any time as the project evolves.
337
+
338
+ ---
339
+
340
+ ## Token Budget Controls
341
+
342
+ Long unattended agent sessions can consume significant tokens. Set these controls up **before** first use:
343
+
344
+ 1. **Set provider-side limits first**: monthly soft-limit plus hard usage cap in your provider dashboard:
345
+ - OpenAI: [platform.openai.com/account/limits](https://platform.openai.com/account/limits)
346
+ - Anthropic: [console.anthropic.com](https://console.anthropic.com)
347
+ - Google AI Studio: [aistudio.google.com/app/usage](https://aistudio.google.com/app/usage)
348
+
349
+ 2. **Route models by task type**: use a fast and cheap model (for example `haiku`, `gpt-4o-mini`) for orchestration and status loops; reserve expensive models (for example `sonnet`, `opus`, `gpt-4o`) for implementation tasks only.
350
+
351
+ 3. **Install the quota plugin**: the [`@slkiser/opencode-quota`](https://www.npmjs.com/package/@slkiser/opencode-quota) plugin adds `/quota` and `/quota_status` commands that surface real-time token usage inside OpenCode sessions.
352
+
353
+ 4. **Use `/quota` checkpoints**: run `/quota` before starting any `/plan-apply` session and after each agent wave. Pause at 75 percent consumed; stop at 90 percent.
354
+
355
+ 5. **Confirm before large runs**: the onboarded `/plan-apply` workflow will ask for your confirmation before spawning agents for Medium (4 to 7 tasks) or High (8 or more tasks) scope sessions.
356
+
357
+ ---
358
+
359
+ ## Prerequisites
360
+
361
+ | Requirement | Notes |
362
+ | ----------- | ----- |
363
+ | **Node.js 18 or higher** | Required |
364
+ | **[OpenCode](https://opencode.ai)** | The agent runtime |
365
+ | **[gh CLI](https://cli.github.com)** | GitHub platform, must be authenticated |
366
+ | **[az CLI](https://learn.microsoft.com/en-us/cli/azure/install-azure-cli)** plus azure-devops extension | Azure DevOps platform |
367
+ | **[acli](https://developer.atlassian.com/cloud/acli/guides/install-acli/)** | Jira (Atlassian) backlog platform, must be authenticated |
368
+ | **[glab](https://gitlab.com/gitlab-org/cli/#installation)** | GitLab repository platform, must be authenticated |
369
+
370
+ ---
371
+
372
+ ## Development
373
+
374
+ The repository splits along one line: **`harness/` is the product, `cli/` is the machinery that installs it.**
375
+
376
+ ```
377
+ harness/ what lands in your repository, copied verbatim
378
+ cli/ the installer: commands, wizard steps, presets, fragments
379
+ skills/ skills about this CLI, for agents that operate it
380
+ docs/ the documentation site
381
+ ```
382
+
383
+ Browse `harness/` to see what the Plain Concepts Platform Harness actually is, without reading a line of installer code.
384
+
385
+ Inside `cli/`, the layout follows the ten wizard steps: one directory per step under `cli/steps/`, each owning its prompts and its file writes, with `cli/commands/` holding the top-level entry points (`wizard`, `update`, `join`, `migrate`, `single`).
386
+
387
+ Data the CLI reads lives in two places, split by kind:
388
+
389
+ **`cli/presets/`** holds JSON that shapes the wizard's questions and defaults:
390
+
391
+ - `source.json` controls source-scope prompt options
392
+ - `platforms.json` controls platform labels, CLI checks, and backlog-only flags
393
+ - `clean.json` controls AI file detection and preservation
394
+ - `models.json` controls model role prompts and agent assignments
395
+ - `optimization.json` controls RTK, quota, Simple English, codegraph, agentmemory, and humanizer checklist defaults
396
+ - `quota.json` controls opencode-quota defaults
397
+ - `browser.json` controls the agent-browser installer (npm package + Chrome setup)
398
+
399
+ **`cli/fragments/`** holds Markdown injected into the installed harness, one directory per marker family: `archive/`, `guardrails/`, `ops-backlog/`, `ops-evidence/`, `ops-review/`, `ops-ship/`. Each file is the platform-specific body that replaces a `<!-- PC-PLATFORM-*-START -->` block.
400
+
401
+ Every filename the harness writes into a project is declared once in `cli/utils/paths.js`. Change it there, and remember the OpenCode plugins under `harness/.opencode/plugins/` read those same names at runtime.
402
+
403
+ `skills/` holds skills *about this CLI*, for agents that have to operate it. See [skills/README.md](./skills/README.md). They are not published to npm, and they are separate from the `pc-*` skills in `harness/` that get installed into your project.
404
+
405
+ ```bash
406
+ git clone https://github.com/PlainConceptsPlatform/agent-harness.git
407
+ cd agent-harness
408
+ pnpm install
409
+
410
+ # Run the CLI locally
411
+ node cli/index.js
412
+
413
+ # Run tests
414
+ pnpm test
415
+
416
+ # Run linting
417
+ pnpm lint
418
+
419
+ # Fix auto-fixable lint issues
420
+ pnpm lint:fix
421
+
422
+ # Watch mode
423
+ pnpm test:watch
424
+ ```
425
+
426
+ Tests are written with [Vitest](https://vitest.dev). Linting uses ESLint flat config with Node ESM defaults and stricter correctness rules.
427
+
428
+ ---
429
+
430
+ ## License
431
+
432
+ MIT © [Plain Concepts](https://github.com/PlainConceptsPlatform)