Trial Reels: batch-scheduling Instagram Trial Reels through Metricool

This skill runs a repeatable pipeline: finished videos in → captioned, approved, Trial-Reel-flagged, scheduled Instagram posts out. It is Instagram-only. Trial Reels do not exist on other platforms, so never cross-post trial reels elsewhere under this skill.

Two roles: the owner is whoever the account belongs to, and whose voice the captions must sound like. The operator is whoever runs this pipeline — they give the approvals, and their confirmed preferences are the defaults. These may be the same person. Everywhere this skill says "ask the operator," it means whoever is accountable for what goes live.

"Working folder" means a local folder this assistant can read and write — not the cloud storage the source videos came from. They are different places, and the asymmetry matters: an assistant can usually write freely to a connected local folder but cannot push large video files back into cloud storage (§1). If your setup has no connected local folder, files have to be handed over through the chat instead, and the naming steps below become the operator's job.

Before you start — what this skill needs from you

Confirm these once, record the answers here (or in your project instructions), and the skill stops asking:

Environment assumptions. This skill was written for an assistant that has: Metricool API access, browser control (the Trial Reel flag is browser-only — there is no API path), read/write access to a local working folder, and optionally ffmpeg. Without browser control you can get as far as verified drafts, but you cannot flag or schedule them.

The two rules that override everything

1. Nothing goes live without the operator's explicit, specific approval. Not a draft flipped to scheduled, not a browser click that could publish, nothing. There are two hard approval gates below (Gate A before any write, Gate B before the browser pass that can publish). Gate B's go-ahead covers the clean path only — a mid-pass surprise (failed flag, reverted caption, publish-cap error, transcoding error, past-due draft) is not covered by it and needs a fresh, specific check-in. If you are ever unsure whether an action could make something go live, stop and ask.
2. When you are not sure, ask — don't guess. Ambiguous clip→caption matches, an unclear trigger word, which brand, whether a post is already published: ask a direct question rather than picking the likely answer. Guessing on a live account is how duplicates and wrong posts happen.

The Trial Reel API rule that shapes the whole order of work

Metricool's API can read a post's Trial Reel type but cannot write it. Passing type: TRIAL_REEL hard-errors, and — this is the part that bites — any API update to a post that is already a Trial Reel silently downgrades it back to a normal POST and drops shareTrialAutomatically. That includes innocent-looking edits like fixing a caption.

The practical consequence, which drives the step order below: everything about a post's text and settings must be final before you flag it as a Trial Reel in the browser. Once the browser flag is on, the API is read-only for that post — treat it as look-but-don't-touch. If something genuinely has to change afterward, it changes in the browser, and you re-verify the type via API after.

Follow the steps in order. Do not jump ahead to scheduling.

1. Locate and identify the videos
2. Confirm the Metricool brand + Instagram eligibility
3. Confirm the trigger word (check for collisions)
4. (Optional) Add music — kept generic
5. Write captions (voice skill first) — these must be final before step 11
6. Verify media is fetchable by Metricool
7. Decide dates and times
8. Build a review file → Gate A: get sign-off
9. Create everything as DRAFTS via the API + verify
10. Gate B: get the go-ahead for the full flag → schedule browser pass — before opening the browser
11. Browser: one pass per post — flag Trial Reel, toggle share, auto-publish, Schedule + verify via API after every action
12. Post-flight verification

1. Locate and identify the videos

Ask where this batch lives if it isn't obvious (a Drive folder link, a local folder, etc.). Do not assume a folder's contents from its name or from how the request was phrased — list the folder first, and read any planning/notes doc inside it before doing bulk work.

Never trust filenames to tell you what a clip says. If several files share a naming pattern (1Rep_Topic.mp4, 2Rep_Topic.mp4, or three takes like A05_...-1/-2/-3), treat them as separate takes/cutdowns until proven otherwise. When several physical files map to one described reel, surface the ambiguity to the operator and ask which take is the one to post — do not silently pick one.

