@harness-engineering/cli 4.0.1 → 4.2.0

package/dist/agents/skills/cursor/harness-execution/SKILL.md

@@ -131,6 +131,19 @@ RMH005 (`harness validate`).
 
    - If no roadmap row matches this plan (e.g. ad-hoc execution), skip the claim.
 
+#### Step 0.5: Plan parallelization (standard automatic parallelism)
+
+Before the per-task loop, decide the safe parallel structure so independent tasks dispatch concurrently by default (no human typing "in parallel").
+
+1. Collect this run's tasks with their `files` and `dependsOn` (from the plan's task headers) and call the `plan_parallelization` MCP tool (`{ path, tasks, depth: 1 }`). It returns `ParallelizationPlan` (`waves[]`, `serialized[]`, `cyclic[]`, `narration`).
+2. If `cyclic` is non-empty, STOP and escalate (dependency cycle = plan defect). Do not execute.
+3. Emit `narration` (announce-and-proceed — do not pause).
+4. Run `serialized` tasks first (serially, in order — cross-bucket prerequisites), then process `waves` **in array order** (topologically sorted; do not reorder, do not key off `firing` alone).
+5. Per wave: `auto-dispatch` (multi-task) → dispatch the wave via **harness-parallel-agents** with worktree-per-unit isolation (`docs/guides/agent-worktree-patterns.md`), announce and proceed; `confirm` → one plain-text confirmation, then parallel or serial per the answer; `serialize` / single-task → run through the per-task loop below serially.
+6. **Serial fallback preserved:** when independent tasks < `minWaveSize` (default 3), a `confirm` is declined, or no graph is available and the human does not confirm, run every task through the per-task loop below serially — the standing "when in doubt, run serially" default.
+
+Tasks dispatched into a parallel wave are executed by harness-parallel-agents' focused agents; tasks that fall to serial run through the loop below unchanged.
+
 For each task, starting from current position:
 
 1. **Read task instructions completely** before writing any code.

package/dist/agents/skills/cursor/harness-parallel-agents/SKILL.md

@@ -2,12 +2,15 @@
 
 > Dispatch independent tasks to concurrent agents, integrate results, and verify no conflicts. Only for truly independent problems.
 
+**Invoked automatically by `harness-autopilot` (and standalone `harness-execution`), not only manually.** When a plan's phase has an auto-dispatch wave, the execution loop calls this skill to run that wave. In that mode the caller supplies worktree-per-unit isolation per `docs/guides/agent-worktree-patterns.md` (one worktree per task, sequential commits, squash-merge on integrate) and has already verified independence via `plan_parallelization`; this skill still owns the focused agent briefs (Step 2), concurrent dispatch (Step 3), and integration/verification (Steps 4–5). Manual invocation (a human asking to "work in parallel") continues to work unchanged.
+
 ## When to Use
 
 - When 3 or more tasks are truly independent (no shared state, no shared files, different subsystems)
 - When tasks involve investigation or implementation in separate parts of the codebase
 - When parallel execution would meaningfully reduce wall-clock time
 - When a plan has tasks explicitly marked as parallelizable
+- When `harness-autopilot`/`harness-execution` reaches an `auto-dispatch` (or confirmed) wave from `plan_parallelization` — this skill is the wave's dispatcher
 - NOT when failures across tasks might be related (investigate serially to find the common cause)
 - NOT when tasks need full system understanding to complete correctly
 - NOT when agents would modify the same files or shared state

package/dist/agents/skills/cursor/harness-planning/SKILL.md

