Agent skill

Build In Public

by alinaqi in alinaqi/maggy

Best practices for sharing engineering work publicly — what to post, what to withhold, and channel-specific guidance

MITAuto-check passed

Install Build In Public

skills CLI
$ npx skills add alinaqi/maggy --skill build-in-public -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install alinaqi/maggy build-in-public --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/alinaqi/maggy.git skills-src && mkdir -p .claude/skills && cp -r skills-src/skills/build-in-public .claude/skills/build-in-public && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
build-in-public
GitHub stars
707
Token cost
~1.6k tokens
SKILL.md length
776 words
Files
1
Skills in repo
71
Repo updated
First seen
Licence
MIT

At a glance

Best practices for sharing engineering work publicly — what to post, what to withhold, and channel-specific guidance

  • Works in 6 steps: The "we" trap — Solo builders using "we"… → Engagement bait — "Agree?" or… → Posting without building — If you… → …
  • SKILL.md covers Philosophy, What to Share (and What Not To), Channel-Specific Best Practices and Content Calendar Rhythm, plus 4 more sections
  • Instructions only: no scripts, shell commands, URLs or credentials in SKILL.md

What it does

Build In Public is an agent skill from alinaqi/maggy. Best practices for sharing engineering work publicly — what to post, what to withhold, and channel-specific guidance

Its SKILL.md is about 1.6k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.

The repository describes itself as: What started as an opinionated Claude Code setup kit is now an autonomous AI engineering command center. The licence is MIT.

Example prompts

  • “/build-in-public”

Workflow steps

6 steps, taken from the first numbered list in SKILL.md.

  1. The "we" trap — Solo builders using "we" sounds insecure. Use "I" unless you're actually a team.
  2. Engagement bait — "Agree?" or "Thoughts?" at the end of every post reads as desperate. Let the insight stand alone.
  3. Posting without building — If you haven't shipped in 2 weeks, don't post. Your content should be a byproduct of your work, not a…
  4. The LinkedIn bro voice — "I'm humbled and honored to share..." Delete immediately. You're not accepting an award.
  5. Over-polishing — A post that sounds like it went through 5 rounds of editing reads as corporate. Ship the draft.
  6. Ignoring replies — If someone takes time to engage, reply within 24h. The conversation in comments often outperforms the original post.

What it can do on your machine

Read from SKILL.md and the folder at commit 72a456e. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    No scripts in the folder and no shell commands in SKILL.md (its code samples are yaml).

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Build In Public loads about 1.6k tokens when it runs. Until then it costs about 33 tokens; SKILL.md has 776 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~33
When it runs · the whole SKILL.md, loaded when a task matches
~1.6k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from alinaqi/maggy at commit 72a456e, republished under its MIT licence (© alinaqi). 776 words, ~1,561 tokens.

