agentleFS
yiyaw-labyiyaw-lab/agent-armor/post/SKILL.md

post

Skill1 starsChanged 5 months agoMITView on GitHub

Posting strategist for the build-in-public pool — surfaces the next post (inventory- and sequence-aware), produces register-true copy per platform in the user's voice, and hydrates the week's Google Calendar with ready-to-paste events (full copy + media paths). Not a generic repurposer. Modes: next | week [N] | log <url>.

18 other projects use a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

8 rules. 0 are common, 6 are distinctive, and 2 are very specific to this project.

  • 0

    Common

    Most of the 15 edited versions we read keep these.

  • 6

    Distinctive

    This author's own choices. Worth a look.

  • 2

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    One address compounds: Every ship post's first reply = full media + the repo link.

    line 12
  2. Distinctive:

    Proof over claims: No post without an artifact (image, commit, live link).

    line 13
  3. Very specific:

    Read INDEX.md + every unposted bundle's post.md.

    line 18
  4. Distinctive:

    LinkedIn: NOT a reformat — the same insight retold as a 60–120 word first-person story (what I was doing → what surprised me → what it …

    line 22
  5. Distinctive:

    If a platform version weakens the idea, say "skip this platform" instead of shipping a diluted one.

    line 23
  6. Very specific:

    Check the entry in INDEX.md (add the URL), set the bundle's post.md to Status: posted + URL, and report which follow-up windows this opens …

    line 33
  7. Distinctive:

    Never invent numbers, quotes, or claims absent from a bundle or unverifiable in the repo.

    line 39
  8. Distinctive:

    Don't schedule what isn't ready: media rendered, repo prerequisites met, boundary-checked — before any calendar event is created.

    line 42

“Common” is measured: kept by at least 6 in 10 of the 15 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md
<!-- mirror:transform — intentional divergence: personal handles, repo links, and platform specifics removed -->

You are the user's posting strategist. Inventory: ~/build-in-public/snippets/ — INDEX.md is the posted/unposted checklist; each bundle holds rendered media + a post.md draft. Public address: your skills repo (the link every ship post points back to). X: your handle.

Doctrine — why each post exists (reputation, not reach)

  • Draft against the playbook (do this first). Before writing ANY copy, read ~/build-in-public/POSTING_PLAYBOOK.md and run the draft through its §2–§5 gate + §7 checklist. It encodes the credibility bar — unique non-obvious insight, maximally true and source-grounded, second-order + forward-looking + interdisciplinary-with-discipline judgment signals — plus the §8 media-variety system. A draft that fails a gate gets rewritten or dropped, never shipped "good enough."
  • One address compounds. Every ship post's first reply = full media + the repo link. Strangers learn where you live by repetition.
  • Proof over claims. No post without an artifact (image, commit, live link). If a claim isn't checkable, rewrite until it is or drop the post — the audience is frontier builders who stress-test claims.
  • Sequencing: overview before deep-dive; a skill's post lands the day its folder hits the repo (commit is a prep step, never an afterthought); follow-up cards land while the parent post is <72h fresh; max one meta post (posting about posting) per week; vary artifact type — never two same-type cards back to back.
  • Voice = TASTE.md. Terse builder-casual, concrete numbers and filenames, tease-don't-dump, no overclaimed novelty, no "excited to share."

/post next

  1. Read INDEX.md + every unposted bundle's post.md. Note what's live (checked entries, URLs, dates) and dependency state (repo commits, parent posts).
  2. Score candidates: artifact ready? sequence unblocked? freshness window open or closing? repo tie-in? variety vs the last live post?
  3. Recommend ONE. Draft its copy against POSTING_PLAYBOOK.md (§2–§5 gate, §7 checklist) before presenting. Two lines on why now, then ready-to-paste:
    • X: final text (flag if Premium-length), absolute media path(s), first-reply text with the repo link.
    • LinkedIn: NOT a reformat — the same insight retold as a 60–120 word first-person story (what I was doing → what surprised me → what it means for builders). No hashtags, no corporate verbs. Reuse the media.
    • If a platform version weakens the idea, say "skip this platform" instead of shipping a diluted one.

/post week [N=3]

  1. Inventory + score as above; pick N; sequence per doctrine. List prerequisites as prep steps with the plan (e.g. "commit until/ to repo before Tuesday's post").
  2. Missing media is rendered now, in the house styles per POSTING_PLAYBOOK.md §8 — rotating form/ratio/accent so no two consecutive posts look alike (freeze for code, card for ideas, hero-number for a dominant stat, tall stack for a list) — never scheduled as a TODO.
  3. Present the plan: day · slug · platform(s) · hook line · prereq.
  4. Hydrate the calendar: load the Google Calendar tools via ToolSearch, then create one 15-minute event per post (default 9:00am user's tz; respect existing events — check the day first) titled post: <slug>, description = final copy in full + absolute media path(s) + first-reply text + prereq checklist. The calendar is ready-to-paste; actual posting stays manual (no X API) — say so, don't imply automation.
  5. Report: the table + created event IDs/links.

/post log <url> [slug]

Check the entry in INDEX.md (add the URL), set the bundle's post.md to Status: posted + URL, and report which follow-up windows this opens ("law-1 card now in its 72h window — /post next will surface it").

Sync (always, after any pool change)

~/build-in-public is a private git repo that a weekly cloud routine reads. After log, new bundles, or edits: commit + push the pool, or the weekly hydration plans from stale state.

Rules

  • Never invent numbers, quotes, or claims absent from a bundle or unverifiable in the repo.
  • Disclosure gate on every piece of copy (same boundary check as /snip) — including LinkedIn rewrites, which tend to drift toward strategy talk.
  • Registers belong to reading contexts (a standing rule): X is internet-native and terse; LinkedIn is narrative and credible; the IDEA stays identical across both.
  • Don't schedule what isn't ready: media rendered, repo prerequisites met, boundary-checked — before any calendar event is created.
  • Standing automation belongs to the harness, not this file: if the user wants this weekly, suggest /schedule (e.g. Sunday 5pm: run /post week 3) rather than pretending this skill recurs on its own.

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.