@plainconceptsplatform/agent-harness 2.0.0 → 2.0.1

package/src/fragments/ops-review/gl.md

@@ -1,57 +1,57 @@
-**ALL GitLab data MUST come from `glab` CLI. NEVER use webfetch, HTTP requests, or browser MCP tools for GitLab operations, even if glab CLI fails. If `glab` is unavailable, report as a blocker.**
-Always pass `--repo {owner}/{repo}` explicitly, never rely on git context to resolve the repo.
-
----
-
-### Step 1: Parse MR URL or number
-
-- `https://gitlab.com/{owner}/{repo}/-/merge_requests/123` → MR !123, repo: `{owner}/{repo}`
-- `https://gitlab.com/{owner}/{repo}/-/merge_requests/123#note_456` → MR !123, note: 456
-- `!123` → MR !123
-
-### Step 2: Fetch MR details and comments
-
-```bash
-glab mr view {number} --repo {owner}/{repo}
-glab mr note list {number} --repo {owner}/{repo}
-```
-
-Also fetch MR threads (inline code comments):
-
-```bash
-glab api "projects/:id/merge_requests/{number}/discussions"
-```
-
-### Step 3: Classify comments
-
-Categorize each comment as:
-- **BLOCKER**: must fix before merge (test failures, security issues, broken logic)
-- **IMPORTANT**: should fix (missing edge case, code quality, performance)
-- **SUGGESTION**: nice to have (style, refactor, docs)
-- **QUESTION**: needs clarification (respond or discuss)
-- **RESOLVED**: already addressed or invalid
-
-### Step 4: Report
-
-Display a structured summary:
-
-```text
-MR Feedback Summary: !{number}
-
-  Blockers: {count}
-    [B1] {comment-author}: {comment-summary}
-  Important: {count}
-    [I1] {comment-author}: {comment-summary}
-  Suggestions: {count}
-    [S1] {comment-author}: {comment-summary}
-  Questions: {count}
-    [Q1] {comment-author}: {comment-summary}
-
-Next: Run /plan-apply to fix blockers and important items.
-```
-
-### Step 5: Do NOT implement fixes
-
-This mode only triages. Fixing is done via `/plan-apply`. Tell the user what needs fixing, then stop.
-
+**ALL GitLab data MUST come from `glab` CLI. NEVER use webfetch, HTTP requests, or browser MCP tools for GitLab operations, even if glab CLI fails. If `glab` is unavailable, report as a blocker.**
+Always pass `--repo {owner}/{repo}` explicitly, never rely on git context to resolve the repo.
+
+---
+
+### Step 1: Parse MR URL or number
+
+- `https://gitlab.com/{owner}/{repo}/-/merge_requests/123` → MR !123, repo: `{owner}/{repo}`
+- `https://gitlab.com/{owner}/{repo}/-/merge_requests/123#note_456` → MR !123, note: 456
+- `!123` → MR !123
+
+### Step 2: Fetch MR details and comments
+
+```bash
+glab mr view {number} --repo {owner}/{repo}
+glab mr note list {number} --repo {owner}/{repo}
+```
+
+Also fetch MR threads (inline code comments):
+
+```bash
+glab api "projects/:id/merge_requests/{number}/discussions"
+```
+
+### Step 3: Classify comments
+
+Categorize each comment as:
+- **BLOCKER**: must fix before merge (test failures, security issues, broken logic)
+- **IMPORTANT**: should fix (missing edge case, code quality, performance)
+- **SUGGESTION**: nice to have (style, refactor, docs)
+- **QUESTION**: needs clarification (respond or discuss)
+- **RESOLVED**: already addressed or invalid
+
+### Step 4: Report
+
+Display a structured summary:
+
+```text
+MR Feedback Summary: !{number}
+
+  Blockers: {count}
+    [B1] {comment-author}: {comment-summary}
+  Important: {count}
+    [I1] {comment-author}: {comment-summary}
+  Suggestions: {count}
+    [S1] {comment-author}: {comment-summary}
+  Questions: {count}
+    [Q1] {comment-author}: {comment-summary}
+
+Next: Run /plan-apply to fix blockers and important items.
+```
+
+### Step 5: Do NOT implement fixes
+
+This mode only triages. Fixing is done via `/plan-apply`. Tell the user what needs fixing, then stop.
+
 ---

package/src/fragments/ops-ship/az.md

