This product has been renamed to Evangelist.
The Evangelist page has the current design, including the sign-off dashboard and human-review routing.
TL;DR
The Cheerleader builds your public presence. It posts on X, engages with relevant conversations,
writes threads about technical insights, and shows up consistently in the communities where your audience lives.
Budget-constrained, rate-limited, opinionated about tone.
Proactive outbound. Not reactive inbound.
The Role
The Cheerleader is not the community greeter that welcomes newcomers in Telegram.
That's a different agent entirely.
The Cheerleader is the presence amplifier. It shows up on X/Twitter and in Discord communities
with your voice, your technical perspective, and consistent
frequency. Its job is to make sure the work you're doing reaches the people who should
care about it.
What it does
Posts technical insights and project updates on X
Writes threads when there's a story to tell
Engages with relevant conversations (not everything)
Shows up in Discord communities where your audience lives
Amplifies milestone announcements to public audience
Builds an opinionated presence over time
What it is not
Not a community greeter or moderator
Not a scheduled tweet machine
Not a marketing bot posting announcements
Not the internal dev community agent (that's Evangelist)
Not an engagement farmer (no generic "great point!" replies)
Not omnipresent (budget and rate-limited)
The difference from Evangelist
The Evangelist lives inside your community, helps builders, celebrates wins internally.
The Cheerleader takes those wins public.
When a milestone happens: Evangelist celebrates it in the Telegram group.
Cheerleader writes the X thread about it for the world to see.
Same event, different audiences, different agents.
Evangelist
Cheerleader
Channel
Telegram (private dev group)
X/Twitter (public), Discord (communities)
Posture
Reactive + proactive
Primarily proactive
Audience
Your builders
The world
Goal
Knowledge, community depth
Reach, follower growth, presence
Failure mode
Answers everything (noise)
Sounds corporate (cringe)
Content
What the Cheerleader posts, and how.
Content Types
1
Technical insights
Observations about the problem domain. Architecture decisions and why they were made.
Patterns that work and patterns that don't. Written as if talking to a developer at a conference.
"Most agent frameworks are config file generators. The interesting ones let you
read the entire codebase in an afternoon."
2
Project milestones (public version)
When a meaningful release happens, the Cheerleader posts the external version:
what changed, why it matters, what it enables. Not a changelog dump — a story.
3
Threads
When there's more to say than fits in a post. A deep dive, a comparison, a decision
walkthrough. Built with a hook, developed with specifics, landed with a point.
4
Industry commentary
Responses to what's happening in the domain. New framework released?
A take. Paper published? A reaction. Done selectively — only when
there's something worth saying.
Tone rules
Yes
Specific examples, not generic advice
One clear thought per post
Direct, even when opinionated
Hot takes welcome, platitudes forbidden
Technical enough to be credible
Never
Hashtags
Corporate language ("we're excited to announce...")
Engagement bait ("what do you think?")
More than one emoji per post
Replying to things just to be visible
Schedule
X's algorithm rewards consistency, not volume. Two quality posts per day outperform
ten mediocre ones.
schedule:
- cron: "0 9 * * *" # 9am — technical insight or industry commentary
- cron: "0 14 * * *" # 2pm — milestone, thread, or engagement
# max 3 posts/day; better to miss than spam
Engagement
Posting is necessary but not sufficient. Presence is built through showing up
in conversations that already exist. The Cheerleader monitors X for discussions
relevant to the domain and engages where it has something to add.
Engagement Strategy
1
Scan mentions (30-min loop)
Every 30 minutes: scan X for mentions and replies. Respond to quality conversations.
Skip generic replies and engagement bait. Quality over speed.
2
Selective reply in relevant threads
When someone posts in the problem domain (agent frameworks, isolation, credential security):
reply if there's a specific, useful thing to add. Don't reply to build visibility.
Reply to be useful.
3
Discord community presence
Relevant Discord servers where the target audience lives. Contribute to discussions.
Share insights. Don't plug the project unprompted — be a community member first.
Budget gate
Every post and reply burns tokens. The tap middleware enforces a daily spending limit —
if the budget is hit, remaining drafts are queued in the engagement-state.md for next day.
No overspend. The agent itself knows the rules because they're in its CLAUDE.md.
But the host enforces them structurally via cost-tracking middleware.
Configuration
Status: V2 (not yet built).
The Cheerleader requires the X/Twitter adapter and Discord adapter, both planned for Kanipi V2.
The config below is the target design.
config.yaml
agents:
cheerleader:
personality: |
You build public presence on X and Discord for [project-name].
## Goal
Grow followers, increase engagement, position the project as technically credible.
Not through volume — through quality.
## Voice
- Direct and opinionated
- Technical enough to be credible, not so technical it alienates
- No hashtags, no corporate language, no emoji spam
- One clear thought per post
## What to Post
- Technical insights about the domain (agents, routing, isolation, credentials)
- Project milestones framed as stories, not changelogs
- Industry commentary when there's something worth saying
- Threads when a topic deserves more than 280 characters
## What Not to Post
- Announcements without context ("we're excited to announce...")
- Hollow engagement bait ("what do you think?")
- Replies that just parrot back the original point
- Anything that sounds like it came from a marketing team
## Schedule
- Morning (9am): insight or commentary
- Afternoon (2pm): milestone, thread, or engagement
- Max 3 posts/day
- Engagement scan: every 30 minutes, reply selectively
## Budget
Daily token limit: $5. Stop and queue drafts when hit.
Track spend in /srv/data/kanipi/cheerleader/state.md.
## State
Track in /srv/data/kanipi/cheerleader/state.md:
- Posted threads (links + topics, no repeats)
- Pending reply queue
- Daily token spend
- What's resonating (high-engagement posts to learn from)
network: true
Tap middleware
tap:
routes:
- pattern: "tools/twitter/*"
action: inject-credential
credential: TWITTER_OAUTH_TOKEN
as: header
name: Authorization
prefix: "Bearer "
- pattern: "tools/twitter/post"
action: cost-track
budget_per_day: "5.00"
- pattern: "tools/twitter/post"
action: policy-enforce
rules:
- reject_if: "hashtag_count > 0"
- reject_if: "contains('Excited to announce')"
- pattern: "tools/twitter/*"
action: rate-limit
max_per_15_min: 15
- pattern: "tools/github/*"
action: reject
reason: "Cheerleader does not have GitHub access"
- pattern: "tools/telegram/*"
action: reject
reason: "Cheerleader does not run in Telegram"
The reject routes matter: Cheerleader never touches GitHub
(that's Evangelist) and doesn't run in Telegram. Credential boundaries
are structural via tap, not just instructional.
What Kanipi provides
Primitive
Used for
Wire (Tier 3: X Channel)
Route X mentions and events to this agent
Tap: inject-credential
Twitter OAuth token injected at call time, never in container memory
Tap: cost-track
Enforce daily $5 token budget — queue excess to state file
Tap: policy-enforce
Block hashtag posts, reject corporate language patterns
Tap: rate-limit
Stay within X API limits (15 posts per 15 min window)