@plainconceptsplatform/agent-harness 2.0.0 → 2.0.1

package/src/content/.agents/skills/pc-plan-propose/SKILL.md

@@ -1,125 +1,125 @@
----
-name: pc-plan-propose
-description: Parse a work item or idea and produce an OpenSpec change plan (proposal.md, specs, tasks.md) with enriched task assignments (agent, tier, depends_on, touches). Load when turning a requirement into a structured plan. Invoked by the /plan-propose command (interactive) and the plan-goal pipeline (autonomous).
-license: MIT
----
-
-# Plan Propose
-
-**READ-ONLY UNTIL CONFIRMED.** Until the Step 3 checkpoint resolves to `yes`, this entire skill is read-only. You MUST NOT write, edit, or create any file. Build everything in context. Files hit disk only in Step 4. After Step 5, the skill ends; if the user keeps chatting without invoking a new command, remain read-only. Writing requires either an explicit user command (e.g. `/plan-apply`) or the Step 3 `yes` confirmation.
-
-## Input
-
-The caller provides:
-- A work item URL, issue key, or direct feature description. Exploration findings may accompany it; incorporate them.
-- Optionally a mode (see below). Default: `interactive`.
-
-## Modes
-
-- `interactive` (default): every checkpoint below is active. Wait for the user at each one.
-- `autonomous`: there is no user. Never ask anything. Each checkpoint marked with a stop sign states its autonomous resolution inline.
-
-## Step 0.a: Check for unarchived changes (stop)
-
-Before proposing a new change, inspect `openspec/changes/` (ignore `openspec/changes/archive`).
-If any change folder exists in `openspec/changes/` (names vary by platform: `gh-*`, `us-*`, or a plain slug), list them in the question text, then call the `question` tool:
-
-```json
-{
-  "questions": [
-    {
-      "header": "Unarchived changes",
-      "question": "There are unarchived changes pending:\n{change-name}\n{change-name}\n...\n\nContinue with the proposal or stop to archive first?",
-      "options": [
-        { "label": "continue", "description": "Proceed with the proposal." },
-        { "label": "stop", "description": "End without generating a proposal. Archive the pending change first." }
-      ]
-    }
-  ]
-}
-```
-
-- If the user answers `stop`, end without generating a proposal.
-- If the user answers `continue`, proceed to the next step.
-
-Autonomous mode: do not call the `question` tool; treat the answer as `continue` and proceed.
-
-## Step 0.b: Load proposal skill
-
-If a work item URL or issue key is provided (GitHub Issue, Azure DevOps work item, Jira issue, or browser-based backlog): load `@pc-userstory` skill and fetch the work item before continuing. Backlog platform is set in `.opencode/harness.json` -> `platform.backlog`. If backlog platform is `none`, skip this step and work from direct input.
-
-## Step 1: Generate the proposal in memory
-
-Load `@openspec-propose` skill and follow its instructions to generate proposal.md, specs, and tasks.md. Do not write them to disk yet. Build the complete proposal content in your context.
-
-## Step 2: Enrich task assignments
-
-1. List every `*-engineer.md` file in `.opencode/agents/`. For each file read:
-   - `description:` from the YAML frontmatter: the engineer's specialization summary
-   - `## Abilities` section: the skills listed under Development, Testing, Infrastructure (e.g. `@nodejs-backend`, `@secure-nextjs-api-routes`)
-   Build a map of `agent-name -> { description, abilities }`.
-2. For each task, compare the task text and domain against every engineer's description AND abilities. Pick the engineer whose combined profile most closely matches. `fullstack-engineer` is `mode: primary` (the user's planning agent), not a spawned worker. If no specialist matches a task, leave the agent field blank and record the missing specialization in the proposal. An annotated OpenSpec task needs a real subagent; never substitute the lead or an obsolete generic agent name.
-3. Pick a tier, derive `depends_on`, derive `touches`, and annotate each task line. Follow the [task annotation](task-annotation.md) reference for the full tier selection guide, dependency derivation, touches derivation, and annotation format with examples.
-
-## Step 3: Show the plan and ask for confirmation (stop)
-
-Display the complete proposal to the user:
-- Change name and description
-- Total task count
-- Full task list with agent (including tier suffix) and dependency annotations
-
-Then call the `question` tool:
-
-```json
-{
-  "questions": [
-    {
-      "header": "Save proposal",
-      "question": "Save this proposal?",
-      "options": [
-        { "label": "yes", "description": "Write all files to disk and proceed." },
-        { "label": "edit", "description": "Provide feedback, revise in memory, show again." },
-        { "label": "stop", "description": "End without writing anything." }
-      ]
-    }
-  ]
-}
-```
-
-- `yes` -> proceed to Step 4 and write all files
-- `edit` -> user provides feedback, revise in memory, show again, ask again
-- `stop` -> end without writing anything
-
-Wait for the user's response. Do not proceed without a response.
-
-Autonomous mode: do not call the `question` tool; treat the answer as `yes` and write the files immediately.
-
-## Step 4: Write (only after the Step 3 checkpoint resolves)
-
-Write the proposal files to `openspec/changes/{change-slug}/`:
-- `proposal.md`: the change description and rationale
-- `specs/`: any spec files generated
-- `tasks.md`: the enriched task list with agent annotations
-
-## Step 5: Stop (stop)
-
-Call the `question` tool:
-
-```json
-{
-  "questions": [
-    {
-      "header": "Ready to implement",
-      "question": "Ready to implement?",
-      "options": [
-        { "label": "yes", "description": "Load the pc-plan-apply skill to start implementation." },
-        { "label": "no", "description": "Stop here. You can run /plan-apply later." }
-      ]
-    }
-  ]
-}
-```
-
-Loading `pc-plan-apply` requires explicit user confirmation.
-
-Autonomous mode: do not call the `question` tool. The PROPOSE stage is complete. Hand the change slug and task count back to the caller (the `/plan-goal` pipeline) so it immediately continues to the apply phase. This is a stage boundary, not the end of the run.
+---
+name: pc-plan-propose
+description: Parse a work item or idea and produce an OpenSpec change plan (proposal.md, specs, tasks.md) with enriched task assignments (agent, tier, depends_on, touches). Load when turning a requirement into a structured plan. Invoked by the /plan-propose command (interactive) and the plan-goal pipeline (autonomous).
+license: MIT
+---
+
+# Plan Propose
+
+**READ-ONLY UNTIL CONFIRMED.** Until the Step 3 checkpoint resolves to `yes`, this entire skill is read-only. You MUST NOT write, edit, or create any file. Build everything in context. Files hit disk only in Step 4. After Step 5, the skill ends; if the user keeps chatting without invoking a new command, remain read-only. Writing requires either an explicit user command (e.g. `/plan-apply`) or the Step 3 `yes` confirmation.
+
+## Input
+
+The caller provides:
+- A work item URL, issue key, or direct feature description. Exploration findings may accompany it; incorporate them.
+- Optionally a mode (see below). Default: `interactive`.
+
+## Modes
+
+- `interactive` (default): every checkpoint below is active. Wait for the user at each one.
+- `autonomous`: there is no user. Never ask anything. Each checkpoint marked with a stop sign states its autonomous resolution inline.
+
+## Step 0.a: Check for unarchived changes (stop)
+
+Before proposing a new change, inspect `openspec/changes/` (ignore `openspec/changes/archive`).
+If any change folder exists in `openspec/changes/` (names vary by platform: `gh-*`, `us-*`, or a plain slug), list them in the question text, then call the `question` tool:
+
+```json
+{
+  "questions": [
+    {
+      "header": "Unarchived changes",
+      "question": "There are unarchived changes pending:\n{change-name}\n{change-name}\n...\n\nContinue with the proposal or stop to archive first?",
+      "options": [
+        { "label": "continue", "description": "Proceed with the proposal." },
+        { "label": "stop", "description": "End without generating a proposal. Archive the pending change first." }
+      ]
+    }
+  ]
+}
+```
+
+- If the user answers `stop`, end without generating a proposal.
+- If the user answers `continue`, proceed to the next step.
+
+Autonomous mode: do not call the `question` tool; treat the answer as `continue` and proceed.
+
+## Step 0.b: Load proposal skill
+
+If a work item URL or issue key is provided (GitHub Issue, Azure DevOps work item, Jira issue, or browser-based backlog): load `@pc-userstory` skill and fetch the work item before continuing. Backlog platform is set in `.opencode/harness.json` -> `platform.backlog`. If backlog platform is `none`, skip this step and work from direct input.
+
+## Step 1: Generate the proposal in memory
+
+Load `@openspec-propose` skill and follow its instructions to generate proposal.md, specs, and tasks.md. Do not write them to disk yet. Build the complete proposal content in your context.
+
+## Step 2: Enrich task assignments
+
+1. List every `*-engineer.md` file in `.opencode/agents/`. For each file read:
+   - `description:` from the YAML frontmatter: the engineer's specialization summary
+   - `## Abilities` section: the skills listed under Development, Testing, Infrastructure (e.g. `@nodejs-backend`, `@secure-nextjs-api-routes`)
+   Build a map of `agent-name -> { description, abilities }`.
+2. For each task, compare the task text and domain against every engineer's description AND abilities. Pick the engineer whose combined profile most closely matches. `fullstack-engineer` is `mode: primary` (the user's planning agent), not a spawned worker. If no specialist matches a task, leave the agent field blank and record the missing specialization in the proposal. An annotated OpenSpec task needs a real subagent; never substitute the lead or an obsolete generic agent name.
+3. Pick a tier, derive `depends_on`, derive `touches`, and annotate each task line. Follow the [task annotation](task-annotation.md) reference for the full tier selection guide, dependency derivation, touches derivation, and annotation format with examples.
+
+## Step 3: Show the plan and ask for confirmation (stop)
+
+Display the complete proposal to the user:
+- Change name and description
+- Total task count
+- Full task list with agent (including tier suffix) and dependency annotations
+
+Then call the `question` tool:
+
+```json
+{
+  "questions": [
+    {
+      "header": "Save proposal",
+      "question": "Save this proposal?",
+      "options": [
+        { "label": "yes", "description": "Write all files to disk and proceed." },
+        { "label": "edit", "description": "Provide feedback, revise in memory, show again." },
+        { "label": "stop", "description": "End without writing anything." }
+      ]
+    }
+  ]
+}
+```
+
+- `yes` -> proceed to Step 4 and write all files
+- `edit` -> user provides feedback, revise in memory, show again, ask again
+- `stop` -> end without writing anything
+
+Wait for the user's response. Do not proceed without a response.
+
+Autonomous mode: do not call the `question` tool; treat the answer as `yes` and write the files immediately.
+
+## Step 4: Write (only after the Step 3 checkpoint resolves)
+
+Write the proposal files to `openspec/changes/{change-slug}/`:
+- `proposal.md`: the change description and rationale
+- `specs/`: any spec files generated
+- `tasks.md`: the enriched task list with agent annotations
+
+## Step 5: Stop (stop)
+
+Call the `question` tool:
+
+```json
+{
+  "questions": [
+    {
+      "header": "Ready to implement",
+      "question": "Ready to implement?",
+      "options": [
+        { "label": "yes", "description": "Load the pc-plan-apply skill to start implementation." },
+        { "label": "no", "description": "Stop here. You can run /plan-apply later." }
+      ]
+    }
+  ]
+}
+```
+
+Loading `pc-plan-apply` requires explicit user confirmation.
+
+Autonomous mode: do not call the `question` tool. The PROPOSE stage is complete. Hand the change slug and task count back to the caller (the `/plan-goal` pipeline) so it immediately continues to the apply phase. This is a stage boundary, not the end of the run.

