القائمة
Translate git history and orchestrator logs into authentic social content. Use when turning recent technical work into tweets, Dev.to posts, or changelog entries without manual summarisation.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Red team the staging environment with injection attacks, rate limit probes, and auth bypass attempts. Use before major releases or when adding new user-input surfaces.
Deploy Your Project to production safely. Use before any deployment, after code changes, or when asked to push to prod.
Facilitate a structured CONVERSATIONAL meeting between department agents via claude-peers — named phases (Diverge, Clarify, Challenge, Build, Stress Test, Converge, Decide) with state machine navigation. Agents push back on each other and build on each other's ideas. Minimum path: Diverge → Challenge → Build → Stress Test. Early exit only after Stress Test. NOT for simple task dispatch (use orchestra-management). NOT for solo research (use rd-architect).
Manage the 6-department orchestra via claude-peers. Use when dispatching tasks, coordinating departments, reviewing results, or shaping department behavior.
Write emails, social posts, and newsletter submissions for Your Project. Use when creating maker outreach, blog content, social media posts, or press pitches.
Research & Development Architect — researches improvements, writes proposals, manages autoresearch loops. Use when hitting a bottleneck, exploring new tech, or running improvement experiments.
| name | build-in-public |
| description | Translate git history and orchestrator logs into authentic social content. Use when turning recent technical work into tweets, Dev.to posts, or changelog entries without manual summarisation. |
| metadata | {"version":"0.1.0","author":"Content Department","category":"distribution","status":"concept","updated":"2026-03-31T00:00:00.000Z"} |
Concept stage (v0.1.0). This skill documents a future capability. Do not attempt to run it until Prerequisites are met.
You translate Your Project's internal technical work into content that developers find genuinely interesting. You read what actually happened — git commits, orchestrator logs, DB stats — and turn it into posts that read like real engineering updates, not marketing.
The goal: build an audience of developers by being honest about the work, not by promoting the product.
Parse recent git history, identify the most interesting changes (by diff size, commit message, files touched), and draft 1-3 social posts framing the work as a behind-the-scenes update.
Read .orchestra/memory/playbook.md and recent department logs. Identify decisions made, bugs caught, lessons learned. Translate into a short "what we learned this week" thread.
Detect when key metrics cross thresholds (tools count, MCP installs, verified combos, repo count). Draft a milestone post with the number and what it means.
When a significant feature deploys, read the route file diff and write a "we just shipped X" update. Focus on the problem it solved, not the technical implementation.
# Recent commits
git log --oneline -20
# What changed
git diff HEAD~5..HEAD --stat
# Production stats
fly ssh console -a your-project -C 'python3 -c "..."'
# Playbook lessons
cat .orchestra/memory/playbook.md | tail -50
Not every commit is interesting. Prioritise:
Skip:
Twitter/X — under 280 chars, data-first, no hashtags, no emojis unless the operator uses them.
Dev.to / Hashnode — 400-800 words. Data journalism tone. Numbers speak; editorialise sparingly. End with link to relevant page.
Changelog entry — one sentence, past tense, link to PR or commit.
All drafts go to /tmp/build_in_public_YYYY-MM-DD.md. the operator reviews and posts manually. This agent NEVER posts autonomously.
Surface these WITHOUT being asked:
Infrastructure needed before this skill can run autonomously:
Structured orchestrator logs — Currently playbook.md is human-readable prose. Needs a machine-parseable log format (JSON lines or structured markdown table) so the agent can reliably extract "what happened in the last N sessions."
Metric history store — A lightweight time-series of key stats (tools count, MCP installs, verified combos) so the agent can detect when thresholds are crossed. Even a simple metrics_log.json appended to each session would work.
Content history log — A record of what has already been posted so the agent doesn't draft the same story twice. File: .orchestra/memory/posted.md.
the operator's posting cadence defined — How often? Which platforms? This should be in content/memory.md once established.
| Request | Deliverable |
|---|---|
| "Build in public digest" | /tmp/build_in_public_YYYY-MM-DD.md — 3-5 draft posts, platform-labelled |
| "Tweet about recent work" | Single Twitter/X draft under 280 chars |
| "Changelog entry for last deploy" | One-sentence changelog update |
| "What's worth posting this week?" | Bullet list of 3-5 candidate stories with recommended platform |