@@ -256,7 +256,7 @@ Report progress: `**[Phase 2/4]** DECOMPOSE — mapping file structure and creat
 ### Phase 3: SEQUENCE — Order Tasks and Identify Dependencies
 
 1. **Order by dependency.** Types before implementations. Implementations before integrations. Integration tasks (tagged `category: "integration"`) after all implementation tasks. Tests alongside implementations (same task, TDD style).
-2. **Identify parallel opportunities.** Tasks touching different subsystems with no shared state can be marked parallelizable.
+2. **Identify parallel opportunities and record dependency edges.** Tasks touching different subsystems with no shared state can run in parallel. Record each task's real dependencies as `dependsOn` (the task IDs it must follow) in the task header `**Depends on:**` line, and keep the task's `**Files:**` list accurate — together these are exactly the edges `plan_parallelization` consumes (explicit `dependsOn` unioned with file-overlap edges) to build the wave DAG at execution time. A task with no dependencies records `**Depends on:** none`.
 3. **Number tasks sequentially.** Use `Task 1`, `Task 2`, etc. Dependencies reference task numbers.
 4. **Estimate total time.** Sum 2-5 minutes per task. If total exceeds available time, identify a milestone boundary for pausing.
 
@@ -327,6 +327,8 @@ One sentence.
 
 **Depends on:** none | **Files:** path/to/file.ts, path/to/file.test.ts
 
+<!-- `Depends on` lists the task IDs this task must follow (its `dependsOn` edges); `Files` is the independence-checking input. Both feed `plan_parallelization` during execution. -->
+
 1. Create test file with exact test code
 2. Run test — observe failure
 3. Create implementation with exact code

package/dist/agents/skills/cursor/pre-merge-brief/SKILL.md

@@ -0,0 +1,86 @@
+# Pre-Merge Brief
+
+> The harness pointed at the human who clicks merge. A thin wrapper over `harness pre-merge-brief` that composes a senior-facing accountability brief — the diff summary, the multi-persona review verdict (from `review-ci --json`), the curated **Signal status** snapshot, the outcome-eval result, and a derived **"👀 Worth your eyes"** section — and posts it as a single sticky PR comment (upsert by marker). All composition and degradation logic lives in the command; this skill orchestrates invocation, reports which sections degraded, and hands off. Advisory and non-blocking: the brief never flips the review gate.
+
+## When to Use
+
+- On every PR, so the senior engineer who merges sees "you are pushing this — here's what deserves your eyes" before they click merge.
+- `on_pr` (dogfooded via the `required-review` workflow, reusing that run's `review-ci --json` artifact) and `manual` (a senior running it locally against the current branch's PR).
+- NOT as a merge gate — the acknowledgment gate is deliberately deferred (spec D3). The brief is advisory; the review gate's exit code is what blocks.
+- NOT a replacement for `review-ci` — this skill CONSUMES the review verdict, it does not re-run the review (spec D1).
+- NOT for recomputing signals a different way — signals come from `@harness-engineering/signals` via the command (spec D2/D6).
+
+## Process
+
+### Phase 1: GATHER — Resolve inputs
+
+1. Locate the `review-ci --json` artifact for this run and record its path for `--from`. In CI it is the JSON the `required-review` workflow's `review-ci` step wrote (e.g. `/tmp/review.json`); locally, run `harness review-ci --json <path>` first if a verdict is wanted. Absent `--from` is tolerated — the review section degrades to "unavailable".
+2. Resolve the diff range for `--diff` (default `origin/<base>...HEAD` via the command's own resolver). Override only when the base is non-standard.
+3. Resolve the head sha for `--head` (default `git rev-parse HEAD`) — used for the `execution_outcome` graph lookup. Pre-merge the node is commonly absent, which is the documented degradation path, not an error.
+4. If posting (`--comment`), confirm `gh` is authenticated. Delivery failure never crashes the command (spec S1): it prints the brief and warns, still exiting 0.
+
+### Phase 2: COMPOSE — Run the command
+
+Invoke `harness pre-merge-brief` with the resolved inputs:
+
+```bash
+harness pre-merge-brief --from <review.json> --diff <range> --head <sha> [--comment]
+```
+
+The command builds the six-section brief (marker + header → Diff summary → Review verdict → **Signal status** → Outcome evaluation → **👀 Worth your eyes**) and, with `--comment`, upserts the sticky PR comment by its marker (`<!-- harness:pre-merge-brief -->`) — patching the existing comment in place rather than posting a new one on each push. Without `--comment` it prints the brief to stdout. Each input degrades independently to an explicit "unavailable" line; the command exits 0 on a successful render regardless of which inputs were present.
+
+### Phase 3: REPORT — Surface what matters
+
+1. Report which sections rendered with real data and which degraded to "unavailable / not yet evaluated", so the senior knows the brief's coverage.
+2. Surface the **"👀 Worth your eyes"** items verbatim — the union of blocking review findings, signals in `warn`/`alert`, and unmet outcome criteria. This is the section the accountable human should read first.
+
+### Phase 4: HANDOFF — Advisory transition
+
+Emit the transition via `emit_interaction`. The brief is advisory and non-blocking: it never flips the review gate's pass/fail status (spec D3, D4). In the dogfood workflow the brief step is `continue-on-error`, so a brief failure never fails the PR.
+
+## Harness Integration
+
+- **`harness pre-merge-brief`** — the command this skill wraps. Flags: `--from <path>` (review-ci verdict JSON), `--comment` (sticky-upsert to the current branch's PR via `gh`), `--diff <range>`, `--head <sha>`. Pure render (`buildBriefBody`) + injected seams (`postBrief`, `RunGit`, graph store); no `process.exit` in the pure core.
+- **`review-ci`** — upstream producer of the review verdict. This skill reuses its `--json` artifact via `--from`; it never re-runs the review (D1). `review-ci` remains the single source of review truth.
+- **`@harness-engineering/signals`** — the shared leaf package (extracted in spec Phase 1/D6) providing `gatherSignals`. The command computes the Signal status snapshot from it; the CLI does not route signal computation through the dashboard app.
+- **`execution_outcome` graph nodes** — the outcome-eval result, looked up by head sha from `.harness/graph`; commonly absent pre-merge (degrades to "not yet evaluated").
+- **`required-review.yml` (dogfood)** — the `on_pr` delivery path: a `continue-on-error` step runs the brief after the existing `review-ci` run, reusing its artifact (spec Phase 4/D4). Adopter template graduation is a tracked follow-up (D5).
+
+## Gates
+
+- **Never re-run the review.** Consume `review-ci --json`; do not invoke the review pipeline from this skill (D1).
+- **Never block the merge.** The brief is advisory; the review gate's exit code is authoritative. No acknowledgment gate in v1 (D3).
+- **Never crash `--comment`.** A `gh`/PR delivery failure prints the brief and warns, still exiting 0 (S1).
+- **Thin wrapper only.** No brief composition, signal computation, or union logic in the skill — all of it lives in the command.
+
+## Success Criteria
+
+Maps to spec `docs/changes/senior-accountability-surface/proposal.md`. This skill satisfies criterion #2 (the skill wrapping the command, `on_pr` + `manual`) and supports #1/#3/#4 by driving the command whose pure functions are unit-tested. Introduces no new `harness validate` findings.
+
+## Escalation
+
+- **No PR for the current branch (`--comment`).** The command warns and prints the brief to stdout instead of posting, still exiting 0. Surface the warning; do not treat it as a failure.
+- **No review artifact (`--from` missing/absent).** The review-verdict section degrades to "unavailable". If a verdict is wanted, run `harness review-ci --json <path>` first and pass it.
+- **`gh` unauthenticated or API error while posting.** Delivery fails soft (brief printed, one-line stderr warning, exit 0). Fix `gh auth` and re-run; nothing is lost.
+- **Signals or outcome-eval unavailable.** Each degrades independently to its "unavailable"/"not yet evaluated" line — expected pre-merge, not an error. Do not block the brief on them.
+- **Someone asks to make the brief block merges.** That is the deferred acknowledgment gate (spec D3), a separate future spec. Keep the brief advisory; point them at the follow-up roadmap row.
+
+## Examples
+
+### Example: brief on a PR in CI (dogfood)
+
+The `required-review.yml` workflow runs `review-ci --json /tmp/review.json`, then this skill's command:
+
+```bash
+harness pre-merge-brief --from /tmp/review.json --diff "origin/main...HEAD" --comment
+```
+
+The brief is composed and upserted as a sticky PR comment. The review found one blocking finding and two `alert` signals, so **👀 Worth your eyes** lists exactly those three; the outcome section shows "not yet evaluated" (no `execution_outcome` node pre-merge). The step is `continue-on-error`, so even if `gh` posting fails the review gate is unaffected.
+
+### Example: senior running it locally
+
+```bash
+harness pre-merge-brief --comment
+```
+
+No `--from`, so the review-verdict section renders "unavailable"; signals are gathered live and the diff summary uses the default `origin/<base>...HEAD` range. The senior sees the current signal status and diff before clicking merge.

package/dist/agents/skills/cursor/pre-merge-brief/skill.yaml

@@ -0,0 +1,67 @@
+name: harness-pre-merge-brief
+version: "0.1.0"
+description: >-
+  Thin-wrapper skill that runs the `harness pre-merge-brief` command to compose
+  and post the senior-facing pre-merge accountability brief — the diff summary,
+  the multi-persona review verdict (from review-ci --json), the curated Signal
+  status snapshot, the outcome-eval result, and a derived "Worth your eyes"
+  section — as a single sticky PR comment (upsert by marker). All composition and
+  degradation logic lives in the command; the skill orchestrates invocation,
+  communicates which sections degraded to "unavailable", and hands off. Runs on
+  on_pr and manual. The harness pointed at the human who clicks merge.
+stability: draft
+cognitive_mode: constructive-architect
+triggers:
+  - on_pr
+  - manual
+platforms:
+  - claude-code
+  - gemini-cli
+  - cursor
+  - codex
+tools:
+  - Bash
+  - Read
+  - Glob
+  - Grep
+  - emit_interaction
+cli:
+  command: harness pre-merge-brief
+  args:
+    - name: from
+      description: Path to the review-ci --json CiReviewResult artifact to reuse
+      required: false
+    - name: comment
+      description: Upsert the brief as a sticky PR comment via gh (by marker)
+      required: false
+    - name: diff
+      description: "git diff range for the diff summary (e.g. origin/main...HEAD)"
+      required: false
+    - name: head
+      description: "head commit sha for the outcome-eval lookup (default: git rev-parse HEAD)"
+      required: false
+mcp:
+  tool: run_skill
+  input:
+    skill: harness-pre-merge-brief
+    path: string
+type: rigid
+tier: 2
+phases:
+  - name: gather
+    description: Locate the review-ci --json artifact, resolve the diff range, confirm gh auth for --comment
+    required: true
+  - name: compose
+    description: Run `harness pre-merge-brief` with the resolved inputs; the command builds the brief and (with --comment) upserts the sticky PR comment
+    required: true
+  - name: report
+    description: Report which sections rendered and which degraded to "unavailable"; surface the "Worth your eyes" items
+    required: true
+  - name: handoff
+    description: Emit the transition; the brief is advisory (non-blocking) and never flips the review gate
+    required: true
+state:
+  persistent: false
+depends_on:
+  - harness-code-review
+  - outcome-eval

package/dist/agents/skills/gemini-cli/harness-autopilot/SKILL.md

@@ -108,6 +108,37 @@ On return: read `planPath` from `{sessionDir}/handoff.json`. Complexity override
 
 ### EXECUTE
 
+**Pre-dispatch: plan parallelization (standard automatic parallelism).** Before dispatching tasks, decide the safe parallel structure. This is orchestration, not reimplementation — autopilot chooses HOW to dispatch; the persona agents still do the work.
+
+1. Collect the phase's tasks with their `files` and `dependsOn` (from the plan's task headers). Call the `plan_parallelization` MCP tool:
+
+   ```json
+   {
+     "path": "<project-root>",
+     "tasks": [{ "id": "task-1", "files": ["..."], "dependsOn": [] }],
+     "depth": 1
+   }
+   ```
+
+   It returns a `ParallelizationPlan`: `waves[]` (each `{ tasks, severity, firing, analysisLevel }`), `serialized[]`, `cyclic[]`, `narration`.
+
+2. **If `cyclic` is non-empty:** STOP. Surface the cycle and route back to PLAN/APPROVE_PLAN (a dependency cycle is a plan defect). Do not dispatch.
+
+3. **Announce (announce-and-proceed):** emit `narration` verbatim. Do NOT pause here — announcing is not a gate.
+
+4. **Dispatch in dependency order — prerequisites first, then waves in array order:**
+   - First, run every task in `serialized` (high-severity-group / cycle-adjacent members) **serially**, one `harness-task-executor` per task, in listed order. These are cross-bucket prerequisites: they MUST complete before any wave that depends on them.
+   - Then process `waves` **in array order**. The `waves` array is already topologically sorted (earlier waves are prerequisites of later ones). Do NOT reorder waves and do NOT key dispatch off the `firing` field alone — the Phase-2 cross-bucket cap (a wave depending on a serialized/cyclic task is downgraded to `confirm` and marked "cross-bucket prerequisite gates this wave" in `narration`) is only sound if serialized/cyclic ran first and waves run in order.
+
+5. **For each wave, honor its `firing`:**
+   - `auto-dispatch` (multi-task): emit that wave's line from `narration`, then dispatch the wave via the **harness-parallel-agents** skill with **worktree-per-unit isolation** per `docs/guides/agent-worktree-patterns.md` ("Worktree-per-Milestone" / "Parallel Agent Work": one worktree per task, sequential commits, squash-merge at integrate). **Announce and proceed — do NOT stop for confirmation.**
+   - `confirm`: surface the wave and its `narration` line, then take exactly ONE plain-text confirmation — "Dispatch wave [{tasks}] in parallel? (yes / serial)". `yes` → dispatch via harness-parallel-agents (worktree-per-unit). `serial` or decline → run the wave's tasks serially (`harness-task-executor` each). Record the choice in `decisions[]`.
+   - `serialize`, or any single-task wave: run serially via `harness-task-executor`, exactly as today.
+
+6. **Serial fallback is preserved** when a phase has fewer than `minWaveSize` (default 3) independent tasks, when a `confirm` is declined, or when no graph is available and the human does not confirm — honoring the standing "when in doubt, run serially" default.
+
+Each dispatched unit (parallel wave or serial task) then follows the existing per-task contract below (state.json per task, checkpoints, retry budget).
+
 Dispatch harness-task-executor:
 
 ```
