building-in-the-open v1.0.0
What’s New
Ask an AI agent to write three documents in the same session. You’ll get three different voices, three different quality levels, and zero consistency. That’s the problem.
building-in-the-open is a Claude Code plugin that fixes it. Four writer personas. Eight skills. One tone firewall. The rule is simple: if you wouldn’t say it at a technical conference, it doesn’t reach the repo.
4 writer personas — Technical Writer, Context Curator, Doc Writer, Marketing Copywriter. Each one has a distinct voice, calibration examples, and a do/don’t table. Personas compose — a README gets Marketing Copywriter above the fold and Doc Writer below. A changelog gets Technical Writer for the entry and Marketing Copywriter for the release announcement. Same changes, two voices, one skill invocation.
8 skills for the artifacts that emerge during building: ADRs, design docs, handoffs, changelogs, end-user guides, plus a routing skill, an onboarding interview that generates your .bito.yaml config, and an editorial reviewer that acts as the tone firewall.
Quality gates powered by bito-lint — token counting, readability scoring, completeness checking, path-based rules. Define what checks run on what files in your config, then bito-lint lint <file> runs all matching checks in one pass. Deterministic tools for measurement, agents for judgment. Each does what it’s good at.
Plugin hooks run quality checks in real time as your agent writes, not just at commit time. The SessionStart hook announces available writer personas. The PostToolUse hook lints every markdown file on write. Belt and suspenders.
Getting Started
claude plugin add claylo-marketplace/building-in-the-openInstall the quality gate tooling (optional but recommended):
brew install claylo/brew/bito-lintVerify: bito-lint doctor
Then ask Claude to write a handoff, an ADR, or a design doc. The skills activate automatically based on what you ask for. Every skill announces itself and its persona — so you always know which voice is active and why.
How We Built This
The plugin itself has been in development since early February — five phases of incremental work, each one producing real artifacts that were immediately used to test the personas and quality gates. ADR-0001 was written through the Technical Writer persona before anything else existed. The handoff at the end of each phase was written through the Context Curator persona. Eating our own cooking from day one.
The 1.0.0 release prep was a cleanup and modernization pass. The original skill names (writing-adrs, handoff) were renamed to things that better describe what they do (capturing-decisions, curating-context). The design doc skill got split into with-superpowers and without-superpowers variants so it works standalone — not everyone has the superpowers plugin installed, and burning context loading skills that don’t exist is worse than useless.
The quality gate story evolved significantly. Early versions used a justfile with hardcoded per-type check logic — just lint-handoffs, just lint-adrs, each one a bash loop calling individual bito-lint subcommands. With bito-lint v0.3.0 shipping path-based rules and config discovery, all of that collapsed into bito-lint lint <file>. The config is the single source of truth now. The justfile got deleted the same day.
The pre-release sweep caught what you’d expect from a project that renamed things mid-stream: persona calibration examples referencing old skill names, an ADR example title mentioning tiktoken-rs (removed months ago in favor of pluggable tokenizer backends), and a quickstart section telling people to run just lint-docs against a justfile that no longer existed. Embarrassing stuff — exactly the kind of thing this plugin is supposed to prevent. At least we caught it before anyone else saw it.
The onboarding skill was a late addition — a brainstorming-style interview that walks you through configuring quality gates for your project. One question at a time, multiple choice where possible, pre-fills answers from existing config and docs. The output is a .bito.yaml file. It’s the friendliest on-ramp we could design for a tool that has a lot of knobs.