yadflow 2.18.1 → 3.1.0

package/skills/yad-engineer-review/SKILL.md

@@ -39,11 +39,22 @@ a **second set of eyes, never the authority**: it cannot approve or merge. Where
 (no remote), run an equivalent AI first-pass by hand and capture its notes. Record that the AI review
 ran; surface its findings to the engineer. Do **not** treat AI approval as a gate.
 
+Also run the **Review Companion** so the human review is easy and fun: post the 60-sec trailer
+(`yad review trailer --repo <r> --pr <n> --body "<text>"`) and deal the swipe cards / open the grounded
+chat from the bundle (`yad review context --repo <r> --pr <n>` → [yad-review-companion](../yad-review-companion/SKILL.md)).
+Companion comments carry `<!-- yad:noblock -->` (history-only, never block); genuine concerns are posted
+unflagged and block normally.
+
 ### Step 2 — `approve` (the engineer review — the human gate)
 A human engineer reads the diff **against the spec** (`specs/<story>/`) and the acceptance criteria,
 and records an approval. Determine the rule from the PR's Impact & Risk block (run
 `../yad-pr-template/templates/checks/risk-route.sh` on the PR body): base, or escalated to a
 domain-owner per touched domain. Record each approval; re-evaluate whether the rule is satisfied.
+Record `engagement: verified` when the engineer reviewed through the companion (else `none` for a bare
+approve); `yad review reconcile --epic <id> --repo <r> --pr <n>` stamps it onto the ship record from the
+platform. Soft by default (both count; a bare approve draws `yad review nudge`); only gates when
+`hub.review.requireEngagement: true`. The signal is gameable by design and sits **beside** the CI gates,
+never above them.
 Recording an approval does **not** ship — shipping is a separate, explicit step. Front-half discipline:
 the gate talks only through files; refuse to treat AI review as a human approval.
 
@@ -55,8 +66,8 @@ engineer-review rule is satisfied (Step 2). Then:
   ```json
   { "story": "<story>", "task": "<task>", "repo": "<repo>", "branch": "feat/<story>-<task>-…",
     "pr": "<url|#>", "mergeCommit": "<sha>", "gates": ["spec-link","contract-check","build-test-lint"],
-    "ai_review": "coderabbit (advisory)", "engineer_review": [{"approver":"<name>","role":"<role>","domain":"<opt>"}],
-    "risk": "<low|medium|high>", "shippedAt": "<YYYY-MM-DD>" }
+    "ai_review": "coderabbit (advisory)", "engineer_review": [{"approver":"<name>","role":"<role>","domain":"<opt>","engagement":"<verified|none>"}],
+    "companion": {"trailer":true,"cards":true,"chat":false}, "risk": "<low|medium|high>", "shippedAt": "<YYYY-MM-DD>" }
   ```
 - **Update the story state** — when **every** task in `specs/<story>/tasks.md` has a ship record, set
   the story frontmatter `status: shipped`; otherwise `status: in-build`. The chain

package/skills/yad-engineer-review/references/ship-and-record.md

@@ -33,9 +33,10 @@ Append-only. One record per shipped task:
       "gates": ["spec-link", "contract-check", "build-test-lint"],
       "ai_review": "coderabbit (advisory)",
       "engineer_review": [
-        { "approver": "amelia", "role": "owner" },
-        { "approver": "carol", "role": "reviewer" }
+        { "approver": "amelia", "role": "owner", "engagement": "verified" },
+        { "approver": "carol", "role": "reviewer", "engagement": "none" }
       ],
+      "companion": { "trailer": true, "cards": true, "chat": false },
       "risk": "low",
       "shippedAt": "2026-06-06"
     }
@@ -46,6 +47,18 @@ Append-only. One record per shipped task:
 This is the back-half analogue of the front half's `approvals.json` — files only, no hidden state, so a
 future service can drive ship by writing the same records.
 
