build-in-publiclisted

Turn what the developer has actually been building into a queue of build-in-public X posts. **You write the posts** from the real git history — capx never generates content; it only ships (each post passes the casserole guardrail at send). User's extra intent, if any: "$ARGUMENTS" Follow these steps: 1. **Read the real work.** Run `git log --oneline -30` (or a range the user named). Skim the diffs of the substantive commits if needed. **Skip the noise** — merges, `wip`, `fix typo`, formatting, dependency bumps. You want the *shippable, interesting* changes: new features, fixes users would care about, milestones, hard problems solved. 2. **Group into themes.** Cluster related commits into a handful of "this is worth a post" stories. A week is usually 3–5 posts, not one-per-commit. 3. **Draft the posts.** For each theme write ONE post that is: - **Concrete and specific** — name the actual thing you built and why it matters. "Shipped X so users can now Y" beats "made great progress today!". (The guardrail actively blocks vague hype, engagement-bait, hashtag stuffing, and duplicates — specificity is what gets through *and* what people actually read.) - **Grounded in the commits** — do NOT invent features, numbers, or outcomes that aren't real. If you're unsure a claim is true, leave it out or ask. - **In the user's voice** — if a voice profile is available (the `voice-match` skill), match it; otherwise mirror the tone of their recent p