Get It Out There: scheduling reels across platforms with Metricool

Before you start — what this skill needs from you

This skill can't run on defaults alone. Confirm these four things once, write the answers into this file (or your project instructions), and it stops asking:

Also required: your media host must be able to serve a direct, public, unauthenticated file URL, because Metricool fetches media server-side. Google Drive is the worked example throughout; anything meeting that requirement works.

Follow these steps in order. Do not skip ahead to scheduling before completing steps 1–6.

1. Identify what's actually in each video file
2. Confirm the Metricool brand
3. Confirm live automations per platform
4. Write captions (mandatory voice/caption-skill fetch first)
5. Verify Drive media is fetchable
6. Decide dates and times
7. Build a review artifact and get sign-off
8. Schedule, verify, handle edits

Where ready-to-post videos live

Most accounts keep finished, ready-to-post videos in one consistent place — a Drive folder, a local folder, a Dropbox. Ask once, then record it: add the folder link to this skill (or to the project's instructions) so future runs check it automatically instead of asking again.

Until it's recorded, ask where the batch lives rather than guessing. When the user says "the ready folder" or "ready to post," they mean that recorded location.

1. Identify what's actually in each video file

Never assume filenames tell you the content. If several files share a naming pattern (1Rep_Topic.mp4, 2Rep_Topic.mp4, 3Rep_Topic.mp4, etc.), treat them as potential numbered cutdowns of one long-form video until proven otherwise. Confirm with the user or by transcribing.

To transcribe a video:

• Ask the user for a one-line description of each clip, OR transcribe it yourself.
• If the file is too large for the Drive download tool (limits around 10MB are common), use Claude in Chrome: navigate to the file's Drive /view URL, open the Gemini panel built into Drive's viewer, and type: "Please transcribe the full spoken audio of this video word for word."
• If a click into the Gemini prompt box doesn't register, take a screenshot before retrying — its position shifts between the empty state and the after-first-message state.

Write every caption from the actual transcript of that specific clip. Do not write one generic caption and reuse it across multiple clips that share a topic name — verify each clip's content individually first.

2. Confirm the Metricool brand

Call the brand-settings tool before anything else. Extract:

• The brand id — use this as blogId in every scheduling call.
• The brand timezone — use this exact IANA string in every publicationDate.
• The connected networks (networksData). Only schedule to networks confirmed connected here. Do not assume a network is connected because the user mentions it.

If more than one brand exists on the account, ask the user which one before proceeding.

Default platform set

Confirm once which platforms this account posts to, and record it. A reasonable starting point is every network confirmed connected in networksData — but whether an account wants all of them is a strategy decision, not a default worth assuming. Once it's recorded, schedule to that set without re-asking each run.

Whatever the set is, schedule every platform in the same pass. Leaving one platform for "later" is how a batch ends up half-published.

3. Trigger-word CTAs — which platforms, and how they read

Trigger-word CTAs need a comment/DM automation tool (ManyChat or similar) with a live automation behind the word. Which platforms have one is account-specific — confirm it once and record it. What's fixed is what each platform supports:

If nothing is recorded yet, ask which platforms have live automations and what the trigger word is before writing any trigger CTA. Never write a trigger word with no live automation behind it — the CTA promises something that won't happen.

Where the trigger sits in the caption is a wording decision: leave it to the voice skill. If the voice skill has no view, ask rather than defaulting to the first line.

4. Write captions

Mandatory: before writing a single caption, invoke the account's voice/caption skill (a skill covering tone, hook library, audience language, hashtag rules — see voice-skill-template in this repo if the account doesn't have one yet) and follow its mandatory fetch requirements exactly — this typically means pulling a "Voice DNA" reference, a hook library, and running hashtag research before drafting anything. Do not write captions from a transcript alone, skipping the voice/caption skill's required steps, even if you already know the platform format rules below. The format rules below govern structure; the voice skill governs the actual words.

The table below is platform constraints only — hard limits and field rules that will break a post or get it rejected if ignored. It deliberately says nothing about paragraph counts, line breaks, hashtag counts or tone: those are editorial, they vary enormously by account, and they belong to the voice skill. If the voice skill is silent on something, ask rather than inventing a house style.

The one rule that isn't editorial: a CTA must promise only what that platform can actually deliver. Never write "comment WORD" on a platform with no comment automation, and never invent reward copy for a platform with no destination to send people to.

Before finalizing a CTA that links to an external video, confirm the link points to the correct piece of content — use the platform's oEmbed endpoint or equivalent to check the title before linking (for YouTube: https://www.youtube.com/oembed?url=<url>&format=json).

5. Verify hosted media is fetchable

Metricool fetches media server-side via a public URL — it does not use the user's browser session. This applies to any host; the Drive specifics below are the worked example. Before scheduling anything:

