No editor required
All content management via MCP tool calls from Claude Code. Your content workflow stays in your terminal — the same place you write code.
Claude Code Skill
Your repo already
Your repo already
has a story.
repo-publisher reads your git history, decides what's worth writing about, and publishes it to your scsiwyg blog — without you opening a text editor.
// download → copy folders to ~/.claude/commands/
repo-publisher + scsiwyg
↓ .zip
- repo-publisher/README.md
- repo-publisher/SKILL.md
- repo-publisher/references/ (5 files)
- scsiwyg/README.md
- scsiwyg/SKILL.md
- scsiwyg/references/ (2 files)
Full workflow — publishes to scsiwyg.com →
scsiwyg only
↓ .zip
- README.md
- SKILL.md
- references/blogs.md
- references/claude-skills-conventions.md
Manual blog management · scsiwyg.com →
The problem
You shipped.
You shipped.
You didn't blog.
You shipped 47 commits last month.
You wrote 0 blog posts.
You wrote 0 blog posts.
You know you should document your work. Every commit contains a decision, a discovery, or a hard-won lesson someone else is about to make the hard way.
But by the time you finish shipping, writing about it feels like the last thing you want to do. You're tired. The next ticket is already open. The moment passes.
So you don't write it up. The knowledge lives in your git log and nowhere else. The audience that would have found your work, learned from it, or hired you because of it — never sees it.
How it works
Six phases.
Six phases.
Zero new habits.
repo-publisher attaches to your existing git workflow. You keep shipping. It keeps writing.
Read State
Loads .blog-state/state.json and reads git log since last run.
Analyze
Runs code-audit, security-posture, infra-cost pipelines. Caches results in analysis/.
Decide
Scores story candidates by significance, novelty, timeliness, audience fit. Selects 1–2 per run.
Produce
Generates Markdown drafts with Mermaid diagrams. Saves to queue/.
Publish
Pushes approved drafts to scsiwyg via MCP tools. Appends to published/log.jsonl.
Save State
Snapshots state.json to history. Updates content ledger. Ready for next run.
The decision engine
Not every commit
Not every commit
is a post.
Most commit-to-content automations produce noise. repo-publisher is built around the assumption that the most valuable thing it can do is not publish.
Every potential story is scored across four dimensions before a single word gets written:
- significance How substantial was the change? Architecture shifts score high. Lockfile updates score low.
- novelty Has this topic been covered recently? Stateful memory prevents repetition.
- timeliness Is this relevant now? A new feature ships, its window is open. A refactor from six months ago is past it.
- audience-fit Does this match your blog's configured audience and voice?
// scoring model
score = significance × novelty × timeliness × audience-fit
score = significance × novelty × timeliness × audience-fit
threshold: 0.5 — stories below this are skipped. you control the rest via publish_mode.
repo-publisher — candidate analysis
$ repo-publisher analyze --candidates
Scanning commits since 2026-04-09...
Found 23 commits across 4 active branches.
STORY CANDIDATES (scored):
[0.91] feat: migrate auth to JWT + refresh tokens
significance=0.9 novelty=0.85 timeliness=1.0 fit=0.9
→ format: deep-dive | estimated: 800 words
→ STATUS: SELECTED
[0.74] refactor: extract PaymentService from monolith
significance=0.8 novelty=0.7 timeliness=0.7 fit=0.8
→ format: changelog | estimated: 400 words
→ STATUS: SELECTED
[0.41] fix: correct timezone offset in date formatter
significance=0.3 novelty=0.4 timeliness=0.6 fit=0.5
→ STATUS: SKIPPED (below threshold 0.5)
[0.38] chore: update lockfile
significance=0.1 novelty=0.2 timeliness=0.7 fit=0.4
→ STATUS: SKIPPED (below threshold 0.5)
[0.29] style: fix indentation in auth module
significance=0.1 novelty=0.2 timeliness=0.5 fit=0.3
→ STATUS: SKIPPED (below threshold 0.5)
Publishing 2 of 23 commits as posts this run.
Next run scheduled per cadence: weekly
The platform
A blog platform
A blog platform
that speaks Claude.
scsiwyg is the headless, API-first blog platform that repo-publisher publishes to. There is no web editor. No dashboard to maintain. All content management — creating posts, updating drafts, publishing, managing your newsletter — happens through MCP tool calls from Claude Code. It's a blog platform designed for the way developers actually work.
Markdown native
Every post is plain Markdown. No proprietary formats, no locked-in content. Your writing is yours — move it anywhere, any time.
Newsletter included
Manage subscribers and send newsletters from Claude Code. Your audience, your list, your tools. No separate email platform needed.
Under the hood
One config file.
One config file.
One state directory.
No hidden complexity. Everything repo-publisher does is visible, configurable, and yours.
Configure once, run forever.
Everything about how repo-publisher behaves lives in a single
.blog-state/config.yaml
file. Set your target blog, define your voice, choose your cadence, pick which
analysis pipelines to run.
Change it whenever your priorities change. It's just a file.
# .blog-state/config.yaml
blog:
target: "scsiwyg" # publishing destination
slug: "your-blog-slug" # your scsiwyg identifier
voice:
tone: "technical, direct"
audience: "senior engineers"
avoid: ["marketing speak", "buzzwords"]
cadence:
frequency: "weekly" # daily | weekly | per-commit
max_posts_per_run: 2
publish_mode: "propose" # draft | propose | auto
pipelines:
code_audit: true
security_posture: true
infra_cost: false
cross_post:
enabled: false
targets: []
Stateful by design.
repo-publisher keeps its memory in .blog-state/.
It knows what it's covered, what's queued, and what's been published.
It doesn't repeat itself. It doesn't forget what it published six months ago. Your blog maintains an implicit editorial calendar that prevents saturation.
.blog-state/
├── config.yaml # your configuration
├── state.json # current state snapshot
├── analysis/ # cached pipeline results
│ ├── code-audit.json
│ ├── security.json
│ └── infra-cost.json
├── queue/ # drafts awaiting approval
│ ├── 2026-04-16-auth-migration.md
│ └── 2026-04-14-payment-refactor.md
├── published/
│ └── log.jsonl # append-only publish history
└── history/ # state.json snapshots
├── 2026-04-09.json
└── 2026-04-02.json
You stay in control.
Three publish modes. Choose how much you trust it. Start with draft
while you calibrate. Graduate to auto when you're confident.
Your editorial voice, your approval gate, your call.
# publish_mode options
draft → generates posts, saves to queue/,
does not publish. you review and
push manually when ready.
propose → shows you what it would publish,
waits for your approval before
pushing to scsiwyg.
auto → publishes immediately on each run.
posts appear in published/log.jsonl.
you review afterward.