OPENBUILDROOM DESKTOP · YOUR LOCAL PRODUCT WORKSPACE

Your control room for the software your agent builds.

See the plan. Run the app. Check the tests. Know what’s happening as your product grows.

Explore the interactive demo See each feature

PRODUCT DIRECTION / LOCAL WORKSPACE

Know why this feature matters.

A product goal stays visible beside the work your agent does.

Direction

VISION · docs/vision.md

Make every order easy to find and trust.

One place to follow an order from request to verified result.

NORTH STAR · EXAMPLE12 / 100 teams

Weekly teams completing an order lookup

ROADMAP · FIRST RELEASE

Define order lookupDone

Build and verify lookupIn progress

Team handoffNext

NEXT DECISION1 open item

Review the order lookup against its requirement.

PV-024 · Verify order details

01 / PRODUCT DIRECTIONStart with a product goal.Play the guided story or open any step yourself.

Follow one example order from product goal to test result. This tour simulates actions; 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 / FOLLOWPrototype

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 prototype plots values entered by the team.

05 / DECIDEPrototype

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 / PRESERVEPrototype

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 prototype / Interface previews illustrate the workflow. Planned capabilities are marked.

01 / UNDERSTANDPrototype

Project Map

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

02 / OPERATEPrototype

Services & logs

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

03 / VERIFYPrototype

Test runs

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

04 / EXPLOREPrototype

MCP Explorer

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

05 / EXPLOREPrototype

CLI Explorer

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

06 / INSPECTPrototype

Database & storage resources

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

07 / CONFIGUREPrototype

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 / TRACEPrototype

Spec Kit & requirements

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

09 / BROWSEPrototype

Workspaces & files

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

10 / CONTINUEPrototype

Product Chat

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

11 / REVIEWPrototype

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 prototype currently 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.

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.

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.

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.

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.

Install OpenBuildRoom Desktop on your Mac

Download the Apple Silicon macOS preview. Unzip it, move the app to Applications, and open it. This preview is unsigned and not notarized.

Download for macOS Apple Silicon · 0.9.48

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.

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

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 & GitHub Install 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.

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

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

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

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 prototype.

WHERE IT STANDS

A working desktop prototype.
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 PROTOTYPE

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