@@ -204,7 +235,7 @@ Persist findings to `{sessionDir}/phase-{N}-review.json`. No blocking → PHASE_
 ### DONE
 
 1. Present: total phases, tasks, retries, time, `finalReview.status` + findings count, any overridden findings.
-2. Ask "Create a PR? (yes / no)."
+2. Ask "Create a PR? (yes / no)." When creating the PR, include a bare closing line `Closes #<N>` where `<N>` is the issue number from the roadmap row's `External-ID`. The keyword MUST sit IMMEDIATELY before the ref — no intervening words (`Closes #<N>`, never `Closes roadmap #<N>`), or GitHub will not link/close the issue and roadmap auto-done will skip the row.
 3. Write final handoff to `{sessionDir}/handoff.json`. Append learnings to `.harness/learnings.md`. Call `promoteSessionLearnings(projectPath, sessionSlug)`. If learnings count > 30, suggest `harness learnings prune`.
 4. If `docs/roadmap.md` exists: call `manage_roadmap update` to set feature done. Skip if not found.
 5. Write final `writeSessionSummary()`. Set `currentState: "DONE"` in autopilot-state.json.
@@ -254,13 +285,14 @@ Persist findings to `{sessionDir}/phase-{N}-review.json`. No blocking → PHASE_
 
 ## Rationalizations to Reject
 
