OpenBuildRoom

OPENBUILDROOM DESKTOP · YOUR LOCAL PRODUCT WORKSPACE

Your control room for the software your agents build.

Watch your app take shape. Start services, inspect data and logs, run tests, and guide what your agents build next.

Explore the interactive demo See each feature
Atlas/ OpenBuildRoom INTERACTIVE EXAMPLE
OVERVIEW / ATLAS WORKSPACE

Everything at a glance.

One starting point for product progress and the running app.

Overview
RUNNING SERVICES0 / 3Web · API · MCP
RECORDED CHECKS0 / 4Last simulated run
OPEN BACKLOG03Stored with the repo
SPEC KIT TASKS3 / 4Order lookup feature
DEVELOPMENT ENVIRONMENT
▷Web appStopped
▷API serviceStopped
⬡MCP serverStopped
NEXT TO REVIEWFR-001 · Find an order by ID

Three tasks complete. The final task checks the response against PostgreSQL.

Open Requirements to follow the link.
01 / OVERVIEWStart with the whole product.Play the guided walkthrough or open any view yourself.

Explore the desktop navigation through one example workspace. Tour actions are simulated; the desktop app operates your real local repository.

FOR PRODUCT OWNERS

Shape what gets built.
Follow what gets done.

Keep the why, the next steps, and the evidence together in the repository. Your coding agent works from the same product context that you can inspect in OpenBuildRoom.

Product directionSpec KitCoding agentRunning evidence
01 / FOLLOW

Progress overview

Return to one dashboard for declared services, recent tests, open work, and progress read from Spec Kit tasks.

02 / DEFINEOptional view

Vision

Write the product purpose in a Markdown document the team and agent can revisit. Enable this view when you have a vision to show.

03 / PRIORITIZEOptional view

Roadmap

Turn product milestones into a shared plan. Link them to components and show their declared status as the work moves forward.

04 / MEASUREOptional view

North Star

Choose one product outcome, set a target, and record observations over time. The chart plots values entered by the team.

05 / DECIDE

Backlog

Capture requests as Markdown issues with status and priority, then link them to specs. GitHub and Linear can be referenced; live sync is still planned.

06 / PRESERVE

Documentation

Read and edit product documentation in the project folder. Keep decisions and onboarding notes alongside specifications and code.

Vision, Roadmap, and North Star are optional views. Add them through workspace settings or productview.yaml when the project has real content.

RUN & VERIFY

Look inside the software.
Check what actually works.

Go from product progress to the running system. Inspect the services, tests, tools, data, and files behind each release.

Available in the desktop preview / Interface previews illustrate the workflow. Planned capabilities are marked.

01 / UNDERSTAND

Project Map

See the real services, databases, storage, and persistent processes that make up your local system.

02 / OPERATE

Services & logs

Start and stop configured local services, check their state and ports, and read the output when something fails.

03 / VERIFY

Test runs

Run a suite or individual discovered tests and inspect the result and output without hunting for commands.

04 / EXPLORE

MCP Explorer

Connect project MCP servers, browse their tools, resources, and prompts, then try a tool deliberately.

05 / EXPLORE

CLI Explorer

Discover local command-line tools, read their commands and options like a friendly manual, and run trials.

06 / INSPECT

Database & storage resources

Collect every configured project source in one place. Inspect supported databases and local files with limited, read-only previews.

07 / CONFIGURE

Environment variables

See every variable declared for the workspace and its components. Set encrypted local values without putting secrets in YAML or Product Chat.

08 / TRACE

Spec Kit & requirements

Read existing specs, plans, tasks, and project rules; follow the progress of work stored with the code.

09 / BROWSE

Workspaces & files

Switch local repositories and browse their source trees, with folders collapsed until you open them.

10 / CONTINUE

Product Chat

Ask a local coding agent about the project, its tools, and next steps. Type or dictate in the desktop app.

11 / REVIEW

Activity history

See recorded starts, test runs, agent connections, and project changes so the next session has context.

12 / MONITORPlanned

CPU, memory & disk

