B Pipeline

b-pipeline

A Claude Code plugin that drives a GitHub issue all the way to a merged pull request — triage → isolated worktree → build → screenshots → commit → draft PR → code review → gated merge — by chaining a set of small, focused skills.

It is built for SvelteKit projects (Remote Functions, Svelte 5 runes, Drizzle, shadcn-svelte) and keeps a human in the loop at the points that matter: nothing complex gets built, and nothing ever merges, without a person saying yes.

Throughout this plugin, "task" = GitHub issue. The two terms are used interchangeably.

Table of contents

1. What it does
2. How it works (mental model)
3. Prerequisites
4. Installation, step by step
5. Quick start
6. The skills at a glance
7. The pipeline, step by step
8. Orchestrators and their flags
9. Human gates
10. Labels the pipeline uses
11. Artifacts it produces
12. Safety features
13. Recovery and idempotency
14. Using individual skills
15. Troubleshooting

1. What it does

You give it an issue number. It:

1. Triages the issue (labels it, evaluates complexity, asks for missing info).
2. Creates an isolated git worktree so your main checkout is never touched.
3. Builds the feature screen by screen, verifying each one in a real browser.
4. Commits with conventional-commit messages.
5. Opens a draft PR with release notes, technical changes, and screenshots.
6. Runs an automated code review across five areas.
7. Waits for a human approval, then merges, closes the issue, and cleans up the worktree.

It runs unattended where it is safe to do so, and stops and asks where judgement is required (complex builds, every merge).

Don't have the issues yet? Start one step earlier with b0-conversation-to-issues: it turns the current conversation (a design chat, a brainstorm, a plan) into well-scoped GitHub issues, sliced vertically (tracer-bullet), ordered by dependency, and grouped under an epic — the exact shape b10-ship --epic drains. It verifies what you really want before creating anything. You can even invoke it with nothing but a raw idea: design mode interviews you one question at a time (recommended answer included, codebase facts looked up instead of asked), keeps a living design doc in docs/plans/, and only converts to issues once the plan converges.

2. How it works (mental model)

A few ideas explain the whole design:

• Orchestrators chain atomic skills. The big skills (b10-ship, b7-issue-to-pr, b8-swarm) do not implement anything themselves — they decide and call the small skills (b1-triage-issue, b1-add-worktree, b2-build-feature, b3-git-commit, b4-pull-request, b6-pr-review, b9-close). The value is the orchestration, the budgets, and the gates.
• State lives in GitHub, not on disk. Labels, sticky comments with hidden markers (e.g. <!-- b7:status -->), and PR review verdicts (<!-- b6:verdict=... -->) are the source of truth. This is why the pipeline is idempotent: re-running the same command reconciles state from GitHub and resumes where it left off (see §13).
• Isolation by worktree. Every feature is built in its own git worktree on its own branch, with its own dev-server port. Your main working tree is never edited.
• Screen-first builds. Features are decomposed into screens (Feature-Sliced Design). Each screen is built, then visually verified in your real Chrome before the PR is opened. The outcome is never silent: a b7:screen-review= marker on the PR and a screens= token on the run's status line always say whether it ran, passed, or was skipped (and why) — see §7 and §11.
• Budgets and backpressure. Runs are bounded (max iterations, max changed files) and the pipeline refuses to pile up work (it will not start if too many bot PRs are already open).
• Delegation, not bypass, at scale. Every automated shortcut (epic auto-merge, batched approvals, parallel builds) re-derives its own evidence at the moment it acts instead of trusting a flag — see §9.

3. Prerequisites