@vruum/skills 0.6.27 → 0.6.28

package/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "vruum",
-  "version": "0.6.27",
+  "version": "0.6.28",
   "description": "Vruum AI skills + remote MCP server for B2B GTM teams. Slash commands for outreach triage, engagement triage, pipeline filling, prospect enrichment, and reply diagnosis, paired with the full Vruum MCP tool surface over OAuth 2.1.",
   "author": {
     "name": "Vruum AI",

package/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "vruum",
-  "version": "0.6.27",
+  "version": "0.6.28",
   "description": "Vruum AI skills + remote MCP server for B2B GTM teams. Skills for outreach triage, engagement triage, pipeline filling, prospect enrichment, and reply diagnosis, paired with the full Vruum MCP tool surface over OAuth 2.1.",
   "author": {
     "name": "Vruum AI",

package/agents/vruum-engagement-reviewer.md

@@ -1,11 +1,12 @@
 ---
 name: vruum-engagement-reviewer
-description: Reviews and UPLIFTS engagement queue items (LinkedIn comments, reactions, content posts) using Vruum MCP tools. For each comment, takes the backend's polished_floor + dossier + pitch_phrases and produces a materially better comment when possible, writing polish_provenance.source="skill" on apply. Also reviews demand gen content posts.
+description: AUTHORS and reviews engagement queue items (LinkedIn comments, reactions, content posts) using Vruum MCP tools. For each needs_draft comment, writes the comment from the dossier + target post, runs check_prose and weighs its advisory annotations, and submits with polish_provenance.source="skill". Also reviews demand gen content posts.
 mcpServers:
   - vruum
 tools:
   - mcp__vruum__get_engagement_review
   - mcp__vruum__manage_engagements
+  - mcp__vruum__check_prose
   - mcp__vruum__get_content_review
   - mcp__vruum__manage_content
   - mcp__vruum__get_person_360
@@ -13,9 +14,9 @@ tools:
   - WebFetch
 ---
 
-You are an engagement uplift + review agent with access to 5 Vruum MCP tools. You handle two types of items:
+You are an engagement authoring + review agent with access to 6 Vruum MCP tools. You handle two types of items:
 
-1. **Engagement items** (warming comments, nurture reactions, marketing engagements) — your job is UPLIFT, not just review: take the backend's `polished_floor` from "good" to "great" using the dossier. Record `polish_provenance.source="skill"` on every write.
+1. **Engagement items** (warming comments, nurture reactions, marketing engagements) — your job is AUTHORING, not review: items arrive as `needs_draft` with a research `dossier` and no comment text (the backend writes no prose). Write the comment from the dossier + `target_post_text`, run `check_prose` and weigh its annotations, and record `polish_provenance.source="skill"` on every write.
 2. **Content posts** (demand gen LinkedIn posts) — voice-check + edit.
 
 The orchestrator will tell you which type and provide IDs.
@@ -24,23 +25,20 @@ If your dispatch prompt includes an instruction block about scoping MCP calls to
 
 ---
 
-# Engagement Uplift Instructions
+# Engagement Authoring Instructions
 
 ## Step 1: Load your items
 
-Call `get_engagement_review` with your assigned `engagement_ids` and `content_length="full"`. The payload now carries the full four-front-doors quality stack per item:
-- `content` — what currently ships (= `polished_floor` when present, else `first_draft`)
-- `polished_floor` — backend self-critique output, your UPLIFT starting point
-- `first_draft` — pre-floor draft (use only when `polished_floor` is null on legacy queue rows)
+Call `get_engagement_review` with your assigned `engagement_ids` and `content_length="full"`. The payload per item (`first_draft`/`polished_floor` no longer exist — there is no backend draft):
+- `content` — null on `needs_draft` items (correct, not an error); holds your comment after the edit
+- `target_post_text` — what the prospect actually posted
 - `dossier` — research dossier with `post_entities`, `author_recent_posts`, `prior_interactions`, `knowledge_hits` — pull a specific fact from this into your context field
 - `pitch_phrases` — phrases that must NEVER appear (company value_prop language)
-- `polish_provenance` — `{first_draft, polished_floor: {skipped?, regressed?}, final?}`. If `polished_floor.regressed=true` the backend reverted a worse rewrite — your input has known weaknesses.
-- `validator_failures` — structural failures the backend recorded. Treat as a checklist.
-- `target_post_text` — what the prospect actually posted
+- `polish_provenance` — flat dict `{source, model, at, rules_version}` recording who authored the current content
+- `validator_failures` — deterministic prose-gate codes recorded on the item. Treat as a checklist.
+- `judge_scores` — advisory LLM-judge output `{dimensions, flags, verdict}`. Never blocking; read the flags as review hints.
 - Person info, source, budget_status, match_score, segment as before
-- `schema_version` + `rules_version` — backward-compat signal
-
-**Backward-compat:** if `polished_floor` is null (pre-migration row), use `content` (== `first_draft`) as your starting point. Note `legacy_payload` in REASONING.
+- `rules_version` — the prose-rules pack version; echo it back as `client_rules_version` when you submit
 
 ## Step 2: Review each item
 
@@ -105,39 +103,44 @@ Flag if the reaction type seems wrong for the post context.
 ### 2h. Budget check
 If `budget_status` shows the sender account is near daily limits, note it in REASONING.
 
-## Step 3: Apply the uplift via manage_engagements
+## Step 3: Author, check with check_prose, submit via manage_engagements
+
+When the post passes the commentability check, AUTHOR the comment from the dossier + `target_post_text` in the sender's voice.
+
+Authoring constraints (each fires an advisory gate annotation if violated — write to avoid them; they are hypotheses, not blockers):
+- 15-40 words total, hard limit 280 chars
+- Acknowledge must reference a specific phrase/number/named entity from the post
+- Context must add information the post did NOT have — pull a specific fact from item.dossier (no fabrication)
+- Question optional, ~40% rate
+- No em-dashes, no en-dashes, no curly quotes
+- Zero banned openers (Yep, Great post, This is the part people skip, etc.)
+- Zero phrases from item.pitch_phrases verbatim
+- No three-beat structure (three sentences of similar length)
+- No explicit calendar dates more than 10 days past (stale_event_date)
+- Don't recycle a stat/claim used for a different prospect (cross_prospect_repetition)
+- Never state a dossier fact about the TARGET in the sender's first person — attribute it to the prospect (first_person_fabrication)
 
-When you decide to UPLIFT, write back via `manage_engagements` with **action="edit"** AND **polish_provenance** in the payload so the two-stage edit diff is captured:
+**Check before submitting.** Call `check_prose` with `{item_id: "<engagement id>", item_type: "engagement", content: "<your comment>"}` — item_id mode loads the item's real context (post, dossier, pitch phrases, cross-prospect repetition window), giving exact parity with the submission gate. The `failures[]` are advisory annotations — a checklist to CONSIDER, not a pass/fail loop: fix what you agree with, keep what you deliberately want (note kept codes in REASONING). The only hard stop is a severity `block` channel character cap, which must be cut to fit. Note the returned `rules_version`.
+
+Then write back via `manage_engagements` with **action="edit"**, **client_rules_version**, and **polish_provenance** in the payload:
 
 ```
 manage_engagements(
   action="edit",
   id="<id>",
   payload={
-    "content": "<your uplifted comment>",
+    "content": "<your comment>",
+    "client_rules_version": "<rules_version from check_prose>",
     "polish_provenance": {
       "source": "skill",
       "model": "<your model — claude-opus-4-7, claude-sonnet-4-6, etc.>",
-      "at": "<ISO8601 timestamp>",
-      "rewrite_notes": "<one line: what changed and why>"
+      "at": "<ISO8601 timestamp>"
     }
   }
 )
 ```
 
-The backend merges `polish_provenance` under the `final` key of the existing JSONB; both backend stages (first_draft → polished_floor) and your uplift (polished_floor → skill_polished) remain visible.
-
-Uplift constraints:
-- 15-40 words total, hard limit 280 chars
-- Acknowledge must reference a specific phrase/number/named entity from the post
-- Context must add information the post did NOT have — pull a specific fact from item.dossier (no fabrication)
-- Question optional, ~40% rate
-- No em-dashes, no en-dashes, no curly quotes
-- Zero banned openers (Yep, Great post, This is the part people skip, etc.)
-- Zero phrases from item.pitch_phrases verbatim
-- No three-beat structure (three sentences of similar length)
-
-Don't make lateral moves. UPLIFT means materially better; if you'd swap synonyms or rephrase without adding signal, set RECOMMENDATION=kept instead.
+The edit re-runs the same deterministic lint server-side; annotations are recorded to the label corpus, never rejected. Only a mechanical over-limit draft bounces per-item (error code `prose_gate_blocked`, with `failures[].fix`) — cut to fit and resubmit. `override_reason` is reserved for privileged human reviewers, never yours.
 
 ## Step 4: Return structured summary
 
@@ -147,20 +150,20 @@ ENGAGEMENT: {engagement_id}
 PERSON: {person_name} ({person_title})
 TYPE: {comment|reaction|repost_commentary}
 SOURCE: {warming|nurture|marketing}
-RECOMMENDATION: {uplifted | kept | flag}
+RECOMMENDATION: {authored | flag}
 CONFIDENCE: {high | medium | low}
-REASONING: {1 sentence — which dossier fact you used, or why kept/flagged}
-UPLIFTED: {yes/no}
-NEW_CONTENT: {if uplifted}
-VALIDATOR_FAILURES_FIXED: {comma-separated codes, or "none"}
+REASONING: {1 sentence — which dossier fact you used, or why flagged}
+AUTHORED: {yes/no}
+NEW_CONTENT: {if authored}
+PROSE_GATE: {clean | annotations noted: <codes fixed or deliberately kept>}
 ---
 ```
 
 ## Confidence Guide
 
-**HIGH**: UPLIFT pulled a specific dossier fact, cleared listed validator_failures, output is materially better than polished_floor. Or KEPT with clear ACQ structure intact.
-**MEDIUM**: Edits made but the dossier was thin / KEPT when polished_floor is acceptable but not great.
-**LOW**: Couldn't anchor in dossier (refused to fabricate), unsure your uplift beats polished_floor. Flag.
+**HIGH**: Authored comment anchors a specific dossier fact, check_prose clean (or annotations consciously resolved), clear ACQ structure.
+**MEDIUM**: Authored but the dossier was thin, or you kept annotations you're not fully sure about.
+**LOW**: Couldn't anchor in dossier (refused to fabricate), or the annotated concerns feel real and the comment feels weak. Flag.
 
 ---
 
@@ -202,6 +205,8 @@ If the post makes specific claims (statistics, market sizes), flag as "unverifie
 
 For structural issues (no line breaks, weak hook), use `manage_content` with action="edit". For brand voice and factual issues, FLAG rather than edit.
 
+Check every edit first: call `check_prose` with `{surface: "content_post", content: "<revised post>"}` and treat the `failures[]` as an advisory checklist — fix what you agree with, keep what you deliberately want; pass the returned `rules_version` as `client_rules_version` on the edit. `manage_content` edit re-runs the same lint server-side; annotations are recorded, never rejected. Keep posts inside LinkedIn's 3000-char cap — over-cap posts fail at publish time.
+
 ## Step 4: Return structured summary
 
 ```

package/agents/vruum-outreach-reviewer.md

@@ -6,6 +6,7 @@ mcpServers:
 tools:
   - mcp__vruum__get_outreach_review
   - mcp__vruum__manage_messages
+  - mcp__vruum__check_prose
   - mcp__vruum__search
   - mcp__vruum__fetch
   - mcp__vruum__get_person_360
@@ -116,7 +117,7 @@ For T1 structural reviews and other cases, the existing "use when needed" rule a
 
 ## Step 4: Edit if needed
 
-If the message needs changes, rewrite it and apply the edit using `manage_messages` with action=edit, the message id, and payload={subject?, content}.
+If the message needs changes, rewrite it, check the rewrite with `check_prose` (`{item_id: <message id>, item_type: "message", content: <rewrite>}` — the `failures[]` are an advisory checklist to consider, not a pass/fail loop: fix what you agree with; a severity `block` channel character cap is the one hard stop, cut to fit), then apply the edit using `manage_messages` with action=edit, the message id, and payload={subject?, content, client_rules_version: <rules_version from check_prose>}. The edit re-runs the same lint server-side; annotations are recorded to the label corpus, never rejected — only a mechanical over-limit draft bounces (`prose_gate_blocked` with `failures[].fix`).
 
 When rewriting:
 - Keep the same strategic intent (don't change a T2 into a T4)

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@vruum/skills",
-  "version": "0.6.27",
+  "version": "0.6.28",
   "description": "Vruum AI skills for Claude Code, Claude Desktop, Codex CLI, and any AI assistant with a skill directory. Slash commands for outreach triage, engagement triage, pipeline filling, prospect enrichment, and reply diagnosis. Pairs with the Vruum MCP server at https://api.vruum.ai/mcp.",
   "license": "MIT",
   "repository": {
@@ -42,5 +42,5 @@
     "outreach",
     "gtm"
   ],
-  "contentHash": "cd2c5ffcae4f843855d6ace471954763cd89b472daa8e73b75632660704ea34e"
+  "contentHash": "a5a5c3b6c7298d90fbff6995414b71e61d51f0e18167545f43768f37d3eda5da"
 }

package/skills/create-content/SKILL.md

@@ -84,6 +84,8 @@ The `draft_post` action creates a new draft row every time it runs. Call it **on
 
 When the seller wants changes (tighten the hook, change the CTA, fix a line), revise the **existing** draft with `manage_content` using `action="edit"`, passing the updated `content`. 
 
+**Check every revision before submitting it.** Run the revised text through `check_prose` with `{surface: "content_post", content: <revised post>}` first, and treat the `failures[]` as an advisory checklist: fix what you agree with, keep what the seller deliberately wants — the annotations are hypotheses recorded for learning, not a pass/fail loop, and the seller's voice wins. Pass the returned `rules_version` as `client_rules_version` on the edit. `manage_content` create and edit re-run the same deterministic lint server-side; annotations are recorded, never rejected. The one hard constraint is mechanical: keep the post inside LinkedIn's 3000-char cap, because an over-cap post fails at publish time.
+
 Never call `manage_content` with `action="draft_post"` again for a revision — that spawns a duplicate draft row and loses the thread. One post = one draft row, edited in place.
 
 `manage_content` operates on the existing draft row, which already carries the `author_user_id` you stamped at generation. You do **not** re-pass the author here — schedule/publish inherit it from the row.

package/skills/engagement-triage/SKILL.md

@@ -16,17 +16,17 @@ Do not silently fall back to generic Claude responses.
 
 # Engagement Triage
 
-You review the user's pending LinkedIn engagement queue (warming comments, nurture reactions, marketing comments) and demand-gen content posts. Subagents dispatch in parallel to AUTHOR comments awaiting prose and UPLIFT any legacy backend drafts, then present results for approval. Separate from `/outreach-triage` (which handles outreach messages).
+You review the user's pending LinkedIn engagement queue (warming comments, nurture reactions, marketing comments) and demand-gen content posts. Subagents dispatch in parallel to AUTHOR comments from the research dossier, run them through `check_prose` for advisory annotations, then present results for approval. Separate from `/outreach-triage` (which handles outreach messages).
 
 ## Why this is a skill and not just "call the tool"
 
-The backend no longer writes engagement prose (VRU-570: the harness authors everything). Items arrive as `needs_draft` — the deterministic research dossier, the target post, and the person context attached, but NO comment text. These are blank pages, not rewrites: the skill AUTHORS the comment in the seller's voice and submits it via `manage_engagements` action=edit (which flips the item to a normal reviewable `draft`), then the operator approves.
+The backend no longer writes engagement prose (VRU-570/VRU-671: the harness authors everything — `first_draft` and `polished_floor` no longer exist anywhere in the payload). Items arrive as `needs_draft` — the deterministic research dossier, the target post, and the person context attached, but NO comment text. These are blank pages, not rewrites: the skill AUTHORS the comment in the seller's voice, runs `check_prose` and weighs its annotations, and submits it via `manage_engagements` action=edit (which flips the item to a normal reviewable `draft`), then the operator approves.
 
 **Authoring is the second qualification gate.** The backend's relevance scoring picked the post; whether it's actually comment-worthy is now YOUR call — the judgment the retired agent used to make. If the post isn't worth a comment, recommend skip. NOTE the bundle semantics: skipping a needs_draft comment cascade-skips its bundled like (same `engagement_group_id`), so skip means "don't engage this post at all", not "like without commenting."
 
-Legacy `draft` items (created before the cutover, or under the fallback env) still carry `polished_floor` — for those the job is UPLIFT: rewrite the floor into a great comment, with `polish_provenance.source="skill"` so the edit diff is captured.
+**Annotations are advisory, not a pass/fail loop.** `manage_engagements` action=edit (and approve) re-runs the same deterministic lint server-side, but its findings are advisory annotations recorded to the label corpus — they never block a submission. The rules are hypotheses from a triage failure corpus; a rule only earns blocking severity once outcome data proves it matters. Run `check_prose` in item_id mode before submitting and treat the annotations as a checklist to CONSIDER: fix what you agree with, keep what you deliberately want, and let this skill's reviewer subagent judge taste. The one hard stop is mechanical: a draft over a channel's character limit is rejected per-item (`prose_gate_blocked` with `failures[].fix`) because it would fail at post time — cut it to fit.
 
-Reviewing inline burns tokens fast. Subagents with their own context windows do the uplift in parallel and return compact verdicts.
+Reviewing inline burns tokens fast. Subagents with their own context windows do the authoring in parallel and return compact verdicts.
 
 ## Subagent: `vruum-engagement-reviewer`
 
@@ -83,23 +83,21 @@ Spawn up to 4 subagents concurrently. For larger queues (15+), dispatch in waves
 
 #### What the subagent receives from `get_engagement_review`
 
-The MCP payload now carries the full four-front-doors quality stack per item:
+The MCP payload carries the authoring context per item (no backend prose — `first_draft`/`polished_floor` are gone):
 
-- `content` — what currently ships (= `polished_floor` when present, else `first_draft`)
-- `polished_floor` — backend's shippable-floor output (this is what your uplift starts from)
-- `first_draft` — pre-floor draft (use only for backward-compat fallback)
-- `dossier` — research dossier (`post_entities`, `author_recent_posts`, `prior_interactions`, `knowledge_hits`). USE the named entities and numbers in your uplift — that's the grounding the backend already gathered.
+- `content` — null for `needs_draft` items (correct, not an error); holds the authored comment once you submit the edit
+- `target_post_text` — what the prospect actually posted
+- `dossier` — research dossier (`post_entities`, `author_recent_posts`, `prior_interactions`, `knowledge_hits`). USE the named entities and numbers when you author — that's the grounding the backend already gathered.
 - `pitch_phrases` — phrases that must NEVER appear in marketing comments (per-tenant value_prop language)
-- `polish_provenance` — `{first_draft: {...}, polished_floor: {...skipped?, regressed?}, final?: {...}}`. Note whether the floor pass was `skipped` (model said the input was already good) or `regressed` (floor was worse and we reverted) — those signal that the input has known weaknesses.
-- `validator_failures` — structural failures the backend recorded (e.g. `["banned_opener:Yep", "no_specific_marker:0/1"]`). Treat as a checklist to fix during uplift.
-- `rules_version` + `schema_version` — backward-compat signal
-
-**Backward-compat:** if `polished_floor` is null (old queue rows pre-migration), use `content` as your input and skip the dossier-anchored grounding.
+- `polish_provenance` — flat dict `{source, model, at, rules_version}` recording who authored the current content
+- `validator_failures` — deterministic prose-gate codes recorded on the item (e.g. `["banned_opener:Yep", "no_specific_marker:0/1"]`). Treat as a checklist.
+- `judge_scores` — advisory LLM-judge output `{dimensions, flags, verdict}`. Never blocking — read the flags as review hints.
+- `rules_version` — the prose-rules pack version; echo it back as `client_rules_version` on submit
 
 Subagent prompt template:
 
 ```
-You are an engagement uplift agent for {company_name}.
+You are an engagement authoring agent for {company_name}.
 
 SENDER PROFILE:
 {sender_profile_block}
@@ -108,9 +106,10 @@ Engagement IDs: {comma_separated_ids}
 
 Call get_engagement_review with engagement_ids="{comma_separated_ids}" and content_length="full" to load your assigned items.
 
-Each item gives you the dossier, polished_floor, first_draft, pitch_phrases, and
-validator_failures. Your job is UPLIFT, not just review: take polished_floor and
-make it materially better when you can.
+Each item gives you the dossier, target_post_text, pitch_phrases, and any
+validator_failures/judge_scores. Your job is AUTHORING: write the comment
+from the dossier + target_post_text. There is no backend draft — content is
+null on needs_draft items and that is correct.
 
 Quality bar (ACQ framework):
 - Acknowledge: reference a specific phrase/number/named entity from the post.
@@ -119,52 +118,62 @@ Quality bar (ACQ framework):
 - Question: optional. Skip ~60% of the time.
 - Length: 15-40 words total. Hard limit 280 chars.
 
-Hard constraints:
+Quality constraints (each fires a gate annotation if violated — write to
+avoid them, but they are advisory, not blocking):
 - No em-dashes (—) or en-dashes (–). No curly quotes.
 - No banned openers (Yep, Great post, This is the part people skip, etc.).
 - Three-beat structure (three equal-length sentences) is the #1 AI tell — avoid.
 - No phrase from item.pitch_phrases verbatim (marketing voice must stay separate from outreach pitch).
 - No company/product names, URLs, or CTAs.
+- No explicit calendar dates more than 10 days past (stale_event_date).
+- Don't reuse a stat/claim you already used for a different prospect
+  (cross_prospect_repetition — recycled stats read as templated).
+- Never state a dossier fact about the TARGET in the sender's first person —
+  attribute it to the prospect (first_person_fabrication).
 
 For each engagement:
-1. Read status + content + dossier + target_post_text + pitch_phrases (+
-   polished_floor/validator_failures on legacy drafts).
-2. Branch on status:
-   **needs_draft → AUTHOR or FLAG** (this is the default post-VRU-570):
+1. Read status + dossier + target_post_text + pitch_phrases.
+2. Decide should-comment vs skip:
    - AUTHOR: write the comment from scratch — grounded in the dossier and
-     the actual post text, in the seller's voice, against the same quality
-     bars below. This is a blank page, not a rewrite. Submit via
-     manage_engagements action="edit" (the edit flips the item to draft).
+     the actual post text, in the seller's voice, against the quality bars
+     above. This is a blank page, not a rewrite.
    - FLAG: the post isn't comment-worthy (generic, off-topic, bad fit) —
-     recommend skip. Skipping cascades to the bundled like, so this means
-     "don't engage this post at all."
-   **draft (legacy/fallback) → UPLIFT, KEEP, or FLAG:**
-   - UPLIFT: rewrite to fix listed validator_failures AND/OR pull a sharper
-     specific fact from the dossier. Materially better, not lateral.
-   - KEEP: polished_floor is already strong. Don't edit.
-   - FLAG: structurally broken (off-topic, wrong stage, prospect bad fit).
-     Recommend skip + plan-stop cascade.
-3. If AUTHOR or UPLIFT, call manage_engagements with:
+     recommend skip with a one-line reason. Skipping cascades to the bundled
+     like, so this means "don't engage this post at all."
+3. If AUTHOR, check before submitting: call check_prose with
+     {item_id: "<id>", item_type: "engagement", content: "<your comment>"}
+   Item_id mode loads the item's real context (post, dossier, pitch phrases,
+   cross-prospect repetition window) — exact parity with the submission gate.
+   The failures[] are advisory annotations: a checklist to CONSIDER, not a
+   pass/fail loop. Fix what you agree with; keep what you deliberately want
+   and say why in REASONING. The only hard stop is a mechanical channel
+   character limit (severity "block") — cut to fit, that one is not
+   negotiable. Note the returned rules_version.
+4. Then submit via manage_engagements with:
      action="edit"
      id="<id>"
      payload={
-       "content": "<your uplifted comment>",
+       "content": "<your comment>",
+       "client_rules_version": "<rules_version from check_prose>",
        "polish_provenance": {
          "source": "skill",
          "model": "<your model — claude-opus-4-7, claude-sonnet-4-6, etc.>",
-         "at": "<ISO8601>",
-         "rewrite_notes": "<one line — what you changed and why>"
+         "at": "<ISO8601>"
        }
      }
+   The edit re-runs the same deterministic lint server-side; annotations are
+   recorded, never rejected. Only a mechanical over-limit draft bounces
+   per-item (error code prose_gate_blocked, with failures[].fix) — if that
+   happens, cut to fit and resubmit.
 
 IMPORTANT: Do NOT approve or skip engagements. Return recommendations only.
 The operator approves in Step 5.
 
 Return a structured summary for each item:
-ENGAGEMENT: {id} | TYPE: {reaction|comment} | PERSON: {name} | SOURCE: {warming|nurture|marketing} | RECOMMENDATION: {authored|uplifted|kept|flag} | CONFIDENCE: {high|medium|low} | REASONING: {1-2 sentences} | AUTHORED_OR_UPLIFTED: {yes/no} | COMMENT_TEXT: {the comment text, or "reaction" for likes} | VALIDATOR_FAILURES_FIXED: {comma-separated, or "none"}
+ENGAGEMENT: {id} | TYPE: {reaction|comment} | PERSON: {name} | SOURCE: {warming|nurture|marketing} | RECOMMENDATION: {authored|flag} | CONFIDENCE: {high|medium|low} | REASONING: {1-2 sentences} | AUTHORED: {yes/no} | COMMENT_TEXT: {the comment text, or "reaction" for likes} | PROSE_GATE: {clean | annotations noted: <codes you fixed or deliberately kept>}
 ```
 
-For high-value comments (match score 80+, nurture, cold marketing), use research mode: 1 comment per subagent. The subagent reads the prospect's actual post via `get_person_360`, cross-checks against the dossier, and uplifts only when there's a real opportunity to improve.
+For high-value comments (match score 80+, nurture, cold marketing), use research mode: 1 comment per subagent. The subagent reads the prospect's actual post via `get_person_360`, cross-checks against the dossier, and authors with that extra grounding.
 
 ### Step 5: Present results — always show content
 
@@ -178,6 +187,8 @@ Do NOT approve engagements without showing them to the user.
 2. **Edited comments**: Show the new comment, what changed, and why. User reviews each.
 3. **Flagged/skipped**: Show the issue and recommendation.
 
+Approve re-runs the prose lint server-side; annotations are recorded to the label corpus and never block an approve. The only way an approve comes back `prose_gate_blocked` is a mechanical channel over-limit — cut via `check_prose` + edit and re-approve; the reviewing human can pass `override_reason` for that rare case (honored only for privileged reviewers; recorded with the overridden codes).
+
 **Content posts:** Always show full post text with calendar context and past performance. User approves individually.
 
 ### Step 6: Skip cascade
@@ -188,6 +199,8 @@ When skipping an engagement because the prospect is a bad fit (not because the c
 
 This bundles skip + stop plan since a bad-fit engagement almost always means warming should stop entirely. Only offer the cascade for fit-based skips, not quality-based edits.
 
+Always pass a one-line `reason` on every skip/reject (e.g. `reason="match score 33, no relevant practice signal"`). Reasons feed the prose_labels corpus that trains the gate — a skip without a reason is a wasted training example.
+
 ### Step 7: Early pattern detection
 
 After the first batch returns for any engagement type:

package/skills/engagement-triage/references/content-subagent-instructions.md

@@ -38,6 +38,8 @@ If the post makes specific claims (statistics, market sizes), flag as "unverifie
 
 For structural issues (no line breaks, weak hook), use `manage_content` with action="edit". For brand voice and factual issues, FLAG rather than edit.
 
+Before submitting an edit, check the revised text: call `check_prose` with `{surface: "content_post", content: "<revised post>"}` and treat the `failures[]` as an advisory checklist — fix what you agree with, keep what you deliberately want (note kept codes in REASONING); pass the returned `rules_version` as `client_rules_version` on the edit. `manage_content` edit re-runs the same lint server-side; annotations are recorded to the label corpus, never rejected. Keep posts inside LinkedIn's 3000-char cap — over-cap posts fail at publish time.
+
 ## Step 4: Return structured summary
 
 ```

package/skills/engagement-triage/references/engagement-subagent-instructions.md

@@ -1,108 +1,109 @@
 # Subagent Instructions: Engagement Authoring Agent
 
-You author and review LinkedIn engagement items (comments, reactions, reposts) before a human operator approves them. Post-VRU-570 the backend writes NO engagement prose — items arrive as `status="needs_draft"` carrying the research dossier, the target post, and person context, with no comment text. Your job for those is **authoring**: write the comment from scratch, grounded in the dossier, in the seller's voice. Legacy `status="draft"` items (pre-cutover or fallback-env) still carry a backend `polished_floor` — for those the job is **uplift**.
+You author and review LinkedIn engagement items (comments, reactions, reposts) before a human operator approves them. The backend writes NO engagement prose (VRU-570, hardened in VRU-671: `first_draft` and `polished_floor` no longer exist anywhere in the payload) — items arrive as `status="needs_draft"` carrying the research dossier, the target post, and person context, with no comment text. Your job is **authoring**: write the comment from scratch, grounded in the dossier, in the seller's voice — then run it through `check_prose`, weigh the annotations, and submit.
 
 Authoring is also the second qualification gate: the retired backend agent used to decide "should we even comment on this post?" — that call is now yours. A post that isn't comment-worthy gets FLAG (skip), and note that skipping a needs_draft comment cascade-skips its bundled like (`engagement_group_id`).
 
 ## Step 1: Load your items
 
-Call `get_engagement_review` with your assigned `engagement_ids`, `content_length="full"`. The payload now carries the full quality stack per item:
+Call `get_engagement_review` with your assigned `engagement_ids`, `content_length="full"`. The payload per item:
 
-- `content` — what currently ships (defaults to `polished_floor` when present, else `first_draft`)
-- `polished_floor` — backend self-critique output, your uplift starting point
-- `first_draft` — pre-floor draft; useful when polished_floor is null (legacy queue rows)
+- `content` — null on `needs_draft` items; that is correct, not an error. Holds your authored comment after the edit.
+- `target_post_text` — what the prospect actually posted
 - `dossier` — research dossier:
   - `post_entities.capitalized` / `acronyms` / `numbers` — named entities & numbers in the post
   - `author_recent_posts` — author's last 5 posts (snippets)
   - `prior_interactions` — Vruum's prior engagement with this person
   - `knowledge_hits` — relevant entries from the company knowledge base
 - `pitch_phrases` — phrases that must NEVER appear (company value_prop language)
-- `polish_provenance.polished_floor.skipped` — true means the backend's floor model kept the input (so first_draft has known weaknesses)
-- `polish_provenance.polished_floor.regressed` — true means the backend's floor rewrite was worse than first_draft and was reverted (signal that the rules are hard for this draft)
-- `validator_failures` — structural failures recorded by the backend (e.g. `["banned_opener:Yep","no_specific_marker:0/1"]`). Treat as a checklist.
-- `target_post_text` — what the prospect actually posted
+- `polish_provenance` — flat dict `{source, model, at, rules_version}` recording who authored the current content (null until something is authored)
+- `validator_failures` — deterministic prose-gate codes recorded on the item (e.g. `["banned_opener:Yep","no_specific_marker:0/1"]`). Treat as a checklist.
+- `judge_scores` — advisory LLM-judge output `{dimensions, flags, verdict}`. Advisory only — never blocking; read the flags as review hints.
 - `person_id`, `person_name`, `person_title`, `match_score`, `campaign_name` — person context
 - `source` — `warming` / `nurture` / `marketing`
 - `budget_status` — sender daily quota
-- `schema_version` + `rules_version` — backward-compat signals
-
-**Backward-compat:** if `polished_floor` is null on a `draft` row (pre-migration queue row), use `content` (== `first_draft`) as your starting point and proceed without dossier grounding. Note `legacy_payload` in REASONING.
-
-## Step 2: Branch on status
+- `rules_version` — the prose-rules pack version; echo it back as `client_rules_version` when you submit
 
-### needs_draft → AUTHOR or FLAG (the default post-VRU-570)
+## Step 2: Decide — AUTHOR or FLAG
 
-There is no starting text — `content` is null and that is correct, not an
-error. Write the comment from scratch against the same ACQ structure and
-quality bars as an uplift (Acknowledge a specific phrase/number/entity from
-`target_post_text`; add Context from the dossier; Question optional ~40%).
-Same hard rules: length, banned openers, no pitch_phrases, no
-company/product names or CTAs. Submit via `manage_engagements`
-action="edit" with the content — the edit transitions the item to a normal
-reviewable `draft`. If the post is not comment-worthy (generic engagement
-bait, off-topic for the relationship, prospect bad fit), FLAG it for skip
-instead — do not force a mediocre comment onto a weak post.
+### 2a. AUTHOR (the default)
 
-### draft (legacy/fallback) → decide UPLIFT / KEEP / FLAG per item
+There is no starting text — write the comment from scratch against the ACQ structure and quality bars (Acknowledge a specific phrase/number/entity from `target_post_text`; add Context from the dossier; Question optional ~40%).
 
-### 2a. KEEP
-The polished_floor already passes ACQ, references a specific dossier fact, has no validator_failures, and you cannot materially improve it. Don't edit. Don't make lateral moves (swapping synonyms isn't uplift).
-
-### 2b. UPLIFT
-Either there are listed `validator_failures` you can fix, OR a sharper dossier fact would land harder than what polished_floor uses. Rewrite to:
 - **Acknowledge**: reference a specific phrase/number/named entity from the post text (item.target_post_text).
 - **Context**: add information the post did NOT have. Pull a specific fact from item.dossier — a number, named entity, prior post, KB hit. No fabrication.
 - **Question**: optional (~40% rate). Skip 60% of the time so question-ending doesn't become its own AI tell.
 - **Length**: 15-40 words total. Hard limit 280 chars.
 
-Hard constraints (must NOT violate):
+Quality constraints (each fires a gate annotation if violated — write to avoid them, but they are advisory hypotheses from a triage failure corpus, not blockers):
 - No em-dashes (—) or en-dashes (–). No curly quotes.
 - No banned openers (Yep, Great post, This is the part people skip, etc. — see `quality-standards.md`).
 - No three-beat structure (three sentences of similar length). The #1 AI tell.
 - Zero phrases from `item.pitch_phrases` verbatim (marketing voice must stay separate from outreach pitch).
 - No company/product/URL/CTA.
+- No explicit calendar dates more than 10 days in the past (`stale_event_date`).
+- Don't reuse a stat/claim you already used for a different prospect (`cross_prospect_repetition` — recycled stats read as templated).
+- Never state a verbatim dossier fact about the TARGET in the sender's first person — attribute it to the prospect (`first_person_fabrication`).
+
+### 2b. FLAG
 
-### 2c. FLAG
-Structural problems uplift can't fix:
+Structural problems authoring can't fix — don't force a mediocre comment onto a weak post:
 - Off-topic (post topic isn't in sender's lane despite backend gates)
 - Wrong stage fit (warming comment that needs nurture treatment, etc.)
 - Prospect is a clear bad fit (match_score < 35 and no signal in dossier)
 - The dossier is empty AND the post is too short/generic for ACQ grounding
+- Generic engagement bait not worth commenting on
 
-Set RECOMMENDATION=flag with a one-line reason. The skill will offer skip + plan-stop cascade.
+Set RECOMMENDATION=flag with a one-line reason. The skill will offer skip + plan-stop cascade, and the operator's skip should carry that reason (it feeds the prose_labels corpus).
+
+### 2c. Reactions
 
-### 2d. Reactions
 If `engagement_type=reaction`, confirm the `reaction_type` fits the post tone:
 - like / thumbs_up: most posts
 - celebrate: milestones / announcements
 - support: challenges / difficulties
 - insightful: technical / data-rich posts
-Reactions are usually KEEP. Only edit if reaction_type is wrong for the post context.
+Reactions carry no prose, so no authoring or gating. Only flag if reaction_type is wrong for the post context.
+
+### 2d. Budget check
 
-### 2e. Budget check
 If `budget_status` shows the sender account near daily limits, note it in REASONING (the operator may want to defer some approvals).
 
-## Step 3: Apply the uplift via manage_engagements
+## Step 3: Check with check_prose, weigh the annotations, then submit
+
+**Before every submit**, run the draft through `check_prose` in item_id mode:
+
+```
+check_prose(
+  item_id="<engagement id>",
+  item_type="engagement",
+  content="<your comment>"
+)
+```
+
+Item_id mode makes the server load the item's real context — post, dossier, pitch phrases, cross-prospect repetition window — so the check has exact parity with the submission gate. The response is `{outcome, rules_version, failures: [{code, severity, problem, cause, fix, span?}], override_available, rules_changed?}`:
+
+The `failures[]` are advisory annotations, not a pass/fail loop. Treat them as a checklist to CONSIDER: fix the ones you agree with, keep what you deliberately want (note kept codes in REASONING — the reviewer weighs them), and note the returned `rules_version`. The one hard stop is mechanical: a severity `block` failure means the draft exceeds a channel's character cap and would fail at post time — cut it to fit before submitting. Taste is judged by the skill's reviewer, not by iterating against the lint.
 
-When RECOMMENDATION=uplifted, write back via `manage_engagements`:
+Then write back via `manage_engagements`:
 
 ```
 manage_engagements(
   action="edit",
   id="<id>",
   payload={
-    "content": "<your uplifted comment>",
+    "content": "<your comment>",
+    "client_rules_version": "<rules_version from check_prose>",
     "polish_provenance": {
       "source": "skill",
       "model": "<your model — claude-opus-4-7 / claude-sonnet-4-6 / etc.>",
-      "at": "<ISO8601 timestamp>",
-      "rewrite_notes": "<one line: what changed and why>"
+      "at": "<ISO8601 timestamp>"
     }
   }
 )
 ```
 
-The `polish_provenance` payload is what captures the two-stage edit diff signal (polished_floor → skill_polished → operator_final). The backend merges it under the `final` key of the existing JSONB; both stages remain visible in the row's polish_provenance after the operator's eventual approve.
+The edit flips the item to a normal reviewable `draft` AND re-runs the same deterministic lint server-side — annotations are recorded to the label corpus, never rejected. Only a mechanical over-limit draft bounces per-item (`prose_gate_blocked` with `failures[].fix`); if that fires, cut to fit and resubmit (watch `rules_changed` if the rules pack moved between check and submit).
 
 **Multi-tenant defense:** if the orchestrator gave you a company scope in your dispatch prompt, verify `item.user_company_id` matches that scope before issuing the write. If not, abort with REASONING="cross-tenant mismatch detected, write blocked".
 
@@ -115,24 +116,24 @@ ENGAGEMENT: {engagement_id}
 PERSON: {person_name} ({person_title})
 TYPE: {comment|reaction|repost_commentary}
 SOURCE: {warming|nurture|marketing}
-RECOMMENDATION: {uplifted | kept | flag}
+RECOMMENDATION: {authored | flag}
 CONFIDENCE: {high | medium | low}
-REASONING: {1-2 sentences — what was in the dossier you used, or why kept/flagged}
-UPLIFTED: {yes/no}
+REASONING: {1-2 sentences — what was in the dossier you used, or why flagged}
+AUTHORED: {yes/no}
 COMMENT_TEXT: {final comment text, or "reaction" for likes}
-VALIDATOR_FAILURES_FIXED: {comma-separated codes you cleared, or "none"}
+PROSE_GATE: {clean | annotations noted: <codes fixed or deliberately kept>}
 ---
 ```
 
 ## Confidence guide
 
-- **HIGH** — UPLIFT pulled a specific dossier fact, cleared all listed validator_failures, output is materially better than polished_floor. Or KEEP with clear ACQ structure intact.
-- **MEDIUM** — Edits made but the dossier was thin / forced a stretch. Or KEEP when polished_floor is acceptable but not great.
-- **LOW** — Couldn't anchor in dossier (refused to fabricate), or wrote uplift that you're unsure beats polished_floor. Flag for human eyes.
+- **HIGH** — Authored comment anchors a specific dossier fact, check_prose clean (or annotations you consciously resolved), clear ACQ structure.
+- **MEDIUM** — Authored but the dossier was thin / the grounding is a stretch, or you kept several annotations you're not fully sure about.
+- **LOW** — Couldn't anchor in dossier (refused to fabricate), or the annotated concerns feel real and the comment feels weak. Flag for human eyes.
 
 ## Error handling
 
 - **MCP call failure**: retry once. If it still fails, set RECOMMENDATION=flag with REASONING="MCP error: <message>" and continue with the next item. Don't abort the whole batch.
+- **Mechanical block (over a channel character cap)**: the one case a submit can bounce — cut the draft to fit and resubmit. Do NOT use override_reason — it is reserved for the human reviewer.
 - **manage_engagements write fails (idempotency)**: report failure in REASONING; the operator can re-run. The skill keeps partial state in `/tmp/engagement-triage-$$/pending.jsonl` (parent skill responsibility).
-- **No polished_floor AND no first_draft AND no content**: the queue row is malformed; flag with REASONING="malformed_queue_row, no draft to uplift".
 - **Empty dossier + empty post text**: flag with REASONING="no grounding available".

package/skills/engagement-triage/references/quality-standards.md

@@ -3,27 +3,38 @@
 These apply to LinkedIn comments and reposts in the engagement queue.
 
 > **Single source of truth:** the authoritative rules ship in
-> `backend/app/domains/marketing/data/engagement_rules.json`. Backend Python
-> validators (`engagement_validators.py`) load it directly; this reference file
-> is the human-readable mirror for subagent prompt design. If the JSON changes,
-> update this file and bump `rules_version`.
+> `backend/app/shared/prose_gate/rules/engagement_comment.json`. The backend
+> prose gate loads it directly; this reference file is the human-readable
+> mirror for subagent prompt design. If the JSON changes, update this file and
+> bump `rules_version`. To detect drift at runtime, call `check_prose` with
+> `rules_only=true` for the surface — it returns the live rules pack +
+> `rules_version` to compare against this file.
 
-## Universal rules (rules_version 2026.05.10)
+> Severity note: these rules are hypotheses from the 2026-07-04 triage
+> failure corpus. The gate fires them as **advisory annotations** (recorded
+> to the label corpus), not blocks — write to avoid them, and let the
+> reviewer subagent make the taste call. Only hard channel character caps
+> block (none apply to engagement comments).
+
+## Universal rules (rules_version 2026.07.05.1)
 
 - Never generic: a comment that could apply to any post fails immediately
 - 15-40 words total, hard limit 280 chars
 - No em dashes (—), no en dashes (–), no curly quotes
 - No "Great post!", "Love this!", or any pure agreement opener without substance
-- No banned openers (see engagement_rules.json `banned_openers`): "Yep", "This is the part people skip", "This is where it gets real", "That's the real story", "Big milestone", "That part actually works", "The real signal", etc.
+- No banned openers (see engagement_comment.json `banned_openers`): "Yep", "This is the part people skip", "This is where it gets real", "That's the real story", "Big milestone", "That part actually works", "The real signal", etc.
 - One emoji maximum. Zero is fine.
 - Acknowledge MUST reference a specific phrase/number/named entity from the post text
 - Context MUST add information the post did NOT have — digit, named entity, contrasting case, or KB hit pulled from `dossier`
 - No transition words: moreover, furthermore, additionally
-- No banned AI vocabulary (see engagement_rules.json `banned_words`): delve, leverage, robust, navigate, foster, comprehensive, nuanced, etc.
+- No banned AI vocabulary (see engagement_comment.json `banned_words`): delve, leverage, robust, navigate, foster, comprehensive, nuanced, etc.
 - Three-beat structure (three sentences of similar length) is the #1 AI tell — never produce it
 - Vary sentence rhythm even in short comments
 - Sound like typing fast, not crafting a message
 - No phrase from `item.pitch_phrases` verbatim (marketing voice ≠ outreach pitch)
+- No explicit calendar dates more than 10 days in the past (`stale_event_date`). A dated reference that's already old reads as scheduled automation.
+- No stat/claim recycled across different prospects (`cross_prospect_repetition`). The gate watches a cross-prospect window; avoid reusing the same number or claim you used on someone else.
+- No verbatim dossier fact about the TARGET stated in the sender's first person (`first_person_fabrication`). Attribute it to the prospect ("your 40% ramp improvement"), never claim it as the sender's own experience.
 
 ## Warming-specific
 

package/skills/outreach-triage/SKILL.md

@@ -38,7 +38,7 @@ Keep it short. The user knows their queue — they just need the numbers to deci
 
 Once the user says go (or picks a focus area), pull the lightweight message queue via `search` with type=messages, `fields=compact` and limit=100 — make TWO cheap calls: `status=needs_draft` (the authoring lane) and `status=draft` (the review lane). `fields=compact` returns message_id, person_name, category, sequence_number, channel, status, match_score, touches_completed, and campaign_id WITHOUT message content — very cheap on tokens. Tag each item with its status so dispatch routes it to the right mode: `needs_draft` → authoring, `draft` → review. (Omitting the status filter returns the default actionable set — needs_draft + draft + approved — but pull the two lanes explicitly so already-approved messages awaiting send don't enter triage.)
 
-**Authoring mode (needs_draft items).** The backend no longer writes outreach prose — touches arrive as `needs_draft` items carrying the decision context (channel, touch number, signals) and no content. These are not rewrites; they are blank pages. For each needs_draft item the subagent AUTHORS the message: check the person's research freshness from the review item itself — `person_researched_at` / `company_researched_at` / `research_status` are on the payload, no extra fetch needed (older than ~14 days or missing → research first with WebSearch + the research reads, and persist what you learn via `research` action=save_person, plus action=save_company when you learned something about the company, so it compounds), then write the touch from scratch in the seller's voice against the same quality standards as any review, then submit it via `manage_messages` action=edit with the content — that transitions the item to a normal draft — and approve only what the user's standing instructions allow. Inbound replies also arrive as needs_draft (category inbound_reply, with the conversation attached): author the reply with full thread context. If a prospect turns out to be a bad fit at authoring time, skip the item and say why — authoring is the second qualification gate, not an obligation to write.
+**Authoring mode (needs_draft items).** The backend no longer writes outreach prose — touches arrive as `needs_draft` items carrying the decision context (channel, touch number, signals) and no content. These are not rewrites; they are blank pages. For each needs_draft item the subagent AUTHORS the message: check the person's research freshness from the review item itself — `person_researched_at` / `company_researched_at` / `research_status` are on the payload, no extra fetch needed (older than ~14 days or missing → research first with WebSearch + the research reads, and persist what you learn via `research` action=save_person, plus action=save_company when you learned something about the company, so it compounds), then write the touch from scratch in the seller's voice against the same quality standards as any review, then check it — call `check_prose` with `{item_id: <message id>, item_type: "message", content: <draft>}` and treat the `failures[]` as an advisory checklist: fix what you agree with; the one hard stop is a severity `block` channel character cap, which must be cut to fit because it fails at post time — then submit it via `manage_messages` action=edit with the content and the returned `rules_version` as `client_rules_version` — that transitions the item to a normal draft — and approve only what the user's standing instructions allow. (The edit re-runs the same lint server-side; annotations are recorded to the label corpus, never rejected — only a mechanical over-limit draft bounces with `prose_gate_blocked` + `failures[].fix`.) Inbound replies also arrive as needs_draft (category inbound_reply, with the conversation attached): author the reply with full thread context. If a prospect turns out to be a bad fit at authoring time, skip the item and say why — authoring is the second qualification gate, not an obligation to write.
 
 Categorize into three processing groups:
 
@@ -98,7 +98,7 @@ For each message:
 4. Rate personalization depth (surface/basic/deep)
 5. Check strategic fit (CTA matches stage, moves conversation forward)
 
-If a message needs fixes, edit it via manage_messages with action=edit. If personalization is weak, use search with type=kb to find better hooks.
+If a message needs fixes, run the rewrite through check_prose ({item_id: <message id>, item_type: "message", content: <rewrite>}) and weigh the failures[] as an advisory checklist — fix what you agree with; a severity "block" channel character cap is the one hard stop (cut to fit) — then edit it via manage_messages with action=edit, passing the returned rules_version as client_rules_version. If personalization is weak, use search with type=kb to find better hooks.
 
 Return a structured summary per message:
 MESSAGE: {id} | PERSON: {name} | MATCH_SCORE: {n} | CATEGORY: T{n} | RECOMMENDATION: {approve|edited|flag|reject} | CONFIDENCE: {high|medium|low} | REASONING: {1-2 sentences} | EDITED: {yes/no} | ISSUES_FOUND: {list or "none"}
@@ -128,7 +128,7 @@ Review the message against what you learned:
 - Is the personalization based on real, verified information?
 - Are there AI tells, cross-touch duplication, or structural issues?
 
-If the message is good as-is, approve it. If there is clear opportunity to improve (weak personalization when rich signals exist, fabricated references, wrong framing), edit it via manage_messages with action=edit. Do NOT rewrite messages that are already solid just because you can.
+If the message is good as-is, approve it. If there is clear opportunity to improve (weak personalization when rich signals exist, fabricated references, wrong framing), run the rewrite through check_prose ({item_id: <message id>, item_type: "message", content: <rewrite>}) and weigh the failures[] as an advisory checklist — fix what you agree with; a severity "block" channel character cap is the one hard stop (cut to fit) — then edit it via manage_messages with action=edit, passing the returned rules_version as client_rules_version. Do NOT rewrite messages that are already solid just because you can.
 
 Return a structured summary:
 MESSAGE: {id} | PERSON: {name} | MATCH_SCORE: {n} | CATEGORY: T{n} | RECOMMENDATION: {approve|edited|flag|reject} | CONFIDENCE: {high|medium|low} | REASONING: {1-2 sentences} | EDITED: {yes/no} | ISSUES_FOUND: {list or "none"} | RESEARCH_SUMMARY: {2-3 sentences on what you found} | PROBLEM_IDENTIFIED: {yes/no/speculative} | REWRITE_REASON: {why you edited, or "n/a"}
@@ -160,6 +160,8 @@ When a message is rejected because the prospect is a bad fit (not because the me
 
 Bundles the two actions (reject message + stop plan) since a bad-fit rejection almost always means the outreach should stop entirely. Only offer the cascade for fit-based rejections, not quality-based rejections (those just need a rewrite).
 
+Include a one-line `reason` on every reject/skip (e.g. `reason="no D2C signal, biosimilars don't go D2C"`) — reasons feed the prose_labels corpus that trains the prose gate.
+
 ### Step 6: User overrides
 
 The user can always:

package/skills/outreach-triage/references/subagent-instructions.md

@@ -4,7 +4,7 @@ You are reviewing and improving outreach messages before they go to a human oper
 
 You do NOT approve or send messages. You review, edit if needed, and return a structured summary.
 
-**needs_draft items are authoring jobs, not reviews.** The item arrives with decision context (channel, touch number, signals, prior touches) and NO content — the backend does not write prose. Author the message from scratch: verify research freshness first — the review item carries `person_researched_at`, `company_researched_at`, and `research_status`, so no extra fetch is needed (missing or >14 days stale → research with WebSearch and the research reads, persist findings via `research` action=save_person, and action=save_company for company-level findings), then write the touch in the seller's voice to the same standards below, and submit it with `manage_messages` action=edit (content) — that turns it into a normal draft for the orchestrator's approval flow. If the prospect is a bad fit on fresh evidence, recommend skip with the reason instead of writing.
+**needs_draft items are authoring jobs, not reviews.** The item arrives with decision context (channel, touch number, signals, prior touches) and NO content — the backend does not write prose. Author the message from scratch: verify research freshness first — the review item carries `person_researched_at`, `company_researched_at`, and `research_status`, so no extra fetch is needed (missing or >14 days stale → research with WebSearch and the research reads, persist findings via `research` action=save_person, and action=save_company for company-level findings), then write the touch in the seller's voice to the same standards below, check it with `check_prose` (`{item_id: <message id>, item_type: "message", content: <draft>}` — the `failures[]` are an advisory checklist: fix what you agree with; a severity `block` channel character cap is the one hard stop, cut to fit), and submit it with `manage_messages` action=edit (content + the returned `rules_version` as `client_rules_version`) — that turns it into a normal draft for the orchestrator's approval flow. If the prospect is a bad fit on fresh evidence, recommend skip with a one-line `reason` instead of writing (reasons feed the prose_labels corpus).
 
 ## Step 1: Load your messages
 
@@ -93,7 +93,7 @@ Do NOT use these tools for every message. Only when the draft needs improvement
 
 ## Step 4: Edit if needed
 
-If the message needs changes, rewrite it and apply the edit using `manage_messages` with action=edit, the message id, and the new content in the payload.
+If the message needs changes, rewrite it, check the rewrite with `check_prose` (`{item_id: <message id>, item_type: "message", content: <rewrite>}` — the server loads the item's real context for exact parity with the submission gate; the `failures[]` are an advisory checklist to consider, not a pass/fail loop — fix what you agree with, and cut to fit if a severity `block` channel character cap fires), then apply the edit using `manage_messages` with action=edit, the message id, the new content, and the returned `rules_version` as `client_rules_version` in the payload. The edit re-runs the same lint server-side; annotations are recorded to the label corpus, never rejected — only a mechanical over-limit draft bounces (`prose_gate_blocked` with `failures[].fix`).
 
 When rewriting:
 - Keep the same strategic intent (don't change a T2 into a T4)