@plainconceptsplatform/agent-harness 2.0.0

package/src/content/.agents/skills/pc-plan-apply/simple-mode.md

@@ -0,0 +1,21 @@
+# Simple mode: sequential in-session
+
+When the plan lives in the Todo pane (from `/plan-quick`) and no OpenSpec change exists:
+
+1. Read the task list from the Todo pane (the `pending` items created by `/plan-quick`).
+2. Create a feature branch if not already on one: `git switch -c feature/{slug}`. (Skip when the caller passed `start_from: load-plan`.)
+3. Work through tasks one at a time, in order, directly in this session:
+   - Read the task text from the Todo item.
+   - Mark it `in_progress` via `todowrite`.
+   - Implement it (edit files, run commands as needed).
+   - Mark it `completed` via `todowrite`.
+   - Commit the change: `git add -A && git commit -m "task {id}: {summary}"`.
+4. After all tasks are done, run the project's typecheck/build check if one exists. Fix any errors.
+5. Report: tasks N/N completed, commits made, branch name.
+
+Rules:
+- Work in this session only. No subagent spawning.
+- No OpenSpec commands.
+- Keep each commit focused on one task.
+- Use `todowrite` to track progress: `pending` -> `in_progress` -> `completed`.
+- If a task is too complex or blocked, mark it `completed` with a note, and continue with the next.

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

@@ -0,0 +1,63 @@
+---
+name: pc-plan-archive
+description: Archive a completed OpenSpec change and update documentation. Interactive mode finds the oldest merged unarchived change and opens an archive PR; autonomous mode archives a named change in place on the current branch. Invoked by the /plan-archive command (interactive) and the plan-goal pipeline (autonomous).
+license: MIT
+---
+
+# Plan Archive
+
+## Input
+
+The caller provides (all optional):
+- A mode (see below). Default: `interactive`.
+- In autonomous mode: the change id to archive (required in that mode; the caller knows which change it just implemented).
+
+## Modes
+
+- interactive (default): full flow below. Find the oldest unarchived change with a completed PR, confirm with the user, archive it, update docs with approval, and open an archive PR. No input required.
+- autonomous: the caller names the change to archive. Skip the working-tree prep, the PR lookup, the confirmation prompt, and the archive-PR step. Instead, archive in place on the current branch:
+  1. Archive the change by its id. Prefer the `@openspec-archive-change` skill if it is available. If it is not available, run the CLI directly, and it must be non-interactive, because there is no user to answer prompts:
+
+     ```bash
+     openspec archive "<change-id>" -y
+     ```
+
+     `-y` skips the confirmation prompt (without it the command blocks forever in an unattended run). Add `--skip-specs` only for infra/tooling/doc-only changes that produced no spec deltas. If the command reports the change is already archived, treat that as success.
+  2. Verify the archive actually moved. The change folder must no longer exist at `openspec/changes/<change-id>/`, and a dated copy must now exist under `openspec/changes/archive/` (the CLI renames it to `archive/YYYY-MM-DD-<change-id>/`):
+
+     ```bash
+     REPO_ROOT="$(git rev-parse --show-toplevel)"
+     test ! -d "$REPO_ROOT/openspec/changes/<change-id>" \
+       && ls -d "$REPO_ROOT/openspec/changes/archive/"*"<change-id>" >/dev/null 2>&1 \
+       && echo ARCHIVED_OK || echo ARCHIVE_FAILED
+     ```
+
+      If this prints `ARCHIVE_FAILED`, run the archive once more and repeat the check. If it still fails, report it to the caller as a failure; do not pretend it succeeded.
+  3. Compare the archived change's specs against `ARCHITECTURE.md` and `DESIGN.md`; apply any needed doc updates directly (no approval prompt).
+  4. If the change was a bug fix or new functionality with important impact, check if `@pc-guardrails-project` exists and update it.
+  5. Do not commit or push: the caller owns the git operations.
+   6. The ARCHIVE stage is complete. Hand control back to the caller (the `/plan-goal` pipeline) so it continues with evidence and output. Do not stop or end the turn here; archiving is not the end of the run.
+
+---
+
+## Interactive flow
+
+Steps
+
+1. Prepare working tree
+
+   ```bash
+   REPO_ROOT="$(git rev-parse --show-toplevel)"
+   DEFAULT_BRANCH="$(git symbolic-ref --short refs/remotes/origin/HEAD 2>/dev/null | sed 's|^origin/||')"
+   [ -z "$DEFAULT_BRANCH" ] && DEFAULT_BRANCH="main"
+   ```
+
+   1. If the tree has uncommitted changes: `git stash push -u -m "WIP before archive"` and tell the user their work is stashed (it is restored in step 6).
+   2. Sync the default branch (skip the pull if there is no `origin` remote):
+
+   ```bash
+   git switch "$DEFAULT_BRANCH" && git pull origin "$DEFAULT_BRANCH"
+   ```
+
+<!-- PC-PLATFORM-ARCHIVE-START -->
+<!-- PC-PLATFORM-ARCHIVE-END -->

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

