platform_specs_validation v1.0.0

name: platform_specs_validation description: Validate a social post against current platform specs before it ships, for X, Instagram, TikTok, LinkedIn, YouTube, Facebook, Threads, and Bluesky. Ships a tested Python validator plus dated spec tables covering text and caption limits, weighted counting on X, grapheme counting on Bluesky, hashtag and mention caps, image and video size, format and aspect ratio rules, link rules, and alt text rules, and returns a pre-publish report that names every failure in plain language. Use when a post, caption, Reel, Short, or cross-platform batch is about to be scheduled or published, when a scheduler rejected a post, or when specs need checking before a campaign ships.

Platform Specs Validation

Purpose

Catch a post that a platform will reject, crop, or quietly cripple, before it ships. Most publishing failures are boring arithmetic: 43 hashtags where 30 fit, a PNG where the API wants a JPEG, a caption that fits in the app and fails through a scheduler. This skill runs that arithmetic with a tested script, using dated spec tables, and reports every failure in plain language with the fix attached.

Workflow

1. Build a manifest for the post. One JSON file per platform version of the post, never one manifest for all platforms. Fields: platform, text, title and description where the platform uses them, tags for YouTube, premium set true only for X Premium accounts, and a media list where each item carries kind, width, height, size_bytes, format, duration_sec, alt_text, and decorative. Templates and real examples sit in examples/pass.json and examples/fail.json.

1. Run the validator.

python3 scripts/validate.py examples/pass.json

Quick checks without a file work too:

python3 scripts/validate.py --platform x --text "your post text"

1. Read the report line by line. FAIL means fix before shipping. WARN means the post publishes but will underperform, break on a stricter route, or read badly. The final RESULT line is the verdict, and the exit code matches it: 0 for pass, 1 for fail, 2 for bad input.

1. Fix failures at the source, not in the scheduler. Recrop the image, compress the file, cut the hashtags, move the Instagram link to the bio or first comment, write the missing alt text. Then rerun the validator on the fixed manifest. A report from an earlier draft proves nothing about the current one.

1. Check the spec date before trusting a clean pass on a big launch. The tables in references/spec-tables.md are dated 2026-10-19 and the validator prints that date in every report. If the date is stale, or a platform announced a change, recheck the platform help pages, update references/specs.json and references/spec-tables.md together, and rerun both bundled examples before shipping anything.

1. Keep the report with the ship note. Paste the RESULT line and every WARN you accepted into the scheduling note, so the next person knows what was checked and what was waived on purpose.

Output Contract

For each post and platform pair, this skill produces:

• A validator report with one PASS, WARN, or FAIL line per check, each failure naming the current value, the limit, and the fix in plain language
• A final RESULT line with the platform, the failure and warning counts, and the spec date the verdict rests on
• An exit code a scheduler or script can gate on: 0 pass, 1 fail, 2 bad input
• Worked pass and fail reports in references/worked-reports.md, generated from the bundled examples, so a reader can see the exact output shape before running anything

Operating Rules

• Hard limits fail, soft limits warn. Where the app and the API disagree, the validator encodes both: TikTok captions fail above 4,000 characters and warn above 2,200, because the Content Posting API is stricter than the app. Instagram carousels fail above 20 items and warn above 10, because some publishing API routes cap at 10.
• Counting is platform specific, never raw character count everywhere. X counts links as 23 weighted characters and CJK characters and most emoji as 2. Bluesky counts graphemes, so an emoji counts as 1, with a separate 3,000 byte ceiling.
• Missing alt text on a meaningful image is a failure on every platform in this skill, not only where the platform forces it. WCAG 1.1.1 requires a text alternative. Decorative images are the one exception, and they should carry empty alt text.
• Alt text aims for 125 characters or fewer, starts with the subject, and never starts with image of or photo of. Platform ceilings are higher (1,000 on X and Threads, 2,000 on Bluesky) and the validator fails past those, but the 125 warning fires first for a reason.
• A link in an Instagram caption is a warning, not a failure. It publishes, it just is not clickable. Move it and say where it went.
• Never invent a spec. Every number in references/specs.json traces to a source checked on the spec date: X Help Center and developer documentation for X, Meta developer documentation for Instagram, Facebook, and Threads, TikTok developer documentation for the API cap, LinkedIn Help for the 3,000 character post limit, YouTube Help for title and description limits, AT Protocol documentation for Bluesky, and WCAG 1.1.1 for alt text. A number with no source does not go in the table.
• Specs change without notice. Treat any spec sheet older than a quarter as suspect, recheck primary sources before a major launch, and update the date in specs.json when you do.
• One post, one verdict per platform. A pass on Instagram says nothing about TikTok. Validate every destination separately, because the same caption can pass on LinkedIn at 3,000 characters and fail hard on Bluesky at 300 graphemes.

Available connectors

• Use muse.connector_search to find other connectors and muse.skill_search to find related skills.

• If nothing here fits, look on the web for a maintained API or MCP server and set it up with the custom connector setup skill, or build a custom connector.