What WeaveSpec is and what it refuses to do

Most tools that touch a codebase describe themselves by what they generate. That is the least interesting half. If something is going to read every repository your product lives in, the first question is not what it produces — it is what it is allowed to do while it is in there.

So the short version, boundaries first.

What it is

WeaveSpec connects several GitHub repositories into one project, analyses them together, and generates the cross-repo documentation and tasks that a feature needs before anyone starts building it.

A project is the tenant boundary: repositories, members, integrations, documents and history all live inside it, and nothing crosses between projects. You connect the repositories that make up one product — the web client, the API, the mobile app, the worker, the infrastructure — and from that point on they are read as a single system rather than five unrelated codebases.

From a feature request written in plain product language, the output is a product requirements document, a technical design document, the list of affected repositories, the API and data model changes implied by the request, test scenarios, risks and dependencies, and — after a human approves it — Jira epics, stories and tasks.

Underneath that is a repository intelligence layer: an inventory of every file, extracted symbols and routes, per-module summaries, a graph of how services call and consume each other, and a search index over all of it. The documents are a view of that layer, not a one-shot prompt.

What it refuses to do

These are not features that have not been built yet. They are boundaries the product is designed around, and several of them are enforced below the application — at the GitHub permission level or in the database, where the app cannot talk its way past them.

• It does not change your code. The GitHub App is installed with read permissions. There is no write path to your repositories, so there is no version of a bug that ends with a commit you did not make.
• It does not open pull requests. Not drafts, not "for your review". The output is a document a person reads, not a branch a person has to close.
• It does not write to Jira without approval. Issues are previewed in full — hierarchy, types, fields — and created only when someone with the authority to approve says so. Approval is a separate permission from editing, precisely because it is the step that reaches outside the product.
• It does not touch production. No environments, no runtime access, no logs. It reads a repository at a pinned commit and nothing else.
• It does not analyse your secrets. Secret files and credentials are outside what gets read and indexed.
• It does not estimate. No automatic story points, no generated timelines. A model that has never met your team has no business claiming how long anything takes.

There is a pattern in that list. Everything it refuses is an action that changes the state of a system somebody else is accountable for. Everything it does is reading, and then writing something a human decides what to do with.

Why the boundary is the product

The obvious objection is that these limits make it less useful. Let the thing open a pull request and you have saved a step.

That trade is worse than it looks. A tool that only reads can be wrong in exactly one way: it tells you something inaccurate, and you notice while reading. A tool that writes can be wrong in every way the system can be wrong, and you find out later, in a place you were not looking. The review cost of a generated pull request lands on the engineer who has to reconstruct the intent behind it — which is the work you were trying to remove.

There is also an adoption reality. The person who benefits most from cross-repo analysis is usually a product manager. The person who has to approve the tool's access is usually not. That conversation goes very differently when the answer to "what can it do to our repositories" is "read them".

So the claims in a generated document are anchored to evidence instead: a file path, a commit, a line range. The product manager does not need to open any of them. The tech lead who is sceptical of the document does, and can check it in under a minute. Verifiability is what makes a generated document arguable rather than merely plausible, and a document nobody can argue with is a document nobody trusts.

Where it is today

WeaveSpec is pre-launch and running as a closed early access group — invited accounts, fixed quotas, no self-serve signup and no billing yet. Some of what is described above is live, some is being built against the specification it was designed from. We would rather describe the shape honestly than imply a finished product.

The bet underneath all of it is small enough to state in one sentence: the reason cross-repo specs are painful is not that writing is hard, it is that reading five repositories together is work nobody is assigned. Automate the reading, keep the deciding where it belongs, and refuse everything in between.