@harness-engineering/cli 4.3.3 → 6.0.0

package/dist/agents/skills/codex/harness-rollback/skill.yaml

@@ -0,0 +1,52 @@
+name: harness-rollback
+version: '1.0.0'
+description: Post-ship circuit breaker — proposes a full-context revert PR when a shipped PR fails post-merge evaluation or crosses a signal threshold. Propose-only in v1 (never auto-merges).
+stability: static
+cognitive_mode: constructive-architect
+triggers:
+  - manual
+platforms:
+  - claude-code
+  - gemini-cli
+  - cursor
+  - codex
+tools:
+  - Bash
+  - Read
+  - Write
+  - Edit
+  - Glob
+  - Grep
+cli:
+  command: harness skill run harness-rollback
+  args:
+    - name: path
+      description: Project root path
+      required: false
+    - name: pr
+      description: Target merged PR number to evaluate for rollback
+      required: false
+mcp:
+  tool: run_skill
+  input:
+    skill: harness-rollback
+    path: string
+type: rigid
+tier: 2
+phases:
+  - name: resolve
+    description: Identify the target merged PR, merge commit, and merge shape
+    required: true
+  - name: classify
+    description: Determine revert-readiness (clean revert + no dependent later merge)
+    required: true
+  - name: compose
+    description: Open a full-context revert PR (or dry-run), idempotent by label
+    required: true
+  - name: record
+    description: Append the rollback_event breadcrumb
+    required: true
+state:
+  persistent: false
+depends_on:
+  - outcome-eval

package/dist/agents/skills/codex/product-requirements/SKILL.md