Download SKILL.mdSave it as .claude/skills/build-in-public/SKILL.md (or your agent's skills folder).
name
build-in-public
description
Best practices for sharing engineering work publicly — what to post, what to withhold, and channel-specific guidance
when-to-use
When drafting build-in-public posts, changelogs, or launch content for social channels
user-invocable
false
effort
low

Build in Public — Best Practices

Philosophy

Build in public isn't marketing. It's letting people watch you work. The best posts feel like you're narrating your thought process to a friend who's also a senior engineer. No hype sludge. No "I'm excited to announce." Just: here's what I built, here's why it matters, here's what I learned.

What to Share (and What Not To)

Share:

  • Technical decisions and the reasoning behind them ("Chose SQLite over Postgres because...")
  • Architecture insights ("Here's how the 9-tier routing pipeline works")
  • Failures and what you learned ("Spent 3 hours debugging a race condition. Root cause: ...")
  • Before/after metrics ("Compaction death spirals: 26 → 0 after Mnemos")
  • Open source releases with context, not just links
  • Counter-intuitive findings that surprised you

Never share:

  • Revenue numbers, user counts, valuation
  • Customer names or identifiable client details
  • Internal URLs, API keys, credentials
  • Anything covered by NDA
  • Roadmap promises you might not keep
  • "We're hiring" disguised as content

Channel-Specific Best Practices

LinkedIn

Audience: Engineers, CTOs, founders who build. They scroll between meetings looking for something that makes them think.

Format:

  • 1-3 paragraphs, 800-2000 characters sweet spot
  • Lead with the insight, not the context
  • Use line breaks generously — wall of text kills engagement
  • One clear takeaway per post
  • No external links in first paragraph (LinkedIn penalizes off-platform clicks)

Tone: Confident, teaches something. You're the senior engineer explaining your approach to a peer. No jargon without explanation. If you used a technique others might not know, explain it briefly.

When to post: Tuesday-Thursday, 8-10 AM in target timezone. Avoid weekends and Monday mornings (everyone's catching up).

What works:

  • Technical deep dives with concrete code examples
  • "How I built X" narratives with architecture diagrams
  • Lessons learned from failures (these outperform success stories 3:1)
  • Opinionated takes on industry trends (but only if you have data)

What flops:

  • "Excited to announce" press releases
  • Pure product updates without technical insight
  • Motivational content without substance
  • Posts longer than 2500 chars without strong hook
X (Twitter)

Audience: Developers who ship. They scroll fast and judge faster. You have one sentence to earn their attention.

Format:

  • 280 characters max
  • No threads unless the insight genuinely needs 3+ posts
  • Lead with the counter-intuitive or surprising element
  • One idea per post. If you have two ideas, make two posts.
  • Screenshots need alt-text describing what's shown

Tone: Sharp, opinionated, zero filler. Imagine you're texting a builder friend. If it sounds like marketing, delete it.

When to post: Tuesday-Friday, 9-11 AM or 2-4 PM in target timezone. Weekends can work for developer audience (they're building side projects).

What works:

  • One-sentence technical insights ("The difference between a good API and a great one is error messages.")
  • Before/after comparisons with metrics
  • "Just shipped X. Here's the one thing that surprised me."
  • Asking genuine technical questions (engagement bait backfires)

What flops:

  • Hashtag stuffing
  • Threads that could be one post
  • Generic "hot take" without personal experience
  • Posting links without context
Show full SKILL.md (297 more words)Show less

Content Calendar Rhythm

Daily (if you have something to say):

  • One X post about what you're working on or learned today

Weekly:

  • One LinkedIn post: deeper technical insight or project milestone

Per event (triggered by plugin):

  • PR merged → LinkedIn within 24h, X same day
  • Feature shipped → both channels, LinkedIn first, X 90 min later
  • Review passed → X only (architecture insights are punchy)
  • Major release → LinkedIn deep dive + X announcement

Anti-Patterns to Avoid

  1. The "we" trap — Solo builders using "we" sounds insecure. Use "I" unless you're actually a team.
  2. Engagement bait — "Agree?" or "Thoughts?" at the end of every post reads as desperate. Let the insight stand alone.
  3. Posting without building — If you haven't shipped in 2 weeks, don't post. Your content should be a byproduct of your work, not a substitute for it.
  4. The LinkedIn bro voice — "I'm humbled and honored to share..." Delete immediately. You're not accepting an award.
  5. Over-polishing — A post that sounds like it went through 5 rounds of editing reads as corporate. Ship the draft.
  6. Ignoring replies — If someone takes time to engage, reply within 24h. The conversation in comments often outperforms the original post.

Measuring What Works

Track these signals (Buffer, LinkedIn analytics, X analytics):

  • Impressions — how many people saw it
  • Engagement rate — (likes + comments + reposts) / impressions
  • Profile visits — did the post drive people to learn more?
  • Inbound — DMs, connection requests, or emails referencing specific posts

A good LinkedIn post: 3-5% engagement rate. A great one: 8%+. On X, anything above 2% is solid for technical content.

Plugin Integration

The build-in-public plugin follows these practices automatically:

yaml
# What gets shared vs skipped:
on_pr_merged:
  - Share if: >3 files changed, meaningful commit message
  - Skip if: typo fix, dependency bump, config change only

on_feature_shipped:
  - Share: always, with screenshot
  - LinkedIn: deep dive on architecture decisions
  - X: punchy one-liner on impact

on_review_passed:
  - Share if: 3/3 unanimous approval
  - X only: architecture insights are punchy
  - Skip if: 1/3 or 0/3 (revisions aren't share-worthy)

Anonymous by Default

All posts are redacted through anonymize.yaml before publishing. Company names become generic descriptors. Revenue becomes "at scale." The reader learns about your engineering, not your employer's financials.

© alinaqi, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in skills/build-in-public of alinaqi/maggy.

Open the folder on GitHubat commit 72a456e

Compare with similar skills

Build In Public next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Build In Public compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Build In Public this skillalinaqi/maggy707—~1.6kAutomated safety check: PassMIT
ShareClickHouse/ClickHouse50k—~558Automated safety check: NotesApache-2.0
Developing Share PagesTriliumNext/Trilium38k—~3.7kAutomated safety check: PassAGPL-3.0
SharingBuilderIO/agent-native7.1k—~3.4kAutomated safety check: PassNone
Public Relationscoreyhaines31/marketingskills54k—~2.4kAutomated safety check: PassMIT
Public Relationssickn33/agentic-awesome-skills47k1 repos~1.8kAutomated safety check: PassMIT

Similar skills

  • Share

    ClickHouse/ClickHouse

    Share a Claude Code session to pastila.nl and return a viewer link.

    50k GitHub stars~558 tokensUpdated today
    DatabasesAuto-check: notes
  • Developing Share Pages

    TriliumNext/Trilium

    A skill your agent uses when working on Trilium's share functionality — shared pages under /share/, the static HTML (share-theme) export, the share theme package (packages/share-theme: EJS…

    38k GitHub stars~3.7k tokensUpdated today
    Knowledge ManagementAuto-check passed
  • Sharing

    BuilderIO/agent-native

    Framework-level sharing and privacy for user-authored resources (dashboards, documents, forms, decks, etc.).

    7.1k GitHub stars~3.4k tokensUpdated yesterday
    Auto-check passed
  • Public Relations

    coreyhaines31/marketingskills

    When the user wants help with public relations, earned media, press coverage, journalist outreach, or media strategy (not pull requests).

    54k GitHub stars~2.4k tokensUpdated 2 days ago
    Writing & ContentAuto-check passed
  • Public Relations

    sickn33/agentic-awesome-skills

    When the user wants help with public relations, earned media, press coverage, journalist outreach, or media strategy (not pull requests).

    47k GitHub starsUsed in 1 repo~1.8k tokens
    DevelopmentAuto-check passed
  • Crossframe Public

    sickn33/agentic-awesome-skills

    A skill your agent uses when CrossFrame Suite routes explicit Chinese analysis of public issues, platform governance, policy, institutional responsibility, appeals, or compliance evidence.

    47k GitHub starsUsed in 1 repo~1.2k tokens
    Auto-check passed

More from alinaqi/maggy

All 71 skills in this repo
  • Aeo Optimization

    alinaqi/maggy

    AI Engine Optimization - semantic triples, page templates, content clusters for AI citations

    707 GitHub stars~3.7k tokensUpdated 17 days ago
    Auto-check passed
  • Agent Teams

    alinaqi/maggy

    Claude Code Agent Teams - default team-based development with strict TDD pipeline enforcement

    707 GitHub stars~5k tokensUpdated 17 days ago
    Auto-check: notes
  • AI Models

    alinaqi/maggy

    Latest AI models reference - Claude, OpenAI, Gemini, Eleven Labs, Replicate

    707 GitHub stars~4.1k tokensUpdated 17 days ago
    Auto-check passed
  • Android Java

    alinaqi/maggy

    Android Java development with MVVM, ViewBinding, and Espresso testing

    707 GitHub stars~3.9k tokensUpdated 17 days ago
    Auto-check: notes
  • Android Kotlin

    alinaqi/maggy

    Android Kotlin development with Coroutines, Jetpack Compose, Hilt, and MockK testing

    707 GitHub stars~3k tokensUpdated 17 days ago
    Auto-check passed
  • Autonomous Testing

    alinaqi/maggy

    AI-driven testing agent that auto-discovers, generates, executes, evaluates, and fixes tests for any project type

    707 GitHub stars~1.1k tokensUpdated 17 days ago
    Auto-check passed

Questions about Build In Public

What does Build In Public do?

Best practices for sharing engineering work publicly — what to post, what to withhold, and channel-specific guidance. Build In Public is an agent skill from alinaqi/maggy.

How do I install Build In Public in Claude Code?

Run `npx skills add alinaqi/maggy --skill build-in-public -a claude-code`. Or copy the skill folder (skills/build-in-public in alinaqi/maggy) into .claude/skills/build-in-public in your project. Claude Code loads it when a task matches its description.

How do I install Build In Public in Codex?

Run `npx skills add alinaqi/maggy --skill build-in-public -a codex`. Or copy the skill folder (skills/build-in-public in alinaqi/maggy) into .agents/skills/build-in-public in your project. Codex loads it when a task matches its description.

Can I use Build In Public in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add alinaqi/maggy --skill build-in-public -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/build-in-public, .gemini/skills/build-in-public, .github/skills/build-in-public and .opencode/skills/build-in-public in your project.

What does Build In Public need to run?

SKILL.md names no scripts, command-line tools or credentials: Build In Public is instructions for the agent only.

Does Build In Public access the network?

SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.

Is Build In Public safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Build In Public use?

Build In Public is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Build In Public use?

About 1.6k tokens (SKILL.md is roughly 6.2k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Build In Public?

Skills that share tags, products or a category with Build In Public: Share (ClickHouse/ClickHouse, 50k stars), Developing Share Pages (TriliumNext/Trilium, 38k stars), Sharing (BuilderIO/agent-native, 7.1k stars) and Public Relations (coreyhaines31/marketingskills, 54k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Build In Public?

alinaqi (a GitHub user) maintains it in alinaqi/maggy, which has 707 GitHub stars. The repository holds 71 skills in this directory. The repository was last updated on September 24, 2026.

Source: alinaqi/maggy on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.