@@ -1,81 +1,81 @@
-**Browser MCP tools are FORBIDDEN for all Azure DevOps operations.**
-Browser tools are ONLY permitted for screenshots of the LOCAL running app on `localhost` URLs.
-
----
-
-### Step 1: Verify feature branch
-
-```bash
-git branch --show-current
-```
-
-Branch must be `feature/{id}-{slug}`. NEVER push to `main`.
-
-### Step 2: Capture screenshots (if UI changes exist)
-
-```bash
-browser_navigate url="http://localhost:{port}/{route}"
-browser_wait ms=2000
-browser_screenshot
-```
-
-Save to: `openspec/changes/{change-name}/images/{feature}.png`
-
-### Step 3: Commit and push
-
-```bash
-git add .
-git commit -m "feat({scope}): {description} (#{id})"
-git push origin feature/{id}-{slug}
-```
-
-### Step 4: Create PR
-
-```bash
-az repos pr create \
-  --repository {repo} \
-  --source-branch feature/{id}-{slug} \
-  --target-branch main \
-  --title "feat({scope}): {title} (#{id})" \
-  --description "{description}"
-```
-
-### Step 5: Link work item (MANDATORY, run sequentially, not in parallel)
-
-```bash
-az repos pr work-item add --id {pr-id} --work-items {workitem-id}
-```
-
-### Step 6: Post screenshot comment
-
-Build raw URL for each image:
-
-```
-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
-```
-
-Post via:
-
-```bash
-az devops invoke \
-  --area git --resource pullRequestThreads \
-  --route-parameters project={project} repositoryId={repo} pullRequestId={pr-id} \
-  --http-method POST --api-version 7.1 --in-file body.json
-```
-
-`body.json`:
-
-```json
-{
-  "comments": [
-    {
-      "parentCommentId": 0,
-      "content": "## Screenshots\n\n![{feature}]({raw-url})",
-      "commentType": 1
-    }
-  ],
-  "status": "active"
-}
-```
-
+**Browser MCP tools are FORBIDDEN for all Azure DevOps operations.**
+Browser tools are ONLY permitted for screenshots of the LOCAL running app on `localhost` URLs.
+
+---
+
+### Step 1: Verify feature branch
+
+```bash
+git branch --show-current
+```
+
+Branch must be `feature/{id}-{slug}`. NEVER push to `main`.
+
+### Step 2: Capture screenshots (if UI changes exist)
+
+```bash
+browser_navigate url="http://localhost:{port}/{route}"
+browser_wait ms=2000
+browser_screenshot
+```
+
+Save to: `openspec/changes/{change-name}/images/{feature}.png`
+
+### Step 3: Commit and push
+
+```bash
+git add .
+git commit -m "feat({scope}): {description} (#{id})"
+git push origin feature/{id}-{slug}
+```
+
+### Step 4: Create PR
+
+```bash
+az repos pr create \
+  --repository {repo} \
+  --source-branch feature/{id}-{slug} \
+  --target-branch main \
+  --title "feat({scope}): {title} (#{id})" \
+  --description "{description}"
+```
+
+### Step 5: Link work item (MANDATORY, run sequentially, not in parallel)
+
+```bash
+az repos pr work-item add --id {pr-id} --work-items {workitem-id}
+```
+
+### Step 6: Post screenshot comment
+
+Build raw URL for each image:
+
+```
+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
+```
+
+Post via:
+
+```bash
+az devops invoke \
+  --area git --resource pullRequestThreads \
+  --route-parameters project={project} repositoryId={repo} pullRequestId={pr-id} \
+  --http-method POST --api-version 7.1 --in-file body.json
+```
+
+`body.json`:
+
+```json
+{
+  "comments": [
+    {
+      "parentCommentId": 0,
+      "content": "## Screenshots\n\n![{feature}]({raw-url})",
+      "commentType": 1
+    }
+  ],
+  "status": "active"
+}
+```
+
 ---

package/src/fragments/ops-ship/gh.md