package/src/content/.agents/skills/pc-plan-propose/task-annotation.md

@@ -1,39 +1,39 @@
-# Task annotation reference
-
-## Tier selection
-
-Pick a tier for each task based on complexity:
-- `build`: complex code: data models, APIs, auth logic, core business logic, UI components
-- `fast`: light work: i18n keys, config changes, env variables, navigation links, simple markup, verification runs
-- `plan`: reserved for orchestration, do not use for implementation tasks
-
-The tier suffix is appended to the agent name with a dot (e.g. `backend-engineer.build`). This is the agent name you write in the annotation. The `pc-subagent-tiers` plugin resolves the model at startup from `models[<tier>]`.
-
-## depends_on
-
-Derive `depends_on` for each task: the OpenSpec task IDs (`N.M`) it logically needs completed first (a task that consumes another's output: UI needs its RPC, tests need the code, a seed needs its migration). Root tasks get `[]`. Reference the IDs OpenSpec already generated. Never invent new ones.
-
-## touches
-
-Derive `touches` for each task: the file path(s)/glob(s) it will create or modify (the task text usually names them, e.g. "Modify src/board/components/CreateForm.tsx"). This lets `pc-plan-apply` serialize same-file tasks that have no logical dependency. Include net-new files.
-
-## Annotation format
-
-Annotate each task line in-place with all three fields:
-
-```
-- [ ] <task text> <!-- agent: <name>, depends_on: [<ids>], touches: [<globs>] -->
-```
-
-Example result (note same-file tasks like 1.1/1.2 share `touches`, so `pc-plan-apply` runs them sequentially even with no `depends_on` between them; tier suffix encodes the model):
-
-```
-- [ ] 1.1 Add Project model to schema <!-- agent: backend-engineer.build, depends_on: [], touches: [src/types.ts] -->
-- [ ] 1.2 Add projectId field to LoopOptions <!-- agent: backend-engineer.build, depends_on: [], touches: [src/types.ts] -->
-- [ ] 2.1 Project RPC endpoints <!-- agent: backend-engineer.build, depends_on: [1.1], touches: [src/rpc/project/**] -->
-- [ ] 3.1 Accept page UI <!-- agent: frontend-engineer.build, depends_on: [2.1], touches: [src/board/components/CreateForm.tsx] -->
-- [ ] 3.2 i18n keys for invitation flow <!-- agent: frontend-engineer.fast, depends_on: [3.1], touches: [src/i18n/**] -->
-- [ ] 4.1 Run typecheck and fix errors <!-- agent: backend-engineer.fast, depends_on: [2.1,3.1], touches: [] -->
-```
-
-`pc-plan-apply` reads these annotations to build conflict-free waves: `depends_on` gates ordering, `touches` keeps concurrent agents file-disjoint, and the tier suffix in `agent` determines the model (resolved at startup by the `pc-subagent-tiers` plugin). `depends_on` is mandatory; `touches` is a best-effort hint.
+# Task annotation reference
+
+## Tier selection
+
+Pick a tier for each task based on complexity:
+- `build`: complex code: data models, APIs, auth logic, core business logic, UI components
+- `fast`: light work: i18n keys, config changes, env variables, navigation links, simple markup, verification runs
+- `plan`: reserved for orchestration, do not use for implementation tasks
+
+The tier suffix is appended to the agent name with a dot (e.g. `backend-engineer.build`). This is the agent name you write in the annotation. The `pc-subagent-tiers` plugin resolves the model at startup from `models[<tier>]`.
+
+## depends_on
+
+Derive `depends_on` for each task: the OpenSpec task IDs (`N.M`) it logically needs completed first (a task that consumes another's output: UI needs its RPC, tests need the code, a seed needs its migration). Root tasks get `[]`. Reference the IDs OpenSpec already generated. Never invent new ones.
+
+## touches
+
+Derive `touches` for each task: the file path(s)/glob(s) it will create or modify (the task text usually names them, e.g. "Modify src/board/components/CreateForm.tsx"). This lets `pc-plan-apply` serialize same-file tasks that have no logical dependency. Include net-new files.
+
+## Annotation format
+
+Annotate each task line in-place with all three fields:
+
+```
+- [ ] <task text> <!-- agent: <name>, depends_on: [<ids>], touches: [<globs>] -->
+```
+
+Example result (note same-file tasks like 1.1/1.2 share `touches`, so `pc-plan-apply` runs them sequentially even with no `depends_on` between them; tier suffix encodes the model):
+
+```
+- [ ] 1.1 Add Project model to schema <!-- agent: backend-engineer.build, depends_on: [], touches: [src/types.ts] -->
+- [ ] 1.2 Add projectId field to LoopOptions <!-- agent: backend-engineer.build, depends_on: [], touches: [src/types.ts] -->
+- [ ] 2.1 Project RPC endpoints <!-- agent: backend-engineer.build, depends_on: [1.1], touches: [src/rpc/project/**] -->
+- [ ] 3.1 Accept page UI <!-- agent: frontend-engineer.build, depends_on: [2.1], touches: [src/board/components/CreateForm.tsx] -->
+- [ ] 3.2 i18n keys for invitation flow <!-- agent: frontend-engineer.fast, depends_on: [3.1], touches: [src/i18n/**] -->
+- [ ] 4.1 Run typecheck and fix errors <!-- agent: backend-engineer.fast, depends_on: [2.1,3.1], touches: [] -->
+```
+
+`pc-plan-apply` reads these annotations to build conflict-free waves: `depends_on` gates ordering, `touches` keeps concurrent agents file-disjoint, and the tier suffix in `agent` determines the model (resolved at startup by the `pc-subagent-tiers` plugin). `depends_on` is mandatory; `touches` is a best-effort hint.

package/src/content/.agents/skills/pc-plan-quick/SKILL.md

@@ -1,62 +1,62 @@
----
-name: pc-plan-quick
-description: Quick plan: analyze the codebase and create a task checklist using the Todo pane. No files, no OpenSpec. Invoked by the /plan-quick command.
-license: MIT
----
-
-This command is strictly read-only. You may read files, search code, and use `todowrite` to create Todo pane items. You MUST NOT write, edit, or create any file. After completing the checklist and asking the user what's next, if the user continues chatting without invoking a new command (e.g. `/plan-apply`) or explicitly requesting implementation, remain read-only. The only output of this command is the Todo pane checklist and a question to the user.
-
-Lightweight planning for focused changes. Reads the codebase, creates a task checklist in the Todo pane using `todowrite`, and stops. This is a thinking tool, not a file writer.
-
-When to use this instead of `/plan-explore` then `/plan-propose`:
-- The task is clear and well-scoped (not a half-formed idea)
-- You don't need to think through alternatives or investigate deeply
-- You want a task list in under a minute, not a full proposal
-
-## Step 1: Understand the task
-
-Read the user's description. Use `glob` and `grep` to locate the relevant files, components, and patterns in the codebase. Read the key files to understand what exists and what needs to change.
-
-## Step 2: Create the plan in the Todo pane
-
-Use `todowrite` to create one todo item per task. Each item must be:
-
-- Concrete and actionable: include file paths or areas in the task text when possible
-- Ordered by logical dependency: dependencies first
-- Granular: one clear action per item, not a bundle
-
-Example `todowrite` call:
-
-```json
-{
-  "todos": [
-    { "content": "Add Project model to src/types.ts", "status": "pending", "priority": "high" },
-    { "content": "Add projectId field to LoopOptions in src/types.ts", "status": "pending", "priority": "high" },
-    { "content": "Create Project RPC endpoints in src/rpc/project/", "status": "pending", "priority": "medium" },
-    { "content": "Build Accept page UI in src/board/components/CreateForm.tsx", "status": "pending", "priority": "medium" },
-    { "content": "Run typecheck and fix errors", "status": "pending", "priority": "low" }
-  ]
-}
-```
-
-## Step 3: Ask what's next
-
-Call the `question` tool:
-
-```json
-{
-  "questions": [
-    {
-      "header": "What next",
-      "question": "What next?",
-      "options": [
-        { "label": "/plan-apply", "description": "Implement these tasks now (creates a feature branch and works through them)." },
-        { "label": "/plan-propose", "description": "Turn this into a full OpenSpec proposal with agent assignments." },
-        { "label": "Start on specific tasks", "description": "Tell me which tasks to start on." }
-      ]
-    }
-  ]
-}
-```
-
-Do not create any files. Do not run `/plan-apply` or `/plan-propose` automatically. The only output is the Todo pane checklist.
+---
+name: pc-plan-quick
+description: Quick plan: analyze the codebase and create a task checklist using the Todo pane. No files, no OpenSpec. Invoked by the /plan-quick command.
+license: MIT
+---
+
+This command is strictly read-only. You may read files, search code, and use `todowrite` to create Todo pane items. You MUST NOT write, edit, or create any file. After completing the checklist and asking the user what's next, if the user continues chatting without invoking a new command (e.g. `/plan-apply`) or explicitly requesting implementation, remain read-only. The only output of this command is the Todo pane checklist and a question to the user.
+
+Lightweight planning for focused changes. Reads the codebase, creates a task checklist in the Todo pane using `todowrite`, and stops. This is a thinking tool, not a file writer.
+
+When to use this instead of `/plan-explore` then `/plan-propose`:
+- The task is clear and well-scoped (not a half-formed idea)
+- You don't need to think through alternatives or investigate deeply
+- You want a task list in under a minute, not a full proposal
+
+## Step 1: Understand the task
+
+Read the user's description. Use `glob` and `grep` to locate the relevant files, components, and patterns in the codebase. Read the key files to understand what exists and what needs to change.
+
+## Step 2: Create the plan in the Todo pane
+
+Use `todowrite` to create one todo item per task. Each item must be:
+
+- Concrete and actionable: include file paths or areas in the task text when possible
+- Ordered by logical dependency: dependencies first
+- Granular: one clear action per item, not a bundle
+
+Example `todowrite` call:
+
+```json
+{
+  "todos": [
+    { "content": "Add Project model to src/types.ts", "status": "pending", "priority": "high" },
+    { "content": "Add projectId field to LoopOptions in src/types.ts", "status": "pending", "priority": "high" },
+    { "content": "Create Project RPC endpoints in src/rpc/project/", "status": "pending", "priority": "medium" },
+    { "content": "Build Accept page UI in src/board/components/CreateForm.tsx", "status": "pending", "priority": "medium" },
+    { "content": "Run typecheck and fix errors", "status": "pending", "priority": "low" }
+  ]
+}
+```
+
+## Step 3: Ask what's next
+
+Call the `question` tool:
+
+```json
+{
+  "questions": [
+    {
+      "header": "What next",
+      "question": "What next?",
+      "options": [
+        { "label": "/plan-apply", "description": "Implement these tasks now (creates a feature branch and works through them)." },
+        { "label": "/plan-propose", "description": "Turn this into a full OpenSpec proposal with agent assignments." },
+        { "label": "Start on specific tasks", "description": "Tell me which tasks to start on." }
+      ]
+    }
+  ]
+}
+```
+
+Do not create any files. Do not run `/plan-apply` or `/plan-propose` automatically. The only output is the Todo pane checklist.