-| Rationalization                                                         | Reality                                                                                           |
-| ----------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------- |
-| "Low complexity means I can skip APPROVE_PLAN"                          | Low complexity means auto-approval only when no signals fire. Signals override complexity.        |
-| "I can inline planning logic instead of dispatching to harness-planner" | Iron Law. Autopilot delegates, never reimplements. No exceptions.                                 |
-| "Retry budget exhausted but one more approach might work"               | 3-attempt budget prevents compounding failure. Exceeding it without human input is unrecoverable. |
-| "Keeping research in conversation is faster than scratchpad"            | Scratchpad gated by rigor level. At standard/thorough, >500 words must go to scratchpad.          |
-| "Plan auto-approved, so I can skip recording the decision"              | Every approval—auto or manual—is recorded in `decisions[]`. That array is the audit trail.        |
+| Rationalization                                                         | Reality                                                                                                                                                             |
+| ----------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| "Low complexity means I can skip APPROVE_PLAN"                          | Low complexity means auto-approval only when no signals fire. Signals override complexity.                                                                          |
+| "I can inline planning logic instead of dispatching to harness-planner" | Iron Law. Autopilot delegates, never reimplements. No exceptions.                                                                                                   |
+| "Retry budget exhausted but one more approach might work"               | 3-attempt budget prevents compounding failure. Exceeding it without human input is unrecoverable.                                                                   |
+| "Keeping research in conversation is faster than scratchpad"            | Scratchpad gated by rigor level. At standard/thorough, >500 words must go to scratchpad.                                                                            |
+| "Plan auto-approved, so I can skip recording the decision"              | Every approval—auto or manual—is recorded in `decisions[]`. That array is the audit trail.                                                                          |
+| "`Closes roadmap #123` reads fine, GitHub will figure out the issue"    | An intervening word breaks GitHub's closing-keyword parser: `closingIssuesReferences` stays empty and auto-done leaves the row `planned`. Use a bare `Closes #123`. |
 
 ## Success Criteria
 

package/dist/agents/skills/gemini-cli/harness-catalog-retrospective/SKILL.md

