Fix issues from first pipeline run

_spec_AgentOrchestration.md

@@ -569,7 +569,7 @@ All three components needed to reach a runnable state. `dev_team.py` exits with
 
 ---
 
-### Task 2: Step protocol refactor — `get_actions` / `handle_results` / `ParallelSteps` 🤖
+### Task 2: Step protocol refactor — `get_actions` / `handle_results` / `ParallelSteps` 🤖 (ADR-277)
 
 _Depends on Task 1. Refactor only — no behaviour changes visible to the pipeline._
 

plugins/dev-team/agents/developer.md

@@ -21,6 +21,7 @@ tools:
   - mcp__jira__transitionJiraIssue
   - mcp__jira__editJiraIssue
   - mcp__jira__addCommentToJiraIssue
+  - mcp__plugin_github_github__create_pull_request
 ---
 
 You are the Developer for the AdaptiveRemote development team.

plugins/dev-team/agents/reviewer.md

@@ -12,6 +12,11 @@ tools:
   - Grep
   - Bash
   - Skill
+  - mcp__plugin_github_github__pull_request_read
+  - mcp__plugin_github_github__pull_request_review_write
+  - mcp__plugin_github_github__add_comment_to_pending_review
+  - mcp__plugin_github_github__add_reply_to_pull_request_comment
+  - mcp__plugin_github_github__update_pull_request
 ---
 
 You are the Reviewer for the AdaptiveRemote development team.

plugins/dev-team/agents/task-runner.md

