@plainconceptsplatform/agent-harness 3.4.1 → 3.5.0

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

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

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

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

package/skills/pc-userstory-az/SKILL.md

@@ -1,71 +1,71 @@
----
-name: pc-userstory
-description: Parse Azure DevOps user story URL and create OpenSpec change. Use when user provides an Azure DevOps URL.
-license: MIT
-compatibility: Requires openspec CLI and Azure CLI.
-metadata:
-  author: copilots
-  version: "3.1"
----
-
-Turn an Azure DevOps work item URL into an OpenSpec change, then hand the change to `pc-plan-propose`.
-
-## Rules
-
-- Work item data comes from `az`, never from a page fetch or a browser (denied by `pc-system-reminders`). An `az` that cannot reach the org is a blocker to report.
-- Never load `pc-plan-apply` until the user has said yes.
-
-## Contracts
-
-The ID is in the URL: `?workitem=193208` or `/workitems/edit/193208` both give `193208`.
-
-```bash
-az boards work-item show --id 193208
-```
-
-That relies on the configured defaults, which is the one piece of setup this skill needs:
-
-```bash
-az devops configure --defaults organization=https://dev.azure.com/{org} project={project}
-```
-
-Without them every command needs `--organization`. A PAT with Work Items (Read and Write) and Code (Read and Write) comes from `https://dev.azure.com/{org}/_usersSettings/tokens`.
-
-From the JSON take `fields.System.Title`, `fields.System.Description` (often HTML, strip the tags), `fields.System.WorkItemType`, `fields.System.IterationPath`, `fields.System.State` and `fields.System.AcceptanceCriteria` when it is there.
-
-```bash
-openspec new change "us-{id}-{slug}"
-```
-
-Screenshots live in the change folder, `openspec/changes/{change-name}/images/{name}.png`. Embedding one uses the `_apis/git/repositories` URL, since `_git/` returns HTML: `https://dev.azure.com/{org}/{project}/_apis/git/repositories/{repo}/items?path=openspec/changes/{change}/images/{file}.png&versionType=branch&version={branch}&api-version=7.1`
-
-Report:
-
-```
-## User Story Parsed
-
-Work Item: #{id}
-Title: {title}
-Type: User Story
-Iteration: {sprint}
-State: {state}
-
-Change Created: us-{id}-{slug}
-```
-
-Then load `pc-plan-propose` (interactive) and, once it returns, ask:
-
-```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." }
-      ]
-    }
-  ]
-}
-```
+---
+name: pc-userstory
+description: Parse Azure DevOps user story URL and create OpenSpec change. Use when user provides an Azure DevOps URL.
+license: MIT
+compatibility: Requires openspec CLI and Azure CLI.
+metadata:
+  author: copilots
+  version: "3.1"
+---
+
+Turn an Azure DevOps work item URL into an OpenSpec change, then hand the change to `pc-plan-propose`.
+
+## Rules
+
+- Work item data comes from `az`, never from a page fetch or a browser (denied by `pc-system-reminders`). An `az` that cannot reach the org is a blocker to report.
+- Never load `pc-plan-apply` until the user has said yes.
+
+## Contracts
+
+The ID is in the URL: `?workitem=193208` or `/workitems/edit/193208` both give `193208`.
+
+```bash
+az boards work-item show --id 193208
+```
+
+That relies on the configured defaults, which is the one piece of setup this skill needs:
+
+```bash
+az devops configure --defaults organization=https://dev.azure.com/{org} project={project}
+```
+
+Without them every command needs `--organization`. A PAT with Work Items (Read and Write) and Code (Read and Write) comes from `https://dev.azure.com/{org}/_usersSettings/tokens`.
+
+From the JSON take `fields.System.Title`, `fields.System.Description` (often HTML, strip the tags), `fields.System.WorkItemType`, `fields.System.IterationPath`, `fields.System.State` and `fields.System.AcceptanceCriteria` when it is there.
+
+```bash
+openspec new change "us-{id}-{slug}"
+```
+
+Screenshots live in the change folder, `openspec/changes/{change-name}/images/{name}.png`. Embedding one uses the `_apis/git/repositories` URL, since `_git/` returns HTML: `https://dev.azure.com/{org}/{project}/_apis/git/repositories/{repo}/items?path=openspec/changes/{change}/images/{file}.png&versionType=branch&version={branch}&api-version=7.1`
+
+Report:
+
+```
+## User Story Parsed
+
+Work Item: #{id}
+Title: {title}
+Type: User Story
+Iteration: {sprint}
+State: {state}
+
+Change Created: us-{id}-{slug}
+```
+
+Then load `pc-plan-propose` (interactive) and, once it returns, ask:
+
+```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." }
+      ]
+    }
+  ]
+}
+```

package/skills/pc-userstory-browser/SKILL.md