@@ -1,69 +1,69 @@
-**ALL GitHub data MUST come from `gh` CLI. NEVER use webfetch, HTTP requests, or browser MCP tools for GitHub operations, even if gh CLI fails. If `gh` is unavailable, report as a blocker.**
-Always pass `--repo {owner}/{repo}` explicitly, never rely on git context to resolve the repo.
-
----
-
-### Step 1: Verify feature branch
-
-```bash
-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"
-```
-
-`$BRANCH` must be a work branch (`feature/*` or `bugfix/*`: the `pc-plan-apply` skill creates `feature/{change-slug}`). NEVER push the default branch.
-
-### Step 2: Capture screenshots (if UI changes exist)
-
-```bash
-browser_navigate url="http://localhost:{port}/{route}"
-browser_wait ms=2000
-browser_screenshot
-```
-
-Save to: `openspec/changes/{change-name}/images/{feature}.png`
-
-### Step 3: Commit and push
-
-The `pc-plan-apply` skill already committed each task group: usually only screenshots or small residuals remain. Stage **specific paths only** (never `git add .`, it sweeps unrelated files into the ship commit):
-
-```bash
-git add openspec/changes/{change-name}/images/  # plus any other paths you actually changed
-git commit -m "feat({scope}): {description} (#{id})"   # only if there is something to commit
-git push -u origin "$BRANCH"
-```
-
-### Step 4: Create PR
-
-```bash
-gh pr create \
-  --repo {owner}/{repo} \
-  --base "$DEFAULT_BRANCH" \
-  --head "$BRANCH" \
-  --title "feat({scope}): {title} (#{id})" \
-  --body "{description}"
-```
-
-### Step 5: Post screenshot comment
-
-Resolve commit SHA (the commit that includes screenshots):
-
-```bash
-git rev-parse HEAD
-```
-
-Build blob URL for each image with `?raw=true` (a plain blob URL renders the GitHub HTML page, not the image, inside `![...]()`):
-
-```
-https://github.com/{owner}/{repo}/blob/{sha}/openspec/changes/{change}/images/{file}.png?raw=true
-```
-
-Note: on private repos the embedded image is only visible to users with repo access.
-
-Post comment:
-
-```bash
-gh pr comment {pr-number} --repo {owner}/{repo} --body $'## Screenshots\n\n![{feature}]({blob-url})'
-```
-
+**ALL GitHub data MUST come from `gh` CLI. NEVER use webfetch, HTTP requests, or browser MCP tools for GitHub operations, even if gh CLI fails. If `gh` is unavailable, report as a blocker.**
+Always pass `--repo {owner}/{repo}` explicitly, never rely on git context to resolve the repo.
+
+---
+
+### Step 1: Verify feature branch
+
+```bash
+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"
+```
+
+`$BRANCH` must be a work branch (`feature/*` or `bugfix/*`: the `pc-plan-apply` skill creates `feature/{change-slug}`). NEVER push the default branch.
+
+### Step 2: Capture screenshots (if UI changes exist)
+
+```bash
+browser_navigate url="http://localhost:{port}/{route}"
+browser_wait ms=2000
+browser_screenshot
+```
+
+Save to: `openspec/changes/{change-name}/images/{feature}.png`
+
+### Step 3: Commit and push
+
+The `pc-plan-apply` skill already committed each task group: usually only screenshots or small residuals remain. Stage **specific paths only** (never `git add .`, it sweeps unrelated files into the ship commit):
+
+```bash
+git add openspec/changes/{change-name}/images/  # plus any other paths you actually changed
+git commit -m "feat({scope}): {description} (#{id})"   # only if there is something to commit
+git push -u origin "$BRANCH"
+```
+
+### Step 4: Create PR
+
+```bash
+gh pr create \
+  --repo {owner}/{repo} \
+  --base "$DEFAULT_BRANCH" \
+  --head "$BRANCH" \
+  --title "feat({scope}): {title} (#{id})" \
+  --body "{description}"
+```
+
+### Step 5: Post screenshot comment
+
+Resolve commit SHA (the commit that includes screenshots):
+
+```bash
+git rev-parse HEAD
+```
+
+Build blob URL for each image with `?raw=true` (a plain blob URL renders the GitHub HTML page, not the image, inside `![...]()`):
+
+```
+https://github.com/{owner}/{repo}/blob/{sha}/openspec/changes/{change}/images/{file}.png?raw=true
+```
+
+Note: on private repos the embedded image is only visible to users with repo access.
+
+Post comment:
+
+```bash
+gh pr comment {pr-number} --repo {owner}/{repo} --body $'## Screenshots\n\n![{feature}]({blob-url})'
+```
+
 ---

package/src/fragments/ops-ship/gl.md

