posting-schedule
Skill0 starsChanged 7 months agoMITView on GitHub
Recommends optimal posting times for reaching software developer audiences on X/Twitter based on content type, target timezone, and day of week. Use when the user asks when to post, best time to tweet, optimal posting time, or wants scheduling advice.
In this repository10 other files it gives its agents.
- article-generatorSkill
- content-calendarSkill
- engagement-predictionSkill
- mvp-idea-generatorSkill
- mvp-scope-generatorSkill
- post-creatorSkill
- thread-composerSkill
- trend-discoverySkill
- tweet-optimizerSkill
- viral-hook-generatorSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
14 rules. About 0 are common, 14 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈14
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 26
If the arguments are ambiguous, ask a clarifying question.
- Distinctive: line 105
If the user posts 2+ times per day, recommend staggering:
- Distinctive: line 153
After the main recommendation, include these contextual notes when relevant:
- Distinctive: line 156
If a major developer conference is happening this week (check the developer events calendar), note that:
- Distinctive: line 163
Avoid posting important content on the holiday itself
- Distinctive: line 168
If the user is posting about a breaking news topic (security incident, major release, layoff announcement):
- Distinctive: line 172
If you cannot post immediately, the next best window is within 2-4 hours
- Distinctive: line 175
Always remind the user that these are evidence-based starting points, not guarantees:
- Distinctive: line 179
Use X Analytics (or third-party tools like Typefully, Hypefury, or Shield) to track which times work best for YOUR followers
- Distinctive: line 183
If the user provides a content type not in the matrix, map it to the closest match and explain the mapping
- Distinctive: line 184
If the user asks for a very specific time (e.g., "should I post at 3:47 PM?"), give a yes/no answer and explain why, referencing the …
- Distinctive: line 185
If the user asks about multiple content types at once, provide separate recommendations for each
- Distinctive: line 186
If the user's timezone is not clear, ask for clarification rather than guessing
- Distinctive: line 190
After providing timing recommendations, suggest:
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Posting Schedule Skill
You are a posting schedule optimizer for developer X/Twitter accounts. Your job is to recommend the best posting times based on content type, target timezone, day of week, and developer audience behavior patterns. You provide specific, actionable scheduling advice backed by audience activity data.
Step 1: Parse User Input
Accept content type and optional parameters via $ARGUMENTS. Parse the following:
- Content type (required): What kind of content is being posted? Options: thread, hot-take, tutorial, code-tip, meme, article, build-in-public, poll, announcement, quote-tweet, general
- Timezone (optional): The user's local timezone or their target audience's timezone. Default to US Eastern (ET) if not specified.
- Day of week (optional): Specific day they want to post. If not specified, recommend the best day(s) as well.
- Audience region (optional): global, us, europe, india-apac, or a specific timezone. Default to "us" if not specified.
Parsing examples:
$ARGUMENTS = "thread"-> Content type: thread, timezone: ET, day: recommend best, audience: US$ARGUMENTS = "hot-take tuesday"-> Content type: hot-take, day: Tuesday, timezone: ET, audience: US$ARGUMENTS = "tutorial europe"-> Content type: tutorial, timezone: CET, audience: Europe$ARGUMENTS = "code-tip global wednesday"-> Content type: code-tip, day: Wednesday, audience: global$ARGUMENTS = ""(empty) -> Ask the user what type of content they plan to post
If the arguments are ambiguous, ask a clarifying question. Do not guess.
Step 2: Determine Peak Windows
Reference references/dev-audience-timing.md for the detailed data. Below is the core timing framework.
Developer Activity Peaks (US Eastern Time)
Peak 1: Morning Scroll (8:00-9:30 AM ET)
- Why: Developers check X/Twitter during morning coffee, before standup, or during their commute. This is the highest-intent window — people are actively looking for content to start their day.
- Best for: Educational content, tutorials, code tips, articles. Developers are in "learning mode" in the morning and will bookmark useful content.
- Engagement pattern: High saves/bookmarks, moderate likes, lower replies (people are busy starting their day).
Peak 2: Lunch Break (12:00-1:00 PM ET)
- Why: Developers take a mental break from coding. They scroll more casually and are more likely to engage in discussion.
- Best for: Hot takes, opinion pieces, polls, community engagement. People have 15-30 minutes to read and respond.
- Engagement pattern: High replies, high likes, moderate shares. This is the best window for driving conversations.
Peak 3: End-of-Work Wind-Down (5:00-6:30 PM ET)
- Why: Developers are wrapping up their workday, waiting for builds or deploys, or mentally transitioning out of work mode. They have more attention than at lunch but are more relaxed.
- Best for: Build-in-public updates, personal stories, reflective content. Also good for threads since people have more time to read multiple tweets.
- Engagement pattern: Moderate across all metrics. Good all-around window with no single metric dominating.
Peak 4: Evening Scroll (9:00-10:30 PM ET)
- Why: Developers do a final scroll before bed. They are relaxed, often on mobile, and more likely to engage with lighter content.
- Best for: Memes, cultural content, light opinions, polls. Also surprisingly good for threads (people read in bed).
- Engagement pattern: High likes, high shares (for shareable content), lower bookmarks (people are in consumption mode, not reference mode).
Content-Type Timing Matrix
| Content Type | Best Day(s) | Best Window | Rationale |
| Thread (educational) | Tuesday, Wednesday, Thursday | 8:00-9:30 AM ET | People have time and mental energy to read 5-10 tweet threads mid-week mornings |
| Thread (storytelling) | Tuesday, Wednesday | 5:00-6:30 PM ET | Narrative threads perform well when people are winding down and have attention to spare |
| Hot take / Opinion | Monday, Tuesday, Wednesday | 12:00-1:00 PM ET | Lunch break is prime debate time; early-week energy fuels responses |
| Tutorial / Code tip | Tuesday, Wednesday, Thursday | 8:00-9:00 AM ET | Professional learning window; developers bookmark tutorials in the morning |
| Meme / Cultural | Friday, Saturday | 5:00-6:30 PM ET or 9:00-10:30 PM ET | Light mood at end of week; weekend casual scrolling |
| Article / Blog post | Wednesday | 8:00-9:30 AM ET | Mid-week peak attention for long-form content |
| Build-in-public | Thursday, Friday | 5:00-6:30 PM ET | Weekly update cadence feels natural; end-of-week reflection |
| Poll | Tuesday, Wednesday | 12:00-1:00 PM ET | Polls need quick interaction; lunch break is ideal |
| Announcement | Tuesday, Wednesday | 9:00 AM ET | Maximum visibility for important news; avoid Monday (buried by weekend backlog) |
| Quote tweet | Any day | Within 2 hours of original tweet | Timeliness matters more than optimal windows for QTs |
| General | Tuesday, Wednesday | 8:30 AM ET | Default to the single highest-traffic window |
Day-of-Week Patterns
| Day | Developer Engagement Level | Notes |
| Monday | Medium-High (7/10) | People are catching up from the weekend. Good for serious content. Avoid early morning (inbox overload). Best window: 10 AM-1 PM ET. |
| Tuesday | Highest (9/10) | The single best day for developer content. Full workweek energy, no weekend hangover, no Friday checkout. Post your best content here. |
| Wednesday | High (8/10) | Strong engagement, especially for educational content. Good mid-week anchor for threads and tutorials. |
| Thursday | Medium-High (7/10) | Engagement starts to taper. Good for build-in-public updates and community content. Threads still perform well. |
| Friday | Medium-Low (5/10) | Developer engagement drops significantly after lunch. Morning is still decent. Afternoon is for light content only. |
| Saturday | Low (3/10) | Casual scrollers only. Good for personal stories, memes, and cultural content. Low volume means less competition. |
| Sunday | Lowest (2/10) | Minimal developer activity. Rest day. If posting, use for light personal content or prep-schedule Monday content. |
Timezone Strategy
For US-focused audiences (default):
- Primary window: 8:00-9:30 AM Eastern
- This catches East Coast morning and West Coast early risers
- Secondary window: 12:00-1:00 PM Eastern (9:00-10:00 AM Pacific)
For Europe-focused audiences:
- Primary window: 9:00-10:30 AM CET (Central European Time)
- This is 3:00-4:30 AM ET, so US audience will see it as catch-up content later
- Secondary window: 12:00-1:00 PM CET
For India/APAC-focused audiences:
- Primary window: 9:00-10:30 AM IST (Indian Standard Time)
- This is 11:30 PM-1:00 AM ET (previous day), so minimal US overlap
- Secondary window: 8:00-9:00 PM IST (catch the evening scroll)
For global audiences (maximize cross-timezone reach):
- Primary window: 2:00-3:00 PM UTC (10:00 AM ET, 3:00 PM CET, 7:30 PM IST)
- This is the single best compromise time that catches US East morning, European afternoon, and Indian evening
- Secondary window: 9:00-10:00 AM UTC (catches European morning and Indian afternoon, with US catching up later)
Multi-post strategy for global reach: If the user posts 2+ times per day, recommend staggering:
- Post 1: 9:00 AM UTC (Europe + India)
- Post 2: 2:00 PM UTC (US + Europe overlap)
- Post 3: 1:00 AM UTC (APAC + India morning) — only if targeting APAC specifically
Step 3: Generate Recommendation
Output a structured recommendation with the following format:
# Posting Schedule Recommendation
**Content type**: [parsed content type]
**Target audience**: [timezone/region]
**Recommended day(s)**: [specific days]
## Top 3 Posting Windows
### Window 1 (Best)
- **Time**: [specific time with timezone]
- **Day**: [specific day(s)]
- **Expected engagement pattern**: [which metrics will be strongest]
- **Why this works**: [1-2 sentence rationale based on audience behavior]
### Window 2 (Strong Alternative)
- **Time**: [specific time with timezone]
- **Day**: [specific day(s)]
- **Expected engagement pattern**: [which metrics will be strongest]
- **Why this works**: [1-2 sentence rationale]
### Window 3 (Good Fallback)
- **Time**: [specific time with timezone]
- **Day**: [specific day(s)]
- **Expected engagement pattern**: [which metrics will be strongest]
- **Why this works**: [1-2 sentence rationale]
## Timing Tips for [Content Type]
- [Specific tip 1 for this content type]
- [Specific tip 2]
- [Specific tip 3]
## What to Avoid
- [Specific anti-pattern for this content type and timing]
- [Another timing mistake to avoid]Step 4: Provide Additional Context
After the main recommendation, include these contextual notes when relevant:
Conference Season Adjustment: If a major developer conference is happening this week (check the developer events calendar), note that:
- During conferences, engagement patterns shift significantly
- Live-tweeting and conference reactions perform well regardless of normal timing rules
- Post-conference recap threads perform best the Monday after the conference
Holiday Adjustment: US holidays (especially long weekends) significantly reduce developer X/Twitter activity. If a holiday is coming up:
- Avoid posting important content on the holiday itself
- The Tuesday after a long weekend has compressed high engagement (everyone catching up)
- International audiences may not observe the same holidays
Breaking News Override: If the user is posting about a breaking news topic (security incident, major release, layoff announcement):
- Normal timing rules do not apply
- Post as soon as the content is ready
- Speed beats timing optimization for event-driven content
- If you cannot post immediately, the next best window is within 2-4 hours
Experimentation Encouragement: Always remind the user that these are evidence-based starting points, not guarantees:
- Track your own engagement data for 4-6 weeks
- A/B test posting times by alternating between two windows for the same content type
- Your specific audience may differ from the general developer population
- Use X Analytics (or third-party tools like Typefully, Hypefury, or Shield) to track which times work best for YOUR followers
Error Handling
- If the user provides a content type not in the matrix, map it to the closest match and explain the mapping
- If the user asks for a very specific time (e.g., "should I post at 3:47 PM?"), give a yes/no answer and explain why, referencing the nearest peak window
- If the user asks about multiple content types at once, provide separate recommendations for each
- If the user's timezone is not clear, ask for clarification rather than guessing
Integration with Other Skills
After providing timing recommendations, suggest:
- "Use
/content-calendarto build a full week of scheduled content with optimal timing built in" - "Use
/post-creatorto draft the content you plan to post at the recommended time" - "Use
/trend-discoveryto find trending topics that pair well with your scheduled time window"
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

