---
name: interview-followup-polisher
description: Polish interview and recruiting follow-ups through a mandatory 10/10 recipient-side release gate that checks evidence, strategy, human cadence, stage-appropriate brevity, prior feedback, and send timing. Use for interview thank-yous, recruiter or hiring-manager check-ins, post-interview status requests, role-pivot follow-ups, reference offers, and stalled hiring conversations.
---

# Interview Followup Polisher

Turn a rough follow-up into the shortest strong version that still sounds like the sender. The skill must do the review work before presenting or saving a finished draft. The user should not need to ask for extra passes to catch obvious recipient-side problems.

The governing rule is:

> **RIGHT MESSAGE -> RIGHT WEIGHT -> HUMAN VOICE -> RECIPIENT CHECK -> SEND**

A message is not releasable merely because it is polished. It is releasable only when no material improvement remains for the actual recipient and stage.

## Default workflow

1. **Recover context before drafting.** Use the conversation, email thread, calendar event, interview notes or transcript, job description, recruiter promises, prior follow-ups, and relevant user history when available. Do not ask the user to repeat facts that can be retrieved safely.
2. **Carry forward prior findings.** Review available feedback for the same recipient, thread, role, or artifact family. Previously identified failure modes become active constraints.
3. **Identify the real objective.** Examples: thank the interviewer, obtain a status update, preserve two possible role paths, clarify a concern, reinforce fit, or re-open a stalled process.
4. **Rank the evidence.** Use only proof that materially helps the immediate objective. More evidence is not automatically stronger.
5. **Draft the minimum effective message.** Make the recipient's next action obvious. Preserve the existing thread when appropriate.
6. **Run the mandatory release gate internally.** Apply all three passes below before presenting, saving, or sending the draft.
7. **Revise every material issue and restart at Pass 1.** Never defend wording simply because it was already polished or previously scored highly.
8. **Recommend send timing when timing matters.** Give one best estimated send time plus a backup window when useful.
9. **Save as a draft unless the user explicitly asks to send.** If editing a connected mailbox, re-open the saved draft and verify the actual stored content.

## Mandatory 10/10 release gate

Every finished interview answer, recruiter message, hiring-manager follow-up, thank-you note, status request, role-pivot note, compensation message, or other sendable artifact must pass all three reviews below before release.

### Pass 1: Intent and evidence

Verify that the message:

- accomplishes exactly what the user is trying to accomplish;
- preserves the facts, relationship, interview stage, role context, and known constraints;
- does not overstate evidence, access, authority, familiarity, certainty, or internal knowledge;
- uses only the proof needed for the immediate objective;
- does not introduce an unnecessary ask, claim, link, credential, reference, or implication that creates avoidable risk.

Any mismatch is a failed pass.

### Pass 2: Devil's Advocate and communication realism

Read the message as the most skeptical reasonable recruiter, hiring manager, executive, or busy recipient. Remove anything that could reasonably sound presumptuous, needy, transactional, inflated, defensive, manipulative, awkward, unclear, strategically premature, or over-engineered.

A sendable artifact **automatically fails** this pass if any of the following is true:

- it is heavier, longer, or more formal than the relationship stage requires;
- a simple reply, check-in, or recruiter follow-up has turned into a mini cover letter;
- it sounds machine-polished, overly symmetrical, templated, engineered, or AI-written instead of like a credible human sender;
- multiple sentences repeat the same interest, urgency, availability, proof, or ask in different words;
- it uses stacked abstractions or corporate phrasing where ordinary language would be clearer;
- it adds unsolicited references, links, access requests, qualifications, or proof that do not materially improve the immediate objective;
- it makes one live opportunity sound like a consolation prize or implies the recipient previously chose the wrong path;
- it creates an unnecessary hierarchy between parallel opportunities, including wording such as **“my first choice is…”** when both paths should remain genuinely open;
- it asks for gated training, proprietary resources, favors, provisioning, or special access more aggressively than the relationship stage supports;
- it reintroduces wording or a pattern that an earlier review already identified as risky, awkward, too strong, too needy, too AI-like, too long, or strategically premature.

#### Minimum effective message test

Remove every sentence that does not materially improve at least one of these:

1. the recipient's understanding;
2. the recipient's confidence in fit or credibility;
3. the recipient's ability to take the next action.

If a sentence survives only because it sounds polished, delete or simplify it. Natural brevity is a quality requirement, not merely a style preference.

#### Human-cadence check

Ask:

- Would a normal person in this exact relationship and stage plausibly send this as written?
- Does it sound like the sender rather than a communications template?
- Are sentence lengths and transitions natural rather than mechanically balanced?
- Is plain language doing work that corporate phrasing was previously doing?

If not, revise.

#### Regression-memory check

Before scoring Pass 2, review all available prior findings for the same recipient, thread, role, or artifact family. A previously rejected phrase or failure pattern may not silently return.

If a later review finds a weakness that prior self-feedback should already have prevented, the earlier release gate is considered to have failed. Correct it and restart at Pass 1.

### Pass 3: Final recipient simulation

Read the revised message from the actual recipient's perspective and ask both:

> If the user immediately asked me to score this out of 10 and identify anything I would change, would I change anything?

> Would a normal person in this exact relationship and stage plausibly send this message as written?

If either answer exposes a material change, the message fails. Revise and restart at Pass 1.

Only release when all three passes are **10/10 with no known material improvement remaining**. A score of 8.5, 9, or 9.5 is a failed gate, not an acceptable near-pass. This is a quality threshold for the message, not a guarantee of a hiring outcome.

## Two-path role rule

When a conversation introduces a second role or alternate path:

- keep genuine interest in the original role visible when it remains true;
- show interest in the alternate role without declaring an avoidable winner;
- anchor the alternate path in evidence, especially when the recipient raised it first;
- avoid “first choice,” “fallback,” “rather than,” or similar hierarchy language unless the user truly intends to close one path;
- do not imply the recipient was wrong to start with the original role;
- do not assume another stakeholder has approved, rejected, or evaluated the sender;
- make it easy for the recipient to advance either legitimate path.

## Evidence hierarchy

Prefer, in order:

1. A fact the recipient explicitly asked about or a gap they raised.
2. Concrete leadership or ownership scope.
3. Relevant measurable outcomes with careful attribution.
4. Direct product, technical, industry, or customer-facing overlap.
5. One compact work sample or portfolio link that proves how the sender thinks.
6. References, usually offered only when the stage makes them useful.

Do not include weak evidence merely because it exists.

## Portfolio and reference rule

A portfolio link should be one compact proof point. Explain what it demonstrates in one sentence. Do not turn the message into a product pitch or make the recipient inspect the link to understand the email.

References are not default filler. Offer them only when they reduce a real perceived risk or the process is at a stage where they are useful. Do not dump names, contact details, or attachments unless requested.

## Sensitive-information rule

Do not infer that silence or delay is caused by disability, neurodivergence, health information, age, race, religion, gender, sexual orientation, or another protected or sensitive characteristic. Do not reintroduce sensitive information unless the user explicitly wants it included and it serves a clear purpose.

## Send-time engine

Estimate the best send time from the strongest available context rather than a generic rule. Consider:

- current local date and time;
- recipient timezone and likely workday;
- interview or meeting end time;
- elapsed business days;
- explicit promises such as “later today,” “tomorrow,” or “next week”;
- whether the recipient currently owes the sender an update;
- weekends and holidays;
- urgency and competing deadlines;
- startup or executive context;
- same-day thank-you versus status follow-up;
- recent legitimate communication activity;
- lunch, very early, late-day, and after-hours delivery.

### Timing defaults when context is incomplete

- **Same-day interview thank-you:** usually 1 to 4 hours after the conversation while still inside the recipient's business day.
- **Promised update missed:** the next reasonable business window after the promise has clearly elapsed.
- **No promised timeline:** normally 2 to 4 business days after an interview or meaningful recruiting conversation.
- **Late-day draft without urgency:** usually the next business morning.
- **Lunch window:** avoid roughly noon to 1 PM recipient-local time when there is no stronger reason to use it.

Give one concrete recommendation when enough timing information exists. If live time or timezone is unavailable, state the assumption instead of pretending precision.

## Output behavior

If the user asks only for a draft, keep the gate process internal and return only the strongest releasable version plus timing when timing is relevant.

If the user asks whether a draft is 10/10, perform a genuinely fresh review against the full gate. Do not automatically agree with an earlier score.

If the user asks to save a draft in a connected mailbox, run the gate **before** saving, then re-open the saved draft to verify that the stored content is still the approved version.

When showing gate status, use:

- `Release gate: PASS` only when all three passes meet the standard;
- otherwise identify the material failure and revise before presenting a finished artifact.

## Integration with High-Definition Follow-Up

This skill is the content, positioning, naturalness, regression-memory, and timing gate. The separate **High-Definition Follow-Up** skill may be used afterward when a branded HTML presentation is useful. Styling must never override a failed content gate.