@@ -1,86 +1,86 @@
-**ALL GitLab data MUST come from `glab` CLI. NEVER use webfetch, HTTP requests, or browser MCP tools for GitLab operations, even if glab CLI fails. If `glab` is unavailable, report as a blocker.**
-Always pass `--repo {owner}/{repo}` explicitly, never rely on git context to resolve the repo.
-
----
-
-### Step 1: Verify feature branch
-
-```bash
-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"
-```
-
-`$BRANCH` must be a work branch (`feature/*` or `bugfix/*`: the `pc-plan-apply` skill creates `feature/{change-slug}`). NEVER push the default branch.
-
-### Step 2: Capture screenshots (if UI changes exist)
-
-```bash
-browser_navigate url="http://localhost:{port}/{route}"
-browser_wait ms=2000
-browser_screenshot
-```
-
-Save to: `openspec/changes/{change-name}/images/{feature}.png`
-
-### Step 3: Commit and push
-
-The `pc-plan-apply` skill already committed each task group: usually only screenshots or small residuals remain. Stage **specific paths only** (never `git add -A`, it sweeps unrelated files into the ship commit):
-
-```bash
-git add openspec/changes/{change-name}/images/  # plus any other paths you actually changed
-git commit -m "{change}: {summary}"   # only if there is something to commit
-git push -u origin "$BRANCH"
-```
-
-### Step 4: Upload screenshots (if any)
-
-If screenshots exist, upload them so they can be referenced in the MR description:
-
-```bash
-glab api --method POST "projects/:id/uploads" -f "file=@openspec/changes/{change-name}/images/{feature}.png"
-```
-
-(`:id` is glab's placeholder for the current project: this is the one sanctioned use of git context in this skill.)
-
-Parse the returned `markdown` field: use it to embed the image in the MR description. If the upload fails (the endpoint needs multipart form data and `-f` support varies by glab version), fall back to referencing the image committed on the branch instead.
-
-If no UI changes, skip this step.
-
-### Step 5: Create Merge Request
-
-```bash
-glab mr create \
-  --source-branch "$BRANCH" \
-  --target-branch "$DEFAULT_BRANCH" \
-  --title "{title}" \
-  --description "Closes {issue-link}
-
-## Summary
-{summary from proposal.md}
-
-## Changes
-{key changes from tasks.md}
-
-## Test plan
-- [ ] {checklist of manual verification steps}
-{screenshots if available}" \
-  --remove-source-branch \
-  --squash-before-merge
-```
-
-Do NOT use `--yes` unless running in autopilot/non-interactive mode.
-
-### Step 6: Report
-
-Display:
-
-```text
-Merge Request created
-  MR: {mr-url}
-  Title: {title}
-  Source: {branch}
-  Target: {default-branch}
-```
-
+**ALL GitLab data MUST come from `glab` CLI. NEVER use webfetch, HTTP requests, or browser MCP tools for GitLab operations, even if glab CLI fails. If `glab` is unavailable, report as a blocker.**
+Always pass `--repo {owner}/{repo}` explicitly, never rely on git context to resolve the repo.
+
+---
+
+### Step 1: Verify feature branch
+
+```bash
+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"
+```
+
+`$BRANCH` must be a work branch (`feature/*` or `bugfix/*`: the `pc-plan-apply` skill creates `feature/{change-slug}`). NEVER push the default branch.
+
+### Step 2: Capture screenshots (if UI changes exist)
+
+```bash
+browser_navigate url="http://localhost:{port}/{route}"
+browser_wait ms=2000
+browser_screenshot
+```
+
+Save to: `openspec/changes/{change-name}/images/{feature}.png`
+
+### Step 3: Commit and push
+
+The `pc-plan-apply` skill already committed each task group: usually only screenshots or small residuals remain. Stage **specific paths only** (never `git add -A`, it sweeps unrelated files into the ship commit):
+
+```bash
+git add openspec/changes/{change-name}/images/  # plus any other paths you actually changed
+git commit -m "{change}: {summary}"   # only if there is something to commit
+git push -u origin "$BRANCH"
+```
+
+### Step 4: Upload screenshots (if any)
+
+If screenshots exist, upload them so they can be referenced in the MR description:
+
+```bash
+glab api --method POST "projects/:id/uploads" -f "file=@openspec/changes/{change-name}/images/{feature}.png"
+```
+
+(`:id` is glab's placeholder for the current project: this is the one sanctioned use of git context in this skill.)
+
+Parse the returned `markdown` field: use it to embed the image in the MR description. If the upload fails (the endpoint needs multipart form data and `-f` support varies by glab version), fall back to referencing the image committed on the branch instead.
+
+If no UI changes, skip this step.
+
+### Step 5: Create Merge Request
+
+```bash
+glab mr create \
+  --source-branch "$BRANCH" \
+  --target-branch "$DEFAULT_BRANCH" \
+  --title "{title}" \
+  --description "Closes {issue-link}
+
+## Summary
+{summary from proposal.md}
+
+## Changes
+{key changes from tasks.md}
+
+## Test plan
+- [ ] {checklist of manual verification steps}
+{screenshots if available}" \
+  --remove-source-branch \
+  --squash-before-merge
+```
+
+Do NOT use `--yes` unless running in autopilot/non-interactive mode.
+
+### Step 6: Report
+
+Display:
+
+```text
+Merge Request created
+  MR: {mr-url}
+  Title: {title}
+  Source: {branch}
+  Target: {default-branch}
+```
+
 ---