Devkeep
Your code is your kingdom. Every kingdom needs a keep.
One shell, one login, six purpose-built tools — and a living document at the center that every one of them actually reads. We're looking for a few developers and QAs to put it through its paces before anyone else sees it.
↓ Scroll for the walkthrough
It's not a missing tool. It's tools that don't talk to each other.
Most of what slows a team down isn't any single broken thing — it's the seams between tools that weren't designed to know about each other.
Your docs don't know when your code changes.
Nothing connects the wiki to the repo — so the page and the codebase drift apart, and nobody finds out until someone trusts the wrong one.
Your secrets don't know who's still on the team.
An API key set up in a spreadsheet three projects ago outlives the person who made it, because nothing connects your secrets to your roster.
Your reviewer never saw the product doc.
A pull request can pass every check and still undo a decision made two months ago, because the review tool and the decision log have never talked.
Nothing independent ever looks at it twice.
The tool that wrote the code and the tool that reviewed it share the same context — and nothing in the stack exists to check either one from the outside.
One keep. Six keepers. One set of keys.
Devkeep is one interface you open, not six tabs you juggle. Sign in once, link a project once, and call on whichever keeper you need — the way you'd call on any specialist on a team you already trust.
Every tool reads the same page.
At the center of every linked project is one file: docs/PRODUCT.md — a living record of numbered requirements and dated decisions, written by whomever owns the project. It's the thing Devkeep is built to read, and that Devkeep actively maintains.
Meet the keepers.
Scribe
“Every decision gets a record.”
Generates and maintains living documentation — architecture notes, decisions, requirements, release notes, and a QA test plan. A chat interface for asking your own codebase questions. Regenerates only what actually changed.
Crypt
“Every system has its secrets.”
Team secrets, APIs, URLs — all vault-backed and KMS-anchored, with real per-project access control. Not a shared .env file, not a random spreadsheet.
Scout
“Daily news from beyond the walls.”
A daily technical-reading digest scoped to your own stack — the one module that looks outward at the industry instead of inward at your repos. A chat interface to tune the results to your interests.
Seer
“The view from the throne.”
Team access management and a GitHub control board for account admins and owners. Keep an eye on access, releases, commits, and spend.
Judge
“The clearest view is from the outside in.”
An unattached outside auditor with zero prior context — explores a whole repo cold and produces a real, evidenced report, on demand.
Ward
“Nothing gets in unwatched.”
An ensemble of independent AI reviewers — each with its own mandate — evaluates every pull request before it merges, citing your own product doc while doing it.
We didn't wait for testers to find the first bugs.
Ward and Judge have already been turned loose on Devkeep's own code — including on each other. A few of what they found, before anyone outside got a look:
A vault write path with no real check on the destination
Found & fixedWard's security lens, reviewing a sibling module, caught a route that let any signed-in caller name which vault a write landed in — latent while one person runs one vault, live the moment it's shared. Fixed before it shipped to more than one person.
Judge's first cold read of an unfamiliar codebase
Sound with concernsNo prior context, no hand-holding — pointed at a repo it had never seen and asked to audit it the way an outside consultant would. It came back with 33 real, evidenced findings and an honest verdict, not a rubber stamp.
A doc-parsing bug that made a module invisible to its own tools
Found in the wildA stray mention of a heading inside a sentence was enough to make the requirements parser stop at the wrong place — silently, and in the direction that looked like good news. Found through real use, not a spec review.
That's the level of scrutiny we want turned on your own repos next.
One requirement: your repos live on GitHub.
Devkeep scales down as easily as it scales up — a solo developer gets the same six tools a twelve-person team does, with nothing else to set up first.
It's built for how code actually gets written now: alongside an AI coworker, not instead of one. Every linked project ships with instructions that keep those agents honest about documentation as they work — so moving fast doesn't mean losing track of why the code is the way it is.
What we're asking, and what you get.
What we're asking
- Link a real project — or a throwaway one you don't mind poking at.
- Use it the way you'd actually use a tool, not a demo.
- Tell us what's confusing, what's broken, and what you didn't trust — the good notes and the blunt ones.
- QAs especially: try to break it. That's the point of an alpha.
What you get
- Full access to all six modules while they're free and still moving fast.
- A direct line to the person actually building it — not a support queue.
- A real say in what gets fixed and built next, while that's still cheap to change.
- An early, close look at how a product doc-driven suite like this actually holds up under real use.
Help us find what we missed.
A handful of spots are open in this round. If you're a developer or QA who likes finding the seams in something new, we'd like your eyes on this before anyone else's.
Email dev@starterculturestudio.comYour code is your kingdom. Every kingdom needs a keep.
Devkeep · Alpha program · 2026