/platform-content-optimizer

Platform Content Optimizer

Companion skill: social-media-app-researcher produces the sourced algorithm research this skill draws on (its algorithm-and-mindset.md per platform). This skill doesn't duplicate that research methodology — it consumes it, or gathers a lighter equivalent on the fly when no existing research is available. Example output built from both skills together: github.com/elchrysaki/social-app-teardown.

Most "optimize this for the algorithm" advice is folklore — post at 9am, use 3-5 hashtags, ask a question at the end — repeated across marketing blogs with no source, applied identically to every platform as if they all rank content the same way. They don't. This skill's job is to replace that folklore with whatever a platform has actually said, in public, about itself — and to be explicit when no such statement exists and the advice really is folklore, rather than laundering a guess into something that sounds sourced.

Step 1 — Find or build the algorithm research for the target platform

Before touching the draft, get real signals for the specific platform:

1. Check for existing research first. Look for a social-app-teardown-style folder (an algorithm-and-mindset.md per platform — the output of the social-media-app-researcher skill) in the current project, a linked repo, or ask the user if they have one. If it exists, read the target platform's algorithm-and-mindset.md directly — it's already sourced and tiered by confidence.
2. If no existing research covers this platform, gather it fresh rather than relying on memory: search for the platform's own engineering blog posts, official transparency/ranking documentation, and open-sourced ranking code if any exists. Cite what you find. If genuinely nothing official is findable for a specific mechanic, say so rather than filling the gap with a plausible-sounding guess — see the source-hierarchy discipline in social-media-app-researcher's references/research-playbook.md if that skill is installed; the same standard applies here.
3. Separate primary-sourced mechanics from folklore, explicitly, every time. A platform's own engineering post saying "dwell time starts once 50% of the post is visible" is a fact to build on. "Comments are weighted 15x more than likes" repeated across growth-marketing blogs with no primary citation is folklore — usable as a weak prior, never presented with the same confidence as a sourced fact.

Step 2 — Extract what's actually actionable for a single piece of content

Not every ranking signal is something a piece of content can control. Pull out specifically the ones that are:

• Structural cutoffs — feed truncation length ("...see more" after N characters), where a hook needs to land to earn the click/expand.
• Attention-shape signals — dwell time definitions (on-feed vs. after-click), skip-probability discounting, video watch-time thresholds — these reward pacing content to hold attention past a specific point, not just grabbing attention at the top.
• Engagement-type weighting — if the platform's own documentation distinguishes signal types (e.g. an active/passive split, comments modeled differently from likes), that shapes whether the content should be built to prompt a reply vs. just a reaction.
• Format/native-content signals — if there's a sourced reason to prefer native media over outbound links, native video over external embeds, or a specific post type the platform's algorithm treats differently, note it — but don't assert an unsourced "links get suppressed" claim as platform-confirmed fact if it isn't (many platforms have never officially confirmed this even though the growth-marketing world treats it as gospel).
• What the algorithm explicitly does NOT use — if a platform has stated a signal it deliberately excludes (e.g. demographic data), that's worth knowing too — it rules out certain targeting-flavored tactics as theater.

Step 3 — Rewrite the draft against those specific mechanics

For each structural change made to the draft, it should trace to a specific signal from Step 2 — not a vibe. Concretely:

• If there's a known truncation length, the hook is paced to create a real reason to expand within that window — not stuffed with keywords, an actual curiosity gap or a claim worth finishing.
• If dwell time / skip-probability is a real signal, the body is paced to reward continued reading (front-loaded value that still needs the middle to pay off) rather than everything dumped in the first two lines with nothing to hold attention after.
• If comments/replies are modeled as a distinct, higher-value signal, the close asks something genuinely worth answering — a specific question tied to the content, not a generic "thoughts?"
• If there's a sourced native-content preference, keep primary links out of the main body (e.g. first-comment convention) — but say plainly that this is a common practice, not oversell it as a proven mechanic unless the platform has actually confirmed it.

Step 4 — Deliver the rewrite and the reasoning

Hand back two things, not just the final text:

1. The rewritten content, ready to paste.
2. A short annotation mapping each meaningful change to the specific signal driving it, tagged by confidence (platform's own documentation vs. reasonable inference vs. common but unsourced practice) — so the user understands why, and can judge for themselves whether a given change is worth keeping.

Quality bar

• Never present unsourced growth-marketing folklore with the same confidence as a platform's own documented ranking mechanic — always distinguish the two, out loud.
• Never invent a specific number (a dwell-time threshold, a truncation length, a weighting multiplier) that wasn't actually found in a source — approximate ranges are fine, made-up precision isn't.
• The goal is content that's genuinely better because it rewards the behavior the algorithm is actually measuring — not content stuffed with algorithm buzzwords that reads worse to a human. If a "signal-driven" change would make the content worse for an actual reader, say so and don't make it.