To know what each clip actually says, either ask the operator for a one-line description per clip, or transcribe it (for large files, open the file's Drive /view URL in the browser and use the built-in Gemini panel: "Transcribe the full spoken audio word for word"). Write each caption from that specific clip's content — never write one caption and reuse it across clips that only share a topic name.

Environment limits to state up front

• The Drive download tool caps at ~10 MB — but you can compress oversized clips yourself. The cap is on the download tool specifically, not on ffmpeg. So a large scenic or high-motion take (landscape, drone, walking shots) can't be pulled through the download tool, but if the file reaches the environment by a route with no cap — it's in the operator's connected project folder, or they drag it into the chat — you can read it and re-encode it smaller with ffmpeg:

  ffmpeg -i big.mp4 -vf "scale='min(1080,iw)':-2" -c:v libx264 -crf 28 \
    -preset veryfast -c:a aac -b:a 128k -movflags +faststart smaller.mp4

  (1080-wide vertical, CRF 28 is a good reel default; drop to CRF 30–32 if it's still too big.) Check file sizes before you commit to a selection. If a wanted clip is only available via the Drive download tool and is over the cap, ask the operator to drop it in the connected folder or upload it so you can compress it — only fall back to picking a smaller take if it genuinely can't be gotten into the environment at all. Don't tell the operator to compress it themselves; that's your job once you can reach the file.
• This environment can download from Drive and process locally (ffmpeg etc.), but cannot upload finished video files back to Drive — the base64 inline required is far too large. If finished files need to end up in Drive, tell the operator they have to drag them in themselves. Plan this as a real step.
• Files already written into the operator's connected project folder cannot be renamed or deleted by you, and Drive tools here have no rename/delete. To "rename," make a copy with the new name and say plainly the original remains — never imply a true rename happened. (This is exactly why step 4 names files correctly at creation time — see below.)
• Separate limit, don't confuse it with the size cap above: downloads above ~500KB may hit a token-output limit ("exceeds maximum tokens") and get written to a local JSON file instead of returned inline; decode locally (base64.b64decode(json['content'])). That's about how the bytes come back, not whether the file is too big to fetch.

2. Confirm the Metricool brand + Instagram eligibility

Call getBrandSettings before anything else. Extract and keep:

• Brand id → use as blogId in every scheduling call.
• Brand timezone (IANA string) → use exactly in every publicationDate.
• networksData → confirm Instagram is actually connected. If it isn't, stop and tell the operator.

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

Trial Reel eligibility (Instagram's rules, not Metricool's): Trial Reels require the account to have 1,000+ followers and the feature to be enabled for that specific Instagram account. Metricool's UI shows the Trial Reel option regardless of eligibility and fails only at publish time. If you can't confirm the account qualifies, flag it to the operator before building the batch — don't assume the toggle working in the UI means the account is eligible.

3. Confirm the trigger word (check for collisions)

If the reels use a "comment WORD" / "DM me WORD" CTA:

• Never assign a trigger word without checking it against the live automation list first. Pull the current automations (whatever tracker the account uses, and/or the live automation dashboard) and confirm the word isn't already tied to a different lead magnet. Reusing a live word fires two automations off one comment.
• If the planned word collides, find words that are already live and topically match the reel, or ask the operator for a new one. Do not invent a keyword and assume someone will wire it up.
• Keep the source of truth (Notion, a spreadsheet, whatever the account uses) in sync — if you find live automations that aren't logged there, add them.
• If there's no live automation for a word, don't write a trigger-word CTA at all — ask the operator what the CTA should actually promise.

4. (Optional) Add music — kept generic

Only if the batch needs background music added. Note up front: Metricool's own catalog tracks can't be attached through the API (there's no audio field for Instagram — only a TikTok autoAddMusic boolean), and the catalog tracks aren't downloadable files. So if music is wanted, it gets burned into the video before upload, not added in Metricool. Unless the account has standardized a music source, keep this flexible:

• Whatever source is used, it must give a direct, unauthenticated file URL (login-gated or JS-gated pages won't work in an automated pipeline). Options that meet that requirement include Internet Archive, Incompetech (Kevin MacLeod), and Scott Buckley. Pixabay has the friendliest license but no automatable download, so those have to be hand-picked.
• Always surface the license/attribution terms. If a track is CC BY (credit required, e.g. Kevin MacLeod / incompetech), the credit line goes in the post's first comment, not the caption — keeps the caption clean while satisfying the license.
• Before committing one track to a whole batch, produce short previews of a few options and let the operator choose.
• Mux with ffmpeg, looping audio under the (silent) clip and cutting to length:

  ffmpeg -y -i input.mp4 -stream_loop -1 -i music.mp3 \
    -map 0:v -map 1:a -c:v copy -c:a aac -b:a 128k -shortest \
    -movflags +faststart output.mp4

Name every output file with its posting date at creation time

The moment you write a downloaded or muxed file, name it with the reel's posting date as a YYYY-MM-DD_ prefix — e.g. 2026-07-03_desk-take2.mp4. Do this at creation, not as a cleanup pass afterward.

Why it matters: you can't rename files once they're in Drive (§1), and the operator uploads these by hand later. If the date is already in the name when they drag them in, they arrive correctly labeled and sort chronologically — no second rename pass, no guessing which file maps to which slot. If the exact posting dates aren't settled yet (they're decided in §7), name with your best-planned date and confirm at Gate A; a wrong date in a filename is cheap to regenerate before upload, expensive to fix after.

Save finished files to the operator's real project folder in a dated subfolder as well (e.g. Ready to Post/2026-07-02/) so the folder and the filenames agree. Remember: you can't push these back to Drive (§1).

5. Write captions (voice skill first)

Mandatory: before writing a single caption, invoke the account's voice/caption skill and follow its required fetches exactly — voice reference, hook library, hashtag rules. (If the account doesn't have one yet, voice-skill-template in this repo is the skeleton to fill in. Don't skip it and write from a transcript alone — that reliably produces off-voice captions.) The voice skill governs the words; the rules below govern structure. Do not write from a transcript alone.

Caption structure — CTA placement, line breaks, hashtag counts, hook phrasing — is editorial and belongs to the voice skill, not here. If the account has no established convention, derive it from what the account has actually published (check existing posts via getScheduledPosts or the profile) rather than inventing one.

The only structural requirements this skill imposes:

• Every caption is written from that specific clip's transcript, not from a shared topic name.
• Whatever formatting convention is chosen, apply it consistently across the batch.
• Never reuse the short on-screen hook as the whole caption — it's too thin to work as caption copy.
• Follow the account's voice rules on punctuation (many creators ban em dashes, for instance).
• Confirm formatting on the first caption before building the rest. Show the operator one finished example, settle the convention, then apply it across the batch — rather than formatting everything and reworking it.

These captions must be final before step 11. Once a post is flagged as a Trial Reel in the browser, you cannot fix its caption via the API without downgrading it back to a normal post (see the top-of-file rule). Get the wording genuinely locked at Gate A, not "good enough for now."

6. Verify media is fetchable by Metricool

Metricool fetches media server-side via a public URL — it does not use the operator's Google session.

1. Check each source file's sharing. If it isn't "Anyone with the link," do not change it yourself — tell the operator and wait for them to set it.
2. Use exactly this URL form for Drive: https://drive.google.com/uc?id=<FILE_ID>&export=download. Not /view, not ?usp=sharing.
3. When you create the first draft (step 9), confirm the returned media field ends in .mp4, not .html — that's the tell the link resolved to the real file. Instagram validates media type, so it's a good test platform.

7. Decide dates and times

Default strategy — confirm it suits the account. Trial Reels are a test mechanic, so this skill defaults to concentrating a batch on one day at one shared time rather than spreading it across a range: it keeps the variables comparable. An account that wants trials spread out is free to do that — ask if it isn't already recorded. The one thing that can override the single day is the daily publish cap, which pushes overflow trials to the next day (cap-priority rule below). Overflow only ever moves trials, never regular reels.

Pick the target day, then call getBestTimeToPostByNetwork for Instagram for that day's weekday. Which hour to take from that window is a judgement call — the default here is the end of the best posting window (the latest hour still inside the top-performing slot), on the reasoning that a trial benefits from the tail of a busy period. The single peak hour is an equally defensible choice. Whichever is used, apply the same time to every reel in the batch, and record the preference so runs stay consistent.

If the target day moves to a different weekday, recompute the end-of-best-slot time fresh for the new weekday — never carry the old day's time across.

Because every reel now shares one date, they all take the same YYYY-MM-DD_ filename prefix (§4), and the §8 review file should default every reel's date + time picker to that shared slot rather than leaving them per-reel. Once the day is settled, make sure it matches the prefixes on the muxed files from §4; if the day moved, regenerate the filenames before the operator uploads.

Cap priority: trials yield, regular reels are protected

Concentrating a whole batch on one day makes the daily publish cap the binding constraint, and the rule when it binds is fixed: regular (non-Trial-Reel) posts are protected; the trials are what yield. Never move, re-time, downgrade, or drop a non-trial post to make room for a trial.

Before locking the day, call getScheduledPosts and count the non-trial posts already scheduled to publish on the target day — those seats are spoken for, and the trials get only what's left under the cap:

• If the batch fits in the remaining seats, schedule them all at the shared end-of-slot time.
• If it doesn't, spill the overflow trials to the next eligible day — recompute the end-of-best-slot time fresh for that new weekday (per §7 above) — rather than bumping a regular reel or exceeding the day's cap.

Do not guess the cap number. If the operator has confirmed the account's daily cap, use it. If you don't have a confirmed number, surface the counts (regular posts already on the day vs. trials wanting in) and ask the operator how many trials to place that day before scheduling — treat the cap as unknown-and-must-ask, never as unlimited (rule 2). Record whatever number is confirmed so future runs don't re-derive it. (This ties into the mid-pass "publish-cap error" surprise in §10/§11: if the cap bites there, it's a trial that gets held, never a regular reel.)

Note: getScheduledPosts only returns posts that haven't published yet. A post disappearing from that list usually means it published, not that it was deleted — check whether its time has passed before treating it as missing.

8. Build a review file → Gate A

Before any write to Metricool, produce a file the operator can review and edit, saved to their real working folder (not a chat summary, not a spreadsheet). Build it as an interactive HTML file:

• One card per reel, title linking to the source video
• Editable caption field, editable trigger word
• Date + time picker per reel
• "Copy all as plain text" and "save my edits" (re-serializes form state to a new downloadable file — there's no backend)

Tell the operator to open it in a real browser tab (sandboxed previews block link navigation).

Gate A — hard stop. Do not create anything in Metricool until the operator has explicitly approved the captions, trigger words, and dates. Treat this as the point where captions get locked, not just approved — because after the browser step they can't be edited via API. If they say hold off, that's a full stop on writes even mid-batch.

9. Create everything as DRAFTS via the API + verify

Create each post with createScheduledPost, draft: true, blogId = brand id, the Instagram provider entry, and instagramData: {"type": "REEL", "showReelOnFeed": true}.

Reminder of the core limitation (full explanation at top of file): the API cannot set Trial Reel type. So every post is created as a normal REEL draft here, and the Trial Reel flag is set via the browser in step 11. The API can read back "type": "TRIAL_REEL" once the UI sets it — so it's your verification tool even though it can't write the flag.

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

Every create in this step is draft: true. Never create a post with draft: false — a non-draft post whose publicationDate is in the past or near-term, with autoPublish on, fires immediately. The published-post trap in §11 is about updates; this is the same hazard at create time. Going live only ever happens in the browser at Gate B, never from a create call here.

Test one first: create a single draft, confirm its media ends in .mp4 not .html, before creating the rest. Then create the batch, tracking progress with a task list.

10. Gate B — get the go-ahead before opening the browser

Gate B — hard stop. Once every draft is created and confirmed as a real .mp4 (§9), stop and get the operator's explicit go-ahead for the entire browser pass: flagging each post as a Trial Reel, turning on the share toggle, turning on Auto publish, and scheduling it. This is the one point unattended content can go live, so the go-ahead must be specific (which batch, which date range) and revocable — if the operator wants to keep the batch as drafts and publish manually, honor that, and if they want to see the flagged-but-still-draft state before scheduling starts, that's a valid variant to offer.

Ask for this go-ahead before opening the browser, not after flagging is done. The point of moving it here (rather than wedging it between flagging and scheduling) is so the whole per-post routine in §11 — flag, toggle, auto-publish, schedule — happens in one visit instead of two passes over the batch.

This go-ahead covers the clean path only. It does not pre-authorize working around problems. If a post fails to flag, a caption reverts on reload, a publish-cap or transcoding error appears, or a draft is past-due by the time you reach it — stop on that specific post and ask, rather than treating the original go-ahead as covering it (rule 2). A batch-level approval is not a license to improvise batch-level fixes.

11. Browser: one pass per post — flag, toggle, schedule

"Share to everyone automatically" — confirm the account's default once, then apply it consistently. Many accounts want this on for every reel; some don't. Ask once, record the answer, and apply it every time unless told otherwise for a specific batch. It's a Trial-Reel-only Instagram setting, it's browser-only (the API can't set it), and — like the caption — it can't be changed via API afterward without downgrading the post.

Reliable browser recipe (this SPA is fragile — see rules below). Do all of this in one visit per post — don't come back to the same post twice:

1. Open the post from the List tab, not a deep-link. Opening from the List view loads its correct scheduled time; the deep-link resets the time to 1 PM. Set the list page size to "All" so the scroll position holds and posts don't reshuffle under you. The List view interleaves pre-existing campaign posts — identify each target by its constant uuid (see reliability rules below) so you never edit a campaign post by mistake.
2. Click the network-type dropdown next to the Instagram icon → choose "Trial Reel."
3. Turn "Share to everyone automatically" ON.
4. Re-read the post via the API and confirm "type": "TRIAL_REEL" and the expected shareTrialAutomatically value. Do not trust the screenshot — confirm via API.
5. Re-read the caption text (on screen or via API) — captions have silently reverted to a stale trigger word after a page reload. Fix before proceeding if it changed.
6. Turn on Auto publish and click Schedule. Do not touch the post via the API to schedule it — flipping draft: false via an API update hits the same downgrade as a caption edit (reverts TRIAL_REEL to POST, drops shareTrialAutomatically), and a draft: false post with a past/near-term publicationDate and autoPublish on can fire immediately.
7. After Schedule, re-read via the API and confirm type is still TRIAL_REEL, draft is false, autoPublish is true, and shareTrialAutomatically is true. If type reads POST, it downgraded — fix it in the browser before moving to the next post, because with a near-term time it may publish wrong before post-flight ever runs.

Browser reliability rules — this SPA can reload or blank unpredictably, and a mis-timed click here is the one place content can publish unintentionally:

• Re-fetch the scheduled-posts list before each round and read the current id/uuid from that fresh response. id changes after every update; uuid stays constant — never reuse an old id.
• After every UI action, confirm real state with a fresh API read.
• If a page reloads, goes blank, or the window resolution shifts mid-action, stop and re-verify before clicking again. A click that lands on a re-rendered page can silently skip a post, which then surfaces only in post-flight.

The published-post trap (hard rule)

Never call an update on a post that is already PUBLISHED expecting to edit the live post. It doesn't edit — it creates a brand-new duplicate, and if that duplicate has draft: false + a publicationDate in the past + autoPublish: true, it fires immediately as an unwanted live duplicate. Always check a post's status first. If a live post needs a caption fix, do it directly in Instagram, not by "updating" the Metricool object. Treat published content as immutable from this side.

12. Post-flight verification

After scheduling, pull the full scheduled range and verify programmatically (don't trust individual success responses):

• Total count and count of Instagram posts match expectations
• draft is false where it should be
• Every media URL ends in .mp4, not .html
• Every post still reads "type": "TRIAL_REEL" (a post that reads POST here got downgraded — likely by a stray API update — and needs its flag reset in the browser)
• autoPublish is on and shareTrialAutomatically matches the account's confirmed default

If the output is too large to read inline, process the saved file with a script.

Follow-ups on an already-flagged batch (captions, share toggle, dates)

Once posts are Trial Reels, the API is read-only for them (top-of-file rule). So handle common follow-ups accordingly:

• Caption edit on a Trial Reel: must be done in the browser. An API caption update flips type back to POST and drops shareTrialAutomatically. If you edit in the browser, re-read via API afterward to confirm the type survived. If a big caption rewrite is coming for a batch that isn't flagged yet, do the rewrite before the browser step (§5/§8), not after.
• "Share to everyone automatically": follow the account's confirmed default. Browser-only, same downgrade risk via API, so set it during the §11 pass, not after.
• Shifting dates: recompute each post's best time for its new weekday (§7). Only touch posts still in draft or scheduled — never an already-published one (§11 trap).
• Re-checking what went live: remember getScheduledPosts only lists not-yet-published posts, so a missing post usually means it published (§7 note).

Pre-flight checklist (confirm before any non-draft write)

• Videos located by listing the folder; each clip's content actually identified
• File sizes checked; oversized clips either compressed with ffmpeg or requested via the connected folder/upload (not punted back to the operator to shrink)
• Any many-to-one clip ambiguity raised with the operator, not guessed
• Brand id + timezone confirmed; Instagram confirmed connected
• Account meets Trial Reel eligibility (1,000+ followers, feature enabled) — or flagged
• Trigger word checked against the live automation list; no collision; tracker in sync
• Voice/caption skill invoked; captions written from each clip's real transcript; formatting convention confirmed on the first caption and applied consistently
• Muxed files named with YYYY-MM-DD_ posting-date prefix at creation time (best-planned date if §7 isn't settled yet; re-confirm/regenerate at Gate A before the operator uploads)
• Batch scheduled per the account's confirmed timing strategy (default: one day, one shared time); non-trial posts on that day counted first, daily cap respected (overflow trials spilled to the next day, regular reels untouched) — cap number confirmed with the operator, not guessed
• Music (if used) has a direct URL; attribution planned for first comment
• Drive files shared "anyone with the link"; media URLs use uc?id=...&export=download
• One test draft confirmed real .mp4 (not .html)
• Review file built and Gate A sign-off received; captions treated as locked
• All drafts created via API and confirmed as real .mp4 (not .html)
• Gate B explicit go-ahead received for the full flag → schedule browser pass — obtained before opening the browser, not mid-pass
• "Share to everyone automatically" set to the account's confirmed default on every post
• Each draft reads back TRIAL_REEL via API immediately after flagging, before Schedule is clicked on that post
• Draft→scheduled flip done in the browser (Auto publish on, Schedule), never via an API update; type + autoPublish + shareTrialAutomatically re-verified via API after each
• Any mid-pass surprise (failed flag, reverted caption, publish-cap/transcoding error, past-due draft) stopped on and flagged to the operator individually, not pushed through under the original Gate B go-ahead — on a publish-cap hit, a trial yields, never a regular reel (§7)
• No API update ever issued against an already-published or already-flagged Trial Reel post (browser edits are the allowed path)