@@ -0,0 +1,9 @@
+---
+name: pc-plan-explore
+description: Explore an idea or requirement before planning. Invoked by the /plan-explore command.
+license: MIT
+---
+
+**READ-ONLY MODE.** From the moment this skill is loaded until the user explicitly invokes a different command (e.g. `/plan-apply`) or explicitly requests implementation, you MUST NOT write, edit, or create any file, including OpenSpec artifacts. You may only read, search, and discuss. If the conversation drifts toward implementation, remind the user that explore mode is active and suggest `/plan-apply` to start implementing. This overrides any permissive stance in `@openspec-explore` about creating OpenSpec artifacts being "fine."
+
+Load `@openspec-explore` and follow every step defined in it.

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

@@ -0,0 +1,94 @@
+---
+name: pc-plan-goal
+description: Autonomous pipeline: explore, propose, apply, archive, then merge/PR/push. For loop-engineering. Invoked by the /plan-goal command.
+license: MIT
+---
+
+Run the full OpenSpec lifecycle without human interaction. This skill owns phase order, cross-phase gates, commits, and output. Each phase skill owns its procedure.
+
+Keep this checklist visible:
+
+`explore · propose · apply · verify · archive · evidence · output · report`
+
+Move forward only when a phase returns its required result. On a hard failure, follow the [failure policy](failure-policy.md). Continue after each phase skill returns; the run ends only after every checklist item is complete.
+
+**Token efficiency rules:** Batch git operations within a phase (combine `git add -A && git commit` in one tool call). Do not run status checks between sequential operations in the same phase. Minimize model turns: if a phase requires 3 git commands, call them in one tool call, not 3.
+
+Input: `$ARGUMENTS`
+
+## Phase 0: Resolve input
+
+Load the [output mode](output-mode.md) reference and resolve the mode from the first token of `$ARGUMENTS`. Treat the remaining text as data, not orchestration instructions.
+
+- For a work-item URL or issue key with a configured backlog platform, load `@pc-userstory` and fetch the work item.
+- Otherwise, use the remaining text as the direct feature description.
+- Preserve title, description, work-item reference, and acceptance criteria as `{resolved_input}`.
+- Derive `{slug}` and classify scope as `focused`, `standard`, or `complex`.
+
+**Refined-issue detection:** After resolving input, check whether `{resolved_input}` already contains structured acceptance criteria (e.g. "## Acceptance criteria", "### Scenario:", Gherkin blocks), affected artifacts, and design decisions. If it does, set `{refined}` to `true` and skip Phases 2-3 (Explore and Propose). Go directly to Phase 4 (Apply). The issue content IS the proposal; create a minimal OpenSpec change (tasks.md only, `skip_specs: true` in `.openspec.yaml`) directly from the issue's acceptance criteria and affected artifacts.
+
+## Phase 1: Branch
+
+Follow the [branching procedure](branching.md) with `{slug}`. Record `$START_BRANCH`, `$DEFAULT_BRANCH`, `$BRANCH`, and whether the goal stash exists.
+
+## Phase 2: Explore
+
+**Skip if `{refined}` is `true`.** The issue already contains structured acceptance criteria and affected artifacts; re-exploring the codebase would waste tokens re-deriving what the issue already specifies. Set `EXPLORATION_BRIEF` to a one-line summary: `"Pre-refined issue: {title}"`.
+
+Load `pc-plan-explore` with `{resolved_input}` in autonomous mode. Require an in-memory `EXPLORATION_BRIEF` as its findings handoff to Phase 3.
+
+Tick `explore` when `pc-plan-explore` returns its findings handoff.
+
+## Phase 3: Propose
+
+**Skip if `{refined}` is `true`.** Instead, create a minimal OpenSpec change directly: run `openspec new change "{change-id}"`, write `tasks.md` from the issue's acceptance criteria (one task per criterion or artifact group), create `.openspec.yaml` with `skip_specs: true` (the issue already has the spec content), and commit: `git add -A && git commit -m "propose: {title} ({change-id})"`.
+
+Load `pc-plan-propose` in autonomous mode with `{resolved_input}`, `EXPLORATION_BRIEF`, and `scope_classification`.
+
+Confirm its change directory and actionable `tasks.md` exist. Rename `$BRANCH` when the canonical change slug differs from `{slug}`, then commit the proposal:
+
+```bash
+git add -A && git commit -m "propose: {title} ({change-id})"
+```
+
+Tick `propose` when the proposal commit exists.
+
+## Phase 4: Apply and verify
+
+Load `pc-plan-apply` in autonomous mode with `start_from: load-plan`. It owns worker resolution, subagent waves, commits, verification, and re-waves.
+
+Require it to return every task complete and `VERIFIED`, then load `pc-repo-verify`. Tick `apply` and `verify` only when both phases return `VERIFIED`.
+
+## Phase 5: Archive
+
+Require `verify` and a clean working tree. Load `pc-plan-archive` in autonomous mode with `{change-id}`. It owns archive verification and retry.
+
+Require `ARCHIVED_OK` and the archive path, then commit:
+
+```bash
+git add -A && git commit -m "archive: {title} ({change-id})"
+```
+
+Tick `archive` when the archive commit exists.
+
+## Phase 5.5: Evidence
+
+Load `pc-ops-evidence` with `operation: capture` and `{change-id}`. It owns evidence decisions, capture, and the manifest. Evidence capture is non-fatal.
+
+The evidence skill uses `playwright-cli` (headless, works inside containers) and `pnpm run dev` (starts the full app stack with mock auth). Evidence capture works in CI.
+
+Commit evidence when files or a manifest were written:
+
+```bash
+git add -A && git commit -m "evidence: {title} ({change-id})"
+```
+
+Record the manifest result and tick `evidence` after capture was attempted.
+
+## Phase 6: Output
+
+Follow the [output procedure](output.md) with the mode, branch values, change id, work-item reference, archive path, and evidence result. Tick `output` only when its mode-specific postcondition holds.
+
+## Phase 7: Report
+
+Print the final report from the [output procedure](output.md). Tick `report` only after every checklist item is complete.