Historical resource trends for local services and workspaces are planned. The current app shows service state and output.

THE PROBLEM

The first prompt is quick.
The next six months need a system.

What outcome are we building toward?

Which feature is next, and why?

What did the agent actually finish?

Do the app, tests, and data support the claim?

A product owner needs a view across decisions and delivery. OpenBuildRoom keeps product direction, Spec Kit work, and the local system together, so you can steer the agent and return later without reconstructing the project from old chats and shell history.

THE LOCAL CONTROL ROOM

One clear view
across your projects.

Switch between local repositories and find the same starting points each time. OpenBuildRoom sits beside your editor, terminal, and cloud deployment dashboard.

01 / DIRECT

Keep product intent visible.

Bring vision, roadmap, outcome, backlog, Spec Kit requirements, and documentation into the same workspace the agent uses.

VisionBacklogSpec Kit
02 / OPERATE

Run and debug locally.

See configured services, commands, ports, and required environment variable names. Start and stop local processes, check status, and read output.

ServicesCommandsLogs
03 / VERIFY

See what is true.

Run tests, inspect local data sources with limited read-only previews, and review activity as the product changes over time.

TestsDataActivity

You set the product direction. Your agent builds.
OpenBuildRoom lets you follow the work and verify the software.

A DISCIPLINED BUILDING LOOP

From product direction
to software you can maintain.

Give the agent durable product context. GitHub Spec Kit structures requirements, plans, and tasks. OpenBuildRoom reads that work alongside the running system so each iteration can be reviewed.

01

Set the product direction

Describe the users, problem, vision, next milestone, and desired outcome. Keep product documents and backlog items in the repository so the agent can refer to them later.

02

Specify the work

Ask Codex or Claude Code to use GitHub Spec Kit for project rules, feature specs, technical plans, and tasks. OpenBuildRoom reads those existing files.

03

Map what gets built

Have the agent inspect real commands and propose productview.yaml with services, tests, data sources, and verified links to requirements. Review the configuration.

04

Operate, verify, and continue

Start services, inspect logs and data, and run tests. Update roadmap status and documentation when behavior changes; commit the shared setup for the next session.

HOW TO INSTALL & START

From a new idea
to a visible product.

Start with a brief for your coding agent. Put product direction and structured delivery in the repository, then open it in OpenBuildRoom to follow the work.

02

Try the working example

Click Try working example in the app. Start its service, run the tests, and inspect its data and Spec Kit feature. Node.js 20+ is needed for the example commands.

03

Give your agent the OpenBuildRoom guide

Open the agent guide and YAML schema in the public repository, then give the link and the short prompt to Codex or Claude Code. The agent can read the contract and set up your project.

Agent guide YAML schema
04

Open your own project

After the agent has created and checked productview.yaml, choose the repository folder in the desktop app. Review product direction, specs, map, services, tests, and data sources.

STARTER PROMPTFOR CODEX OR CLAUDE CODE

Build with Spec Kit and OpenBuildRoom Desktop.

Fill in your idea and paste this into Codex or Claude Code.

Build [my app idea] for [my audience] with Git, GitHub Spec Kit, and OpenBuildRoom Desktop: https://github.com/OpenBuildRoom/desktop

Read its agent guide and YAML schema, ask me the essentials, and set up the repository so I can open it in the desktop app.
Ready to paste into your agent
USEFUL LINKSGitHub Spec Kit GitHub Skills Learn Git & GitHubInstall Git for macOS

Open source on GitHub: OpenBuildRoom/desktop ↗ · MIT licensed.

A CONCRETE EXAMPLE

A small file.
A repeatable way back in.

This is the part your team commits with the code. It points OpenBuildRoom to product documents, existing Spec Kit files, and verified local commands. It does not copy your application into another platform.

01

Keep direction visible. Vision, roadmap, and North Star sit in the repository and appear as optional product views.

02

Start the app. The service card runs the command declared in the repository.

03

Check the work. The suite appears on the Tests page with its actual command one click away.

04