@@ -1,64 +1,64 @@
----
-name: pc-userstory
-description: Parse work item from any URL using browser automation. Use when user provides a URL that doesn't match GitHub/Azure/Jira CLI platforms, or when backlog platform is 'browser'.
-license: MIT
-compatibility: Requires agent-browser CLI installed and openspec CLI.
-metadata:
-  author: copilots
-  version: "2.0"
----
-
-Read a work item off its own web page, for a backlog with no CLI, then hand the change to `pc-plan-propose`. This is the fallback: a GitHub, Azure DevOps or Jira URL belongs to the CLI skill for that platform, which is faster and cannot misread a page.
-
-Browser is a backlog-only platform. Shipping runs on whichever repo platform the project configured.
-
-## Rules
-
-- Navigate only to a URL the user gave you. This skill is the one exception to `browser-automation`'s ban on leaving localhost, and it is that narrow on purpose: a work-item page is behind the user's own login, and anything else reachable from it is too.
-- Read only. No clicking, no status changes, nothing written back to the tracker.
-- Always reuse the `backlog` session so the login survives; a login page instead of the work item means the session is not authenticated, and the user has to log in manually in the opened window before a retry.
-
-## Contracts
-
-`agent-browser` runs its own Chrome, not the user's daily browser, and keeps state per session:
-
-```bash
-agent-browser --session backlog --restore open "https://the-url-the-user-provided"
-agent-browser wait --load networkidle
-agent-browser snapshot
-```
-
-`agent-browser doctor` verifies the install. The accessibility tree from `snapshot` locates fields more reliably than page text; `agent-browser read` and `agent-browser get text "h1"` fill the gaps, and `agent-browser get url` confirms the page did not navigate away. A single-page app that renders after idle needs a second wait (`--text "<known heading>"` when a stable string exists) and a fresh snapshot, not a sleep.
-
-Take the title, description with its acceptance criteria or definition of done, the ID from the URL or the page, and status, assignee, priority and labels when they are visible. Where to look, by tool:
-
-| Tool | Work item URL | Title | Description |
-|---|---|---|---|
-| Azure DevOps | `/_workitems/edit/{id}` | header | "Description" and "Acceptance Criteria" sections |
-| Linear | `/{team}/issue/{key}` | issue title | issue body |
-| Jira | `/browse/{key}` | summary | description field |
-| Trello | `/c/{short-id}` | card title | card description |
-| Anything else | as given | `<h1>` or page title | main content area |
-
-Then create the change, whose `proposal.md` names the source URL and the work item ID:
-
-```bash
-openspec new change "{slug-from-title}"
-```
-
-Load `pc-plan-propose` (interactive) and, once it returns, ask:
-
-```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." }
-      ]
-    }
-  ]
-}
-```
+---
+name: pc-userstory
+description: Parse work item from any URL using browser automation. Use when user provides a URL that doesn't match GitHub/Azure/Jira CLI platforms, or when backlog platform is 'browser'.
+license: MIT
+compatibility: Requires agent-browser CLI installed and openspec CLI.
+metadata:
+  author: copilots
+  version: "2.0"
+---
+
+Read a work item off its own web page, for a backlog with no CLI, then hand the change to `pc-plan-propose`. This is the fallback: a GitHub, Azure DevOps or Jira URL belongs to the CLI skill for that platform, which is faster and cannot misread a page.
+
+Browser is a backlog-only platform. Shipping runs on whichever repo platform the project configured.
+
+## Rules
+
+- Navigate only to a URL the user gave you. This skill is the one exception to `browser-automation`'s ban on leaving localhost, and it is that narrow on purpose: a work-item page is behind the user's own login, and anything else reachable from it is too.
+- Read only. No clicking, no status changes, nothing written back to the tracker.
+- Always reuse the `backlog` session so the login survives; a login page instead of the work item means the session is not authenticated, and the user has to log in manually in the opened window before a retry.
+
+## Contracts
+
+`agent-browser` runs its own Chrome, not the user's daily browser, and keeps state per session:
+
+```bash
+agent-browser --session backlog --restore open "https://the-url-the-user-provided"
+agent-browser wait --load networkidle
+agent-browser snapshot
+```
+
+`agent-browser doctor` verifies the install. The accessibility tree from `snapshot` locates fields more reliably than page text; `agent-browser read` and `agent-browser get text "h1"` fill the gaps, and `agent-browser get url` confirms the page did not navigate away. A single-page app that renders after idle needs a second wait (`--text "<known heading>"` when a stable string exists) and a fresh snapshot, not a sleep.
+
+Take the title, description with its acceptance criteria or definition of done, the ID from the URL or the page, and status, assignee, priority and labels when they are visible. Where to look, by tool:
+
+| Tool | Work item URL | Title | Description |
+|---|---|---|---|
+| Azure DevOps | `/_workitems/edit/{id}` | header | "Description" and "Acceptance Criteria" sections |
+| Linear | `/{team}/issue/{key}` | issue title | issue body |
+| Jira | `/browse/{key}` | summary | description field |
+| Trello | `/c/{short-id}` | card title | card description |
+| Anything else | as given | `<h1>` or page title | main content area |
+
+Then create the change, whose `proposal.md` names the source URL and the work item ID:
+
+```bash
+openspec new change "{slug-from-title}"
+```
+
+Load `pc-plan-propose` (interactive) and, once it returns, ask:
+
+```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." }
+      ]
+    }
+  ]
+}
+```