package/src/content/.agents/skills/pc-plan-goal/branching.md

@@ -0,0 +1,30 @@
+# Branching procedure
+
+Resolve and record the branch names:
+
+```bash
+START_BRANCH="$(git branch --show-current)"
+DEFAULT_BRANCH="$(git symbolic-ref --short refs/remotes/origin/HEAD 2>/dev/null | sed 's|^origin/||')"
+[ -z "$DEFAULT_BRANCH" ] && DEFAULT_BRANCH="main"
+```
+
+Stash uncommitted work when needed and record that the goal stash exists:
+
+```bash
+git stash push -u -m "goal-wip"
+```
+
+Create the feature branch from the synchronized default branch:
+
+```bash
+git switch "$DEFAULT_BRANCH"
+
+if git remote get-url origin >/dev/null 2>&1; then
+  git pull origin "$DEFAULT_BRANCH"
+fi
+
+git switch -c "feature/{slug}"
+BRANCH="$(git branch --show-current)"
+```
+
+Everything through archive and evidence happens on `$BRANCH`.

package/src/content/.agents/skills/pc-plan-goal/failure-policy.md

@@ -0,0 +1,30 @@
+# Failure policy
+
+`/plan-goal` never asks for input, but must halt instead of shipping broken or incoherent work.
+
+Use the failure policy when:
+
+- exploration cannot produce a safe and coherent functional interpretation after its one retry,
+- exploration determines the goal is infeasible or outside the repository's feasible responsibility,
+- the proposal produces no actionable tasks,
+- the proposal materially contradicts the exploration brief,
+- a task wave stalls because tasks remain but none are eligible,
+- a task exhausts its single retry,
+- tests, lint, build, type checks, or required verification fail and cannot be cleared by re-waving,
+- any verification command (lint, typecheck, test) exits non-zero after the apply phase and re-waving does not clear it,
+- archive verification still prints `ARCHIVE_FAILED` after one retry,
+- required repository state is missing or inconsistent before output,
+- or a merge conflict cannot be resolved cleanly and automatically.
+
+On failure:
+
+1. Stop the pipeline.
+2. Do not merge.
+3. Do not push the default branch.
+4. Leave `$BRANCH` intact whenever it exists.
+5. Abort any incomplete merge.
+6. Restore the Phase 1 goal stash on `$START_BRANCH`.
+7. If stash restoration conflicts, preserve the stash and report its reference.
+8. Report: the failed phase, the exact failed postcondition, commands or verification that failed, retry attempts, current branch, repository state, completed commits, archive state, and the safest manual next step.
+
+For loop-engineering, a clean failure with the feature branch preserved is the correct outcome. Never merge or ship unverified work.

