[ Open source ]

Give every contributor’s agent the rules your regulars already know.

New contributors, and the agents writing their pull requests, see your code and a CONTRIBUTING file. They don’t see your decisions, your accepted RFCs or what you’ve already turned down, so they meet those rules for the first time in review. A public Bench47 workspace lets their agent read them first.

[ The contributor loop ]

Your rules reach the pull request before you do.

  1. 01

    They find your workspace

    The badge in your README, or the repository address, leads to your public workspace. An agent can check any repository for one with a single request, without an account.

  2. 02

    Their agent reads your rules

    It reads your workspace guide first, then the contributing rules, decisions and RFCs that bear on the change, as Markdown, llms.txt or over a read-only MCP server.

  3. 03

    The pull request follows them

    The change targets the right branch, cites the RFC it depends on and leaves out what you already declined, with the documents it followed named in the description.

  4. 04

    Your agents review against the same rules

    Your maintainers’ agents already read and write this workspace, so the contributor’s agent and the reviewer’s agent work from the same page.

README badge: contributing with AI? Use Bench47
The badge for your README. It links to your workspace through bench47.com/gh/{owner}/{repo}, so contributors and their agents always find the current address.

[ For maintainers ]

One workspace, read by your agents and everyone else’s.

Readable without an account

Anyone reads a public workspace at bench47.com/p/{org}/{workspace}/: web pages for people, and llms.txt, raw Markdown, search and records for agents.

A read-only MCP server

Each public workspace has its own MCP address that Claude Code, Codex, Cursor and other agents connect to with no sign-in. It can read and search, never write.

Linked to your repository

Prove the link with the Bench47 GitHub App or a one-line .github/bench47.yml. Then bench47.com/gh/{owner}/{repo} always points at your workspace, and a weekly check keeps the link honest.

Your members still write

Your team edits the workspace as before, with history and trash. Everyone else can only read.

Typed collections stay queryable

RFCs, decisions and roadmap items kept as records can be filtered and sorted by a contributor’s agent, the same way your own agents query them.

Search engines can find it

Each public workspace has its own sitemap. Bench47 doesn’t list public workspaces anywhere; people reach yours through your badge, your links and search.

[ What becomes public ]

Your documents are public. Everything around them isn’t.

Visibility is set per workspace, never per document, and only an owner or admin can change it. Keep secrets, security reports and private conversations in a private workspace.

Anyone can read

  • Markdown documents and their frontmatter
  • Workspace guides and collection schemas
  • Collections and their records
  • Search over the documents

Never leaves your org

  • Stored files
  • Version history and trash
  • The audit log
  • Due dates, locks, schedules and Dispatch jobs

[ The Open Source plan ]

Free, with no limits, for admitted projects.

Public workspaces are on every plan, Free included. Projects that keep one linked to their repository can apply for the Open Source plan: every limit lifted and Enterprise’s features, never billed. A person on our team reviews each application.

Unlimited
No caps on seats, workspaces, documents or the rest of the plan limits.
Enterprise features
API keys, the audit log and export, admin controls, temporary inboxes and Dispatch.
Who can apply
An owner or admin of an organization with a public workspace whose repository link is verified.
Staying on it
The plan is never withdrawn automatically. Keep the public workspace and its link, and it stays.

[ Get started ]

Three steps, all in the dashboard.

  1. 01

    Make a workspace public

    An owner or admin turns on Readable by anyone in the workspace’s Settings → Public card, and adds a title and description. Make a workspace public

  2. 02

    Link your repository and add the badge

    Prove the link with the GitHub App or a .github/bench47.yml file, then paste the badge snippet from the same card into your README. Link a repository

  3. 03

    Apply for the Open Source plan

    From your organization’s Billing settings, pick the workspace and say what the project is and who uses it, in up to 500 characters. About the Open Source plan

[ Questions ]

A few practical questions.

Do contributors need a Bench47 account?
No. Their agent reads the workspace over plain HTTP or the read-only MCP server, with no sign-in. Their own Bench47 connection, if they have one, is separate.
Do I need the Open Source plan to make a workspace public?
No. Every plan can make a workspace public. The Open Source plan removes the limits and adds Enterprise’s features for projects we admit.
Can I make just some documents public?
No. Visibility is per workspace. Keep anything private, such as security reports or maintainer discussions, in a separate private workspace.
What if I make it private again?
An owner or admin can switch it back at any time. Public addresses stop answering within about five minutes, while cached copies expire.
Is there a directory of public workspaces?
No. Bench47 doesn’t list them. Contributors reach yours through your badge, the bench47.com/gh/ address for your repository, links you add, and search engines.
Does this work on a self-hosted install?
No. Public workspaces and the Open Source plan are part of the hosted service only.

Maintain an open-source project?

Make a workspace public on any plan, link your repository, then apply for the Open Source plan to use Bench47 free with no limits.