@@ -0,0 +1,124 @@
+# Harness Catalog Retrospective
+
+> Monthly retrospective over skill-adoption telemetry. Reads `.harness/metrics/adoption.jsonl`, ranks the most-invoked, most-failing, and abandoned-mid-workflow skills, flags ever-invoked skills that have gone quiet, and reports how much of the catalog emits any telemetry at all. Produces a dated Markdown report and surfaces the highlights that warrant follow-up. Compounding-via-learning at the catalog grain.
+
+## When to Use
+
+- On a regular cadence (monthly is the intended grain) to review how the skill catalog is actually being used.
+- After a milestone, to see which skills carried the work and which never fired.
+- When deciding what to prune, fix, or promote in the catalog — the report feeds catalog-rationalization work.
+- NOT as a real-time dashboard — for point-in-time lookups use `harness adoption skills` / `harness adoption recent`.
+- NOT when `.harness/metrics/adoption.jsonl` is absent or empty (the report will be honest but empty; there is nothing to retrospect on yet).
+
+## Process
+
+### Iron Law
+
+**Separate real signal from telemetry gaps before you recommend anything.** The single most common misread of this data is treating "no telemetry" as "abandoned." Adoption records are emitted only from instrumented entry points, so a skill with zero records is usually uninstrumented, not unused. The report's coverage line and the stale-skills section exist to keep that distinction visible — never collapse it.
+
+---
+
+### Phase 1: SCAN — Derive the Report
+
+1. Run the retrospective command from the project root:
+
+   ```bash
+   harness adoption retrospective            # writes docs/retrospectives/<date>.md
+   harness adoption retrospective --no-write # print to stdout without writing a file
+   harness adoption retrospective --json     # structured output for further processing
+   ```
+
+   Optional flags: `--inactive-days <n>` (stale threshold, default 90), `--top <n>` (rows per section, default 10), `--out <path>` (override the output file).
+
+2. The command reads `.harness/metrics/adoption.jsonl` via `readAdoptionRecords`, derives the report via `getCatalogRetrospectiveReport`, and renders it via `renderRetrospectiveMarkdown` (all in `@harness-engineering/core`). Coverage context is computed against the skills discovered under `agents/skills/claude-code/`; when that directory is absent (a consumer project), the coverage line is omitted rather than reporting a false zero.
+
+3. If there are no records, say so plainly and stop: "No adoption telemetry found at `.harness/metrics/adoption.jsonl`. Nothing to retrospect on yet."
+
+### Phase 2: INTERPRET — Signal vs. Noise
+
+Read the report with these discriminations:
+
+- **Coverage line first.** "N/total catalog skills have emitted telemetry" frames everything below it. A low ratio means the rankings describe the _instrumented_ slice, not the whole catalog. State the ratio explicitly in your summary.
+- **Failing skills are not automatically broken.** Some commands fail _by design_ (a gate like `ci.check` returning non-zero on a real violation is the gate working). Before flagging a high failure rate as a problem, note whether the skill is a checker/gate whose failures are expected. Call out only failures that look like defects (crashes, unexpected non-zero on clean input).
+- **Abandoned mid-workflow** uses the broadened definition: an explicit `abandoned` outcome, or a non-completed run that had already reached ≥1 phase. Small counts here are meaningful — a workflow skill people start and bail out of mid-way is a UX signal even at n=1.
+- **Stale skills** are drawn only from _ever-invoked_ skills quiet ≥ the threshold. When the record window is shorter than the threshold, the section says so and reports nothing — do not present that emptiness as "everything is healthy."
+
+### Phase 3: REPORT — Surface and Recommend
+
+1. Confirm where the report was written (`docs/retrospectives/<date>.md`) or present the rendered Markdown.
+2. Summarize the 3–5 findings that actually warrant action, each tied to a section and a number. Prefer specifics ("`cli/review-ci` failed 23/23 — likely a real defect, worth a look") over restating the tables.
+3. When the coverage ratio is the dominant finding (e.g. most of the catalog is uninstrumented), name that as the top follow-up: instrumentation, not pruning, is the lever.
+4. Do not delete, prune, or edit skills from this skill — it reports. Hand any pruning decision to the human or to catalog-rationalization work.
+
+---
+
+## Harness Integration
+
+- **`harness adoption retrospective`** — the CLI entry point (a subcommand of the existing `adoption` command group). Writes `docs/retrospectives/<date>.md` by default.
+- **`getCatalogRetrospectiveReport` / `renderRetrospectiveMarkdown` / `isAbandonedMidWorkflow`** — the pure aggregation + render functions in `@harness-engineering/core` (`packages/core/src/adoption/retrospective.ts`). Callers can supply a fixed `now` and `catalogSkills` for deterministic output.
+- **`readAdoptionRecords`** — reads and parses `.harness/metrics/adoption.jsonl` (read-only; the file is appended by the adoption-tracker hook, never by this skill).
+- **`harness adoption skills` / `recent` / `skill <name>`** — the point-in-time siblings; this skill is the periodic, persisted counterpart.
+
+## Success Criteria
+
+1. The retrospective is derived from `.harness/metrics/adoption.jsonl` without mutating it.
+2. The report ranks top-invoked, top-failing, and abandoned-mid-workflow skills, and flags ever-invoked stale skills.
+3. The report states telemetry coverage (how much of the catalog emits any signal) when the catalog is discoverable.
+4. The stale-skills section notes when the record window is shorter than the inactivity threshold instead of silently reporting zero.
+5. The summary separates real signal (defect-shaped failures, mid-workflow abandonment) from telemetry gaps (uninstrumented skills) and from expected gate failures.
+6. A dated report is written to `docs/retrospectives/<date>.md` (unless `--no-write`/`--json` is requested).
+7. The skill recommends but never prunes, edits, or deletes catalog skills.
+
+## Rationalizations to Reject
+
+| Rationalization                                                                        | Reality                                                                                                                                                             |
+| -------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| "756 skills have no telemetry, so 756 skills are abandoned — recommend deleting them." | Zero telemetry almost always means _uninstrumented_, not unused. The coverage line exists to prevent exactly this misread; the fix is instrumentation, not pruning. |
+| "`ci.check` fails 97% of the time — it's broken."                                      | A gate returning non-zero on a real violation is the gate working. Check whether the skill is a checker before flagging its failures as defects.                    |
+| "The stale section is empty, so the catalog is healthy."                               | If the record window is shorter than the threshold, the signal simply cannot fire yet. Empty ≠ healthy; report the window caveat.                                   |
+| "n=1 abandonment is noise, ignore it."                                                 | A workflow skill users start and bail out of mid-way is a UX signal even at low n. Surface it; let the human weigh it.                                              |
+| "I'll prune the low-usage skills while I'm here."                                      | This skill reports; it does not prune. Pruning is a human/catalog-rationalization decision.                                                                         |
+
+## Examples
+
+### Example: Monthly retrospective on the dogfood repo
+
+**Context:** ~67 days of telemetry (3.2k records) across 50 invoked skills, run at month end.
+
+**Phase 1 — SCAN:**
+
+```bash
+harness adoption retrospective
+# → Catalog retrospective written to docs/retrospectives/2026-07-06.md
+#   3246 records · 50 skills · window 67d
+```
+
+**Phase 2 — INTERPRET:** The report's overview leads with `Telemetry coverage: 5/761 catalog skills have emitted telemetry (756 never invoked)`. Top-invoked is dominated by `cli/*` commands; `cli/ci.check` shows a 97% failure rate; the abandoned-mid-workflow section lists four workflow skills at n=1; the stale section is empty with the note that the 67-day window is shorter than the 90-day threshold.
+
+**Phase 3 — REPORT:**
+
+```
+Retrospective written to docs/retrospectives/2026-07-06.md. Findings that warrant action:
+
+1. Coverage is the headline: only 5/761 catalog skills emit any telemetry. The rankings
+   describe the instrumented slice, not the catalog. Top follow-up is instrumentation, not pruning.
+2. `cli/ci.check` failed 97% (721/741) — but it is a gate; non-zero on a real violation is
+   expected. Not flagged as a defect.
+3. `cli/review-ci` failed 23/23 (100%) — defect-shaped, worth a look. Routed to debugging.
+4. Four workflow skills were abandoned mid-run (n=1 each) — low volume, a UX signal to watch.
+5. Stale skills: none — the 67-day window can't satisfy the 90-day threshold yet.
+```
+
+No skills were pruned or edited — the pruning decision is left to the human.
+
+## Gates
+
+- **No mutation of `adoption.jsonl`.** The telemetry file is read-only input.
+- **No catalog edits.** This skill never adds, edits, or deletes skills — it only reports on them.
+- **Coverage must be stated when discoverable.** If the catalog can be scanned, the summary must include the telemetry-coverage ratio so rankings are read in context.
+
+## Escalation
+
+- **When there are no records:** State that telemetry is absent/empty and stop. Suggest confirming the adoption-tracker hook is installed if telemetry is unexpectedly missing.
+- **When coverage is very low:** Name instrumentation as the top follow-up and note that the rankings describe only the instrumented slice.
+- **When a failing skill looks like a real defect:** Flag it specifically (skill, failure count/rate, why it looks defect-shaped) and route it to debugging or an issue, rather than burying it in the table.

