@plainconceptsplatform/agent-harness 2.4.1 → 2.5.1
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 +435 -437
- package/cli/fragments/archive/az.md +97 -95
- package/cli/fragments/archive/gh.md +96 -94
- package/cli/fragments/archive/gl.md +96 -94
- package/cli/fragments/archive/none.md +75 -73
- package/cli/fragments/guardrails/codegraph.md +5 -7
- package/cli/fragments/guardrails/humanizer.md +4 -4
- package/cli/fragments/guardrails/memory.md +4 -4
- package/cli/fragments/guardrails/rtk.md +3 -3
- package/cli/fragments/guardrails/simple-english.md +4 -4
- package/cli/fragments/ops-backlog/az.md +1 -1
- package/cli/fragments/ops-backlog/gh.md +1 -1
- package/cli/fragments/ops-backlog/jira.md +1 -1
- package/cli/fragments/ops-evidence/az.md +44 -41
- package/cli/fragments/ops-evidence/gh.md +54 -53
- package/cli/fragments/ops-evidence/jira.md +42 -38
- package/cli/fragments/ops-review/az.md +1 -1
- package/cli/fragments/ops-review/gh.md +1 -1
- package/cli/fragments/ops-review/gl.md +1 -1
- package/cli/fragments/ops-ship/az.md +81 -80
- package/cli/fragments/ops-ship/gh.md +68 -68
- package/cli/fragments/ops-ship/gl.md +85 -85
- package/cli/presets/agents-content.json +34 -53
- package/cli/steps/copy/agents.js +18 -17
- package/cli/steps/copy/opencode-json.js +5 -1
- package/cli/steps/copy/skills.js +98 -5
- package/cli/steps/optimization/patch-guardrails.js +5 -3
- package/cli/utils/copy.js +27 -3
- package/cli/utils/update-manifest.js +28 -2
- package/harness/.agents/skills/pc-guardrails-generic/SKILL.md +47 -68
- package/harness/.agents/skills/pc-make-architecture/SKILL.md +31 -51
- package/harness/.agents/skills/pc-make-design/SKILL.md +45 -68
- package/harness/.agents/skills/pc-make-engineer/SKILL.md +59 -219
- package/harness/.agents/skills/pc-make-engineer/signal-mapping.md +53 -68
- package/harness/.agents/skills/pc-make-engineer/template.md +42 -80
- package/harness/.agents/skills/pc-make-evidence-scaffold/SKILL.md +18 -18
- package/harness/.agents/skills/pc-make-evidence-scaffold/evidence-contract.md +29 -29
- package/harness/.agents/skills/pc-make-guardrails/SKILL.md +43 -74
- package/harness/.agents/skills/pc-make-guardrails/category-reference.md +10 -5
- package/harness/.agents/skills/pc-make-merge-risk-assess/category-reference.md +26 -7
- package/harness/.agents/skills/pc-make-user-model/SKILL.md +56 -66
- package/harness/.agents/skills/pc-ops-evidence/SKILL.md +133 -127
- package/harness/.agents/skills/pc-plan-apply/SKILL.md +14 -5
- package/harness/.agents/skills/pc-plan-apply/simple-mode.md +21 -21
- package/harness/.agents/skills/pc-plan-archive/SKILL.md +66 -66
- package/harness/.agents/skills/pc-plan-explore/SKILL.md +19 -2
- package/harness/.agents/skills/pc-plan-goal/SKILL.md +7 -5
- package/harness/.agents/skills/pc-plan-goal/output-mode.md +1 -0
- package/harness/.agents/skills/pc-plan-goal/output.md +71 -65
- package/harness/.agents/skills/pc-plan-propose/SKILL.md +1 -1
- package/harness/.agents/skills/pc-plan-quick/SKILL.md +46 -62
- package/harness/.agents/skills/pc-plan-story/SKILL.md +48 -149
- package/harness/.agents/skills/pc-repo-help/SKILL.md +89 -91
- package/harness/.agents/skills/pc-repo-initialize/SKILL.md +112 -130
- package/harness/.agents/skills/pc-repo-onboard/SKILL.md +32 -87
- package/harness/.agents/skills/pc-repo-verify/SKILL.md +2 -0
- package/harness/.agents/skills/pc-userstory-az/SKILL.md +71 -157
- package/harness/.agents/skills/pc-userstory-browser/SKILL.md +50 -122
- package/harness/.agents/skills/pc-userstory-gh/SKILL.md +63 -120
- package/harness/.agents/skills/pc-userstory-jira/SKILL.md +74 -131
- package/harness/.opencode/commands/init.md +5 -5
- package/harness/.opencode/commands/make-architecture.md +5 -5
- package/harness/.opencode/commands/make-design.md +5 -5
- package/harness/.opencode/commands/make-engineer.md +5 -5
- package/harness/.opencode/commands/make-evidence-scaffold.md +5 -5
- package/harness/.opencode/commands/make-guardrails.md +5 -5
- package/harness/.opencode/commands/make-user-model.md +5 -5
- package/harness/.opencode/commands/plan-apply.md +9 -9
- package/harness/.opencode/commands/plan-goal.md +5 -5
- package/harness/.opencode/commands/plan-quick.md +5 -5
- package/harness/.opencode/commands/plan-story.md +9 -9
- package/harness/.opencode/commands/repo-audit.md +5 -5
- package/harness/.opencode/commands/repo-initialize.md +5 -5
- package/harness/.opencode/commands/repo-onboard.md +5 -5
- package/harness/.opencode/commands/repo-verify.md +5 -5
- package/harness/.opencode/plugins/pc-subagent-monitor.js +82 -2
- package/harness/.opencode/plugins/pc-subagent-tiers.js +9 -6
- package/harness/.opencode/plugins/pc-system-reminders.js +329 -3
- package/harness/AGENTS.md +49 -71
- package/harness/opencode.jsonc +1 -1
- package/package.json +1 -1
|
@@ -1,157 +1,71 @@
|
|
|
1
|
-
---
|
|
2
|
-
name: pc-userstory
|
|
3
|
-
description: Parse Azure DevOps user story URL and create OpenSpec change. Use when user provides an Azure DevOps URL.
|
|
4
|
-
license: MIT
|
|
5
|
-
compatibility: Requires openspec CLI and Azure CLI.
|
|
6
|
-
metadata:
|
|
7
|
-
author: copilots
|
|
8
|
-
version: "3.1"
|
|
9
|
-
---
|
|
10
|
-
|
|
11
|
-
|
|
12
|
-
|
|
13
|
-
##
|
|
14
|
-
|
|
15
|
-
|
|
16
|
-
|
|
17
|
-
|
|
18
|
-
|
|
19
|
-
|
|
20
|
-
|
|
21
|
-
|
|
22
|
-
|
|
23
|
-
|
|
24
|
-
|
|
25
|
-
|
|
26
|
-
|
|
27
|
-
|
|
28
|
-
|
|
29
|
-
|
|
30
|
-
|
|
31
|
-
|
|
32
|
-
|
|
33
|
-
|
|
34
|
-
|
|
35
|
-
|
|
36
|
-
|
|
37
|
-
|
|
38
|
-
|
|
39
|
-
|
|
40
|
-
|
|
41
|
-
|
|
42
|
-
|
|
43
|
-
|
|
44
|
-
|
|
45
|
-
|
|
46
|
-
|
|
47
|
-
|
|
48
|
-
|
|
49
|
-
|
|
50
|
-
|
|
51
|
-
|
|
52
|
-
|
|
53
|
-
|
|
54
|
-
|
|
55
|
-
|
|
56
|
-
|
|
57
|
-
|
|
58
|
-
|
|
59
|
-
|
|
60
|
-
|
|
61
|
-
|
|
62
|
-
|
|
63
|
-
|
|
64
|
-
|
|
65
|
-
|
|
66
|
-
|
|
67
|
-
|
|
68
|
-
|
|
69
|
-
|
|
70
|
-
|
|
71
|
-
|
|
72
|
-
|
|
73
|
-
### Work Items
|
|
74
|
-
```bash
|
|
75
|
-
# Read work item
|
|
76
|
-
az boards work-item show --id <id>
|
|
77
|
-
|
|
78
|
-
# Update work item state
|
|
79
|
-
az boards work-item update --id <id> --state "Active"
|
|
80
|
-
```
|
|
81
|
-
|
|
82
|
-
### PR Threads (Comments)
|
|
83
|
-
```bash
|
|
84
|
-
# Read all threads
|
|
85
|
-
az devops invoke \
|
|
86
|
-
--area git --resource pullRequestThreads \
|
|
87
|
-
--route-parameters project={project} repositoryId=<repo> pullRequestId=<id> \
|
|
88
|
-
--http-method GET --api-version 7.1
|
|
89
|
-
|
|
90
|
-
# Post new comment thread (requires body.json)
|
|
91
|
-
az devops invoke \
|
|
92
|
-
--area git --resource pullRequestThreads \
|
|
93
|
-
--route-parameters project={project} repositoryId=<repo> pullRequestId=<id> \
|
|
94
|
-
--http-method POST --api-version 7.1 --in-file body.json
|
|
95
|
-
|
|
96
|
-
# Reply to existing thread
|
|
97
|
-
az devops invoke \
|
|
98
|
-
--area git --resource pullRequestThreadComments \
|
|
99
|
-
--route-parameters project={project} repositoryId=<repo> pullRequestId=<id> threadId=<tid> \
|
|
100
|
-
--http-method POST --api-version 7.1 --in-file reply.json
|
|
101
|
-
```
|
|
102
|
-
|
|
103
|
-
### Comment Body JSON format
|
|
104
|
-
```json
|
|
105
|
-
{
|
|
106
|
-
"comments": [
|
|
107
|
-
{
|
|
108
|
-
"parentCommentId": 0,
|
|
109
|
-
"content": "Your markdown comment here.",
|
|
110
|
-
"commentType": 1
|
|
111
|
-
}
|
|
112
|
-
],
|
|
113
|
-
"status": "active"
|
|
114
|
-
}
|
|
115
|
-
```
|
|
116
|
-
|
|
117
|
-
For replies, `parentCommentId` should be the ID of the first comment in the thread (usually 1).
|
|
118
|
-
|
|
119
|
-
## Screenshot / Image Strategy
|
|
120
|
-
|
|
121
|
-
Save to openspec change folder and reference via raw URL. Use `_apis/git/repositories` URLs (not `_git/`, which return HTML):
|
|
122
|
-
|
|
123
|
-
```
|
|
124
|
-
openspec/changes/{change-name}/images/{screenshot}.png
|
|
125
|
-
```
|
|
126
|
-
|
|
127
|
-
Raw URL format (renders inline in PR comments):
|
|
128
|
-
```
|
|
129
|
-
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
|
|
130
|
-
```
|
|
131
|
-
|
|
132
|
-
## URL Formats Reference
|
|
133
|
-
|
|
134
|
-
```
|
|
135
|
-
# Sprint board with work item
|
|
136
|
-
https://dev.azure.com/{org}/{project}/_sprints/backlog/{team}/{project}/Sprint%20110?workitem=193208
|
|
137
|
-
|
|
138
|
-
# Direct work item
|
|
139
|
-
https://dev.azure.com/{org}/{project}/_workitems/edit/193208
|
|
140
|
-
|
|
141
|
-
# PR
|
|
142
|
-
https://dev.azure.com/{org}/{project}/_git/{repo}/pullrequest/{pr-id}
|
|
143
|
-
```
|
|
144
|
-
|
|
145
|
-
## Output Format
|
|
146
|
-
|
|
147
|
-
```
|
|
148
|
-
## User Story Parsed
|
|
149
|
-
|
|
150
|
-
Work Item: #{id}
|
|
151
|
-
Title: {title}
|
|
152
|
-
Type: User Story
|
|
153
|
-
Iteration: {sprint}
|
|
154
|
-
State: {state}
|
|
155
|
-
|
|
156
|
-
Change Created: us-{id}-{slug}
|
|
157
|
-
```
|
|
1
|
+
---
|
|
2
|
+
name: pc-userstory
|
|
3
|
+
description: Parse Azure DevOps user story URL and create OpenSpec change. Use when user provides an Azure DevOps URL.
|
|
4
|
+
license: MIT
|
|
5
|
+
compatibility: Requires openspec CLI and Azure CLI.
|
|
6
|
+
metadata:
|
|
7
|
+
author: copilots
|
|
8
|
+
version: "3.1"
|
|
9
|
+
---
|
|
10
|
+
|
|
11
|
+
Turn an Azure DevOps work item URL into an OpenSpec change, then hand the change to `pc-plan-propose`.
|
|
12
|
+
|
|
13
|
+
## Rules
|
|
14
|
+
|
|
15
|
+
- 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.
|
|
16
|
+
- Never load `pc-plan-apply` until the user has said yes.
|
|
17
|
+
|
|
18
|
+
## Contracts
|
|
19
|
+
|
|
20
|
+
The ID is in the URL: `?workitem=193208` or `/workitems/edit/193208` both give `193208`.
|
|
21
|
+
|
|
22
|
+
```bash
|
|
23
|
+
az boards work-item show --id 193208
|
|
24
|
+
```
|
|
25
|
+
|
|
26
|
+
That relies on the configured defaults, which is the one piece of setup this skill needs:
|
|
27
|
+
|
|
28
|
+
```bash
|
|
29
|
+
az devops configure --defaults organization=https://dev.azure.com/{org} project={project}
|
|
30
|
+
```
|
|
31
|
+
|
|
32
|
+
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`.
|
|
33
|
+
|
|
34
|
+
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.
|
|
35
|
+
|
|
36
|
+
```bash
|
|
37
|
+
openspec new change "us-{id}-{slug}"
|
|
38
|
+
```
|
|
39
|
+
|
|
40
|
+
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`
|
|
41
|
+
|
|
42
|
+
Report:
|
|
43
|
+
|
|
44
|
+
```
|
|
45
|
+
## User Story Parsed
|
|
46
|
+
|
|
47
|
+
Work Item: #{id}
|
|
48
|
+
Title: {title}
|
|
49
|
+
Type: User Story
|
|
50
|
+
Iteration: {sprint}
|
|
51
|
+
State: {state}
|
|
52
|
+
|
|
53
|
+
Change Created: us-{id}-{slug}
|
|
54
|
+
```
|
|
55
|
+
|
|
56
|
+
Then load `pc-plan-propose` (interactive) and, once it returns, ask:
|
|
57
|
+
|
|
58
|
+
```json
|
|
59
|
+
{
|
|
60
|
+
"questions": [
|
|
61
|
+
{
|
|
62
|
+
"header": "Ready to implement",
|
|
63
|
+
"question": "Ready to implement?",
|
|
64
|
+
"options": [
|
|
65
|
+
{ "label": "yes", "description": "Load the pc-plan-apply skill to start implementation." },
|
|
66
|
+
{ "label": "no", "description": "Stop here. You can run /plan-apply later." }
|
|
67
|
+
]
|
|
68
|
+
}
|
|
69
|
+
]
|
|
70
|
+
}
|
|
71
|
+
```
|
|
@@ -8,129 +8,57 @@ metadata:
|
|
|
8
8
|
version: "2.0"
|
|
9
9
|
---
|
|
10
10
|
|
|
11
|
-
|
|
11
|
+
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.
|
|
12
12
|
|
|
13
|
-
|
|
14
|
-
|
|
15
|
-
## Prerequisites
|
|
16
|
-
|
|
17
|
-
- agent-browser installed (installed during onboarding) — verify with `agent-browser doctor`
|
|
18
|
-
- An authenticated session for the backlog system:
|
|
19
|
-
- agent-browser runs its own Chrome, not the user's daily browser. Login state persists per session via `--session <slug> --restore`: log in once, and later runs restore cookies automatically.
|
|
20
|
-
- On first use, the user logs in manually in the opened window; state is saved on close and auto-restored afterwards.
|
|
21
|
-
|
|
22
|
-
## Steps
|
|
23
|
-
|
|
24
|
-
1. **Extract the URL** from the user's message
|
|
25
|
-
- The user provides a direct URL to a work item, issue, ticket, or PBI
|
|
26
|
-
- Examples: `https://dev.azure.com/org/project/_workitems/edit/123`, `https://linear.app/team/issue/ENG-123`, `https://trello.com/c/abc123`, `https://your-tool.com/ticket/456`
|
|
27
|
-
|
|
28
|
-
2. **Open the URL in a persistent session**
|
|
29
|
-
```bash
|
|
30
|
-
agent-browser --session backlog --restore open "https://the-url-the-user-provided"
|
|
31
|
-
```
|
|
32
|
-
|
|
33
|
-
3. **Wait for the page to load**
|
|
34
|
-
```bash
|
|
35
|
-
agent-browser wait --load networkidle
|
|
36
|
-
```
|
|
37
|
-
Prefer load-state waits over fixed sleeps; for SPAs that render after idle, add `agent-browser wait --text "<known heading>"` when a stable string is known.
|
|
38
|
-
|
|
39
|
-
4. **Read the work item content**
|
|
40
|
-
```bash
|
|
41
|
-
agent-browser snapshot
|
|
42
|
-
```
|
|
43
|
-
The accessibility tree with `@ref` handles usually reveals the work item title, description, and fields more precisely than raw page text. Also useful:
|
|
44
|
-
```bash
|
|
45
|
-
agent-browser read # agent-readable text of the active tab
|
|
46
|
-
agent-browser get text "h1" # the heading, when present
|
|
47
|
-
```
|
|
48
|
-
|
|
49
|
-
5. **Parse work item fields**
|
|
50
|
-
|
|
51
|
-
From the snapshot and/or text, extract:
|
|
52
|
-
- Title/Summary: usually the main heading or the `<h1>` / page title
|
|
53
|
-
- Description: the body text, acceptance criteria, or "Definition of Done" section
|
|
54
|
-
- ID/Key: the work item ID from the URL or page (e.g. `123`, `ENG-123`)
|
|
55
|
-
- Status: if visible (e.g. "To Do", "In Progress", "Active")
|
|
56
|
-
- Assignee: if visible
|
|
57
|
-
- Priority: if visible
|
|
58
|
-
- Labels/Tags: if visible
|
|
59
|
-
|
|
60
|
-
If the page is a SPA that loads content dynamically:
|
|
61
|
-
- Wait for load state again (`agent-browser wait --load networkidle`)
|
|
62
|
-
- Take a fresh `snapshot` after the wait
|
|
63
|
-
- `agent-browser get url` confirms you are still on the work item
|
|
64
|
-
|
|
65
|
-
If a login page appears instead, the session is not authenticated: tell the user to log in manually in the opened browser window, then retry from step 2 with the same `--session backlog --restore` (the login is saved for future runs).
|
|
66
|
-
|
|
67
|
-
6. **Create OpenSpec Change**
|
|
68
|
-
```bash
|
|
69
|
-
openspec new change "{slug-from-title}"
|
|
70
|
-
```
|
|
71
|
-
|
|
72
|
-
Write `proposal.md` with:
|
|
73
|
-
- Title: the work item title from the page
|
|
74
|
-
- Context: mention the source URL and the work item ID
|
|
75
|
-
- Requirements: extracted from description and acceptance criteria
|
|
76
|
-
- Scope: what's in/out based on the ticket
|
|
77
|
-
|
|
78
|
-
7. **Hand off to proposal.** Load the `pc-plan-propose` skill (interactive mode) to generate the proposal, specs, and tasks. After it completes, call the `question` tool:
|
|
79
|
-
|
|
80
|
-
```json
|
|
81
|
-
{
|
|
82
|
-
"questions": [
|
|
83
|
-
{
|
|
84
|
-
"header": "Ready to implement",
|
|
85
|
-
"question": "Ready to implement?",
|
|
86
|
-
"options": [
|
|
87
|
-
{ "label": "yes", "description": "Load the pc-plan-apply skill to start implementation." },
|
|
88
|
-
{ "label": "no", "description": "Stop here. You can run /plan-apply later." }
|
|
89
|
-
]
|
|
90
|
-
}
|
|
91
|
-
]
|
|
92
|
-
}
|
|
93
|
-
```
|
|
94
|
-
|
|
95
|
-
Wait for confirmation before loading `pc-plan-apply`.
|
|
96
|
-
|
|
97
|
-
## Working with common backlog tools
|
|
98
|
-
|
|
99
|
-
### Azure DevOps (browser fallback)
|
|
100
|
-
- URL: `https://dev.azure.com/{org}/{project}/_workitems/edit/{id}`
|
|
101
|
-
- Title: visible in the work item header
|
|
102
|
-
- Description: "Description" field section
|
|
103
|
-
- Acceptance Criteria: "Acceptance Criteria" field section
|
|
104
|
-
- State: visible in the top-right area
|
|
105
|
-
|
|
106
|
-
### Linear
|
|
107
|
-
- URL: `https://linear.app/{team}/issue/{key}`
|
|
108
|
-
- Title: the issue title
|
|
109
|
-
- Description: the issue body
|
|
110
|
-
- Status: visible as a dropdown
|
|
111
|
-
|
|
112
|
-
### Jira (browser fallback)
|
|
113
|
-
- URL: `https://yoursite.atlassian.net/browse/{key}`
|
|
114
|
-
- Title: the issue summary
|
|
115
|
-
- Description: the description field
|
|
116
|
-
- Status: visible in the status badge
|
|
117
|
-
|
|
118
|
-
### Trello
|
|
119
|
-
- URL: `https://trello.com/c/{short-id}`
|
|
120
|
-
- Title: the card title
|
|
121
|
-
- Description: the card description
|
|
122
|
-
- Labels: visible as colored badges
|
|
123
|
-
|
|
124
|
-
### Other tools (generic)
|
|
125
|
-
- Look for `<h1>` or page title for the work item title
|
|
126
|
-
- Look for the main content area for description
|
|
127
|
-
- Use `agent-browser snapshot` to get structured accessibility tree data
|
|
13
|
+
Browser is a backlog-only platform. Shipping runs on whichever repo platform the project configured.
|
|
128
14
|
|
|
129
15
|
## Rules
|
|
130
16
|
|
|
131
|
-
- Navigate only to
|
|
132
|
-
-
|
|
133
|
-
-
|
|
134
|
-
|
|
135
|
-
|
|
136
|
-
|
|
17
|
+
- 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.
|
|
18
|
+
- Read only. No clicking, no status changes, nothing written back to the tracker.
|
|
19
|
+
- 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.
|
|
20
|
+
|
|
21
|
+
## Contracts
|
|
22
|
+
|
|
23
|
+
`agent-browser` runs its own Chrome, not the user's daily browser, and keeps state per session:
|
|
24
|
+
|
|
25
|
+
```bash
|
|
26
|
+
agent-browser --session backlog --restore open "https://the-url-the-user-provided"
|
|
27
|
+
agent-browser wait --load networkidle
|
|
28
|
+
agent-browser snapshot
|
|
29
|
+
```
|
|
30
|
+
|
|
31
|
+
`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.
|
|
32
|
+
|
|
33
|
+
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:
|
|
34
|
+
|
|
35
|
+
| Tool | Work item URL | Title | Description |
|
|
36
|
+
|---|---|---|---|
|
|
37
|
+
| Azure DevOps | `/_workitems/edit/{id}` | header | "Description" and "Acceptance Criteria" sections |
|
|
38
|
+
| Linear | `/{team}/issue/{key}` | issue title | issue body |
|
|
39
|
+
| Jira | `/browse/{key}` | summary | description field |
|
|
40
|
+
| Trello | `/c/{short-id}` | card title | card description |
|
|
41
|
+
| Anything else | as given | `<h1>` or page title | main content area |
|
|
42
|
+
|
|
43
|
+
Then create the change, whose `proposal.md` names the source URL and the work item ID:
|
|
44
|
+
|
|
45
|
+
```bash
|
|
46
|
+
openspec new change "{slug-from-title}"
|
|
47
|
+
```
|
|
48
|
+
|
|
49
|
+
Load `pc-plan-propose` (interactive) and, once it returns, ask:
|
|
50
|
+
|
|
51
|
+
```json
|
|
52
|
+
{
|
|
53
|
+
"questions": [
|
|
54
|
+
{
|
|
55
|
+
"header": "Ready to implement",
|
|
56
|
+
"question": "Ready to implement?",
|
|
57
|
+
"options": [
|
|
58
|
+
{ "label": "yes", "description": "Load the pc-plan-apply skill to start implementation." },
|
|
59
|
+
{ "label": "no", "description": "Stop here. You can run /plan-apply later." }
|
|
60
|
+
]
|
|
61
|
+
}
|
|
62
|
+
]
|
|
63
|
+
}
|
|
64
|
+
```
|
|
@@ -1,120 +1,63 @@
|
|
|
1
|
-
---
|
|
2
|
-
name: pc-userstory
|
|
3
|
-
description: Parse GitHub Issue URL and create OpenSpec change. Use when user provides a GitHub Issue URL.
|
|
4
|
-
license: MIT
|
|
5
|
-
compatibility: Requires openspec CLI and gh CLI.
|
|
6
|
-
metadata:
|
|
7
|
-
author: copilots
|
|
8
|
-
version: "1.1"
|
|
9
|
-
---
|
|
10
|
-
|
|
11
|
-
|
|
12
|
-
|
|
13
|
-
##
|
|
14
|
-
|
|
15
|
-
|
|
16
|
-
|
|
17
|
-
|
|
18
|
-
|
|
19
|
-
|
|
20
|
-
|
|
21
|
-
|
|
22
|
-
|
|
23
|
-
```
|
|
24
|
-
|
|
25
|
-
|
|
26
|
-
|
|
27
|
-
|
|
28
|
-
|
|
29
|
-
|
|
30
|
-
|
|
31
|
-
|
|
32
|
-
|
|
33
|
-
|
|
34
|
-
|
|
35
|
-
|
|
36
|
-
|
|
37
|
-
|
|
38
|
-
|
|
39
|
-
|
|
40
|
-
|
|
41
|
-
|
|
42
|
-
|
|
43
|
-
|
|
44
|
-
|
|
45
|
-
|
|
46
|
-
|
|
47
|
-
|
|
48
|
-
|
|
49
|
-
|
|
50
|
-
|
|
51
|
-
|
|
52
|
-
|
|
53
|
-
|
|
54
|
-
|
|
55
|
-
|
|
56
|
-
|
|
57
|
-
|
|
58
|
-
|
|
59
|
-
|
|
60
|
-
|
|
61
|
-
|
|
62
|
-
|
|
63
|
-
|
|
64
|
-
```
|
|
65
|
-
|
|
66
|
-
Wait for confirmation before loading `pc-plan-apply`.
|
|
67
|
-
|
|
68
|
-
## Full GitHub CLI Reference
|
|
69
|
-
|
|
70
|
-
Always pass `--repo {owner}/{repo}`, relying on git context is unreliable.
|
|
71
|
-
|
|
72
|
-
### Issues
|
|
73
|
-
```bash
|
|
74
|
-
# Read issue
|
|
75
|
-
gh issue view <number> --repo {owner}/{repo}
|
|
76
|
-
|
|
77
|
-
# List open issues
|
|
78
|
-
gh issue list --repo {owner}/{repo} --state open --limit 10
|
|
79
|
-
|
|
80
|
-
# Update issue
|
|
81
|
-
gh issue edit <number> --repo {owner}/{repo} --add-label "in-progress"
|
|
82
|
-
```
|
|
83
|
-
|
|
84
|
-
## Screenshot / Image Strategy
|
|
85
|
-
|
|
86
|
-
Save to openspec change folder and reference via GitHub blob URL pinned to commit SHA. Keep `?raw=true` when embedding in markdown:
|
|
87
|
-
|
|
88
|
-
```
|
|
89
|
-
openspec/changes/{change-name}/images/{screenshot}.png
|
|
90
|
-
```
|
|
91
|
-
|
|
92
|
-
```
|
|
93
|
-
https://github.com/{owner}/{repo}/blob/{sha}/openspec/changes/{change}/images/{file}.png?raw=true
|
|
94
|
-
```
|
|
95
|
-
|
|
96
|
-
## URL Formats Reference
|
|
97
|
-
|
|
98
|
-
```
|
|
99
|
-
# Issue
|
|
100
|
-
https://github.com/{owner}/{repo}/issues/{number}
|
|
101
|
-
|
|
102
|
-
# PR
|
|
103
|
-
https://github.com/{owner}/{repo}/pull/{number}
|
|
104
|
-
|
|
105
|
-
# Blob file
|
|
106
|
-
https://github.com/{owner}/{repo}/blob/{sha}/{path}
|
|
107
|
-
```
|
|
108
|
-
|
|
109
|
-
## Output Format
|
|
110
|
-
|
|
111
|
-
```
|
|
112
|
-
## Issue Parsed
|
|
113
|
-
|
|
114
|
-
Issue: #{number}
|
|
115
|
-
Title: {title}
|
|
116
|
-
State: {state}
|
|
117
|
-
Milestone: {milestone}
|
|
118
|
-
|
|
119
|
-
Change Created: gh-{number}-{slug}
|
|
120
|
-
```
|
|
1
|
+
---
|
|
2
|
+
name: pc-userstory
|
|
3
|
+
description: Parse GitHub Issue URL and create OpenSpec change. Use when user provides a GitHub Issue URL.
|
|
4
|
+
license: MIT
|
|
5
|
+
compatibility: Requires openspec CLI and gh CLI.
|
|
6
|
+
metadata:
|
|
7
|
+
author: copilots
|
|
8
|
+
version: "1.1"
|
|
9
|
+
---
|
|
10
|
+
|
|
11
|
+
Turn a GitHub Issue URL into an OpenSpec change, then hand the change to `pc-plan-propose`.
|
|
12
|
+
|
|
13
|
+
## Rules
|
|
14
|
+
|
|
15
|
+
- Issue data comes from `gh`, never from a page fetch (denied by `pc-system-reminders`). An unavailable or unauthenticated `gh` is a blocker to report: `gh auth status` says which.
|
|
16
|
+
- Always pass `--repo {owner}/{repo}`. Git context resolves to the wrong repository in a fork or a worktree, and the failure looks like a missing issue.
|
|
17
|
+
- Never load `pc-plan-apply` until the user has said yes.
|
|
18
|
+
|
|
19
|
+
## Contracts
|
|
20
|
+
|
|
21
|
+
`https://github.com/{owner}/{repo}/issues/42` gives owner, repo and number `42`.
|
|
22
|
+
|
|
23
|
+
```bash
|
|
24
|
+
gh issue view 42 --repo {owner}/{repo} --json number,title,body,labels,milestone,state
|
|
25
|
+
```
|
|
26
|
+
|
|
27
|
+
An auth error or a 404 here is the blocker; do not work around it. From the JSON take `number`, `title`, `body` (description and acceptance criteria), `labels`, `milestone` and `state`.
|
|
28
|
+
|
|
29
|
+
```bash
|
|
30
|
+
openspec new change "gh-{number}-{slug}"
|
|
31
|
+
```
|
|
32
|
+
|
|
33
|
+
Screenshots live in the change folder, `openspec/changes/{change-name}/images/{name}.png`, and embed as a blob URL pinned to a commit SHA with `?raw=true`: `https://github.com/{owner}/{repo}/blob/{sha}/openspec/changes/{change}/images/{file}.png?raw=true`.
|
|
34
|
+
|
|
35
|
+
Report:
|
|
36
|
+
|
|
37
|
+
```
|
|
38
|
+
## Issue Parsed
|
|
39
|
+
|
|
40
|
+
Issue: #{number}
|
|
41
|
+
Title: {title}
|
|
42
|
+
State: {state}
|
|
43
|
+
Milestone: {milestone}
|
|
44
|
+
|
|
45
|
+
Change Created: gh-{number}-{slug}
|
|
46
|
+
```
|
|
47
|
+
|
|
48
|
+
Then load `pc-plan-propose` (interactive) and, once it returns, ask:
|
|
49
|
+
|
|
50
|
+
```json
|
|
51
|
+
{
|
|
52
|
+
"questions": [
|
|
53
|
+
{
|
|
54
|
+
"header": "Ready to implement",
|
|
55
|
+
"question": "Ready to implement?",
|
|
56
|
+
"options": [
|
|
57
|
+
{ "label": "yes", "description": "Load the pc-plan-apply skill to start implementation." },
|
|
58
|
+
{ "label": "no", "description": "Stop here. You can run /plan-apply later." }
|
|
59
|
+
]
|
|
60
|
+
}
|
|
61
|
+
]
|
|
62
|
+
}
|
|
63
|
+
```
|