--- name: climbx description: Grow an X (Twitter) account through the ClimbX MCP tools or REST API - read real analytics, draft posts in the account owner's voice, pull outlier inspiration, and publish or schedule. Use when the user asks about their X performance, wants posts drafted, scheduled, or published, wants inspiration from creators they track, or wants a reply drafted. X only; requires a ClimbX API key. metadata: climbx-author: ClimbX climbx-version: "1.0" climbx-homepage: https://climbx.so climbx-source: https://climbx.so/skills/climbx/SKILL.md --- # ClimbX: growing an X account through your agent ClimbX is a growth co-pilot for X (Twitter). It learns the account owner's voice from their real posts, tracks which formats and niches perform for them, and surfaces outlier posts breaking out for creators they follow. The hosted MCP server at https://climbx.so/mcp exposes all of it as 16 tools; the REST API at https://climbx.so/api/v1 offers the same capabilities 1:1. Endpoint schemas and exact payloads live in the tool descriptions and at https://climbx.so/skills.md - this skill covers when and how to use them well, not what they accept. ## When to use this skill - The user asks how their X account or posts are performing. - The user wants a post drafted, improved, scheduled, or published on X. - The user wants to know what is working for creators they track, or wants post inspiration. - The user wants a reply drafted to a specific post. - The user asks how their voice profile or posting rules have evolved. ## When NOT to use it - Any platform other than X. ClimbX is X-only; do not adapt its drafts for LinkedIn or elsewhere as if the data transfers. - Reading data about arbitrary X accounts. The tools cover the connected account and the creators it tracks - nothing else. - Auto-replying or reply automation. suggest_reply returns a draft for the HUMAN to edit and send on X themselves. Never post its output anywhere, never loop it over a list of posts. - Posting anything containing a URL. Rejected server-side by design; see the rules below for what to do instead. - Bulk posting. The 5 posts/day cap is a hard product decision, not a quota to engineer around. ## Capability map - **Read performance**: get_analytics (headline KPIs, up to 90 days), get_format_performance and get_niche_performance (medians + trends per bucket), list_posts (recent posts with metrics). - **Read identity**: get_voice_profile (persona, cadence targets, posting schedule), get_learnings (current do-more / do-less rules with evidence), get_learnings_history (how the rules changed over time). - **Inspiration**: get_inspiration_options (the filter spec - call this once before the outlier tools), get_following_outliers (breakouts from tracked creators, each with a baseline multiplier), get_surprise_outliers (network-wide discovery, filterable). - **Write**: publish_post (now), schedule_post (ISO datetime with offset), list_scheduled, reschedule_post, cancel_scheduled. - **Engage**: suggest_reply (one voice-matched reply draft; suggestion only). ## Rules that make the output good 1. **Voice before drafting.** Always call get_voice_profile and get_learnings before writing post text. Match the persona, casing, and length habits they describe, and apply the do-more / do-less rules. A draft that ignores them is generic AI text, which is exactly what ClimbX users are paying to avoid. 2. **Ground drafts in data, not vibes.** Pull analytics and/or outliers first so a draft can cite why it should work ("your hot takes have 3x your median replies; this outlier format is breaking out"). If you drafted without data, say so. 3. **Insight-first content.** Default drafts must deliver an insight, useful information, or a discussion-worthy question. Engagement-CTA posts (follow prompts, "drop yours below", milestone hype) are a legitimate but separate lane: label them as engagement-focused when suggesting one, and keep them to roughly 1 in 5 drafts at most. 4. **Never put a URL in post text.** Links cut reach 50-90% and are rejected with a 400. The pattern: post the thought, then tell the user to add the link themselves as a reply on X. 5. **Budget the daily cap.** Publish and schedule share 5 posts/day. Call list_scheduled before scheduling a batch, and if a plan needs more than the remaining slots, schedule across days instead of failing mid-batch. 6. **Schedule with an offset.** scheduled_for takes ISO 8601 with a timezone offset (e.g. 2026-07-03T09:00:00+02:00). Pick times from the posting schedule in get_voice_profile unless the user names a time. 7. **Options before outliers.** get_inspiration_options returns the valid filter values and tracked handles. Call it once per session before get_following_outliers or get_surprise_outliers instead of guessing enum values. 8. **Draft ≠ publish.** When a user asks for drafts, return drafts. Only call publish_post or schedule_post when the user has clearly asked for the post to ship. ## Recommended workflows - **Morning briefing**: get_analytics (30 days) -> get_following_outliers -> get_voice_profile -> present a short performance summary plus 2-3 grounded drafts with a one-line rationale each -> user picks -> schedule_post. - **Fill the week**: list_scheduled -> get_voice_profile (cadence + best times) -> schedule the user's ideas into open slots, staying within the cap per day. - **Performance review**: get_format_performance and get_niche_performance for this period vs the last -> get_learnings_history over the same window -> summarize what shifted and what the rules now say. - **Reply co-pilot**: user pastes a post -> suggest_reply -> return the draft and remind the user to edit and send it on X themselves. ## Example requests -> tools - "How did my posts do this month?" -> get_analytics, then get_format_performance if they ask what kind of posts worked. - "Draft me something about my launch" -> get_voice_profile + get_learnings (+ outliers if relevant), then write. Do not publish. - "Ship it" / "post that one" -> publish_post. - "Queue it for tomorrow morning" -> get_voice_profile for the best slot, schedule_post with an offset datetime. - "What's working for the accounts I follow?" -> get_inspiration_options, then get_following_outliers. - "Help me reply to this" -> suggest_reply, deliver as a suggestion. ## Before publishing or scheduling Validate, then ship, then confirm: 1. Check the text: no URL and no bare domain (climbx.so counts), voice matches the profile, insight-first or labeled as engagement-lane. 2. Check the budget: a cap slot is free (list_scheduled, or posts_used_today from the last publish response). 3. Check the intent: the user explicitly asked to ship this exact text. 4. If any check fails, fix and re-check instead of publishing. 5. After publishing, relay the returned post URL so the user can verify on X. ## Gotchas Facts that defy reasonable assumptions - trust these over intuition: - A bare domain with no scheme ("climbx.so") is rejected as a link, same as an https URL. Do not retry with the scheme stripped. - Cancelling a scheduled post does NOT refund its daily-cap slot. The slot is spent at creation. - The cap resets at 00:00 UTC, not in the user's timezone. - suggest_reply failing with 403 is not an auth problem: it unlocks only after the owner has written enough manual replies in the ClimbX Engage tab, and each draft spends a shared daily AI credit. Explain the lock; do not retry. - posts_used_today in the publish/schedule response is the authoritative cap state - use it instead of counting calls yourself. - A young account can have a thin voice profile and empty learnings. Say so and draft conservatively; do not invent rules that are not in the data. ## Errors and edge cases - **401**: key missing, wrong, or revoked. Ask the user to check Settings -> API. - **402**: the ClimbX plan or trial lapsed. Tools stay locked until billing is active; tell the user rather than retrying. - **429**: daily post cap reached. Offer to schedule for after 00:00 UTC instead. - **400 mentioning links**: the text contains a URL or bare host. Remove it and propose the link-in-reply pattern. - **Media**: up to 4 public https image URLs per post; video is not supported over the API. ## Authentication Requests use a bearer key (climbx_sk_...) created at https://climbx.so/account/settings/api. The key is shown once and stored only as a hash; treat it as a secret - environment variable or MCP client config, never hardcoded in scripts or committed files. Connect the MCP server with: ``` claude mcp add --transport http climbx https://climbx.so/mcp \ --header "Authorization: Bearer $CLIMBX_API_KEY" ``` Revoking the key in settings stops every client using it on the next call. ## Maintenance The MCP server executes; this skill reasons. Tool schemas, payloads, and limits are defined by the MCP tool descriptions and https://climbx.so/skills.md - they are not duplicated here, so API additions do not require skill edits. Update this file only when a workflow, selection rule, or product constraint changes (the cap, the link block, the engage lock, the content rules). When an agent following this skill gets corrected on something the skill should have known, add the correction to Gotchas - that section earns its tokens the hardest.