1. Check every source file's sharing permissions. If a file is not shared "Anyone with the link," do not change the permission yourself — tell the user and ask them to set it. Changing sharing permissions requires the user's own action.
2. For Google Drive, use this exact media URL format: https://drive.google.com/uc?id=<FILE_ID>&export=download. For other hosts, use whatever form returns the raw file rather than a viewer page. Do not use /view?usp=sharing, /view?usp=drivesdk, or a bare /view URL — these fail to resolve to the raw file.
3. Before scheduling the full batch, create one test post as draft: true on a platform that strictly validates media type (YouTube or Instagram Reel). Check that the returned media field ends in the real file extension (.mp4), not .html. Only proceed to the full batch once this is confirmed.
4. Never assume a post has real media attached just because the API call returned success — some platforms (X, LinkedIn, TikTok) do not validate media type and will accept broken media silently. Always run the check in step 3.

6. Decide dates and times

Timing strategy — confirm the account's preference once. One workable approach, and the default here unless told otherwise: pick a single reference platform (Instagram is the usual choice, being the most timing-sensitive), query the best-time-to-post tool for that platform on that specific weekday, and apply that one time across every platform scheduled that day. It keeps a batch coherent and avoids querying seven platforms for marginal gain. An account that wants per-platform optimal times instead is equally valid — ask.

Whichever approach is used, the mechanical rule holds: recompute the time fresh for each weekday. Never carry one day's hour across to a different weekday.

When shifting an existing schedule by any number of days, recompute the reference platform's peak time for each post's new weekday and apply it per the chosen strategy. Never carry over the old day's time to the new day.

Before treating a scheduled post as missing or deleted, check whether its scheduled time has already passed — the scheduled-posts list only returns posts that have not yet published, so a post disappearing from it usually means it published successfully.

7. Build a review artifact before scheduling

Before calling any scheduling tool, produce a file the user can review and edit, saved to their actual working folder — not a spreadsheet, not a chat-only summary. Build it as an interactive HTML file with:

• One card per post, with a clickable title linking to the source video
• An editable text field per platform's caption
• Date and time picker inputs
• A "copy all as plain text" action
• A "save my edits" action that re-serializes the current form state into a new downloadable file, since there is no backend to persist edits otherwise

Tell the user to open the file in a real browser tab, not an in-app or sandboxed preview — sandboxed previews block external link navigation, which will make links silently fail.

Do not schedule anything until the user has explicitly signed off on the captions and dates. If the user says to hold off, treat that as a full stop on scheduling writes, even mid-batch, until they say to proceed.

8. Schedule, verify, handle edits

Include only the platform-data block matching each post's provider:

• facebookData: {"type": "REEL"}
• instagramData: {"type": "REEL", "showReelOnFeed": true}
• linkedinData: {"type": "post"}
• tiktokData: {"title": "<short title>"}
• youtubeData: {"title": "<title>", "type": "short", "privacy": "public", "madeForKids": false}
• threadsData: {"allowedCountryCodes": []}
• twitterData: {"tags": []}

Set publicationDate as {"dateTime": "...", "timezone": "<brand timezone>"} and the top-level date param as the equivalent ISO 8601 string with UTC offset.

Always re-fetch the current scheduled-posts list immediately before running a new round of updates, and read the current id/uuid pair from that fresh response. Do not reuse an id from an earlier call — ids change after every update even though uuid stays constant.

Work through the schedule one day/clip at a time, all platforms for that slot together. Track progress with a task list for batches larger than a few posts.

After scheduling, pull the full scheduled-posts range and verify programmatically — do not rely on individual success responses:

• Total post count matches expectations
• Count per network matches expectations
• draft is false everywhere it should be
• Every media URL ends in the real file extension, not .html
• Every post for a given day shares the same time (the Instagram peak hour for that weekday)

If the verification output is too large to read directly, process the saved file with a script instead of reading it inline.

If a later edit requires appending text to an existing caption (for example, adding a CTA to captions that didn't have one), recount the full caption length after the addition for every affected post and trim body copy on any that now exceed the platform limit before submitting.

Tool gaps to check for and flag

• If the available storage tools only include copy/create/download/read/permissions (no rename, no delete), and the user asks to rename source files: create a renamed copy via the copy tool, and tell the user upfront that the original will remain since there is no delete capability. Do not present this as a clean rename.
• Do not change sharing permissions on the user's storage yourself. If a permission issue blocks the workflow, tell the user and wait for them to fix it.

Pre-flight checklist

Confirm every item below before calling the real (non-draft) scheduling call:

• Brand id and timezone confirmed from brand settings
• Batch scheduled to the account's confirmed platform set, all in one pass
• Trigger word applied only to platforms with a confirmed live automation; TikTok's is DM-only
• Every CTA promises only what that platform can deliver
• Voice/caption skill (if one exists for this account) invoked and its mandatory fetches completed before writing captions
• Every caption matches what its specific clip actually says
• Every caption is under its platform's character limit, including any CTA/link
• YouTube title and description/first-comment fields contain different content, not duplicates
• Source files are publicly readable, and media URLs return the raw file (for Drive: the uc?id=...&export=download form)
• One test post confirmed real video (not .html) before the full batch
• User has reviewed and approved the calendar/captions
• Times follow the account's confirmed timing strategy, recomputed per weekday