package/dist/agents/skills/gemini-cli/harness-catalog-retrospective/skill.yaml

@@ -0,0 +1,48 @@
+name: harness-catalog-retrospective
+version: '1.0.0'
+description: Monthly retrospective over skill-adoption telemetry — ranks most-invoked, failing, and abandoned-mid-workflow skills, flags stale ones, and reports catalog telemetry coverage
+stability: static
+cognitive_mode: analytical-reporter
+triggers:
+  - manual
+  - on_milestone
+platforms:
+  - claude-code
+  - gemini-cli
+  - cursor
+  - codex
+tools:
+  - Bash
+  - Read
+  - Glob
+  - Grep
+cli:
+  command: harness skill run harness-catalog-retrospective
+  args:
+    - name: path
+      description: Project root path
+      required: false
+    - name: inactive-days
+      description: 'Inactivity threshold in days for the stale-skills section (default: 90)'
+      required: false
+mcp:
+  tool: run_skill
+  input:
+    skill: harness-catalog-retrospective
+    path: string
+type: rigid
+tier: 2
+phases:
+  - name: scan
+    description: Read adoption telemetry and derive the retrospective report
+    required: true
+  - name: interpret
+    description: Read the rankings and coverage, separating real signal from telemetry gaps
+    required: true
+  - name: report
+    description: Write the dated report and surface highlights plus recommendations
+    required: true
+state:
+  persistent: false
+  files: []
+depends_on: []

package/dist/agents/skills/gemini-cli/harness-execution/SKILL.md

@@ -131,6 +131,19 @@ RMH005 (`harness validate`).
 
    - If no roadmap row matches this plan (e.g. ad-hoc execution), skip the claim.
 
+#### Step 0.5: Plan parallelization (standard automatic parallelism)
+
+Before the per-task loop, decide the safe parallel structure so independent tasks dispatch concurrently by default (no human typing "in parallel").
+
+1. Collect this run's tasks with their `files` and `dependsOn` (from the plan's task headers) and call the `plan_parallelization` MCP tool (`{ path, tasks, depth: 1 }`). It returns `ParallelizationPlan` (`waves[]`, `serialized[]`, `cyclic[]`, `narration`).
+2. If `cyclic` is non-empty, STOP and escalate (dependency cycle = plan defect). Do not execute.
+3. Emit `narration` (announce-and-proceed — do not pause).
+4. Run `serialized` tasks first (serially, in order — cross-bucket prerequisites), then process `waves` **in array order** (topologically sorted; do not reorder, do not key off `firing` alone).
+5. Per wave: `auto-dispatch` (multi-task) → dispatch the wave via **harness-parallel-agents** with worktree-per-unit isolation (`docs/guides/agent-worktree-patterns.md`), announce and proceed; `confirm` → one plain-text confirmation, then parallel or serial per the answer; `serialize` / single-task → run through the per-task loop below serially.
+6. **Serial fallback preserved:** when independent tasks < `minWaveSize` (default 3), a `confirm` is declined, or no graph is available and the human does not confirm, run every task through the per-task loop below serially — the standing "when in doubt, run serially" default.
+
+Tasks dispatched into a parallel wave are executed by harness-parallel-agents' focused agents; tasks that fall to serial run through the loop below unchanged.
+
 For each task, starting from current position:
 
 1. **Read task instructions completely** before writing any code.