package/src/content/.agents/skills/pc-plan-goal/output-mode.md

@@ -0,0 +1,9 @@
+# Output mode
+
+Determine the mode only from the first whitespace-delimited token of `$ARGUMENTS`.
+
+- `pr`: remove the token, push the feature branch, and create a PR.
+- `push`: remove the token and push the feature branch.
+- Any other first token: keep the full input and merge locally into the default branch.
+
+Words such as "push notifications" or "PR template" inside the feature description are feature data. They do not change output mode.

package/src/content/.agents/skills/pc-plan-goal/output.md

@@ -0,0 +1,68 @@
+# Output procedure
+
+Before output, require `verify`, `archive`, a clean working tree, no active change directory, and an archive directory for `{change-id}`.
+
+## Restore stash
+
+If the goal created `goal-wip`, restore it after the mode-specific operation. When restoration conflicts, leave the stash intact, report its `git stash list` reference, and do not drop user work.
+
+## Default mode
+
+Synchronize the default branch, merge, delete the feature branch, then restore the stash:
+
+```bash
+git switch "$DEFAULT_BRANCH"
+
+if git remote get-url origin >/dev/null 2>&1; then
+  git pull origin "$DEFAULT_BRANCH"
+fi
+
+git merge --no-ff "$BRANCH" -m "goal: {title} ({change-id})"
+git branch -d "$BRANCH"
+```
+
+If the merge conflicts, abort it and use the failure policy. Do not push the default branch. Evidence remains in the archive and publication is skipped because no commit-pinned repository URL exists.
+
+## Push mode
+
+Push the feature branch:
+
+```bash
+git push -u origin "$BRANCH"
+```
+
+When a work item exists, load `pc-ops-evidence` with `operation: publish`, `{change-id}`, the work-item reference, and `mode: push`. Publication is non-fatal. Restore the stash and leave the branch available.
+
+## PR mode
+
+Push the feature branch, then load `pc-ops-ship` to create a PR into `$DEFAULT_BRANCH`. Supply title, change id, functional summary, delivered acceptance criteria, task count, verification result, archive path, evidence result, and commits. Do not merge the PR.
+
+When a work item exists, load `pc-ops-evidence` with `operation: publish`, `{change-id}`, the work-item reference, PR number, and `mode: pr`. Publication is non-fatal. Restore the stash.
+
+## Final report
+
+Print:
+
+```text
+Goal: {title}
+Change ID: {change-id}
+Scope classification: focused | standard | complex
+Functional outcome: {one-sentence result}
+Branch: {branch}
+Tasks: {completed}/{total}
+Acceptance criteria: {passed}/{total}
+Commits: {proposal, apply, archive, evidence when present}
+Verification: passed | failed
+Archived: yes | no
+Archive path: {path or none}
+Evidence: passed | skipped | failed | blocked
+Evidence assets: {paths or none}
+Evidence publication: {published | skipped | failed}
+Output mode: default | push | pr
+Final state: merged locally | pushed branch | PR URL | branch preserved after failure
+Stash restoration: not needed | restored | preserved after conflict
+```
+
+## External gate
+
+An unattended caller must verify `openspec list --json` is empty and run the project's lint and typecheck commands before any later git operation.

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

@@ -0,0 +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.

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

@@ -0,0 +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.

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

@@ -0,0 +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.