OpenSpecsCross repository blast radius and AI code verification for your whole codebase. ByteBell builds a verification layer over up to 10 million files, so agents understand what your code actually does and you can see every repository, service and team a change reaches, including dependencies that cross q Installation Launch VS Code Quick Open ( Ctrl+P), paste the following command, and press enter.Copied to clipboard |
OpenSpecsRead the verified spec for any file, right inside VS Code, then hand it to your AI. Your agent writes code faster than anyone can check it. OpenSpecs is the window into ByteBell's verification layer, which reads your entire codebase once and records what every file actually does. Open any indexed file and read its spec without leaving the editor, then send that spec to your copilot so it starts from real intent instead of guessing.
Why a verification layer rather than more retrievalEvery other tool in your editor answers the question of what looks relevant to your prompt. None of them holds an opinion on whether the code is correct, because none of them ever established what correct means. A verification layer does exactly that. ByteBell reads each repository once with cost efficient open source models and records the intent, the dependencies and the business rules as one connected graph across every repository you own. That layer is what makes cross repository analysis possible, and it is what turns blast radius from a guess into a lookup. OpenSpecs is how you read it from the place you already work. The three tabs
Built for the person who currently spends weeks finding out what a feature touches. Enter the product requirement in plain English. The pipeline runs twelve stages and comes back with the user stories, the specification, the affected files and owning teams across every enterprise repository, the data flow, the test cases, and working code with an HTML design of the feature itself. The point is not that a machine writes the plan faster. It is that every line of that plan is grounded in the code you actually run, so the file list is a reading of your system rather than an educated guess from a roadmap document.
Check whether code is correct whenever you want, rather than only when a pull request opens. Point it at a file, a branch, a diff or a whole change and it checks that code against the verification layer. It reports what contradicts the stated intent of the code being modified, what violates a rule the rest of the organisation depends on, and what the change reaches beyond the repository you have open. This is pull request review without the pull request. You can run it on code an agent just wrote, on a branch that is not ready to open yet, or on something a teammate handed you an hour ago.
The two questions worth asking before you change anything. Upstream tells you who depends on this code and who your change is about to affect. Downstream tells you what this code stands on and what could break underneath it. Both traversals cross repository boundaries, so they catch the dependencies that travel through a queue, an event, a shared schema or a call to a service another team owns. Import resolution inside one repository cannot see any of those, and that is precisely where production breaks. This holds at real enterprise scale, so an organisation running a thousand repositories can analyse a change across all of them rather than across the one that happens to be open. Try it without indexing anythingWe have already indexed a set of open source repositories from the React ecosystem, including React, Redux, xyflow and TanStack Table. Clone any of them, open a file, and read its spec within a minute of installing. There is nothing to connect and no indexing run to wait on, so you can judge the output before you point us at your own code. When you are ready to use it on your own repositories, your first 500 files are analysed free. That is enough to cover a real service rather than a toy project, which is the only way to tell whether the specs are actually useful to you. Quick start
How it worksByteBell reads every repository once at index time using cost efficient open source models. An agent pipeline detects the boundary of every class and function, analyses each one against its file, its module, its repository and every other repository you have indexed, then stores the result as a graph with a specification layer on top. There are no vector embeddings anywhere in the pipeline. OpenSpecs queries that graph over MCP and renders the spec for whatever file you have open. Because the expensive reading already happened once during indexing, your copilot receives precise context for a fraction of the usual token cost, and it receives the same context every time rather than a different retrieval result on every prompt. Blast radius and cross repository analysisThe same layer answers the two questions that matter before you change anything. Walking the graph backwards gives you upstream analysis, meaning who depends on this code and who your change is about to affect. Walking it forwards gives you downstream analysis, meaning what this code relies on and what could break underneath it. Those traversals cross repository boundaries, so they catch the dependencies that travel through a queue, an event, a shared schema or a call to a service another team owns. A tool scoped to one repository cannot see any of those, and that is exactly where production breaks. Run blast radius and pull request checks on the ByteBell platform, and read the specs behind them here. Requirements
CommandsOpen the Command Palette and type OpenSpecs to see everything available.
ConfigurationOpenSpecs needs no setup at all. The ByteBell instance URL is baked into the build at compile time, since maintainers set PrivacyYour source code stays inside your own environment at all times. ByteBell indexes your repositories on infrastructure you control, and OpenSpecs only reads the resulting specs over MCP. Nothing about your code is sent to a third party for this extension to function. How well it worksWe indexed forty six repositories from the Kubernetes ecosystem, covering more than two hundred thousand files, and measured the result. The layer held accuracy above 93 percent across that set, answered questions for roughly 80 percent less token cost, and made AI generated changes measurably more accurate, all while running on open source models. Feedback and supportIf you find a bug or have an idea worth building, open an issue on our repository or reach the team through the ByteBell platform. We read every report, and feedback from real workflows shapes what ships next. Links
|