package/dist/agents/skills/gemini-cli/harness-parallel-agents/SKILL.md

@@ -2,12 +2,15 @@
 
 > Dispatch independent tasks to concurrent agents, integrate results, and verify no conflicts. Only for truly independent problems.
 
+**Invoked automatically by `harness-autopilot` (and standalone `harness-execution`), not only manually.** When a plan's phase has an auto-dispatch wave, the execution loop calls this skill to run that wave. In that mode the caller supplies worktree-per-unit isolation per `docs/guides/agent-worktree-patterns.md` (one worktree per task, sequential commits, squash-merge on integrate) and has already verified independence via `plan_parallelization`; this skill still owns the focused agent briefs (Step 2), concurrent dispatch (Step 3), and integration/verification (Steps 4–5). Manual invocation (a human asking to "work in parallel") continues to work unchanged.
+
 ## When to Use
 
 - When 3 or more tasks are truly independent (no shared state, no shared files, different subsystems)
 - When tasks involve investigation or implementation in separate parts of the codebase
 - When parallel execution would meaningfully reduce wall-clock time
 - When a plan has tasks explicitly marked as parallelizable
+- When `harness-autopilot`/`harness-execution` reaches an `auto-dispatch` (or confirmed) wave from `plan_parallelization` — this skill is the wave's dispatcher
 - NOT when failures across tasks might be related (investigate serially to find the common cause)
 - NOT when tasks need full system understanding to complete correctly
 - NOT when agents would modify the same files or shared state

package/dist/agents/skills/gemini-cli/harness-planning/SKILL.md

