---
name: preflight
description: >
  Run Inklate's real per-channel validation on a draft or post — the same checks that gate
  actual publishing, not a generic lint. Fetches each channel's live rules, runs the
  preflight, explains every violation in plain language, applies the auto-fixes with a
  before/after, and re-runs until green. Covers LinkedIn, X (Twitter), Instagram, and
  Facebook. Use when the user says "preflight this", "will this pass",
  "validate against my channels", or "fix this post for Instagram".
  Requires the Inklate MCP connection.
  Reads social-context.md when present so fixes stay on-voice. Ends with a per-channel
  verdict table — green, fixed-then-green, or blocked with the reason.
metadata:
  version: 1.0.0
  topics: [checking]
  examplePrompt: "Preflight this draft against all my connected channels"
  pairsWith: [post-check]
  mcpTools: [preflight_post, apply_fix, get_capabilities]
---

Validate a draft against the real rules of the user's real channels, fix what can be fixed, and deliver an honest per-channel verdict.

## Connection check

1. Call `list_organizations` first.
2. If it fails or the Inklate tools are absent, tell the user to connect at `https://inklate.com/skills/connect?ref=skills-preflight` and STOP — a preflight against remembered platform rules is worthless.
3. If multiple organizations exist, ask which one; channel rules are read from that organization's connected accounts.

## Context

Read `social-context.md` (project root, then `.agents/social-context.md`) if present. `## Voice` and `## Never` constrain how you rewrite content when fixing violations — a fix that passes the platform but breaks the voice is not a fix. Proceed without it if absent.

## Workflow

1. Establish scope: which channels to validate against. "All my channels" means every connected channel; a named platform (e.g. "for Instagram") means just that one. If the draft is not yet an Inklate post, create it first so preflight has a real post to check.
2. For each in-scope channel, call `get_capabilities` and note the rules the draft is most likely to trip:
   - Character limits (per post, and per segment when the channel threads).
   - Media requirements — counts, formats, and whether media is mandatory (Instagram).
   - Link and hashtag handling, and anything the channel currently flags as restricted.
3. Call `preflight_post` on the post for the in-scope channels.
4. **Explain every violation in plain language.** Not "VARIANT_TEXT_OVERFLOW" but "the X variant is 312 characters; X allows 280 — 32 characters need to go." One line per violation, grouped by channel.
5. For each auto-fixable violation, call `apply_fix`. Show the before and after for every fix — the exact text that changed, not a description of the change. If a fix would alter meaning or tone (per social-context.md), treat it as a judgment call instead.
6. Re-run `preflight_post`. Repeat the fix-and-re-run loop until each channel is either green or only judgment calls remain.
7. **Judgment calls become options.** For each remaining violation, present 2–3 concrete resolutions ("(a) cut the third paragraph, (b) split into a 2-post thread, (c) drop X from the targets") and apply the user's choice, then re-run once more.
8. If the loop is not converging — the same violation reappears after two fix attempts — stop looping, show the stuck violation, and hand the decision to the user rather than thrashing.
9. Deliver the verdict. If the user's next step is publishing, point them to the `publish` skill — this skill validates; it never publishes.

## Quality bar

- Rules come from `get_capabilities` and violations from `preflight_post` — never from memorized platform limits, which drift.
- Every `apply_fix` is shown as before/after in chat; a silent fix is a bug.
- Never declare green without a fresh `preflight_post` run confirming it after the last change.
- Fixes preserve meaning and voice; when they cannot, the violation is escalated as a judgment call, not forced.
- A channel that cannot pass (e.g. Instagram with no media attached) gets an honest "blocked" verdict with the unblock condition — not a soft warning.
- This skill makes no irreversible calls: no publishing, no scheduling. Its output is a verdict.
- Verdicts are per-channel, never averaged: "mostly passing" is not a verdict.
- If the user asked about a channel that is not connected, say so in the verdict table rather than validating against imagined rules.

## Receipt

End with the final verdict table:

| Channel   | Verdict | Violations found | Fixed                         | Remaining                |
| --------- | ------- | ---------------- | ----------------------------- | ------------------------ |
| LinkedIn  | green   | 1                | 1 (trimmed to 3000 chars)     | —                        |
| X         | green   | 2                | 2 (shortened, hashtags moved) | —                        |
| Instagram | blocked | 1                | 0                             | needs at least one image |

Below the table: the post ID that was validated, the full list of applied fixes with their before/after, any judgment calls resolved and how, and the single next action (ready to publish via the `publish` skill, or the unblock condition for any blocked channel).

The verdict table reflects the last `preflight_post` run of the session — never an earlier, more optimistic one.