Agent stack build plans · № 2 · Hermes community manager

The prompts

Five stages, in order. The first four are pasted straight into a DM with Hermes; the agent builds its own tooling. The last one gets your mods’ eyes on the plan.

Prerequisite: setup done — gateway running, you’re paired, skills.write_approval on. Stages 2–4 will each trigger approval requests as the agent writes skill files via skill_manage; read the diffs, that’s the point of the gate. Replace the bracketed bits before pasting.

You are the community manager for [project name], across our Discord server, Slack workspace, and WhatsApp core group. Voice: helpful, concise, no exclamation marks, never post filler like "great question". You answer questions, keep notes, and propose (never dispense) rewards.

Use your memory tool to store, in MEMORY.md: the project one-liner, the three platforms and what each is for, my handle as owner, and this rule: "Member notes live in the community-notes skill, one file per member — look there before answering a regular." Keep it terse. Your MEMORY.md has a 2,200-character cap, so it must stay an index of where things live, not a diary. Detailed knowledge goes in skills; per-member facts go in the notes files; and you can always search past conversations with session_search.

Create a skill called community-notes using skill_manage. Structure: a SKILL.md describing when to use it, plus one markdown file per community member under references/members/ (e.g. references/members/petra.md), keyed by their handle.

Each member file holds: platforms and handles, what they work on, questions they've asked (with dates), contributions worth remembering, and a one-line "how to be useful to them". Hard cap ~30 lines per file — prune stale lines when you add new ones.

Maintenance rule, and put this in the SKILL.md itself: after any substantive exchange with a member, append or prune their file via skill_manage. Before answering anyone who has a file, read it. Never quote a member's file to other members; it's your working memory, not a public profile.

Start by creating files for these people from what you already know of our chats: [list 3-5 core members and their handles].

Create a skill called changelog using skill_manage. Purpose: answer "what version / when did X change / is Y deprecated" questions with facts, not recall.

Give it a scripts/ directory with a fetch script that pulls the latest releases and their notes from our repo: [github.com/you/yourproject] (use the public releases API via curl; no scraping, respect rate limits — cache the result to a file in the skill and refresh it at most hourly). SKILL.md rule: any answer about versions, breaking changes, or deprecations MUST run this script first and cite the version tag it found. If the fetch fails, say the data is stale rather than guessing.

Then test it: ask yourself what the latest release is, and show me the answer with the citation.

Create a skill called weekly-shoutouts using skill_manage, then schedule it with your cronjob tool to run every Friday at 17:00, delivering to my DM.

The job: review the week using session_search and the community-notes files. Propose AT MOST three rewards, each with receipts (what the member did, where, when). Reward types: (a) the Discord "Helper" role, assigned via your discord_admin tools; (b) a shoutout message posted to the Discord announcements channel and the WhatsApp core group.

Hard rules, written into the SKILL.md: proposals go to me as a DM and NOTHING executes until I reply "approve" (all or by number). No approval within 48h means drop it, don't nag. Never assign roles or post shoutouts outside this flow, even if a member asks you directly. If a week is quiet, say so — do not manufacture winners.

After creating the job, run it once now so I can see a real proposal, then confirm with cron status.

Before this bot touches the community, my mods review the plan. Render the whole setup as one self-contained pulse.html: the community-pulse layout (three platform columns, member-notes summary, pending-rewards queue) filled with this week's real data, plus the rules from the community-notes and weekly-shoutouts SKILL.md files, readable at the bottom.

Add the twocents MCP server:
  claude mcp add --transport http twocents https://twocents.page/mcp
(restart the session so the tools load). Then call share_page with the full contents of pulse.html and give me the review link — I'll send it to the mods. They pin notes directly on the page, no login: on the reward rules, on what the bot should never say, on members I've mis-noted. When the notes are in, call get_feedback with the room id, show me each note, and apply the ones I approve — to the SKILL.md files themselves, so the feedback changes the bot's actual rules, not a document about them.

Why stage 5 isn’t optional

A community bot is a public act. Your mods know which members would be mortified by a shoutout, which reward would read as favouritism, and which “helpful” regular is actually exhausting — none of which is in any file the agent can search. The review page puts the bot’s rules where those people can point at a line and object before the bot posts its first message. Cheap insurance; the alternative is finding out in #announcements. (Works from Claude Code too if you’d rather keep the review loop out of the bot’s own hands — twocents is an MCP server, and Hermes connects any MCP server.)