--- name: "farcaster_playbook" description: "Run an account on Farcaster: research channels before casting into them, pick cast formats that travel, build a reply habit, use Mini Apps at a basic level, label AI and agent accounts plainly, and post only after approval. Triggers on Farcaster, Warpcast, casts, channels, Farcaster Mini Apps or Frames, Farcaster agents or bots, and Sign In With Farcaster questions." --- # Farcaster Playbook ## Purpose Run a Farcaster account that earns replies instead of shouting into the home feed. Farcaster is a protocol and the account lives in a client such as the Farcaster app at farcaster.xyz, so the same account can be read through other clients. Posts are called casts. Topic feeds are called channels. This skill is account-neutral: it works for a person, a project, or an agent account, on any signer stack, because the method is research, format, and approval discipline, not one tool. ## Workflow 1. **Set up the account and say what it is.** An account has an FID, a unique numeric identifier for users and apps, and an FID is required to post anything. Register through a client, which handles registration for you, or through the protocol registration route an app uses. Write a bio that states, in plain words: who or what runs the account, what it casts about, and how often. If an AI or an agent runs or helps run the account, the bio says so in plain words, for example "AI agent account" or "Automated account, posts approved by a person". Run `scripts/cast_check.py --agent --profile --text ` to confirm the label is present before the account casts at all. Back up the account recovery material the client gives you and never share signer keys, signer UUIDs, or private keys with anyone or paste them into a cast, a doc, or a chat. 2. **Research channels before casting into them.** A channel is a public space around a topic, and casting into one puts the cast in that channel's feed and in front of people who follow the channel. Anyone can follow a channel like a user. Fill the worksheet in `references/channel-research.md` for each candidate channel: exact name as the client shows it, host and norms, three recent casts that earned replies, two that died, five regulars, and moderation signs. Keep two to four regular channels, test new ones for two weeks, and drop rooms that earn no replies. Read a channel's norms before the first cast there and follow them: hosts can pin or hide casts and can block accounts from casting in their channel. If you create a channel, know the creation rules: a host pays a fee in the client, a new channel name is under 16 characters with lowercase letters and numbers only, and the client can remove a channel with no refund for impersonation, squatting without use, or rule violations. Never rename an existing channel in your notes: names found in clients can predate the creation rules, so copy them exactly. 3. **Pick a cast format on purpose.** Formats that travel on Farcaster, in rough order of reply value: - Question cast: one real question the channel can answer from experience, with your own attempt or constraint in the same cast so replies have something to push against. - Build log cast: what changed, one screenshot or short clip, one number or result you actually measured, and what is next. - Resource cast: one link, two sentences on why it mattered to you, and who should skip it. One link per cast as a rule. - Reply-first day: no top-level cast at all. Spend the session replying in your regular channels (step 4). - Thread: two to four casts when one cast cannot carry the steps. Number them only if readers will land mid-thread. - Recap cast: the week's best exchange, credited to the people in it, with a link back to the original cast. Draft short. Clients enforce their own compose limit and limits change, so check the limit the client shows while composing instead of trusting any fixed number, including one from an older guide. Run `scripts/cast_check.py --file draft.txt --channel --max ` before posting. A cast that needs a paragraph of setup before the point is two casts, or a reply to a better cast. 4. **Build the reply habit before the posting habit.** Replies in channels are where unknown accounts get known, because channel members see them and the host's regulars are already there. Daily working order: first, answer every reply to your own casts. Second, reply to five casts in your regular channels where you can add a fact, a result, a fix, or a real follow-up question. Third, only then write a top-level cast. Reply rules: read the parent cast and its thread before replying, add something the author can use, never reply with praise alone, never reply the same line to two people, and never chase large accounts outside channels hoping for attention. Recasts are distribution, likes are quiet. Recast only casts you would defend in a reply, because your followers read a recast as your endorsement. 5. **Use Mini Apps at the basic level, and share them right.** Mini Apps are the current name for what was called Frames v2. They are web apps built with HTML, CSS, and JavaScript that run inside a Farcaster feed, users are signed in without forms or passwords, and they can carry an integrated Ethereum wallet. As a caster, you do not need to build one to use this step: open Mini Apps from your regular channels, try them as a user first, and share one only after it worked for you. To share, cast the app's page URL so the client can render its embed. The embed comes from page-level fc:miniapp meta tags, while the app itself registers a manifest at /.well-known/farcaster.json on its domain. If a share renders as a plain link, the page is missing its embed tags: say so to the builder instead of posting the bare link again. If you do build a Mini App, the pre-launch checklist is: manifest present with name, iconUrl, and homeUrl, on a production domain over HTTPS; sdk.actions.ready() called after load; a webhookUrl in the manifest and a working webhook if you want notifications; and embeds on every page you plan to share. Discovery depends on that manifest, on recent activity, and on working images, so a tunnel URL from local testing will not surface in search. 6. **Handle sign-in and signer questions without leaking keys.** Sign In With Farcaster lets a site sign a user in with their Farcaster account; AuthKit is the React toolkit for it and FIP-11 is the formal standard. An app that posts for an account does it through a signer: a delegated key the account approved. Hosted stacks expose this in their own way, for example a signer UUID in the Neynar developer portal, where an agent account can be created and a cast published by posting the signer UUID and cast text to that API with the matching API key. Treat every signer credential like a password: store it in a secrets store, never in a skill, a repo, or a cast, scope it to one app, and revoke it from the app that issued it when the account stops using that app. If a signer may have leaked, revoke first and explain after. 7. **Plan the week, then get approval, then post.** Generate a starting calendar with `scripts/calendar.py --start --channels home,, --pillars ",," --out calendar.csv`. Fill the draft column with real drafts, not topics. Approval rule, no exceptions: a cast, reply, or recast posts only after the account owner, or a person the owner named for this, approves that exact text for that channel. A standing calendar is not approval. Automated and agent accounts follow the same rule per cast until the owner grants a written, scoped exception, and the exception is recorded with its date and limits. After posting, paste the cast URL into the calendar row and mark it posted. Review weekly: count replies per channel and per format, keep what earned replies, and rewrite or drop what did not. ## Output Contract - An account setup summary: FID if known, bio text with the AI or agent label when one applies, recovery backup confirmed, and signer storage location named without any secret value. - A channel sheet using `references/channel-research.md`, with a keep, test, or skip verdict per channel and the evidence behind it. - A filled cast calendar from `scripts/calendar.py`, each row carrying a real draft, its channel, its format, and an approval state. - For any single cast task: the exact draft, its channel, the `cast_check.py` result, and the approval state. Nothing is reported as posted without the cast URL. - A weekly review: replies by channel and by format, the best exchange credited, and the one change planned for next week. ## Operating Rules 1. Approval first, always. No cast, reply, or recast goes out on a calendar's say-so. The exact text gets approved for the exact channel. 2. Label plainly. An AI or agent account says so in its bio in ordinary words, and its first cast in any new channel repeats the label in one line. This is this skill's rule for accounts it runs. Do not claim Farcaster imposes a platform-wide label mandate: no official source for that was found when this skill was written. 3. Channel names in notes, drafts, and calendars are copied exactly from the client. The under-16-character, lowercase-and-numbers rule is a creation rule for new channels, not a reason to correct an existing name. 4. No fixed cast length in any advice. Report the character count and the limit the client showed at compose time, or do not give a number at all. 5. Keys and signer credentials never appear in casts, docs, calendars, screenshots, or chat. Naming the service that holds a signer is fine. The value is never fine. 6. Replies carry substance or they do not go out. Praise-only replies, repeated lines, and replying without reading the thread are spam behaviour in effect, whatever the intent. 7. Verify before reporting. A cast counts as posted only with its URL. A Mini App counts as shareable only after its embed rendered in a real client. A channel counts as active only from casts seen in it during research, not from its description.