| name | pre-send-check |
| description | Run a pre-send gate before any deliverable goes out. Trigger on "check this before I send", "ready to send", "final review", "look this over before it goes out", "review before I ship", or any variation of pre-ship review on an email, proposal, deck, contract, post, invoice, or status update. Read-only - never modifies the deliverable. Reports PASS or FAIL on each of seven checks and returns a decision.
|
| why | Forces a structured check before anything goes out so token-replacement misses, broken links, and voice inconsistencies are caught rather than sent to clients. |
| enhance | Always provide the source of truth the deliverable was built from - Check 2 (source-truth match) is the most failure-prone check and only works when the skill can compare the draft against real source material. |
| allowed-tools | ["Read"] |
| mcp_requirements | [] |
Do NOT send, publish, deliver, or share this content with the recipient until you have walked through every check below and reported PASS or FAIL on each. This is an instructional stop, not a runtime-enforced one - but treat it as a hard stop in your own behavior. "It looks fine" is not the same as having checked. The gate fires for every client-facing deliverable: emails, proposals, decks, contracts, posts, invoices, status updates.
Pre-Send Check - Instruction Gate Before Ship
Runs on: reasoning - reads your files and reasons; any capable agent can run this.
Catch what the founder missed. Do not re-write. Read-only on the deliverable itself; write only the check report.
When to Run
Trigger this skill whenever the founder is about to send, publish, deliver, or share anything that a recipient will read. Common triggers:
- "Check this before I send"
- "Ready to ship this"
- "Final review on this"
- "Look this over before it goes out"
- Founder pastes an email, proposal, deck, contract, post, invoice, or status update and the context is pre-ship
If the context is ambiguous (e.g. the founder is drafting and asks for feedback), confirm: "Is this pre-send or mid-draft? Pre-send runs the seven-check gate."
Inputs Needed
Before running checks, confirm you have:
- The deliverable itself (text, file path, or pasted content)
- The recipient (who is reading this)
- The source of truth the content is based on (meeting notes, scope doc, brief, contract, prior email)
- The intended channel (email, Slack, WhatsApp, LinkedIn, PDF delivery)
If any of these are missing, ask once. Do not guess.
The Seven-Check Gate
Walk through each check in order. Report PASS or FAIL on each. Do not skip. Do not combine.
Check 1: Blind-Spot Review
Has a blind-spot review run on this deliverable? A blind-spot review surfaces what the founder assumed but did not state, what the recipient does not yet know, and what could be misread.
PASS if: founder confirms a blind-spot review ran, or you run one inline and surface at least three potential blind spots.
FAIL if: no review has happened and the founder wants to skip it. Flag specifically.
Check 2: Source-Truth Match
Does the content match the source of truth? Every factual claim (dates, prices, scope items, deliverables, names, commitments) must map to the source. Hallucinated or drifted details are the most common failure mode.
PASS if: every claim in the deliverable has a matching entry in the source.
FAIL if: any claim is ungrounded, outdated, or contradicts the source. List the specific items.
Check 3: Voice Consistency
Does the deliverable sound like the founder? Check for generic AI phrasing, banned words, dashes, and fillers. Check for tone mismatch (too formal for a warm contact, too casual for a first cold outreach).
PASS if: voice matches the founder's written style for this recipient type.
FAIL if: generic AI phrasing, banned words, em or en dashes, or tone mismatch. List the specific offenders.
Check 4: Asset Inlining
Are all referenced assets (images, attachments, links, logos, screenshots) actually inlined or attached? Broken links, missing images, and "see attached" with nothing attached are common.
PASS if: every referenced asset is present in the deliverable as the recipient will see it.
FAIL if: a reference exists without the asset, or a link is dead. List specifics.
Check 5: Token Replacement
Are all personalization tokens replaced with real values? Common tokens: {name}, {company}, {date}, {amount}, [INSERT X], TBD, TODO, XXX, placeholder text.
PASS if: no tokens, placeholders, or TODO markers remain.
FAIL if: any token or placeholder is still in the text. List each one.
Check 6: Cross-Reference Update
Should any internal file be updated when this goes out? Common triggers:
- Outreach message sent: update context/clients.md
- Proposal sent: update context/clients.md and context/decisions.md if terms are in play
- Content published: update content tracker
- Invoice sent: update the relevant tracking file
- Commitment made: log to brain/log.md
PASS if: all cross-references are identified and either already updated or queued with a clear plan.
FAIL if: a cross-reference is needed and no plan exists. List which file needs which update.
N/A if: the deliverable genuinely triggers no internal updates (e.g., a one-off thank-you, a reply to a known thread, a personal note). State N/A explicitly with a one-line reason so the reader sees the case was considered, not skipped.
Check 7: Recipient-Readiness
Imagine the recipient opening this cold, with no context from prior conversation. Can they:
- Understand what this is within 10 seconds?
- Know what they are being asked to do?
- See the next step clearly (reply, sign, review, pay, schedule)?
PASS if: the deliverable is self-contained for the recipient's context level.
FAIL if: the recipient would need to ask a clarifying question or hunt for context. Identify what is missing.
Output Format
Return a single block. No preamble. No summary beyond what is shown below.
PRE-SEND CHECK
---
Deliverable: [one-line description]
Recipient: [name or type]
Channel: [email / LinkedIn / WhatsApp / PDF / other]
1. Blind-Spot Review: PASS / FAIL - [one-line reason]
2. Source-Truth Match: PASS / FAIL - [one-line reason]
3. Voice Consistency: PASS / FAIL - [one-line reason]
4. Asset Inlining: PASS / FAIL - [one-line reason]
5. Token Replacement: PASS / FAIL - [one-line reason]
6. Cross-Reference Update: PASS / FAIL / N/A - [one-line reason]
7. Recipient-Readiness: PASS / FAIL - [one-line reason]
---
VERDICT: SHIP / HOLD
[If HOLD: list the specific items to fix in the deliverable before re-running the gate.]
[If SHIP: list any cross-references the founder must update after sending.]
Rules
- You are read-only on the deliverable. You do not rewrite. You do not fix. You report.
- One FAIL = HOLD. The gate is binary. Do not soften with "mostly fine" or "minor issue". A check either passes or it does not. N/A is only valid on Check 6 when no cross-reference truly applies; treat anything else as PASS or FAIL.
- If the founder argues a FAIL, re-state the specific item. Do not negotiate the gate.
- If the deliverable passes all seven, list the cross-references the founder must update after sending so the revenue loop stays honest.
- Never invoke other skills mid-check. The gate runs inline. If the founder needs a rewrite, that is a separate request after the gate.
- If the founder skips the gate and ships anyway, note it in the running log with a STALL flag so the pattern is visible.