Keep secrets local. The YAML names DATABASE_URL; each developer sets the value on their own machine.

productview.yamlSIMPLIFIED EXAMPLE
schemaVersion: 1
project:
  id: atlas
  name: Atlas

workspace:
  additionalViews: [vision, roadmap, north-star]

product:
  vision: docs/vision.md
  docsRoot: docs
  roadmap:
    - id: launch
      title: First usable release
      status: in-progress
  documentation: []
  northStar:
    name: Weekly active teams
    unit: teams
    cadence: weekly
    target: 100
    measurements: []

views:
  specifications:
    roots: [specs]

components:
  - id: web
    kind: service
    name: Web app
    position: { x: 15, y: 80 }
    runtime:
      command: [npm, run, dev]
      cwd: .
      port: 3000
      startup: manual

  - id: database
    kind: database
    name: PostgreSQL
    position: { x: 70, y: 80 }
    data:
      engine: postgres
      connectionEnv: DATABASE_URL

  - id: tests
    kind: testSuite
    name: Test suite
    position: { x: 15, y: 250 }
    tests:
      command: [npm, test]
      cwd: .

connections:
  - { from: web, to: database, label: uses }

YOUR CODING AGENT, IN CONTEXT

Keep talking.
Keep seeing.

Product Chat connects to a locally installed Codex CLI or Claude Code setup. Talk through a new feature, ask what changed, and let the agent help update specs and project configuration in edit mode. OpenBuildRoom gives you the documents and local runtime to inspect as the work progresses.

Review the agent’s edits before treating the map as accurate. Services and tests run only after you click Start or Run; environment values stay outside the repository.

Product conversationILLUSTRATION
I want a checkout flow. Specify it with Spec Kit, then show me what needs to run.
◇

I’ll draft the spec, plan, and tasks in the repository. Then I’ll propose the related services, data source, and test commands in productview.yaml for your review.

Ask about this project…↗

PRODUCT & DEVELOPER QUESTIONS

What OpenBuildRoom
actually does.

How do I steer the product as a product owner?

Keep your vision, backlog, roadmap, North Star definition, and documentation in the repository. OpenBuildRoom shows these beside Spec Kit work and the local app. Vision, Roadmap, and North Star are optional views you enable when they have meaningful content.

Does it replace my terminal or editor?

No. It gives you a reliable entry point into the same local repository. Configured commands still run as real local processes, and the source stays in your editor.

Does it automatically know how every repo starts?

It can discover some project structure and tools. A coding agent can help draft the configuration, but you verify the commands, dependencies, and data sources before using them.

What happens to my Spec Kit files?

They stay in the repository. OpenBuildRoom reads existing .specify/ and specs/ artifacts, then lets you link verified requirements to components and test suites.

How does it work across projects?

Each repository keeps its own productview.yaml and product documents. The desktop app lets you switch local workspaces, so each project has a familiar place for its setup, tests, data, and activity.

How does it fit beside cloud deployment?

OpenBuildRoom focuses on the local development system. Your cloud platform still handles deployment and hosted operations. Direct Railway deployment is a future direction, not a feature of the current preview.

WHERE IT STANDS

A working desktop preview.
More to build.

OpenBuildRoom Desktop runs locally on macOS. The first Apple Silicon preview is available for download, alongside its source and agent guide.

AVAILABLE IN THE PREVIEW

Direct and inspect a local project

  • Vision, roadmap, North Star, local backlog, and Markdown documentation
  • Repository configuration, onboarding, files and Spec Kit reading
  • Project Map and manual service start/stop with output
  • Test runs, data previews, CLI and MCP explorers
  • Local Codex CLI or Claude Code chat and activity history
PLANNED, NOT SHIPPED

Make the view more complete

  • Long-term process and performance history
  • Stronger evidence linking requirements to behavior
  • Live issue sync and automatic outcome measurements
  • A reviewable path toward Railway deployment

OPENBUILDROOM

Start with an idea.
Keep building for years.

A clear framework for the work, and a local control room for the software that grows from it.

Get started