Enable a test-loop, review-agent or spec-driven flow in one click — fit-gated to each repo, so nothing lands where it doesn't apply.
baselane team · Jun 10, 2026 · 5 min read
A pack is the unit of everything baselane distributes: a versioned, validated bundle that turns on a specific way of working with AI tools — a test-first loop, a review-agent that checks diffs before a human does, a spec-driven flow that makes an agent write a plan before it writes code. You don't hand-assemble one. You pick it from a catalog, and baselane decides whether it fits the repo before it ever proposes anything.
Under the hood a pack is a structured, schema-validated object — instructions, file templates, and the rules for how those templates merge into a repo's existing AGENTS.md, CLAUDE.md, or tool-specific config. Every pack, whether it's one of ours or one your team authors, passes through the same validator before it can be stored or rendered. There's no hand-constructed exception path. If a pack doesn't validate, it doesn't ship.
That uniformity is what makes packs composable. A repo can run a test-loop pack and a review-agent pack at the same time without their instructions colliding, because both were written against the same schema and rendered through the same pipeline.
Generating a plausible-looking config for a repo is not the hard problem — plenty of tools do that today. The hard problem is knowing when not to. baselane runs a lightweight static analysis over a repo — languages, frameworks, existing test and build commands — and uses that profile to decide which packs are eligible before anything gets proposed. A Vitest-based pack doesn't show up as a one-click option in a repo that runs pytest. A pack that assumes a monorepo build graph doesn't get offered to a single-package library.
"The one-click part is easy. The part where it only offers what actually fits your repo — that's the part we spend our engineering time on."
Turning on a pack for a repo doesn't push anything invisibly. It opens a PR against that repo, containing exactly the files the pack changes, with a description of what it does and why it was offered. Someone on the team reviews it like any other PR. It merges, or it doesn't, or it comes back with review comments the pack author didn't anticipate. Nothing about "fit-gated" and "one click" changes that baseline: the human stays in the loop, every time.
Packs carry a version. When we (or your org's platform team, for internally authored packs) ship an improved test-loop pack, repos already running the previous version see it as an update PR, not a silent replacement. You can see exactly what changed, adopt it on your own timeline, and roll it back the same way you'd roll back any other change — because it's just files in your repo, reviewed the same way everything else is.