--- name: orshot-social-content-calendar description: Plan and load a week of social posts through Orshot. Checks which accounts are connected, chooses posting times, creates scheduled posts and held drafts, and reviews the calendar before anything goes live. Use when the user asks to plan, fill, schedule or load next week's posts, a content calendar, or a batch of social posts across several days or platforms. --- # Plan and load a week of social posts This job is about the **whole week as one reviewable plan**. Build the calendar in full, show it, get approval, then write it. A one-off post is a different job. The failure to avoid is a half-scheduled week: some posts live, some missing, and nobody noticed which. ## 1. Confirm the accounts before planning anything Run `orshot_list_social_accounts` first. Note each account's platform and handle, and whether it is connected and usable. Then: - **No account for a platform the user named:** stop that platform's posts. Offer `orshot_connect_social_account` and say the user must complete the sign-in themselves. Do not plan posts for an account that cannot publish. - **Several accounts on one platform:** ask which one. Never guess between a brand account and a personal one. - **Switching the active workspace or account to reach the right one:** wait for the user's explicit yes first. ## 2. Gather the week's inputs, in one pass Ask once for everything you need, not question by question: - The **days** and how many posts per day or per platform. - The **content source**: a template to render from, an existing held draft, or text the user supplies. Check what exists with `orshot_list_social_posts` rather than listing everything. Filter to the week and to drafts where you can. - Any **fixed dates** (launches, events, holidays). These override timing rules. - Whether anything should be **held as a draft** for the user's review rather than scheduled. ## 3. Choose posting times with a reason Call `orshot_get_best_time_to_post` per platform. Use its result as the default slot for each platform, then apply judgement: - Spread a platform's posts across the week. Two posts within an hour on one account usually cut each other's reach. - Do not put every post in the same slot across all platforms. Keep one slot per platform per day where possible. - Respect fixed dates over the best time. A launch is posted when the launch is. - If the best-time data is thin (a new account, few past posts), say so and use a conservative mid-morning or lunch slot. Do not present a guess as data. ## 4. Build the calendar as a table before writing Draft the full week as a table: day, time, platform, account, content summary, status (scheduled or draft), and any caveat. Check it for: - Gaps: a day with nothing when the user asked for posts every day. - Duplicates: the same asset on two platforms within the same few hours. - Overloads: more than one post per account in the same hour. - Content that cannot go out as is (missing image, text over a platform's length limit, a draft still waiting on a render). Show this table to the user. Do not create anything yet. ## 5. Write the posts, scheduled or held Once the user approves the table, create each post: - **Scheduled** posts: use `orshot_publish_social_post` with the chosen time, or create and then schedule as the tool allows. - **Held drafts**: keep them as drafts for review. Use `orshot_update_social_post` to revise a held post and `orshot_publish_social_draft` only when the user says to send it. Work through the table one row at a time and log each result (created, failed, skipped) against its row. Do not batch silently. If a write fails, record the error, leave that row marked failed, and continue with the rest. Wait for the user's explicit yes before each `orshot_publish_social_post`, `orshot_publish_social_draft`, `orshot_update_social_post` or `orshot_discard_social_post` call. Approval covers the table as a whole only if the user approved that exact table, and it does not cover any row you changed afterwards. ## 6. Review the loaded calendar Run `orshot_list_social_posts` for the week again and compare it with the approved table. Report any row that is missing, in the wrong slot, or in the wrong status. Only then report the week as loaded. ## Common patterns and traps - **"Schedule it for Monday" with no time:** pick the platform's best time and say which one you picked. Do not default silently to midnight. - **Time zones:** state the zone you used. A "9 AM" plan for the wrong zone posts at the wrong hour for the whole audience. - **One asset, many platforms:** the same image rarely fits every size. Check the format for each platform before reusing it. - **Drafts that look scheduled:** after loading, confirm each row's status. A held draft is not live, and a scheduled post will go out without anyone looking again. - **Stale week:** an old draft in the list is not this week's content. Do not pull in last week's leftovers unless the user names them. - **Analytics are not planning data:** past engagement is a reason to pick a slot, not a promise. Do not quote engagement numbers to justify a time unless the tool returned them. ## Output ``` Week: , zone: