@groupby/ai-dev 0.5.16 → 0.5.18

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@groupby/ai-dev",
-  "version": "0.5.16",
+  "version": "0.5.18",
   "description": "Interactive installer for Rezolve Ai development content",
   "type": "module",
   "bin": {

package/teams/dqm/skills/check-jenkins-build/SKILL.md

@@ -0,0 +1,52 @@
+---
+name: check-jenkins-build
+description: Check Jenkins CI build status for current branch or PR and report merge readiness. Use for CI/build status and failed pipeline investigation. Requires Crownpeak Jenkins MCP and user confirmation when job path is ambiguous.
+---
+
+# Check Jenkins Build
+
+Requires Crownpeak Jenkins MCP:
+
+`https://github.com/Crownpeak/dqm-ai-tools/tree/main/jenkins-mcp`
+
+## Fast Path (Primary)
+
+1. Probe Jenkins MCP with `jenkins_list_jobs`.
+2. If probe fails, report the exact tool error and stop.
+3. Resolve branch: `git branch --show-current`.
+4. If `gh` is available and authenticated, check PR:
+
+```bash
+gh pr list --head <branch> --state open --json number,title,url
+```
+
+5. If PR exists, target `PR-<number>`.
+6. If PR does not exist, target URL-encoded branch name.
+7. If user expects a PR but none is found, ask for PR number directly.
+8. If `gh` is unavailable/unauthenticated, ask user whether to check branch or PR; if PR, ask PR number.
+9. Discover job candidates with `jenkins_list_jobs`.
+10. Validate candidate with `jenkins_get_latest_build`.
+11. If candidate path is not found, call `jenkins_get_job_info` on nearest existing path segment and refine.
+12. If multiple plausible paths exist, stop and ask user to confirm. Do not guess.
+13. Report target, job, build status, duration, and link.
+14. For in-progress builds, include elapsed time and current stage when available via `jenkins_get_build_status`.
+15. On failure, ask before pulling logs.
+16. If user agrees, call `jenkins_get_console_log` and show only first failure excerpt (<= 40 lines).
+
+## Report Template
+
+```text
+Target: <PR # or branch>
+Job: <resolved-job-path>
+Build: #<n> - ✅ SUCCESS | ❌ FAILURE | 🔄 IN_PROGRESS | ⏸ ABORTED (<duration>)
+Link: https://<jenkins-host>/job/<seg1>/job/<seg2>/.../<build>/
+```
+
+## Reference Notes (Secondary)
+
+- Branches with `/` in the name must be URL-encoded before using as Jenkins sub-jobs.
+- Jenkins foldered links require repeating `/job/<segment>/` for each path segment.
+- If branch has never been built, report that explicitly instead of generic failure.
+- If Jenkins MCP is not connected, suggest connecting it and running `/mcp`.
+- If access is denied for a job, report permissions issue and ask for alternate path or access.
+- Jenkins layout varies (top-level, foldered, multibranch); discover dynamically with `jenkins_list_jobs`.

package/teams/dqm/skills/create-pr/SKILL.md

@@ -0,0 +1,96 @@
+---
+name: create-pr
+description: >-
+  Create or complete PRs to team standard: ticketed title, fully filled template
+  body, AI trailer, and "AI Assisted" label.
+---
+
+# Create PR
+
+## Fast Path (Primary)
+
+1. Find PR for the current branch:
+
+```sh
+gh pr view --json number,isDraft,title,body,url,baseRefName
+```
+
+2. If PR exists:
+  - Update it in place with `gh pr edit`.
+  - Keep `baseRefName` unchanged unless the user explicitly asks to change base.
+
+3. If PR does not exist, resolve effective base in this order:
+  - User-specified base branch.
+  - Repository default branch from:
+
+```sh
+gh repo view --json defaultBranchRef --jq '.defaultBranchRef.name'
+```
+
+  - Topology candidate from:
+
+```sh
+git fetch --prune
+git log --oneline origin/<default-branch>..HEAD --decorate=short \
+  | grep -o 'origin/[^ ,)]*' | grep -v HEAD | sort -u
+```
+
+  - If one non-default candidate is found, use it as the candidate base.
+  - If candidate is non-default, ask the user to confirm.
+  - Verify chosen base exists on `origin`; if missing, fall back to `<default-branch>` and report fallback.
+
+4. Build title as `<TICKET>: <short description>`.
+  - Ticket source: spec Ticket field or branch name (for example, `feature/OCD-1234/...`).
+  - If no ticket is found, ask user; do not invent one.
+  - Keep description concise; put detail in body.
+
+5. Build PR body from repository template in this order:
+  - `.github/pull_request_template.md`
+  - `.github/PULL_REQUEST_TEMPLATE.md`
+  - `.github/PULL_REQUEST_TEMPLATE/*`
+  - platform default if none exists
+
+6. Fill every template section truthfully (no placeholders). Append this exact final line:
+
+```text
+🤖 - Assembled by AI
+```
+
+7. Write body to a temp file and apply:
+
+```sh
+gh pr edit <number> --title "<TICKET>: <short description>" --body-file <path>
+gh pr create --title "<TICKET>: <short description>" --body-file <path> --base <effective-base>
+```
+
+8. Ensure `AI Assisted` label exists, then apply to PR:
+
+```sh
+gh label list --search "AI Assisted" --json name --jq '.[].name'
+gh label create "AI Assisted" --description "AI created PR" --color fcd119
+gh pr edit <number> --add-label "AI Assisted"
+```
+
+9. If Jira skills are available, offer to post PR URL comment:
+
+```text
+**PR:** [<PR title>](<PR URL>)
+
+🤖 **Posted by (AI)**
+```
+
+## Command Reference (Secondary)
+
+- Never merge the PR.
+- Keep draft state as-is unless user asks to change it.
+- Keep existing PR base unchanged unless user asks.
+- Do not assume `main`; always resolve repository default branch.
+- Use `--body-file` for body updates/creation to avoid quoting issues.
+
+## Done
+
+Report PR URL and confirm all:
+- title format is correct
+- template sections are fully filled
+- trailer line is present
+- `AI Assisted` label is applied

package/teams/dqm/skills/dqm-implementation-plan/SKILL.md

@@ -0,0 +1,111 @@
+---
+name: dqm-implementation-plan
+description: >-
+  Produce a structured DQM implementation plan from assembled ticket context or
+  any written source. Handles scope determination, NNNN folder naming, clarifications,
+  architecture scan, phased checklists, and DQM-specific next steps. Typically
+  invoked by dqm-jira-plan but can be used standalone with any source material.
+---
+
+# DQM Implementation Plan
+
+Self-contained. Produces planning files in `docs/planning/` following DQM conventions.
+
+## Input
+
+One of:
+- Assembled context passed from `dqm-jira-plan`
+- A path to an existing document
+- Inline notes or requirements pasted into the conversation
+
+## Defaults
+
+| Setting | Value |
+|---------|-------|
+| Project | `OCD` |
+| Team | `Tardigrades` |
+| Product Line | `DQM` |
+
+## Fast Path
+
+1. **Determine scope:**
+   - Small (1–3 tasks, single concern): single file `docs/planning/<name>.md`
+   - Larger (4+ tasks or cross-cutting): folder `docs/planning/<name>/`
+
+2. **Choose name:** list `docs/planning/`, find the highest existing 4-digit prefix, increment by 1 (start at `0001` if none exist). Pattern: `{NNNN}-{ticket-key-lowercase}-{short-slug}`. Short slug = 2–4 kebab-case words from the summary. Confirm with user if ambiguous; use user-supplied name verbatim if provided.
+
+3. **Scan architecture docs:**
+   - Read `docs/architecture/` — at minimum the README and any file relevant to the task. Note the gap if absent.
+   - Read the project's framework/dependency constraint documentation (e.g. `AGENTS.md`, `CLAUDE.md`, or equivalent) before proposing any concrete type, API, or library construct.
+   - For any dependency or framework version that may post-date the model training window, verify the API exists in that version before naming it in the plan — do not rely on training data for version-specific details.
+   - If the project provides a docs-fetching skill for the framework in use, invoke it. Otherwise use `WebFetch` or `WebSearch` against the library's official docs.
+   - A plan that names the wrong type propagates the mistake to every downstream agent.
+
+4. **Scan existing plans:** check `docs/planning/` for related plans. Note any this plan relates to or supersedes.
+
+5. **Write clarifications:** surface ambiguities from the source with assumed answers. See Clarifications Template below. Write the file immediately and proceed to the plan without stopping.
+
+6. **Write plan:** include all required sections (see Plan Output Templates below). Always include:
+   - Architecture context citing specific files from `docs/architecture/`
+   - Decisions (including those inherited from clarifications)
+   - Open questions that could not be assumed away
+   - Phased checklist with testing and documentation steps
+   - Per-task detail: exact files to create/modify, patterns to follow, edge cases, test requirements
+   - DQM next steps:
+     - Update OCD ticket status to In Progress
+     - Add comment to ticket linking to `docs/planning/<name>/`
+     - Create Jira subtasks for each phase if Tardigrades team tracks at that level
+
+## Reference Notes
+
+### Clarifications Template
+
+```markdown
+# Clarifications: {TICKET-KEY} — {Summary}
+
+Ambiguities identified before planning. Override any ANSWER: line and ask for the plan to be updated.
+
+---
+
+### 1. {Short question title}
+
+{Why this is ambiguous.}
+
+ANSWER: {Assumed answer with brief reasoning.}
+```
+
+### Plan Output Templates
+
+**Single file** (`docs/planning/<name>.md`):
+
+```
+# <Title>
+
+<One-paragraph summary of what this plan accomplishes and why.>
+
+## Source
+## Architecture context
+## Decisions
+## Open questions
+## Implementation checklist
+## Detail (per task)
+## Next steps
+```
+
+**Folder** (`docs/planning/<name>/`):
+
+```
+README.md          # intent, source, links to plan/
+clarifications.md
+plan/
+  README.md        # decisions, checklist, links to sub-plans
+  <sub-plan-1>.md
+  ...
+```
+
+### Edge Cases
+
+- No `docs/architecture/`: note gap in plan; suggest creating it as follow-up.
+- Source has no acceptance criteria: proceed with summary + comments; note gap in clarifications.
+- Conflicting decisions in source: surface each as an open question.
+- User disagrees with a clarification assumption: edit the `ANSWER:` line and ask for the plan to be regenerated.

package/teams/dqm/skills/dqm-jira-plan/README.md

@@ -0,0 +1,33 @@
+# dqm-jira-plan
+
+Generate an implementation plan starting from a DQM Jira ticket (`OCD-XXXX`). Fetches the full ticket context — epic hierarchy, acceptance criteria, subtasks, linked issues, recent comments, and linked Confluence pages — then produces a structured plan inline using the `implementation-plan` format.
+
+## Requirements
+
+Prefers `atlassian-rovo` MCP — no setup needed if it's available in your environment.
+
+**REST API fallback:** set these environment variables when MCP is unavailable:
+
+```sh
+export JIRA_EMAIL=your.email@example.com
+export JIRA_API_TOKEN=<token from https://id.atlassian.com/manage-profile/security/api-tokens>
+```
+
+The skill connects to `https://attraqt.atlassian.net` by default. The same credentials cover both Jira and Confluence.
+
+## Example prompts
+
+- `/dqm-jira-plan OCD-1234`
+- "Plan the implementation for OCD-567"
+- "Create a plan from ticket 1234" *(bare number resolves to OCD-1234)*
+
+## DQM context
+
+- Project key: `OCD-XXXX`
+- Product line filter: `"Crownpeak Product Line" = DQM`
+- Assigned team: Tardigrades
+
+## Related
+
+- [`jira-plan`](../../../../skills/library/jira-plan/) — the library version of this skill; requires Atlassian MCP and delegates to `implementation-plan`
+- [`implementation-plan`](../../../../skills/library/implementation-plan/) — use directly when you have ticket details but no Jira access

package/teams/dqm/skills/dqm-jira-plan/SKILL.md

@@ -0,0 +1,68 @@
+---
+name: dqm-jira-plan
+description: >-
+  Fetch a DQM Jira ticket from attraqt.atlassian.net and assemble full context,
+  then delegate to dqm-implementation-plan to produce the plan. Prefers Atlassian
+  MCP (atlassian-rovo); falls back to REST API with JIRA_EMAIL + JIRA_API_TOKEN.
+  DQM tickets use OCD-XXXX.
+---
+
+# DQM Jira Plan
+
+Fetches ticket context and delegates planning to `dqm-implementation-plan`.
+
+## Defaults
+
+| Setting | Value |
+|---------|-------|
+| Project | `OCD` — bare numbers resolve to `OCD-N` |
+| Instance | `https://attraqt.atlassian.net` (override with `JIRA_URL`) |
+| Team | `Tardigrades` |
+| Product Line | `DQM` |
+
+## Fast Path
+
+1. **Resolve key:** Full key → use directly. Bare number → prepend `OCD-`. Try git branch (e.g. `OCD-1234-slug` → `OCD-1234`). Unknown → ask user. Non-OCD key → proceed as-is and note deviation.
+2. **Connectivity:**
+   - MCP available (`atlassian-rovo`): use MCP tools for all calls.
+   - MCP unavailable: verify `JIRA_EMAIL` + `JIRA_API_TOKEN` are set. If missing, stop — see missing credentials message in Reference Notes. All REST calls target `${JIRA_URL:-https://attraqt.atlassian.net}`.
+3. **Fetch ticket:** `jira_get_issue(issue_key="{TICKET-KEY}")`. Extract: summary, description, status, assignee, priority, story points, acceptance criteria (`customfield_10016` or field containing "acceptance"), issue type, Team field, Crownpeak Product Line field. Flag if Team ≠ `Tardigrades` or Product Line ≠ `DQM`.
+4. **Fetch subtasks:** `jira_search(jql="parent = {TICKET-KEY} ORDER BY status ASC, priority DESC")`
+5. **Fetch linked issues:** extract from `fields.issuelinks` in the issue response.
+6. **Fetch comments:** last 10, most recent first. REST: see Reference Notes.
+7. **Fetch epic context:**
+   - Detect: `fields.parent` (issuetype = Epic) or `fields.customfield_10014`.
+   - If found: fetch epic summary/description; fetch siblings: `jira_search(jql='"Epic Link" = {EPIC-KEY} AND "Crownpeak Product Line" = DQM AND key != {TICKET-KEY} ORDER BY status ASC, priority DESC')`. If JQL fails on that field, drop the filter and retry.
+   - Large epics (20+ siblings): summarise; focus on In Progress and To Do.
+   - No epic: note as orphaned and continue.
+8. **Fetch Confluence pages:** get remote links from issue (`/rest/api/3/issue/{TICKET-KEY}/remotelink`); filter for `atlassian.net/wiki` URLs; fetch each page truncated to ~500 words. Extract page ID from URL path after `/pages/`. MCP: `confluence_get_page(page_id="{PAGE_ID}")`. If 403/404: include title + URL only.
+9. **Delegate to `dqm-implementation-plan`:** pass the assembled context as source material. The ticket key becomes the story name (e.g. `ocd-1234`) unless the user specified otherwise.
+
+## Reference Notes
+
+### REST Fallback Commands
+
+Base: `curl -s -u "$JIRA_EMAIL:$JIRA_API_TOKEN" -H "Content-Type: application/json" "${JIRA_URL:-https://attraqt.atlassian.net}"`
+
+| Data | Path |
+|------|------|
+| Issue | `/rest/api/3/issue/{TICKET-KEY}` |
+| Subtasks | `/rest/api/3/search?jql=parent+%3D+{TICKET-KEY}+ORDER+BY+status+ASC` |
+| Comments | `/rest/api/3/issue/{TICKET-KEY}/comment?maxResults=10&orderBy=-created` |
+| Remote links | `/rest/api/3/issue/{TICKET-KEY}/remotelink` |
+| Confluence page | `/wiki/rest/api/content/{PAGE_ID}?expand=body.view` — extract `body.view.value`, strip HTML tags |
+
+### Missing Credentials Message
+```
+Missing Jira credentials. Please set:
+  export JIRA_EMAIL=your.email@example.com
+  export JIRA_API_TOKEN=<token from https://id.atlassian.com/manage-profile/security/api-tokens>
+```
+
+### Edge Cases
+
+- Ticket not found (404): report clearly; may be moved, deleted, or inaccessible.
+- Non-OCD key: proceed as-is; note deviation from standard DQM project.
+- No description: proceed with summary + comments; note gap in clarifications.
+- Conflicting decisions in comments: pass them as open questions in the assembled context.
+- `"Crownpeak Product Line"` JQL not searchable: drop filter, retry, note fallback.

package/teams/dqm/skills/promote-to-harness/SKILL.md

@@ -0,0 +1,59 @@
+---
+name: promote-to-harness
+description: Promote an approved harness candidate into `coding-guidelines.md`, `AGENTS.md`, or `.github/copilot-instructions.md` to prevent repeat AI mistakes.
+---
+
+Add one rule at a time to the correct harness file.
+
+Do not edit harness files until the user confirms both rule text and target file.
+
+## Harness file responsibilities
+
+- `coding-guidelines.md`: coding patterns, naming, Java/Spring conventions, test strategy.
+- `AGENTS.md`: workflow, TDD, packaging, release, AWS, pipeline constraints.
+- `.github/copilot-instructions.md`: quick inline Copilot constraints.
+
+When in doubt: technical rule -> `coding-guidelines.md`; process rule -> `AGENTS.md`.
+
+## 1. Receive the candidate
+
+Accept one candidate with all required fields:
+- issue description
+- proposed rule text (one imperative sentence)
+- target file (one of the three above)
+- source (PR/comment/reference)
+
+If any field is missing, ask before proceeding.
+
+## 2. Check for duplicates
+
+Read the target harness file and check whether an equivalent rule already exists.
+
+- Match found: quote existing text and ask whether to refine instead of adding.
+- No match: proceed.
+
+## 3. Propose placement
+
+Identify section and exact insertion point, then show:
+- Section
+- Position (after line N / anchor text)
+- Proposed addition (`- <rule text>`)
+
+Ask for confirmation before writing.
+
+## 4. Apply
+
+On confirmation, insert the rule into the target file at the agreed position.
+
+Prefer appending to an existing relevant list; keep surrounding style.
+
+## 5. Confirm and summarise
+
+Report:
+
+- file and section updated
+- rule text as written
+- source reference
+
+Suggested commit message:
+`docs: (<JIRA-KEY>) promote harness rule from <source>` (when available), otherwise `docs: promote harness rule from <source>`

package/teams/dqm/skills/publish-pr/SKILL.md

@@ -0,0 +1,73 @@
+---
+name: publish-pr
+description: >-
+  Publish a draft PR for review: verify it's review-ready (description in sync with
+  the Jira ticket and the actual diff, no unchecked checklist items, reviewed by an AI
+  agent with no open agent comments), take it out of draft, and announce it in the team
+  Slack channel. Use when the user says "publish/release this PR", "take the PR out of
+  draft", or invokes /publish-pr.
+---
+
+# Publish PR
+
+Stages run in order: **verify → un-draft → announce**. Verify is blocking: if any check fails, report
+all results and STOP — do not un-draft or post. Continue only if the user says "publish anyway".
+Never merge; never change the base.
+
+## 1) Locate
+
+```sh
+gh pr view --json number,isDraft,title,body,url,baseRefName,headRefName
+```
+
+No PR → stop, suggest `create-pr`. Resolve ticket (`OCD-XXXX`) from title/branch; if none, ask.
+
+## 2) Verify (BLOCKING — run all, report together)
+
+- **a. PR-body checklist** — no unticked `- [ ]` in the PR description (unless user marked one N/A).
+- **a2. Spec/plan checklists** — for any spec/planning doc in this PR's diff (`specs/**`,
+  `docs/planning/**`), no unticked `- [ ]` remains; these track the story's ACs/phases. List file+line of any.
+- **b. Jira sync** — fetch ticket from `attraqt.atlassian.net` (Atlassian MCP; fall back to REST with
+  `JIRA_EMAIL`+`JIRA_API_TOKEN`). Fail if PR claims scope the ticket lacks, omits a stated AC, or
+  summaries materially disagree. Wording differences are fine.
+- **c. Diff sync** — `gh pr diff <number>`. Fail if the body describes work absent from the diff, or
+  the diff makes significant changes the body never mentions.
+- **d. AI review** — PR must have ≥1 AI-agent review and no unresolved threads it started. Agent =
+  reviewer login like `copilot-pull-request-reviewer[bot]`, `Copilot`, or a clearly-review `[bot]`.
+
+  ```sh
+  gh pr view <number> --json reviews --jq '.reviews[] | {author:.author.login, state:.state}'
+  gh api graphql -f query='query($o:String!,$r:String!,$p:Int!){repository(owner:$o,name:$r){
+    pullRequest(number:$p){reviewThreads(first:100){nodes{isResolved comments(first:1){nodes{author{login}}}}}}}}' \
+    -F o=<owner> -F r=<repo> -F p=<number>
+  ```
+
+  Fail (and list specifics) if no agent review exists — request one via `request_copilot_review` —
+  or if any thread whose first comment is by an agent has `isResolved:false`.
+
+## 3) Un-draft (only after all pass)
+
+```sh
+gh pr ready <number>
+```
+
+Already non-draft → note it, continue.
+
+## 4) Announce in Slack
+
+No Slack tool → skip, report "published, Slack skipped (no connection)". Otherwise:
+
+1. Resolve `#tardigrades` (Crownpeak) via `slack_search_channels` (query `tardigrades`); if ambiguous, confirm with user.
+2. Compose a short message: **repo name**, **ticket title + key**, **PR link**, **1–2 line summary**.
+   Get the repo via `gh repo view --json name --jq .name`. Example:
+   ```text
+   :eyes: Ready for review — `dqm-scim-service` — *OCD-33443: GET /Users/{id}*
+   <PR_URL|#NN Add GET /Users/{id}>
+   Returns a single user by id; DELETE now 404s on unknown/cross-tenant.
+   ```
+3. Show the exact text + target channel and wait for explicit approval (revise + re-confirm on edits).
+4. Post with `slack_send_message` only after approval (or `slack_send_message_draft` if user prefers to send it).
+
+## Done
+
+Report: checks passed · PR now ready (or already was) · Slack posted to `#tardigrades` / skipped / not approved.