+**Engagement (the Review Companion).** Each `engineer_review` entry carries `engagement: verified | none`
+— `verified` when the engineer reviewed through the [companion](../../yad-review-companion/SKILL.md)
+(`yad review trailer/context/nudge`, a real trailer/cards/chat session over the diff), `none` for a bare
+approve. The optional `companion` block records which faces ran. It is **soft by default** (both count;
+a bare approve draws a friendly `yad review nudge`); it only gates ship when
+`hub.review.requireEngagement: true`. `yad review reconcile --epic <id> --repo <r> --pr <n>` reads the
+code PR's approvals (with the engagement signal) and stamps them onto the matching ship record — the
+back-half **bridge**, the analogue of `yad gate sync`. The signal is gameable by design ("visible, not
+impossible"): it makes engineer-review quality visible, it does not prove a human read the diff. It sits
+**beside** the CI gates (build/test/lint/contract/verified-commits) — never above them; CI still
+decides machine safety, the merge is still the human act.
+
 ## Story state
 
 The story frontmatter `status` reflects build progress:

package/skills/yad-hub-bridge/references/bridge.md

@@ -35,6 +35,40 @@ glab api projects/:id/merge_requests/:iid/notes          # discussion notes (com
 All commands run as the **local user**; the bridge stores no tokens. If the CLI is missing/unauthenticated
 or the remote is unreachable, the bridge stops and the gate falls back to file-only (no error).
 
+> **GitLab read parity (GAP-6).** `readPrGitLab` reads approvals (`approved_by[]`) and discussions but
+> does **not** map a "Request changes" reviewer state to `CHANGES_REQUESTED` — on GitLab the blocking
+> signal is an **unresolved discussion**. So on GitLab the gate is held by unresolved threads, not by a
+> reviewer state. (GitHub maps both.) If you need GitLab "Request changes" honored, read
+> `reviewers[].state` from the MR and map it to `CHANGES_REQUESTED`.
+
+## Open recipes (request the reviewers — used by `yad gate open` / `yad open-pr`)
+
+Opening the review PR/MR must **request the required reviewers**, or an escalated gate is opened with
+nobody asked. The CLI (`createPr` in `cli/platform.mjs`) does this; an agent opening a PR by hand uses:
+
+**GitHub** — create, then add each reviewer (a bad/non-collaborator login WARNS instead of aborting the
+whole create):
+```bash
+gh pr create --title "review: <artifact> (<epic>)" --body <body> --base <default> --head <branch> \
+  --assignee @me --label domain:<repo>
+gh pr edit <n> --add-reviewer <login>      # once per required reviewer
+```
+
+**GitLab** — a Free/Core MR carries a **single** reviewer field (multiple reviewers is Premium), so
+assign the first required reviewer and **@-mention the rest in a note** so they are still notified/routed:
+```bash
+glab mr create --title "review: <artifact> (<epic>)" --description <body> \
+  --target-branch <default> --source-branch <branch> --reviewer <first-login> --label domain:<repo> --yes
+glab mr note <iid> -m "Review requested (owner + reviewer rule): @<l2> @<l3> — please review and approve/comment on this MR (this drives the gate)."
+```
+The read side counts a mentioned reviewer normally: their eventual **approval** still appears in
+`…/approvals → approved_by[]`, and their **note** in `…/discussions` — so the single-reviewer-field cap
+loses only the native "Reviewers" UI chip, not the gate routing.
+
+Required reviewers = the hub's `reviewer`/`domain-owner` roster logins for the touched scopes, PLUS any
+repo whose ownership lives only in `repos.json` `domain_owner`/`domain_owners` (those are resolved to a
+login and requested too — otherwise an escalated step is structurally unsatisfiable through routing).
+
 ## Login → role resolution (order)
 
 1. Roster (`.sdlc/hub.json`) maps `login` → `name` + base `role` (owner/reviewer).

package/skills/yad-open-pr/SKILL.md

@@ -62,6 +62,16 @@ PR/MR with the auto-assigned assignee + reviewers.
 On `high` risk or a contract touch, run `bash checks/risk-route.sh <pr-body>` to print the required
 domain-owner reviewers — the same escalation `yad-engineer-review` enforces.
 
+### Step 3b — Post the review trailer (optional, recommended)
+Make the reviewer's job easy: generate the 60-sec briefing and post it to the new PR/MR so it greets
+every reviewer in the UI (idempotent; safe to re-run after a push):
+```bash
+yad review trailer --repo <name> --pr <n> --body "<companion-generated briefing>"
+```
+The full fun-review flow (cards + grounded chat + engagement) is driven by the
+[Review Companion](../yad-review-companion/SKILL.md) during `yad-engineer-review`. Non-blocking by
+design — companion comments carry `<!-- yad:noblock -->`.
+
 ### Step 4 — Stop (no merge)
 Report the PR/MR URL and the requested reviewers. The PR now runs the check gates (Step C); the human
 engineer review and merge happen in `yad-engineer-review` (Step E).

package/skills/yad-pr-template/templates/checks/pr-template.sh

@@ -45,6 +45,15 @@ if [ -z "$BODY" ] || [ ! -f "$BODY" ]; then
   exit 1
 fi
 
+# The Review Companion injects a `<!-- yad:trailer --> … <!-- /yad:trailer -->` briefing block (and
+# `<!-- yad:noblock -->` notes) into the description. Strip those before the template check so the
+# AI-generated prose can never hide a required section heading or be mistaken for the `Risk level:`
+# value (the trailer is prepended, so an unstripped "risk level" mention would win `head -1`).
+STRIPPED="$(mktemp)"
+trap 'rm -f "$STRIPPED"' EXIT
+sed '/<!-- yad:trailer -->/,/<!-- \/yad:trailer -->/d; /<!-- yad:noblock -->/d' "$BODY" > "$STRIPPED"
+BODY="$STRIPPED"
+
 rc=0
 require_heading() {
   if ! grep -qiE "^[[:space:]]*$1[[:space:]]*$" "$BODY"; then

package/skills/yad-review-companion/SKILL.md

@@ -0,0 +1,89 @@
+---
+name: yad-review-companion
+description: 'The fun, easy, transparent review companion for the SDLC review gates. Generates a 60-second AI "trailer" of what changed and where the risk is, deals a swipe-through deck of small review "cards", and runs a grounded chat where a reviewer asks anything and their questions become the review record — then records an engagement signal on the approval (verified vs none) and posts a friendly public nudge on a bare rubber-stamp. Works on the front-half artifact-review PR/MR (yad gate) and the back-half code PR/MR (yad review). Use when the user says "review this", "run the companion", "give me the trailer/cards", or wants reviewing to be less of a chore.'
+---
+
+# SDLC — Review Companion (fun & easy, transparent review)
+
+**Goal:** make the honest review the *easiest, most enjoyable* path, and make laziness **visible**, not
+blocked. This companion does **not** try to prove a human read something — no quiz, no un-fakeable
+proof (a quiz is answerable by AI, swipes can be spammed). Instead it removes the friction that makes
+reviewers skip, and it makes review *quality* visible to the whole team.
+
+> **Philosophy — "visible, not impossible."** Every engagement signal here is gameable by design. It
+> raises the cost of a bare rubber-stamp and shines a light on it; it never claims certainty. State that
+> openly — do not oversell it.
+
+This companion is the AI layer on top of [`yad-review-gate`](../yad-review-gate/SKILL.md) (front half)
+and [`yad-engineer-review`](../yad-engineer-review/SKILL.md) (back half). The **gate** still owns the
+predicate and advancement; the companion only enriches the *input* and records the *engagement* field.
+The CLI never calls an LLM — **you** (this skill) generate the text and post it via the platform.
+
+## The four faces
+
+1. **🎬 Trailer (A)** — a 60-second briefing: what this change does, where the risk is (from the step's
+   `risk_tags`), and an honest read-time estimate. Posted to the **PR/MR description** as a delimited
+   `<!-- yad:trailer --> … <!-- /yad:trailer -->` block so everyone sees it in the UI. Regenerated when
+   the artifact changes (it must never lie about the current content).
+2. **🃏 Cards (B)** — split the change into small **atomic claims**, one per card, each anchored to real
+   line numbers / hunks and tagged with risk. Posted as PR/MR comment threads the reviewer skims 👍/🤔.
+3. **💬 Chat (C)** — a grounded Q&A: the reviewer asks anything; you answer **only from real material**
+   (the artifact + diff + contract + the repo `code-map.md`/`pack.md` + sister docs). The reviewer's
+   questions and flagged concerns become the review record. If you **cannot** answer from the material,
+   say so — that gap is itself a finding (post it as a genuine, blocking comment).
+4. **🏆 Social (E)** — a verified-engagement mark on a real companion review, a friendly public
+   @-mention nudge on a bare approve, and light read-only gamification surfaced by `yad status`.
+
+## Markers (the contract with the gate — all live in PLATFORM data, never a ledger file)
+
+- `<!-- yad:trailer -->` / `<!-- /yad:trailer -->` — the trailer block in the PR/MR description.
+- `<!-- yad:noblock -->` — on **every** companion-posted comment (card deck, chat log) and the nudge.
+  The gate **excludes** these threads from the blocking check, so they stay unresolved as a permanent
+  PR/MR history trail and never hold the gate. A reviewer's *genuine* concern is posted **without** this
+  marker, so it blocks normally.
+- `<!-- yad:engagement verified -->` — embedded in the body of a companion-driven **Approve** review.
+  A bare UI click has no marker → `engagement: none`. (Definitions live in `cli/companion.mjs`.)
+
+## On activation
+
+Inputs: `epic` + `artifact` (front half) **or** `repo` + `pr` (back half); and the `action`
+(`trailer` | `cards` | `chat` | `approve` | `nudge`, default the full flow).
+
+1. **Get the grounding bundle.** Front half: `yad gate review <epic> [artifact]` prints JSON with the
+   artifact path, risk tags, PR number, contract path, touched domains, repo code-map paths, and
+   `requireEngagement`. Back half: `yad review chat --repo <r>` (see `yad-engineer-review`) provides the
+   diff + code-map grounding. Read the named files yourself — never invent content.
+2. **Trailer.** Generate ≤6 lines (what / risk / read-time), grounded only in the bundle. Post it:
+   `yad gate trailer <epic> <artifact> --body "<text>" [--pr <n>]` (idempotent; re-run after edits).
+3. **Cards.** Produce atomic claims, each citing real lines. Post the deck as a single comment carrying
+   `<!-- yad:noblock -->`. A reviewer's 🤔 with a real concern → re-post as a **normal, unflagged**
+   comment so it blocks.
+4. **Chat.** Answer from the material with cited lines. Append the Q&A log as a `<!-- yad:noblock -->`
+   comment so it persists in history without blocking. Turn genuine concerns into unflagged comments.
+5. **Approve.** When the reviewer is satisfied, submit an Approve whose body carries
+   `<!-- yad:engagement verified -->` (so the gate records `engagement: verified`). GitHub:
+   `gh pr review <n> --approve --body "<note>\n\n<!-- yad:engagement verified -->"`. GitLab: approve,
+   then post the marker as a note (`glab mr approve <n>` + `glab mr note <n> -m "…<!-- yad:engagement verified -->"`).
+6. **Nudge.** A bare approve (engagement `none`) still counts under the soft default; `yad gate sync`
+   posts the friendly @-mention automatically. You may also post it directly with the
+   `<!-- yad:noblock -->` marker.
+
+## Hard rules
+
+- **Never write a ledger file.** Post comments / the trailer / the approval to the PLATFORM (the
+  reviewer's own `gh`/`glab`). CI writes `approvals.json`/`comments.json`; the `ledger-guard` check
+  rejects a human ledger edit on a review PR. The markers ride in platform data only.
+- **Trailer/cards/chat are grounded ONLY in real material.** If the material does not answer a
+  question, say so and record the gap — do not fabricate.
+- **Companion comments never block; genuine concerns always do.** Flag the former with `yad:noblock`;
+  leave the latter unflagged.
+- **The engagement signal is gameable and you say so.** It makes review quality visible; it is not
+  proof. The strict-mode switch is `hub.review.requireEngagement` (off by default).
+- **The companion never approves on a human's behalf and never merges.** It assists; the human acts.
+
+## File-only mode (no platform)
+
+With no hub platform, there is no PR to post to: write the trailer to
+`reviews/<artifact-base>--<date>--trailer.md` and the card/chat notes alongside the existing
+`reviews/*.md`, and the reviewer records approval the manual way (`yad-review-gate` `approve`). The same
+generation logic applies; only the surface changes.

package/skills/yad-review-gate/SKILL.md

@@ -92,8 +92,12 @@ Repeat comment→address rounds until reviewers are satisfied. **Commenting neve
 
 **`approve`** — Record an approval. Append to `.sdlc/approvals.json`:
 ```json
-{ "artifact": "<artifact>", "step": "<step id>", "approver": "<name>", "role": "<owner|reviewer|domain-owner>", "domain": "<optional>", "status": "approved", "date": "<YYYY-MM-DD>" }
+{ "artifact": "<artifact>", "step": "<step id>", "approver": "<name>", "role": "<owner|reviewer|domain-owner>", "domain": "<optional>", "status": "approved", "date": "<YYYY-MM-DD>", "engagement": "<verified|none>" }
 ```
+`engagement` records whether the approval came through the [Review Companion](../yad-review-companion/SKILL.md)
+(a real trailer/cards/chat session = `verified`) or as a bare click (`none`). It is soft by default
+(both count; a bare approve draws a friendly nudge) and only gates when `hub.review.requireEngagement`
+is on — see `references/gating.md`. The signal is gameable by design ("visible, not impossible").
 Also write/refresh `reviews/<artifact-base>--<YYYY-MM-DD>--approved.md` as a **named roster** with three
 sections, so every participant is attributable in one place:
 

package/skills/yad-review-gate/references/gating.md

@@ -12,6 +12,15 @@ Let `A` = the set of `approved` records in `.sdlc/approvals.json` for this step.
 **Escalated pass** (step `risk_tags` ∩ `{contract, auth, payments}` ≠ ∅): base pass AND, for every
 touched `domain`, `|domainOwners[domain]| >= 1`.
 
+**Engagement (the Review Companion).** Each approval carries `engagement: verified | none` —
+`verified` when it was recorded through the companion (a real trailer/cards/chat session), `none` for a
+bare UI click. By **default (soft)** both count: a bare approve still passes the gate but is recorded
+`none` and draws a friendly public @-mention nudge, so review *quality* is visible without blocking
+anyone. When `hub.review.requireEngagement: true`, only `verified` approvals are counted toward the
+sets above (a determined faker can still run an empty session — the signal is **gameable by design**;
+it raises the cost of a rubber-stamp and makes laziness visible, it does not prove a human read the
+artifact). Philosophy: *visible, not impossible.*
+
 **Touched domains** are resolved from files, not hardcoded:
 - Architecture+contract review: the touched domains are the epic's `repos` (every repo shares the
   contract surface).
@@ -55,6 +64,15 @@ counterpart to the `reviews/*--comments.md` markdown). It does **not** feed the
 alone decide the gate — but it makes the `approved.md` roster's "Reviewed / commented by" section
 attributable, and it is the same shape a future service or the platform bridge can write.
 
+## Non-blocking companion comments (`<!-- yad:noblock -->`)
+The Review Companion posts scaffolding comments (the card deck, the chat log) and the social nudge.
+These are fun/interactive aids, **not** review objections, so they must never hold the PR/MR — yet they
+are deliberately **left unresolved** so they remain in the PR/MR history forever (anyone can scroll back
+to see the trailer, cards, chat, and nudges). Every such comment carries a `<!-- yad:noblock -->`
+marker, and the gate **excludes marked threads** from the unresolved-thread blocking check (so it does
+not "resolve to pass" — it ignores them). A reviewer's *genuine* concern is posted **without** the
+marker and blocks normally, exactly as a `CHANGES_REQUESTED` or any unresolved human thread does.
+
 ## Platform-backed input (the bridge)
 When the hub has a platform (`.sdlc/hub.json`) and the bridge is enabled, reviewers can approve/comment
 on a real PR/MR instead of (or as well as) the skill recording it directly. `action: sync`

package/skills/yad-review-comments/SKILL.md

@@ -1,63 +0,0 @@
----
-name: yad-review-comments
-description: 'Installs platform-matched PR/MR review-comment scaffolds into a repo so reviewers leave structured, attributable feedback that maps cleanly into the SDLC file ledger. Works for code repos and the product hub. GitHub has no repo-level multi-comment template, so the scaffold is a committed REVIEW_COMMENTS.md reviewers copy from (saved as Saved Replies on GitHub / comment templates on GitLab). Each canned comment carries an attributable `**<name> (<role>)**` header that matches the `## <name> (<role>)` headings yad-review-gate writes. Use when the user says "add the comment templates" or "set up review comments" for a repo.'
----
-
-# SDLC — Review Comment Templates
-
-**Goal:** Give reviewers a consistent, **attributable** set of canned PR/MR comments so review feedback
-reads the same across repos and **maps cleanly into the file ledger** the gate keeps. The headers match
-the `## <name> (<role>)` shape `yad-review-gate` writes into `reviews/<artifact>--<date>--comments.md`
-and the per-commenter record in `comments.json`, so a synced or copy-pasted comment lands without
-reformatting.
-
-## Platform reality (why this is a committed doc, not a config file)
-
-Neither GitHub nor GitLab has a **repo-level** multi-comment template convention: GitHub *Saved Replies*
-are per-account and GitLab *comment templates* are per-user/group, both set in the UI — there is no
-`.github/comment_templates/` or `.gitlab/comment_templates/` the repo can ship. The pragmatic mechanism
-on **both** is a single committed doc reviewers copy from (and optionally paste once into their personal
-Saved Replies / comment templates). This skill ships that doc.
-
-## Conventions
-
-- `{project-root}` resolves from the project working directory — the **product** repo (holds the
-  canonical templates under this skill).
-- Canonical sources live in this skill's `templates/`:
-  - `templates/github/REVIEW_COMMENTS.md` → installs to `<repo>/.github/REVIEW_COMMENTS.md`
-  - `templates/gitlab/REVIEW_COMMENTS.md` → installs to `<repo>/.gitlab/REVIEW_COMMENTS.md`
-- The two variants are identical except a footer line (GitHub: "save these as Saved Replies"; GitLab:
-  "save these as comment templates").
-
-## Inputs
-
-- `repo`   — the repo to add the scaffold to (one of an epic's repos), or `hub` for the product hub.
-- `action` — `wire` (install the matching scaffold). Default `wire`.
-
-## On Activation
-
-### Step 1 — Resolve the repo and detect the platform
-Map `repo` → its path (`{project-root}/demo-repos/<repo>/` or the registry `path`); for `repo: hub` the
-target is `{project-root}` and the platform comes from `.sdlc/hub.json`. Detect the platform: a GitHub
-remote or `.github/` → GitHub; a GitLab remote or `.gitlab/` → GitLab. If ambiguous, ask.
-
-### Step 2 — `wire` (drop only the matching scaffold)
-Copy the matching `templates/<platform>/REVIEW_COMMENTS.md` into the repo's `.github/` or `.gitlab/`.
-Do not clobber an existing non-SDLC file of the same name — back it up / ask. Commit on the repo's
-default branch (shared infrastructure, not a task diff). Idempotent — re-running refreshes in place.
-
-### Step 3 — Stop (no auto-advance)
-Report what was committed. The scaffold is an aid to human review; it approves nothing and touches no
-`.sdlc/` state.
-
-## Hard rules
-
-- **Drop only the matching scaffold** for the detected platform.
-- **Attributable headers** — every canned comment keeps the `**<name> (<role>)**` form so the gate's
-  ledger and the PR thread agree.
-- **Nothing auto-advances.** Comments feed the human review and (via the bridge) `yad-review-gate`.
-
-## Reference
-- Comment conventions + the full scaffold contents: `references/comment-conventions.md`.
-- The ledger headings these match: `../yad-review-gate/SKILL.md` (comment action) and `references/gating.md`.
-- The review bridge that syncs platform comments into the ledger: `../yad-hub-bridge/SKILL.md`.

package/skills/yad-review-comments/references/comment-conventions.md

@@ -1,55 +0,0 @@
-# Review comment conventions
-
-The scaffold (`REVIEW_COMMENTS.md`) groups canned comments into **blocking** (a gate would fail / must
-be fixed before merge) and **non-blocking** (suggestions, nits, questions). Every comment starts with an
-attributable header:
-
-```
-**<name> (<role>)**
-```
-
-`<role>` is one of `owner | reviewer | domain-owner` — the same roles `yad-review-gate` records. This
-header matches the `## <name> (<role>)` headings the gate writes into
-`reviews/<artifact>--<date>--comments.md`, so a comment copied from the PR thread (or synced by
-`yad-hub-bridge`) needs no reformatting to land in the ledger.
-
-## Blocking comments (a gate or rule says stop)
-
-These map to the code-repo check gates (`yad-checks`) and the file-boundary / contract rules:
-
-- **spec-link** — "This commit has no `Task: <story>-<task>` trailer; the spec-link gate will fail. Add
-  the trailer (and ensure `specs/<story>/link.md` exists)."
-- **contract-check** — "This diff changes the contract surface without `Contract-Change: yes` + a
-  re-locked contract. Route back to the architecture gate and re-lock before this can merge."
-- **build-test-lint** — "Lint/build/test is red (or the test doesn't exercise the new behavior). The
-  build-test-lint gate must pass with a test that actually exercises the acceptance criterion."
-- **file-boundary** — "This diff touches files the task's `Files:` list didn't declare. Re-scope the
-  task (re-run `yad-spec`) rather than widening the diff silently."
-
-## Escalation / routing comment
-
-- **routing** — "Risk is `high` / a contract|auth|payments surface is touched — this needs a
-  domain-owner approval per touched repo (the same escalation `yad-review-gate` applies). Run
-  `bash checks/risk-route.sh <body>` (code repo) or `bash checks/hub-route.sh <body>` (hub)."
-
-## Non-blocking comments
-
-- **suggestion** — "Suggestion (non-blocking): …"
-- **nit** — "Nit: …"
-- **question** — "Question: … (not blocking — just want to understand)."
-
-## Approval note
-
-- **approve** — "Approving as `<role>`. Recorded in `approvals.json` (code-repo ship: `build-log.json`).
-  On the hub, your approval here is pulled in by `yad-review-gate action: sync`."
-
-## Hub front-artifact review
-
-The hub scaffold adds a **Front-artifact review** section whose headers mirror the gate's comment file
-exactly, so reviewing an `epic.md` / `architecture.md` / `ui-design.md` / `stories/` PR produces comments
-that drop straight into `reviews/<artifact>--<date>--comments.md`:
-
-```
-**<name> (<role>)**
-- <comment about scope / contract surface / acceptance signals / story split>
-```

package/skills/yad-review-comments/templates/github/REVIEW_COMMENTS.md

@@ -1,49 +0,0 @@
-# Review comments — canned replies
-
-Copy a block below into a PR review comment. Keep the `**<name> (<role>)**` header — it matches the
-SDLC review ledger (`reviews/<artifact>--<date>--comments.md`) so feedback stays attributable.
-`<role>` is one of `owner | reviewer | domain-owner`.
-
-## Blocking (a gate or rule says stop — must be fixed before merge)
-
-**<name> (<role>)**
-- spec-link: this range has no `Task: <story>-<task>` trailer — the spec-link gate will fail. Add the
-  trailer and make sure `specs/<story>/link.md` exists.
-
-**<name> (<role>)**
-- contract-check: this diff changes the contract surface without `Contract-Change: yes` + a re-locked
-  contract. Route back to the architecture gate and re-lock before merge.
-
-**<name> (<role>)**
-- build-test-lint: lint/build/test is red, or the test doesn't exercise the new behavior. The gate must
-  pass with a test that actually exercises the acceptance criterion.
-
-**<name> (<role>)**
-- file-boundary: this touches files the task's `Files:` list didn't declare. Re-scope the task (re-run
-  `yad-spec`) instead of widening the diff.
-
-## Routing / escalation
-
-**<name> (<role>)**
-- routing: risk is `high` / a contract|auth|payments surface is touched — needs a domain-owner approval
-  per touched repo (same escalation as `yad-review-gate`). Run `bash checks/risk-route.sh <body>`.
-
-## Non-blocking
-
-**<name> (<role>)**
-- Suggestion (non-blocking): …
-
-**<name> (<role>)**
-- Nit: …
-
-**<name> (<role>)**
-- Question: … (not blocking — just want to understand).
-
-## Approval
-
-**<name> (<role>)**
-- Approving as `<role>`. Recorded in `approvals.json` (ship: `build-log.json`).
-
----
-> Tip (GitHub): paste the blocks you use most into your personal **Saved Replies**
-> (Settings → Saved replies) so they are one click away in any PR.

package/skills/yad-review-comments/templates/gitlab/REVIEW_COMMENTS.md

@@ -1,49 +0,0 @@
-# Review comments — canned replies
-
-Copy a block below into an MR review comment. Keep the `**<name> (<role>)**` header — it matches the
-SDLC review ledger (`reviews/<artifact>--<date>--comments.md`) so feedback stays attributable.
-`<role>` is one of `owner | reviewer | domain-owner`.
-
-## Blocking (a gate or rule says stop — must be fixed before merge)
-
-**<name> (<role>)**
-- spec-link: this range has no `Task: <story>-<task>` trailer — the spec-link gate will fail. Add the
-  trailer and make sure `specs/<story>/link.md` exists.
-
-**<name> (<role>)**
-- contract-check: this diff changes the contract surface without `Contract-Change: yes` + a re-locked
-  contract. Route back to the architecture gate and re-lock before merge.
-
-**<name> (<role>)**
-- build-test-lint: lint/build/test is red, or the test doesn't exercise the new behavior. The gate must
-  pass with a test that actually exercises the acceptance criterion.
-
-**<name> (<role>)**
-- file-boundary: this touches files the task's `Files:` list didn't declare. Re-scope the task (re-run
-  `yad-spec`) instead of widening the diff.
-
-## Routing / escalation
-
-**<name> (<role>)**
-- routing: risk is `high` / a contract|auth|payments surface is touched — needs a domain-owner approval
-  per touched repo (same escalation as `yad-review-gate`). Run `bash checks/risk-route.sh <body>`.
-
-## Non-blocking
-
-**<name> (<role>)**
-- Suggestion (non-blocking): …
-
-**<name> (<role>)**
-- Nit: …
-
-**<name> (<role>)**
-- Question: … (not blocking — just want to understand).
-
-## Approval
-
-**<name> (<role>)**
-- Approving as `<role>`. Recorded in `approvals.json` (ship: `build-log.json`).
-
----
-> Tip (GitLab): paste the blocks you use most into your personal/group **Comment templates**
-> (Preferences → Comment templates) so they are one click away in any MR.