@@ -256,7 +256,7 @@ Report progress: `**[Phase 2/4]** DECOMPOSE — mapping file structure and creat
 ### Phase 3: SEQUENCE — Order Tasks and Identify Dependencies
 
 1. **Order by dependency.** Types before implementations. Implementations before integrations. Integration tasks (tagged `category: "integration"`) after all implementation tasks. Tests alongside implementations (same task, TDD style).
-2. **Identify parallel opportunities.** Tasks touching different subsystems with no shared state can be marked parallelizable.
+2. **Identify parallel opportunities and record dependency edges.** Tasks touching different subsystems with no shared state can run in parallel. Record each task's real dependencies as `dependsOn` (the task IDs it must follow) in the task header `**Depends on:**` line, and keep the task's `**Files:**` list accurate — together these are exactly the edges `plan_parallelization` consumes (explicit `dependsOn` unioned with file-overlap edges) to build the wave DAG at execution time. A task with no dependencies records `**Depends on:** none`.
 3. **Number tasks sequentially.** Use `Task 1`, `Task 2`, etc. Dependencies reference task numbers.
 4. **Estimate total time.** Sum 2-5 minutes per task. If total exceeds available time, identify a milestone boundary for pausing.
 
@@ -327,6 +327,8 @@ One sentence.
 
 **Depends on:** none | **Files:** path/to/file.ts, path/to/file.test.ts
 
+<!-- `Depends on` lists the task IDs this task must follow (its `dependsOn` edges); `Files` is the independence-checking input. Both feed `plan_parallelization` during execution. -->
+
 1. Create test file with exact test code
 2. Run test — observe failure
 3. Create implementation with exact code

package/dist/agents/skills/gemini-cli/pre-merge-brief/SKILL.md

@@ -0,0 +1,86 @@
+# Pre-Merge Brief
+
+> The harness pointed at the human who clicks merge. A thin wrapper over `harness pre-merge-brief` that composes a senior-facing accountability brief — the diff summary, the multi-persona review verdict (from `review-ci --json`), the curated **Signal status** snapshot, the outcome-eval result, and a derived **"👀 Worth your eyes"** section — and posts it as a single sticky PR comment (upsert by marker). All composition and degradation logic lives in the command; this skill orchestrates invocation, reports which sections degraded, and hands off. Advisory and non-blocking: the brief never flips the review gate.
+
+## When to Use
+
+- On every PR, so the senior engineer who merges sees "you are pushing this — here's what deserves your eyes" before they click merge.
+- `on_pr` (dogfooded via the `required-review` workflow, reusing that run's `review-ci --json` artifact) and `manual` (a senior running it locally against the current branch's PR).
+- NOT as a merge gate — the acknowledgment gate is deliberately deferred (spec D3). The brief is advisory; the review gate's exit code is what blocks.
+- NOT a replacement for `review-ci` — this skill CONSUMES the review verdict, it does not re-run the review (spec D1).
+- NOT for recomputing signals a different way — signals come from `@harness-engineering/signals` via the command (spec D2/D6).
+
+## Process
+
+### Phase 1: GATHER — Resolve inputs
+
+1. Locate the `review-ci --json` artifact for this run and record its path for `--from`. In CI it is the JSON the `required-review` workflow's `review-ci` step wrote (e.g. `/tmp/review.json`); locally, run `harness review-ci --json <path>` first if a verdict is wanted. Absent `--from` is tolerated — the review section degrades to "unavailable".
+2. Resolve the diff range for `--diff` (default `origin/<base>...HEAD` via the command's own resolver). Override only when the base is non-standard.
+3. Resolve the head sha for `--head` (default `git rev-parse HEAD`) — used for the `execution_outcome` graph lookup. Pre-merge the node is commonly absent, which is the documented degradation path, not an error.
+4. If posting (`--comment`), confirm `gh` is authenticated. Delivery failure never crashes the command (spec S1): it prints the brief and warns, still exiting 0.
+
+### Phase 2: COMPOSE — Run the command
+
+Invoke `harness pre-merge-brief` with the resolved inputs:
+
+```bash
+harness pre-merge-brief --from <review.json> --diff <range> --head <sha> [--comment]
+```
+
+The command builds the six-section brief (marker + header → Diff summary → Review verdict → **Signal status** → Outcome evaluation → **👀 Worth your eyes**) and, with `--comment`, upserts the sticky PR comment by its marker (`<!-- harness:pre-merge-brief -->`) — patching the existing comment in place rather than posting a new one on each push. Without `--comment` it prints the brief to stdout. Each input degrades independently to an explicit "unavailable" line; the command exits 0 on a successful render regardless of which inputs were present.
+
+### Phase 3: REPORT — Surface what matters
+
+1. Report which sections rendered with real data and which degraded to "unavailable / not yet evaluated", so the senior knows the brief's coverage.
+2. Surface the **"👀 Worth your eyes"** items verbatim — the union of blocking review findings, signals in `warn`/`alert`, and unmet outcome criteria. This is the section the accountable human should read first.
+
+### Phase 4: HANDOFF — Advisory transition
+
+Emit the transition via `emit_interaction`. The brief is advisory and non-blocking: it never flips the review gate's pass/fail status (spec D3, D4). In the dogfood workflow the brief step is `continue-on-error`, so a brief failure never fails the PR.
+
+## Harness Integration
+
+- **`harness pre-merge-brief`** — the command this skill wraps. Flags: `--from <path>` (review-ci verdict JSON), `--comment` (sticky-upsert to the current branch's PR via `gh`), `--diff <range>`, `--head <sha>`. Pure render (`buildBriefBody`) + injected seams (`postBrief`, `RunGit`, graph store); no `process.exit` in the pure core.
+- **`review-ci`** — upstream producer of the review verdict. This skill reuses its `--json` artifact via `--from`; it never re-runs the review (D1). `review-ci` remains the single source of review truth.
+- **`@harness-engineering/signals`** — the shared leaf package (extracted in spec Phase 1/D6) providing `gatherSignals`. The command computes the Signal status snapshot from it; the CLI does not route signal computation through the dashboard app.
+- **`execution_outcome` graph nodes** — the outcome-eval result, looked up by head sha from `.harness/graph`; commonly absent pre-merge (degrades to "not yet evaluated").
+- **`required-review.yml` (dogfood)** — the `on_pr` delivery path: a `continue-on-error` step runs the brief after the existing `review-ci` run, reusing its artifact (spec Phase 4/D4). Adopter template graduation is a tracked follow-up (D5).
+
+## Gates
+
+- **Never re-run the review.** Consume `review-ci --json`; do not invoke the review pipeline from this skill (D1).
+- **Never block the merge.** The brief is advisory; the review gate's exit code is authoritative. No acknowledgment gate in v1 (D3).
+- **Never crash `--comment`.** A `gh`/PR delivery failure prints the brief and warns, still exiting 0 (S1).
+- **Thin wrapper only.** No brief composition, signal computation, or union logic in the skill — all of it lives in the command.
+
+## Success Criteria
+
+Maps to spec `docs/changes/senior-accountability-surface/proposal.md`. This skill satisfies criterion #2 (the skill wrapping the command, `on_pr` + `manual`) and supports #1/#3/#4 by driving the command whose pure functions are unit-tested. Introduces no new `harness validate` findings.
+
+## Escalation
+
+- **No PR for the current branch (`--comment`).** The command warns and prints the brief to stdout instead of posting, still exiting 0. Surface the warning; do not treat it as a failure.
+- **No review artifact (`--from` missing/absent).** The review-verdict section degrades to "unavailable". If a verdict is wanted, run `harness review-ci --json <path>` first and pass it.
+- **`gh` unauthenticated or API error while posting.** Delivery fails soft (brief printed, one-line stderr warning, exit 0). Fix `gh auth` and re-run; nothing is lost.
+- **Signals or outcome-eval unavailable.** Each degrades independently to its "unavailable"/"not yet evaluated" line — expected pre-merge, not an error. Do not block the brief on them.
+- **Someone asks to make the brief block merges.** That is the deferred acknowledgment gate (spec D3), a separate future spec. Keep the brief advisory; point them at the follow-up roadmap row.
+
+## Examples
+
+### Example: brief on a PR in CI (dogfood)
+
+The `required-review.yml` workflow runs `review-ci --json /tmp/review.json`, then this skill's command:
+
+```bash
+harness pre-merge-brief --from /tmp/review.json --diff "origin/main...HEAD" --comment
+```
+
+The brief is composed and upserted as a sticky PR comment. The review found one blocking finding and two `alert` signals, so **👀 Worth your eyes** lists exactly those three; the outcome section shows "not yet evaluated" (no `execution_outcome` node pre-merge). The step is `continue-on-error`, so even if `gh` posting fails the review gate is unaffected.
+
+### Example: senior running it locally
+
+```bash
+harness pre-merge-brief --comment
+```
+
+No `--from`, so the review-verdict section renders "unavailable"; signals are gathered live and the diff summary uses the default `origin/<base>...HEAD` range. The senior sees the current signal status and diff before clicking merge.