@@ -0,0 +1,150 @@
+# Product Requirements
+
+> Turn one picked work item into a durable PRD — user stories, testable acceptance criteria, and prioritization — through a guided interview. The product-management middle between `product-advisor` (BRD) and `harness-brainstorming` (spec). Authors requirements; never authors the spec.
+
+## When to Use
+
+- When a roadmap item (or a plain feature idea) needs product-level requirements — user stories, acceptance criteria, prioritization — before design begins.
+- When a non-technical author (PM/BA/client) should shape _what_ and _why_ through a guided interview, no code surface.
+- When the downstream spec's acceptance criteria should be authored deliberately rather than fused into the proposal — the PRD feeds `harness-brainstorming` and, transitively, `acceptance-eval`.
+- NOT for authoring a spec/proposal — that is `harness-brainstorming`'s job. This skill stops at the PRD.
+- NOT for the BRD / client-inception intake — that is `product-advisor`'s job (upstream of this).
+- NOT for bugs, chores, or refactors with no user-facing behavior — a PRD there is speculative ceremony (YAGNI).
+
+## Process
+
+### Iron Law
+
+**Every user story carries at least one measurable acceptance criterion, or it ships as an open, named gap — never a silent guess. The skill authors the PRD; it does not author the spec, mutate the roadmap, or claim the item.**
+
+A PRD that hides what it does not know launders assumptions into requirements. A criterion that cannot be judged is not a criterion. If a story has no measurable criterion and you did not surface it in the chase list, STOP and add it.
+
+---
+
+### Argument Resolution
+
+- **`item`** — the slug/name of the work item. From the `item` argument, or the roadmap row being worked, or ask. Sets the artifact directory `docs/product-requirements/<item>/`.
+- **`description`** — a plain feature description, used when no richer input (BRD, roadmap row) exists. The skill requires nothing more than this.
+
+---
+
+### Phase 1: INGEST — Gather the Richest Available Input
+
+Load the richest input that exists, and **degrade gracefully** — the only hard requirement is a one-line description.
+
+1. **BRD when present:** if `docs/inception/<engagement>/brd.md` exists and maps to this item, read its Business Objectives, Scope, and Functional Requirements as the seed.
+2. **Else the roadmap row:** if a roadmap exists (`docs/roadmap.md` aggregate or `docs/roadmap.d/` shard), read the row's summary for this item.
+3. **Else the description argument:** treat it as the sole seed.
+4. **Strategy grounding (optional):** call `read_strategy({ path })` on the harness MCP server when available; capture `Target problem` / `Who it's for` to keep stories aligned. Soft-fail silently when absent, invalid, or the server is unavailable.
+5. **Soft-degrade, never fail:** when the seed is sparse (only a title, no BRD/roadmap/strategy), proceed and record a gap ("no BRD/roadmap context; requirements elicited from description only"). Do not abort.
+
+---
+
+### Phase 2: DRAFT-PRD — Synthesize the First Draft
+
+1. **Write the PRD** to `docs/product-requirements/<item>/prd.md` with these sections, each present even if thin:
+   - **Context** (+ a link to the source BRD when present)
+   - **Goal / Problem** — the user-facing outcome this item delivers
+   - **User Stories** — each `As a <role>, I want <goal>, so that <benefit>`, with its acceptance criteria and a MoSCoW priority
+   - **Prioritization summary** — the MoSCoW rollup (Must / Should / Could / Won't)
+   - **Non-Goals** — what this item explicitly does not cover
+   - **Open Questions (chase list)** — unresolved gaps, each phrased as a question
+2. **Acceptance criteria are EARS by default.** Each criterion follows an EARS pattern:
+   - Event-driven: "When `<trigger>`, the system shall `<response>`."
+   - Unwanted: "If `<condition>`, then the system shall not `<behavior>`."
+   - State-driven / optional: "While `<state>` / Where `<feature>`, the system shall `<response>`."
+     Render a criterion as **Given-When-Then** instead only when a story is behavior-heavy and reads more clearly that way. Every criterion must be testable — an EARS trigger→response or a numeric bound.
+3. **Prioritize every story with MoSCoW** (Must / Should / Could / Won't-this-time).
+4. **Tag gaps against the completeness rubric** (below). Every rubric miss becomes a gap `{ id, section, question, severity: blocker | important | nice, status: open }`. Do not invent facts to fill a section — an empty-because-unknown section is a gap, not a place to guess.
+
+#### PRD completeness rubric
+
+- Every user story has ≥1 acceptance criterion, else it is a gap.
+- Every acceptance criterion is measurable — an EARS trigger→response or a numeric bound — else it is a gap.
+- Every user story carries a MoSCoW priority, else it is a gap.
+- Non-Goals is non-empty (state the boundary explicitly), else it is a gap.
+- Every story traces to the Goal / Problem (or to an explicit gap).
+
+---
+
+### Phase 3: GAP-INTERVIEW — Resolve What You Can
+
+1. **Ask ONE question at a time, in plain text.** Order the gap queue by severity (`blocker` → `important` → `nice`). Ask the highest-severity open gap first, wait for the answer, then continue. Present each gap as a scannable multiple-choice table where options exist, and state a recommendation. **Do NOT route questions through `emit_interaction` or `AskUserQuestion`** — the human will not see them; plain text in your reply is the only reliable channel across all clients.
+2. **Fold each answer back into the PRD.** Update the relevant story/criterion (source: `interview`) and move the gap `open → resolved` with the captured answer.
+3. **Mark unresolvable gaps as chase-list questions.** If the author cannot answer (only the client/stakeholder can), keep the gap `open` and phrase it as a question to ask them.
+4. **Stop when the queue is drained** — every gap is either `resolved` or `open` (chase-list). Do not loop past a drained queue inventing new questions.
+
+---
+
+### Phase 4: FINALIZE — Ship and Hand Off
+
+1. **Finalize `docs/product-requirements/<item>/prd.md`** with all sections populated and the **Open Questions** section listing every remaining `open` gap as a question.
+2. **Stay in your lane.** Do **not** mutate the roadmap and **never** write an `assignee` — this skill operates on one already-picked item; claiming it is `harness-execution`'s job at execution start. If no roadmap exists, there is nothing to touch.
+3. **Emit the handoff to `harness-brainstorming`** via `emit_interaction` (type `transition`, `suggestedNext: harness-brainstorming`). State plainly that brainstorming will consume the PRD — seeding the spec's `## User Stories` and `## Success Criteria` from the PRD's EARS criteria — and then author the spec. **Do not author the spec here.**
+4. **Run `harness validate`.**
+
+---
+
+## Harness Integration
+
+- **`read_strategy`** — Phase 1: read `STRATEGY.md` when present to align stories; never write it.
+- **`gather_context`** — Phase 1 (optional): pull existing project/business knowledge to ground the domain.
+- **`emit_interaction`** — Phase 4: record the `transition` to `harness-brainstorming`. The transition is recorded, not surfaced — any human-facing question is asked in plain text.
+- **`harness validate`** — Phase 4: verify artifact placement and project health.
+- **Boundary with adjacent skills:** `product-advisor` WRITES the BRD (upstream); this skill READS the BRD and WRITES the PRD; `harness-brainstorming` READS the PRD and WRITES the spec; `acceptance-eval` READS the spec's criteria and JUDGES them. This skill never crosses those lines.
+- **Portability:** no hardcoded repo layout. The only hard requirement is a feature description. BRD, roadmap, and strategy are optional richer inputs consumed when present and soft-degraded when absent.
+
+## Success Criteria
+
+- Running the skill with only a feature description (no BRD/roadmap/strategy) produces `docs/product-requirements/<item>/prd.md` with all sections present, none empty.
+- Every user story has ≥1 acceptance criterion; every criterion is EARS-shaped (trigger→response) or carries a numeric bound.
+- Every user story carries a MoSCoW priority.
+- The gap interview asked one question at a time and folded each answer back (resolved gaps moved `open → resolved`); every unresolved gap ships as a chase-list question.
+- The skill did not modify the roadmap and did not write an `assignee`.
+- The handoff transitions to `harness-brainstorming`; no spec was authored.
+- `harness validate` passes.
+
+## Rationalizations to Reject
+
+| Rationalization                                                           | Reality                                                                                                                                                             |
+| ------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| "This story's outcome is obvious, so I can skip the acceptance criterion" | The Iron Law: every story carries a measurable criterion or a named gap. An implied criterion cannot be judged by `acceptance-eval`.                                |
+| "There's no BRD/roadmap, so I can't run"                                  | The only hard requirement is a description. Soft-degrade to description-only and record a gap — never abort.                                                        |
+| "I'll write the spec while I'm here since the requirements are clear"     | This skill stops at the PRD. Authoring a `proposal.md` is a gate violation — hand off to `harness-brainstorming`.                                                   |
+| "I'll mark the item in-progress / assign it so the pick is recorded"      | This skill never mutates the roadmap or writes `assignee`. Claiming happens at execution start; assigning here makes the orchestrator skip the item.                |
+| "Plain prose criteria are fine; EARS is ceremony"                         | EARS is the grammar `harness-planning`/`harness-brainstorming` consume and the shape `acceptance-eval` reads as MEASURABLE. Freeform criteria drift to un-judgable. |
+
+## Gates
+
+- **No un-criterioned stories.** Every user story is either covered by a measurable acceptance criterion or shipped as an `open` chase-list gap. A story that is neither = Iron Law violation; stop and fix.
+- **No guessed requirements.** An unknown section is a gap, not a place to invent facts.
+- **No spec authoring.** This skill stops at the PRD; writing a `proposal.md` = gate violation. Hand off to `harness-brainstorming`.
+- **No roadmap mutation and no assignment.** Writing the roadmap or the `assignee` field = gate violation.
+- **No hard failure on sparse input.** Absent BRD/roadmap/strategy → description-only + recorded gap. Aborting because context is thin = gate violation.
+
+## Escalation
+
+- **The author cannot answer a blocker gap:** keep it `open`, phrase it as a chase-list question for the client/stakeholder, and note in the handoff that brainstorming inherits an open blocker.
+- **Scope spans multiple independent capabilities:** stop and suggest splitting into multiple items (one PRD per item), rather than one bloated PRD.
+- **No item slug resolvable:** ask for a short name; without one, the artifact directory cannot be created.
+- **The item is a bug/chore/refactor with no user-facing behavior:** say so and recommend going straight to `harness-brainstorming` — a PRD adds no value.
+
+## Examples
+
+### Example: PRD for a picked roadmap item with no BRD
+
+**Context:** roadmap-pilot picked "Export dashboard to PDF." No BRD exists; the roadmap row is a one-line summary.
+
+**INGEST:** No BRD found; read the roadmap row summary; strategy present (aligns with the "reporting" audience). Seed = row summary + description. Recorded no gap (seed sufficient).
+
+**DRAFT-PRD:** Wrote `docs/product-requirements/export-dashboard-to-pdf/prd.md`. 3 user stories:
+
+- _As an analyst, I want to export the current dashboard to PDF, so that I can share it offline._ **[Must]** — "When the user clicks Export → PDF, the system shall produce a PDF of the current dashboard within 5 seconds."
+- _As an analyst, I want the PDF to preserve applied filters, so that it reflects what I see._ **[Should]** — "When a filter is applied, the exported PDF shall reflect the filtered data set."
+- _As an admin, I want export disabled for restricted dashboards._ **[Could]** — "If the dashboard is marked restricted, then the system shall not offer the Export → PDF action."
+
+Tagged 2 gaps: G1 (blocker) "max PDF page count?"; G2 (nice) "landscape or portrait default?".
+
+**GAP-INTERVIEW:** Q1 (G1): "Cap the export at (A) 10 pages, (B) 50 pages, (C) no cap? Recommend B." → "B." Folded into story 1's criterion. Q2 (G2) → author defers → kept open as chase-list.
+
+**FINALIZE:** PRD finalized; Open Questions lists G2. No roadmap mutation, no assignee. Emitted handoff → `harness-brainstorming` will seed the spec's Success Criteria from these EARS criteria. `harness validate` — passes.

package/dist/agents/skills/codex/product-requirements/skill.yaml

@@ -0,0 +1,70 @@
+name: product-requirements
+version: "0.1.0"
+description: Guided-interview skill that turns one picked work item into a durable Product Requirements Document (PRD) — user stories, testable EARS acceptance criteria, and MoSCoW prioritization — written to a per-item file under docs/product-requirements/. The product-management middle between product-advisor (BRD) and harness-brainstorming (spec). Reads a BRD/roadmap/description as available and degrades gracefully to description-only; authors requirements but never the spec, never mutates the roadmap, and never assigns.
+stability: static
+cognitive_mode: configuration-interviewer
+triggers:
+  - manual
+platforms:
+  - claude-code
+  - gemini-cli
+  - cursor
+  - codex
+tools:
+  - Bash
+  - Read
+  - Write
+  - Edit
+  - Glob
+  - Grep
+cli:
+  command: harness skill run product-requirements
+  args:
+    - name: item
+      description: Slug/name of the work item. Sets the item's artifact directory under docs/product-requirements/. Resolved from this argument, the roadmap row being worked, or by asking.
+      required: false
+    - name: description
+      description: Plain feature description, used as the seed when no BRD or roadmap row exists. The only hard input the skill needs.
+      required: false
+mcp:
+  tool: run_skill
+  input:
+    skill: product-requirements
+    path: string
+type: rigid
+tier: 2
+phases:
+  - name: ingest
+    description: Load the richest available input — a mapped BRD under docs/inception/, else the roadmap row summary, else the description argument. Optionally read STRATEGY.md for alignment. Soft-degrade to description-only and record a gap when the seed is sparse; never abort.
+    required: true
+  - name: draft-prd
+    description: Synthesize a first PRD into the item's file under docs/product-requirements/ (Context, Goal, User Stories with EARS acceptance criteria + MoSCoW priority, Prioritization summary, Non-Goals, Open Questions). Tag every rubric miss as a severity-ranked gap.
+    required: true
+  - name: gap-interview
+    description: Walk the author through the gap queue one question at a time (plain-text tables), highest severity first; fold each answer back into the PRD; keep unresolvable gaps as open chase-list questions.
+    required: true
+  - name: finalize
+    description: Finalize the PRD with Open Questions listed; do not mutate the roadmap or write an assignee; emit the handoff transition to harness-brainstorming (which seeds the spec's Success Criteria from the PRD's EARS criteria); run harness validate.
+    required: true
+state:
+  persistent: true
+  files:
+    - docs/product-requirements/
+depends_on:
+  - harness-brainstorming
+related_skills:
+  - product-advisor
+  - harness-brainstorming
+  - harness-roadmap-pilot
+  - acceptance-eval
+keywords:
+  - product-requirements
+  - PRD
+  - user-stories
+  - acceptance-criteria
+  - EARS
+  - MoSCoW
+  - requirements-authoring
+  - guided-interview
+  - configuration-interviewer
+  - lifecycle-middle

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

@@ -55,6 +55,8 @@ When no arguments are provided (standalone invocation), the skill operates exact
     - **Contradiction with the user's feature description:** do NOT auto-resolve. Carry the contradiction forward as an open question into Phase 2 EVALUATE — surface it explicitly so the human can decide whether to refine the feature or update strategy via `/harness:strategy`.
 
 1. **Load project context.** Call `gather_context({ path: "<project-root>", intent: "<feature description>", skill: "harness-brainstorming", session: "<session-slug-if-known>", include: ["graph", "businessKnowledge", "sessions", "validation"] })`. The `graph` context surfaces `business_fact` nodes relevant to the feature domain. The `businessKnowledge` context loads documented domain knowledge from `docs/knowledge/`. Use both to ground exploration in verified facts rather than assumptions. When `STRATEGY.md` was loaded in step 0a, treat its sections as a higher-tier grounding source than `businessKnowledge` — strategy reflects an explicit human commitment, knowledge is observation.
+   1b. **Consume the PRD when present.** If `docs/product-requirements/<item>/prd.md` exists for this feature/item (authored upstream by the `product-requirements` skill), read it and treat its user stories and EARS acceptance criteria as settled requirements. In Phase 4, seed the spec's `## User Stories` and `## Success Criteria` from them rather than re-deriving criteria the PRD already resolved, and cite the PRD as evidence. When no PRD exists, proceed unchanged — the PRD is an optional richer input, never required.
+
 2. **Read the existing codebase.** Understand architecture, constraints, and conventions. Check AGENTS.md, existing specs in `docs/`, and relevant source files.
 3. **Identify the problem boundary.** What exactly needs solving? What is out of scope? Write both down. Cross-reference `businessKnowledge` domains — if documented business rules constrain the problem, note them.
 4. **Check for prior art.** Has this been partially solved elsewhere? Are there patterns to follow or deliberately break?
@@ -130,7 +132,7 @@ These flow into `handoff.json` `contextKeywords` field. Select keywords that hel
    - Decisions made (with rationale from brainstorming)
    - Technical design (data structures, APIs, file layout)
    - Integration points (entry points, registrations, docs, decisions, knowledge impact)
-   - Success criteria (observable, testable outcomes)
+   - Success criteria (observable, testable outcomes) — when a PRD exists at `docs/product-requirements/<item>/prd.md`, seed these from its EARS acceptance criteria (see Phase 1 step 1b)
    - Implementation order (high-level phases, not detailed tasks)
 
    The **Integration Points** section is required in every spec. It defines how the feature connects to the existing system. Populate it with five subsections:

package/dist/agents/skills/cursor/harness-roadmap-pilot/SKILL.md

@@ -152,6 +152,11 @@ RMH005). See knowledge [`merge-triggered-auto-done.md`](../../../../docs/knowled
 1. Determine the transition target:
    - If the feature has a `spec` field (non-null): transition to `harness:autopilot`
    - If the feature has no `spec`: transition to `harness:brainstorming`
+   - **Optional (feature-shaped items):** before brainstorming, a no-spec item that carries
+     user-facing behavior may first run `product-requirements` to author a PRD (user stories +
+     acceptance criteria + prioritization) at `docs/product-requirements/<item>/prd.md`, which
+     brainstorming then consumes. Suggest this for feature work; skip it for bugs, chores, and
+     refactors (a PRD there is speculative ceremony).
 
 2. Present the transition to the human via `emit_interaction`:
 

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

@@ -0,0 +1,124 @@
+# Harness Rollback
+
+> Post-ship circuit breaker. Proposes a full-context **revert PR** when a shipped PR fails post-merge evaluation or crosses a signal threshold. v1 is **propose-only** — it NEVER auto-merges. A human merges the revert.
+
+## When to Use
+
+- When a merged PR is suspected of causing a regression and you want a considered, full-context revert prepared for review.
+- When a tracked signal (error rate, a baseline count, any `.harness/signals/` series) crosses a threshold and you want the implicated PR(s) evaluated for rollback.
+- As the manual entry point to the same engine the scheduled `rollback-propose` workflow drives automatically.
+- NOT for reverting un-merged work (use `git`/`gh` directly).
+- NOT for deployment/infrastructure rollback — this operates at the git/PR layer (it opens a revert PR), not at the deploy layer.
+- NOT to auto-merge a revert. v1 does not have that authority (see Iron Law).
+
+## Process
+
+### Iron Law
+
+**v1 never auto-merges a revert. It opens a revert PR and stops. A human decides.**
+
+Auto-merging code — even a revert — is a high-blast-radius write, and a wrong revert is itself an incident. The trust model earns auto-merge authority only after the propose loop has demonstrably proposed _correct_ reverts over time (recorded via the `rollback_event` breadcrumb). Until then, the workflow carries `pull-requests: write` but **not** `contents: write` and **no** self-approving PAT. If you find yourself merging a revert automatically, STOP — that is a separate, deferred trust tier (see ADR 0063).
+
+---
+
+### Phase 1: RESOLVE — Identify the target
+
+1. Take the target merged PR number (`--pr <n>`) and the trigger (`signal` or `eval`).
+2. Resolve the PR's merge commit and changed files via `gh`. If the PR is **not merged** (no merge commit), stop with a structured `skipped` decision — there is nothing to revert.
+3. Determine the merge shape: a two-parent merge commit reverts against parent 1 (`-m 1`); a **squash/rebase** merge is single-parent and reverts against its sole parent. This repo uses both — never assume a two-parent merge.
+
+### Phase 2: CLASSIFY — Is it revert-ready?
+
+Run `classifyRevert` (core). A target is **revert-ready** only when BOTH hold:
+
+- **Clean revert** — an in-memory `git merge-tree --write-tree` of the revert applies with no conflicts. (Never a working-tree-mutating `git revert -n`.)
+- **No dependent later merge** — no PR merged after the target touches the same files. A later dependent merge → `action: 'blocked'` (a naive revert would orphan newer work).
+
+`blastRadius` and `migrationWarnings` are **context only, never gates** — they enrich the PR body so the human reviewer sees the stakes; they do not decide revert-readiness.
+
+### Phase 3: COMPOSE — Open the revert PR (or dry-run)
+
+1. If `--dry-run`, print the PR body and stop — open no PR.
+2. Otherwise open a revert PR: title `revert: <original> (automated rollback)`, marker label `harness:rollback`, body = the full context block (trigger, target, revert-ready verdict, classification reasons, blast-radius, migration warnings, and the `--reason` if given).
+3. **Idempotency:** if an open PR labeled `harness:rollback` already references the target (`#<n>`, word-boundary matched — `#42` must not match `#420`), skip — do not open a duplicate.
+
+### Phase 4: RECORD — Breadcrumb
+
+Append one `rollback_event` to `.harness/signals/`: `{ targetPr, trigger, revertReady, action, prUrl, reason, ts }`. This append-only record is what later justifies (or refuses) the auto-merge trust tier — it is not backfillable, so it is written on every evaluation.
+
+---
+
+## Triggers
+
+- **Signal arm (live):** the scheduled `rollback-propose.yml` workflow runs `harness rollback sweep`, which reads `.harness/signals/timeline.json` and, for each `rollback.signals` entry `{ threshold, direction, window }`, detects an edge crossing, resolves the PR(s) merged in the window, and forwards each to `evaluate --trigger signal`.
+- **Eval arm (dark until #31):** guarded by `rollback.evalTrigger.enabled` (default `false`). When outcome-eval is wired to run post-merge (#31), a high-confidence `NOT_SATISFIED` will route through the same engine with `--trigger eval`. Until then the path exists and is unit-tested but never fires — enabling it is a config flip, not a code change.
+
+## Harness Integration
+
+- **`harness rollback evaluate`** — the CLI core; classification + compose + breadcrumb for one target PR.
+- **`harness rollback sweep`** — the signal arm; timeline threshold detection → `evaluate`.
+- **`classifyRevert` / `RollbackDecision`** (`@harness-engineering/core`) — the pure, injected-IO classification engine.
+- **`.github/workflows/rollback-propose.yml`** — propose-only post-merge + scheduled workflow. `contents: read` + `pull-requests: write`, concurrency-serialized, no self-approving PAT.
+- **`harness.config.json` → `rollback`** — `signals` (record of `{ threshold, direction, window }`) and `evalTrigger.enabled`.
+- **ADR 0063** — the post-ship rollback trust model (propose → auto-merge progression).
+
+## Success Criteria
+
+1. A revert PR is opened only for a revert-ready target (clean revert + no dependent later merge); non-clean/blocked/unmerged targets yield a structured `skipped`/`blocked` decision and no PR.
+2. The revert PR body carries trigger, target, blast-radius, and migration warnings.
+3. Re-running against the same target opens no duplicate PR (label + word-boundary idempotency).
+4. Every evaluation appends one `rollback_event` breadcrumb.
+5. No revert is auto-merged — a human merges the PR.
+6. The eval arm produces no PR while `rollback.evalTrigger.enabled` is false.
+
+## Gates
+
+- **No auto-merge.** v1 opens PRs; it never merges them. Enforced by the workflow's minimal permissions (no `contents: write`, no self-approving PAT).
+- **No revert without revert-ready classification.** A conflicting revert or a dependent later merge blocks the proposal.
+- **No two-parent assumption.** Squash/rebase merges must revert against their sole parent.
+- **No working-tree mutation.** Revert-readiness is tested in-memory (`merge-tree`), never with `git revert -n`.
+
+## Rationalizations to Reject
+
+| Rationalization                                                                   | Reality                                                                                                                         |
+| --------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------- |
+| "The eval clearly failed, so I should auto-merge the revert to stop the bleeding" | v1 has no auto-merge authority. Open the PR; a human merges. Auto-merge is a deferred trust tier (ADR 0063).                    |
+| "`git revert -n` in a temp index is fine for the readiness check"                 | `-n` still writes the working tree. Use `git merge-tree --write-tree` — pure in-memory, no side effects.                        |
+| "It's a merge commit, so `-m 1` is safe"                                          | Squash/rebase merges are single-parent; `-m 1` computes a meaningless revert. Check the parent count first.                     |
+| "The signal fired, so every PR in the window should be reverted"                  | Only revert-ready targets are proposed, and only the human merges. A crossing is a signal to _evaluate_, not to revert blindly. |
+
+## Examples
+
+### Example: Signal-threshold crossing proposes a revert
+
+**Context:** `harness.config.json` sets `rollback.signals.error-rate = { threshold: 50, direction: "above", window: "24h" }`. The hourly `rollback-propose` workflow runs `harness rollback sweep`.
+
+```
+sweep reads .harness/signals/timeline.json → error-rate crosses 50 (edge, not plateau)
+→ resolves PRs merged in the 24h window: #758
+→ evaluate --pr 758 --trigger signal
+   RESOLVE:  #758 merged, two-parent merge commit
+   CLASSIFY: merge-tree revert clean; no later merge touches its files → revert-ready
+   COMPOSE:  opens "revert: Add tiered discount pricing (automated rollback)"
+             labeled harness:rollback, body carries trigger + blast-radius + migration warning
+   RECORD:   appends rollback_event { targetPr: 758, trigger: signal, action: proposed, ts }
+→ A human reviews and merges the revert PR. Autopilot never merges it.
+```
+
+### Example: Blocked because a later merge depends on the target
+
+**Context:** Manual invocation `harness rollback evaluate --pr 740 --dry-run`.
+
+```
+CLASSIFY: PR #752 merged after #740 and touches the same files (dependent merge)
+→ revertReady: false, action: "blocked"
+→ no PR opened; decision reports "a later merge (#752) depends on this PR's files"
+```
+
+## Escalation
+
+- **The target PR is a squash/rebase merge:** the engine reverts against its sole parent (no `-m 1`). If parent resolution is ambiguous, stop with a `skipped` decision and surface the merge shape — do not guess.
+- **`git merge-tree` exits non-zero for a reason other than conflict (e.g. 128 bad object):** this is an error, not a conflict. Re-throw and surface it; do not report a false `skipped`.
+- **A crossing resolves to many PRs in the window:** evaluate each independently; the composer's label idempotency prevents duplicate revert PRs. If the volume looks wrong (an unexpectedly wide window), check for date-truncation in the resolver before proposing.
+- **The human asks to auto-merge the revert:** decline for v1 — that authority is the deferred Stage-2 trust tier (ADR 0063), gated on the `rollback_event` track record. Open the PR and let a human merge.
+- **`rollback.evalTrigger.enabled` is true but #31 has not landed:** the eval arm has no post-merge invoker yet, so it still won't fire; note the dependency rather than wiring a bespoke trigger.

package/dist/agents/skills/cursor/harness-rollback/skill.yaml

@@ -0,0 +1,52 @@
+name: harness-rollback
+version: '1.0.0'
+description: Post-ship circuit breaker — proposes a full-context revert PR when a shipped PR fails post-merge evaluation or crosses a signal threshold. Propose-only in v1 (never auto-merges).
+stability: static
+cognitive_mode: constructive-architect
+triggers:
+  - manual
+platforms:
+  - claude-code
+  - gemini-cli
+  - cursor
+  - codex
+tools:
+  - Bash
+  - Read
+  - Write
+  - Edit
+  - Glob
+  - Grep
+cli:
+  command: harness skill run harness-rollback
+  args:
+    - name: path
+      description: Project root path
+      required: false
+    - name: pr
+      description: Target merged PR number to evaluate for rollback
+      required: false
+mcp:
+  tool: run_skill
+  input:
+    skill: harness-rollback
+    path: string
+type: rigid
+tier: 2
+phases:
+  - name: resolve
+    description: Identify the target merged PR, merge commit, and merge shape
+    required: true
+  - name: classify
+    description: Determine revert-readiness (clean revert + no dependent later merge)
+    required: true
+  - name: compose
+    description: Open a full-context revert PR (or dry-run), idempotent by label
+    required: true
+  - name: record
+    description: Append the rollback_event breadcrumb
+    required: true
+state:
+  persistent: false
+depends_on:
+  - outcome-eval

package/dist/agents/skills/cursor/product-requirements/SKILL.md

@@ -0,0 +1,150 @@
+# Product Requirements
+
+> Turn one picked work item into a durable PRD — user stories, testable acceptance criteria, and prioritization — through a guided interview. The product-management middle between `product-advisor` (BRD) and `harness-brainstorming` (spec). Authors requirements; never authors the spec.
+
+## When to Use
+
+- When a roadmap item (or a plain feature idea) needs product-level requirements — user stories, acceptance criteria, prioritization — before design begins.
+- When a non-technical author (PM/BA/client) should shape _what_ and _why_ through a guided interview, no code surface.
+- When the downstream spec's acceptance criteria should be authored deliberately rather than fused into the proposal — the PRD feeds `harness-brainstorming` and, transitively, `acceptance-eval`.
+- NOT for authoring a spec/proposal — that is `harness-brainstorming`'s job. This skill stops at the PRD.
+- NOT for the BRD / client-inception intake — that is `product-advisor`'s job (upstream of this).
+- NOT for bugs, chores, or refactors with no user-facing behavior — a PRD there is speculative ceremony (YAGNI).
+
+## Process
+
+### Iron Law
+
+**Every user story carries at least one measurable acceptance criterion, or it ships as an open, named gap — never a silent guess. The skill authors the PRD; it does not author the spec, mutate the roadmap, or claim the item.**
+
+A PRD that hides what it does not know launders assumptions into requirements. A criterion that cannot be judged is not a criterion. If a story has no measurable criterion and you did not surface it in the chase list, STOP and add it.
+
+---
+
+### Argument Resolution
+
+- **`item`** — the slug/name of the work item. From the `item` argument, or the roadmap row being worked, or ask. Sets the artifact directory `docs/product-requirements/<item>/`.
+- **`description`** — a plain feature description, used when no richer input (BRD, roadmap row) exists. The skill requires nothing more than this.
+
+---
+
+### Phase 1: INGEST — Gather the Richest Available Input
+
+Load the richest input that exists, and **degrade gracefully** — the only hard requirement is a one-line description.
+
+1. **BRD when present:** if `docs/inception/<engagement>/brd.md` exists and maps to this item, read its Business Objectives, Scope, and Functional Requirements as the seed.
+2. **Else the roadmap row:** if a roadmap exists (`docs/roadmap.md` aggregate or `docs/roadmap.d/` shard), read the row's summary for this item.
+3. **Else the description argument:** treat it as the sole seed.
+4. **Strategy grounding (optional):** call `read_strategy({ path })` on the harness MCP server when available; capture `Target problem` / `Who it's for` to keep stories aligned. Soft-fail silently when absent, invalid, or the server is unavailable.
+5. **Soft-degrade, never fail:** when the seed is sparse (only a title, no BRD/roadmap/strategy), proceed and record a gap ("no BRD/roadmap context; requirements elicited from description only"). Do not abort.
+
+---
+
+### Phase 2: DRAFT-PRD — Synthesize the First Draft
+
+1. **Write the PRD** to `docs/product-requirements/<item>/prd.md` with these sections, each present even if thin:
+   - **Context** (+ a link to the source BRD when present)
+   - **Goal / Problem** — the user-facing outcome this item delivers
+   - **User Stories** — each `As a <role>, I want <goal>, so that <benefit>`, with its acceptance criteria and a MoSCoW priority
+   - **Prioritization summary** — the MoSCoW rollup (Must / Should / Could / Won't)
+   - **Non-Goals** — what this item explicitly does not cover
+   - **Open Questions (chase list)** — unresolved gaps, each phrased as a question
+2. **Acceptance criteria are EARS by default.** Each criterion follows an EARS pattern:
+   - Event-driven: "When `<trigger>`, the system shall `<response>`."
+   - Unwanted: "If `<condition>`, then the system shall not `<behavior>`."
+   - State-driven / optional: "While `<state>` / Where `<feature>`, the system shall `<response>`."
+     Render a criterion as **Given-When-Then** instead only when a story is behavior-heavy and reads more clearly that way. Every criterion must be testable — an EARS trigger→response or a numeric bound.
+3. **Prioritize every story with MoSCoW** (Must / Should / Could / Won't-this-time).
+4. **Tag gaps against the completeness rubric** (below). Every rubric miss becomes a gap `{ id, section, question, severity: blocker | important | nice, status: open }`. Do not invent facts to fill a section — an empty-because-unknown section is a gap, not a place to guess.
+
+#### PRD completeness rubric
+
+- Every user story has ≥1 acceptance criterion, else it is a gap.
+- Every acceptance criterion is measurable — an EARS trigger→response or a numeric bound — else it is a gap.
+- Every user story carries a MoSCoW priority, else it is a gap.
+- Non-Goals is non-empty (state the boundary explicitly), else it is a gap.
+- Every story traces to the Goal / Problem (or to an explicit gap).
+
+---
+
+### Phase 3: GAP-INTERVIEW — Resolve What You Can
+
+1. **Ask ONE question at a time, in plain text.** Order the gap queue by severity (`blocker` → `important` → `nice`). Ask the highest-severity open gap first, wait for the answer, then continue. Present each gap as a scannable multiple-choice table where options exist, and state a recommendation. **Do NOT route questions through `emit_interaction` or `AskUserQuestion`** — the human will not see them; plain text in your reply is the only reliable channel across all clients.
+2. **Fold each answer back into the PRD.** Update the relevant story/criterion (source: `interview`) and move the gap `open → resolved` with the captured answer.
+3. **Mark unresolvable gaps as chase-list questions.** If the author cannot answer (only the client/stakeholder can), keep the gap `open` and phrase it as a question to ask them.
+4. **Stop when the queue is drained** — every gap is either `resolved` or `open` (chase-list). Do not loop past a drained queue inventing new questions.
+
+---
+
+### Phase 4: FINALIZE — Ship and Hand Off
+
+1. **Finalize `docs/product-requirements/<item>/prd.md`** with all sections populated and the **Open Questions** section listing every remaining `open` gap as a question.
+2. **Stay in your lane.** Do **not** mutate the roadmap and **never** write an `assignee` — this skill operates on one already-picked item; claiming it is `harness-execution`'s job at execution start. If no roadmap exists, there is nothing to touch.
+3. **Emit the handoff to `harness-brainstorming`** via `emit_interaction` (type `transition`, `suggestedNext: harness-brainstorming`). State plainly that brainstorming will consume the PRD — seeding the spec's `## User Stories` and `## Success Criteria` from the PRD's EARS criteria — and then author the spec. **Do not author the spec here.**
+4. **Run `harness validate`.**
+
+---
+
+## Harness Integration
+
+- **`read_strategy`** — Phase 1: read `STRATEGY.md` when present to align stories; never write it.
+- **`gather_context`** — Phase 1 (optional): pull existing project/business knowledge to ground the domain.
+- **`emit_interaction`** — Phase 4: record the `transition` to `harness-brainstorming`. The transition is recorded, not surfaced — any human-facing question is asked in plain text.
+- **`harness validate`** — Phase 4: verify artifact placement and project health.
+- **Boundary with adjacent skills:** `product-advisor` WRITES the BRD (upstream); this skill READS the BRD and WRITES the PRD; `harness-brainstorming` READS the PRD and WRITES the spec; `acceptance-eval` READS the spec's criteria and JUDGES them. This skill never crosses those lines.
+- **Portability:** no hardcoded repo layout. The only hard requirement is a feature description. BRD, roadmap, and strategy are optional richer inputs consumed when present and soft-degraded when absent.
+
+## Success Criteria
+
+- Running the skill with only a feature description (no BRD/roadmap/strategy) produces `docs/product-requirements/<item>/prd.md` with all sections present, none empty.
+- Every user story has ≥1 acceptance criterion; every criterion is EARS-shaped (trigger→response) or carries a numeric bound.
+- Every user story carries a MoSCoW priority.
+- The gap interview asked one question at a time and folded each answer back (resolved gaps moved `open → resolved`); every unresolved gap ships as a chase-list question.
+- The skill did not modify the roadmap and did not write an `assignee`.
+- The handoff transitions to `harness-brainstorming`; no spec was authored.
+- `harness validate` passes.
+
+## Rationalizations to Reject
+
+| Rationalization                                                           | Reality                                                                                                                                                             |
+| ------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| "This story's outcome is obvious, so I can skip the acceptance criterion" | The Iron Law: every story carries a measurable criterion or a named gap. An implied criterion cannot be judged by `acceptance-eval`.                                |
+| "There's no BRD/roadmap, so I can't run"                                  | The only hard requirement is a description. Soft-degrade to description-only and record a gap — never abort.                                                        |
+| "I'll write the spec while I'm here since the requirements are clear"     | This skill stops at the PRD. Authoring a `proposal.md` is a gate violation — hand off to `harness-brainstorming`.                                                   |
+| "I'll mark the item in-progress / assign it so the pick is recorded"      | This skill never mutates the roadmap or writes `assignee`. Claiming happens at execution start; assigning here makes the orchestrator skip the item.                |
+| "Plain prose criteria are fine; EARS is ceremony"                         | EARS is the grammar `harness-planning`/`harness-brainstorming` consume and the shape `acceptance-eval` reads as MEASURABLE. Freeform criteria drift to un-judgable. |
+
+## Gates
+
+- **No un-criterioned stories.** Every user story is either covered by a measurable acceptance criterion or shipped as an `open` chase-list gap. A story that is neither = Iron Law violation; stop and fix.
+- **No guessed requirements.** An unknown section is a gap, not a place to invent facts.
+- **No spec authoring.** This skill stops at the PRD; writing a `proposal.md` = gate violation. Hand off to `harness-brainstorming`.
+- **No roadmap mutation and no assignment.** Writing the roadmap or the `assignee` field = gate violation.
+- **No hard failure on sparse input.** Absent BRD/roadmap/strategy → description-only + recorded gap. Aborting because context is thin = gate violation.
+
+## Escalation
+
+- **The author cannot answer a blocker gap:** keep it `open`, phrase it as a chase-list question for the client/stakeholder, and note in the handoff that brainstorming inherits an open blocker.
+- **Scope spans multiple independent capabilities:** stop and suggest splitting into multiple items (one PRD per item), rather than one bloated PRD.
+- **No item slug resolvable:** ask for a short name; without one, the artifact directory cannot be created.
+- **The item is a bug/chore/refactor with no user-facing behavior:** say so and recommend going straight to `harness-brainstorming` — a PRD adds no value.
+
+## Examples
+
+### Example: PRD for a picked roadmap item with no BRD
+
+**Context:** roadmap-pilot picked "Export dashboard to PDF." No BRD exists; the roadmap row is a one-line summary.
+
+**INGEST:** No BRD found; read the roadmap row summary; strategy present (aligns with the "reporting" audience). Seed = row summary + description. Recorded no gap (seed sufficient).
+
+**DRAFT-PRD:** Wrote `docs/product-requirements/export-dashboard-to-pdf/prd.md`. 3 user stories:
+
+- _As an analyst, I want to export the current dashboard to PDF, so that I can share it offline._ **[Must]** — "When the user clicks Export → PDF, the system shall produce a PDF of the current dashboard within 5 seconds."
+- _As an analyst, I want the PDF to preserve applied filters, so that it reflects what I see._ **[Should]** — "When a filter is applied, the exported PDF shall reflect the filtered data set."
+- _As an admin, I want export disabled for restricted dashboards._ **[Could]** — "If the dashboard is marked restricted, then the system shall not offer the Export → PDF action."
+
+Tagged 2 gaps: G1 (blocker) "max PDF page count?"; G2 (nice) "landscape or portrait default?".
+
+**GAP-INTERVIEW:** Q1 (G1): "Cap the export at (A) 10 pages, (B) 50 pages, (C) no cap? Recommend B." → "B." Folded into story 1's criterion. Q2 (G2) → author defers → kept open as chase-list.
+
+**FINALIZE:** PRD finalized; Open Questions lists G2. No roadmap mutation, no assignee. Emitted handoff → `harness-brainstorming` will seed the spec's Success Criteria from these EARS criteria. `harness validate` — passes.