package/teams/dqm/skills/triage-pr-comments/SKILL.md

@@ -0,0 +1,119 @@
+---
+name: triage-pr-comments
+description: Triage open PR review comments and return recommendations before any code/reply/git write actions.
+---
+
+Triage GitHub PR comments in analysis-only mode.
+
+## Operating mode (default)
+
+- No file edits.
+- No GitHub replies.
+- No `git add`, `git commit`, or `git push`.
+- Do not perform any write action unless explicitly approved by the user.
+- Do not auto-transition from triage to implementation; wait for explicit per-comment approval.
+
+Use `gh` when available. If `gh` is unavailable/unauthenticated, ask the user for PR link + comment context and continue manually.
+
+## 1) Build unresolved triage set
+
+Preferred source: review-thread metadata + issue-level comments.
+
+- Include review threads where:
+  - `isResolved == false`
+  - `isOutdated == false`
+- From each included thread, use only the latest comment as the actionable item.
+- Include issue-level PR comments that still require action.
+- Do not exclude bot authors.
+- De-duplicate by comment ID/URL.
+- Sort newest first by `updatedAt`/`updated_at`.
+
+If user asks for "today" or "recent", apply recency filter after unresolved-set construction.
+
+## 2) Classify each comment (exactly one)
+
+- `requires-code-change`
+- `requires-doc-change`
+- `explanation-only`
+- `needs-clarification`
+- `decline-with-reason`
+
+For each comment, capture:
+
+1. Assessment (request + validity)
+2. Proposed action (minimal code/doc/test change plan; no edits yet)
+3. Impact/risk (scope, regressions, dependencies)
+4. Verification plan (tests/lint/checks if implemented)
+5. Draft reply (concise, professional, technical refs in backticks)
+6. Harness candidate (optional):
+   - rule text (single imperative sentence)
+   - target file: `docs/coding-guidelines.md`, `AGENTS.md`, or `.github/copilot-instructions.md`
+
+Inline draft-reply protocol:
+- Start with `🤖 **(AI):**`
+- Use a factual/professional tone
+- If code change: what changed + why (1-2 sentences)
+- If no code change: clear technical reasoning, not acknowledgement-only text
+- Use backticks for technical references (`files`, `symbols`, `flags`, `variables`)
+
+## 3) Ambiguity rule
+
+If intent is ambiguous or multiple valid fixes exist, stop and ask user to choose:
+
+Comment <id> is ambiguous. Which direction should I take?
+1) <option-a>
+2) <option-b>
+3) <option-c>
+
+Do not guess.
+
+## 4) Return prioritized triage report
+
+Group by priority:
+
+- High: correctness/security/data loss/regression risk
+- Medium: behavior/test coverage/maintainability
+- Low: style/wording/non-functional nits
+
+For each comment, return:
+
+- ID + link/context
+- Classification
+- Decision: `implement` | `reply-only` | `clarify` | `decline`
+- Proposed change summary (no edits; specify code vs doc-only)
+- Draft reply
+- Verification commands (if implemented)
+- Harness candidate (rule + target file) or blank
+
+Also include totals:
+
+- comments by classification
+- decisions (`implement` / `reply-only` / `clarify` / `decline`)
+- harness candidate count by target file
+- open questions needing user input
+
+## 5) Ask for execution approval
+
+Ask exactly:
+
+1. Which comment IDs should be implemented now?
+2. Which draft replies should be posted now?
+3. Run verification commands after implementation? (yes/no)
+4. Stage/commit/push after verification? (yes/no)
+5. Promote any harness candidates now? (yes/no; list IDs)
+
+If posting replies is approved, use this posting protocol:
+
+- Post only after related implementation/verification is complete for that comment.
+- ID safety: never use GraphQL node IDs (for example `PRRC_*`) for REST reply endpoints; use numeric PR review comment IDs from `repos/<owner>/<repo>/pulls/<number>/comments`.
+- Inline review-comment reply endpoint:
+  - `repos/<owner>/<repo>/pulls/<number>/comments/<comment_id>/replies`
+- Issue-level PR comment endpoint:
+  - `repos/<owner>/<repo>/issues/<number>/comments`
+- JSON safety: do not build non-trivial `{"body":"..."}` payloads inline; serialize with a JSON tool and post via `--input <json-file>`.
+- Temp-file safety: create payload files with `mktemp`; if `/tmp` is not writable, use a workspace-local temp path.
+- Preflight: verify target comment exists and is replyable before posting.
+- On `404`/`400` posting errors, stop and fix ID/payload generation before retrying; do not mark as posted.
+- PowerShell safety: avoid `gh api -f body="..."` for markdown/backticks; write JSON body to a UTF-8 (no BOM) temp file and post with `--input <tmp-file>`.
+
+Do not execute write actions without explicit approval.