@@ -86,7 +86,7 @@ Agent(
 The sub-agent invokes the named skill and returns its full output. Capture that output
 as the skill result for Step 4.
 
-### Step 4 — Write result to context file
+### Step 4 — Write result to context file (Edit only — never Write)
 
 Overwrite `write_section` in `context_file` with the skill's full output.
 
@@ -97,10 +97,24 @@ The section format in the file is:
 <content>
 ```
 
-If the section already exists in the file, replace it entirely (including the sentinel
-line). If it does not exist, append it after the last existing section.
+Use `Read` to read the current file content, then use **`Edit` only — never `Write`**.
+Using `Write` would overwrite the entire file and erase sections written by other
+concurrent agents.
+
+**If the sentinel `<!-- section:<write_section> -->` already exists in the file:**
+
+Use `Edit` where:
+- `old_string` = the sentinel line, the blank line after it, and all content up to
+  (but not including) the next `<!-- section:` marker or the end of the file
+- `new_string` = `<!-- section:<write_section> -->\n\n<skill output>\n`
+
+**If the sentinel does not exist (new section):**
+
+Find the last `<!-- section:...` line in the file (and its content block that follows).
+Use `Edit` where:
+- `old_string` = that last sentinel line plus all content that follows it to end of file
+- `new_string` = that same block plus `\n\n<!-- section:<write_section> -->\n\n<skill output>\n`
 
-Use `Read` to read the current file content, then `Edit` or `Write` to update it.
 **Overwrite the entire section — never append to it.**
 
 ### Step 5 — Return result

plugins/dev-team/commands/developer-create-pr.md

@@ -37,29 +37,38 @@ stop:
 {"pr_url": "$PR_URL"}
 ```
 
-### 2 — Determine the base branch
+### 2 — Determine the base branch and repo coordinates
 
 Using Bash:
 
-1. Run `git fetch --all --quiet` to ensure remote branches are up to date.
-2. List candidate base branches in priority order:
+1. Get the current branch name: `git branch --show-current`
+2. Run `git fetch --all --quiet` to ensure remote branches are up to date.
+3. List candidate base branches in priority order:
    - `main`
    - Any remote `feature/*` branches: `git branch -r | grep "feature/" | sed "s|.*origin/||"`
-3. For each candidate, count how many commits HEAD is ahead of it:
+4. For each candidate, count how many commits HEAD is ahead of it:
    ```bash
    git rev-list --count origin/<candidate>..HEAD 2>/dev/null || echo 99999
    ```
-4. Select the candidate with the fewest commits (the closest ancestor to HEAD). If two
+5. Select the candidate with the fewest commits (the closest ancestor to HEAD). If two
    candidates tie, prefer `main`. If no candidate is reachable, fall back to `main`.
+6. Parse owner and repo from the remote URL:
+   ```bash
+   git remote get-url origin
+   ```
+   Extract `owner` and `repo` from formats like `https://github.com/owner/repo.git`
+   or `git@github.com:owner/repo.git`.
 
 ### 3 — Create the draft PR
 
-Use `gh pr create` with:
+Use `mcp__plugin_github_github__create_pull_request` with:
 
-- `--draft`
-- `--base <base branch from step 2>`
-- `--title "<work-item-id>: <concise one-line description of what the implementation delivers>"`
-- `--body` A well-structured description with these sections:
+- `owner` and `repo` from step 2
+- `head`: the current branch name from step 2
+- `base`: the base branch from step 2
+- `draft`: `true`
+- `title`: `"<work-item-id>: <concise one-line description of what the implementation delivers>"`
+- `body`: A well-structured description with these sections:
   - **Work item:** `<work-item-id>` with a one-sentence summary of what the task required
   - **Changes:** A bullet list drawn from the work summaries — one bullet per logical change
     (new file, modified interface, new test scenario, etc.)
@@ -75,6 +84,4 @@ The PR title and body are read by human reviewers — write them clearly and pre
 
 Output the PR URL as the final JSON line:
 
-```json
 {"pr_url": "https://github.com/..."}
-```

plugins/dev-team/commands/researcher-validate.md

@@ -48,23 +48,21 @@ exercises the scenario — not just that the code path exists.
 
 ### 3 — Return the result
 
-Return a JSON array. Each entry is one exit criterion. Do not omit criteria even if they
-clearly pass — include them all so the caller has a complete picture.
-
-```json
-[
-  {
-    "criterion": "Exact text of the exit criterion from the spec",
-    "status": "pass | fail | partial",
-    "finding": "One-sentence explanation. Required for fail and partial; omit for pass."
-  }
-]
+Output a JSON object as the very last line of your response (bare, not inside a code block).
+Set `status` to `"validated"` if all criteria passed, `"failed"` if any criterion is
+`fail` or `partial`. Include the full criteria array so the developer has details.
+
+```
+{"status": "validated|failed", "criteria": [{"criterion": "...", "status": "pass|fail|partial", "finding": "..."}]}
 ```
 
+Each criterion entry:
+- `criterion` — exact text of the exit criterion from the spec
+- `status` — `pass`, `fail`, or `partial`
+- `finding` — one-sentence explanation (required for `fail` and `partial`; omit for `pass`)
+
 **Status definitions:**
 - `pass` — criterion is fully and demonstrably met by the code and tests
 - `partial` — criterion is met in part but not completely (e.g., happy path covered but
   error cases are not, or implementation exists but no test verifies it)
 - `fail` — criterion is not met
-
-Return only the JSON array — no surrounding text.

plugins/dev-team/commands/reviewer-review.md

@@ -36,15 +36,27 @@ error and stop.
 
 ## Step 4 — Retrieve and read the diff
 
-Fetch the PR diff using the `gh` CLI:
+Extract the pull number from `$PR_URL` (last path segment). Parse `owner` and `repo` from
+the URL (e.g. `https://github.com/owner/repo/pull/123`).
 
-```bash
-gh pr diff <pull-number>
+Fetch the PR diff using the GitHub MCP:
+
+```
+mcp__plugin_github_github__pull_request_read(method="get_diff", owner=<owner>, repo=<repo>, pullNumber=<number>)
 ```
 
 Read all changed files in full to understand the complete context of each change.
 
-## Step 5 — Review the changes
+## Step 5 — Create a pending review
+
+Before reviewing, create a pending review so inline comments can be added as issues are
+discovered:
+
+```
+mcp__plugin_github_github__pull_request_review_write(method="create", owner=<owner>, repo=<repo>, pullNumber=<number>)
+```
+
+## Step 6 — Review the changes
 
 Evaluate the diff against each dimension below, in priority order. For each issue you
 find, note the file, line number, and a clear description of the problem.
@@ -88,38 +100,35 @@ find, note the file, line number, and a clear description of the problem.
 - Do tests use `MockBehavior.Strict` and `Expect_*` helpers?
 - Is there a `CreateSut()` method?
 
-## Step 6 — Post the GitHub PR review
+## Step 7 — Post each inline issue as you find it
 
-Create a **pull request review** (not a regular PR comment) using the `gh` CLI:
+For each Priority 1–4 issue discovered in step 6, post it immediately to the pending
+review using the **source file line number** (not the diff position):
 
-```bash
-gh api "repos/${GITHUB_REPOSITORY}/pulls/<pull-number>/reviews" \
-  --method POST \
-  --field body='<overall summary>' \
-  --field event='COMMENT' \
-  --field comments='[{"path":"<file>","position":<diff-position>,"body":"<comment>"}]'
 ```
+mcp__plugin_github_github__add_comment_to_pending_review(owner=<owner>, repo=<repo>, pullNumber=<number>, path=<file>, line=<line>, side="RIGHT", subjectType="LINE", body=<comment>)
+```
+
+## Step 8 — Submit the review
+
+Submit the pending review with an overall summary. Use `event: COMMENT` — do not use
+`APPROVE` or `REQUEST_CHANGES`, as GitHub rejects those when the reviewer and PR author
+share the same account.
 
-Notes:
-- Use `event: COMMENT`, not `APPROVE` or `REQUEST_CHANGES` — GitHub rejects those from
-  the PR author's account, and the developer and reviewer agents share the same account.
-- Each entry in `comments` must use the **diff position** (line number within the unified
-  diff), not the source file line number. Run `gh pr diff <number>`
-  and count lines from the start of each file's hunk to get the position.
-- Do NOT use `POST /repos/.../issues/{number}/comments` — that creates a plain conversation
-  comment, not a structured review thread.
+```
+mcp__plugin_github_github__pull_request_review_write(method="submit_pending", owner=<owner>, repo=<repo>, pullNumber=<number>, body=<overall summary>, event="COMMENT")
+```
 
-## Step 7 — Output
+## Step 9 — Output
 
 Write a concise plain-text summary of all issues found (one bullet per issue, Priority
 1–4 first, style issues last). This summary will be passed to the developer so they can
 address each point without re-reading the full PR thread.
 
-Then output the JSON result as the final line:
+Then output the following JSON object as the very last line of your response.
+Write it as a bare JSON object — do not wrap it in a code block or add any text after it:
 
-```json
 {"status": "approved|changes_requested", "pr_url": "https://github.com/..."}
-```
 
 Use `"approved"` if no Priority 1–4 issues were found; `"changes_requested"` otherwise.
 Always include the PR URL even when approving.