CyberTycoon

Vibe To Ship — Development skill for Claude Code

Development community

Productionized graph engineering for everyday vibe coders — a drop-in agent skill (Claude Code + opencode) that designs how a hundred jobs get done, then verifies they shipped.

How to install Vibe To Ship

This entry records only its repository, not the path inside it, so there is no exact command to give. Open CyberTycoon/vibe-to-ship and copy the folder into ~/.claude/skills/, or the file into ~/.claude/agents/.

What Vibe To Ship does

Productionized graph engineering for everyday vibe coders — a drop-in agent skill (Claude Code + opencode) that designs how a hundred jobs get done, then verifies they shipped. Optional OpenLotus memory superpower.

Alternatives in Development

Ic Memo — 投委会备忘录 — 8 章节结构化决策文档（含三情景回报 + Top 3 风险） 6.6k ★
Content Shipped — Proactively detect and log shipped content when user mentions publishing, launching, or completing work 1k ★
Overnight PRs — Autonomous overnight loop — verify issues against the codebase, close stale ones, ship PRs through /ship (bug 324 ★

README

vibe-to-ship

Your agent doesn't need more prompts. It needs a graph.

![The Diamond — fan out, reduce, verify, synthesize](assets/diamond-flow.svg)

`vibe-to-ship` is a single skill that gives any coding agent — Claude Code, opencode, Codex, Cursor — the discipline to ship like a team. No new chat, no extra dashboard. Just a way to turn a messy repo into a working plan and make it real.

Works with or without [OpenLotus](https://www.openlotus.io) — standalone when you want speed, supercharged when you want memory.

The problem it solves

Single-agent vibe coding collapses after ten files. It forgets what you asked, claims `All tests pass` without running anything, and stalls.

Throwing five agents at it is worse. They talk over each other, edit the same `page.tsx` at the same time, and politely agree with each other's mistakes.

`vibe-to-ship` replaces both with a graph. One node is one agent doing one job, with a clear contract for what goes in and what comes out. If two nodes don't actually need each other's output, they run at the same time. If they do, a fresh pair of eyes checks the work before it ships.

That is graph engineering. It is the difference between prompting and designing.

In 30 seconds

# 1. Drop it in
cp -r vibe-to-ship ~/.claude/skills/      # or .opencode/skills/

# 2. Ask your agent
"Run vibe-to-ship triage on this repo"

You get back a short, honest triage — **High / Watch / Noise** — and a plan you can trust. No files changed until you say go.

Prefer pointers?

High   — fix today, blocks the next move
Watch  — worth tracking, not urgent
Noise  — looked at, safely ignored

What your agent actually does (5 beats)

**Boot** reads the guardrails (`.env`, secrets, payments are off-limits) and checks the budget. **Triage** diffs what you *said* you'd do against what `git` *says* you did — branch, quiet days, dirty files, TODOs. **Act** fans out the real work into isolated git worktrees so parallel