FREE, OPEN-SOURCE MAC APP FOR AGENT-BUILT SOFTWARE

Your agent builds the app.
You keep the controls.

Build in Codex, Claude Code, Cursor, or your usual editor. Project Room opens the same repository and brings your running app, tests, data, and product plan into one place.

Download free for Mac Explore the interactive tour

Apple Silicon preview Runs locally on your Mac MIT licensed

ONE CONTROL SURFACE · SEPARATE LOCAL PROCESSES

One control surface for your local stack.

Your agent edits the repository. Project Room makes the product and the running software behind it visible and operable.

ATLAS REPOSITORY · INTERACTIVE SIMULATION

YOUR CONTROL ROOM

THE APP RUNNING LOCALLY

Project RoomOPENS THE SAME REPO

RUN & VERIFY / SERVICES

Run your project.

Start and inspect each local process from one place.

▣Web appStopped

⌁API serviceStopped

⬡MCP serverStopped

0 / 3 runningTests · Logs · Data ↗

Your coding agentCodex · Claude Code · Cursor

SEPARATE TOOL

YOU ASK“Add order lookup.”

AGENT UPDATES spec.md apps/api

Friendly robot representing your coding agent

One shared repositoryCode · specs · project config

Understand the systemThen take the controls

INTERACTIVE WORKSPACE TOUR

See the whole workspace. Then try it.

Follow a product from its plan through the connected services, data, and tests. Play the story or open any view yourself.

OVERVIEW / ATLAS WORKSPACE

Everything at a glance.

Development, quality, and product progress in one place.

Overview

RUNNING SERVICES · EXAMPLE2 / 3Web and API online

LATEST CHECKS · EXAMPLE3 / 41 check to review

OPEN BACKLOG03Order lookup · 2 next

SPEC KIT TASKS · SAMPLE3 / 4Order lookup feature

DEVELOPMENT ENVIRONMENT

▣Web app:3000 · v1.4.2Running

⌁API service:4000 · b8f12d0Running

⬡MCP serverv0.7.0 · c39e2a4Stopped

PERFORMANCESample signal · last 4 hours

LatencyCPUMemory

09:0010:0011:0012:00Now

P95 186 msCPU 18.6%Memory 384 MB

NEXT TASKS

PV-024 · Verify order lookupIn progress

FR-001 is built. Check the API response against PostgreSQL.

PV-025 · Add saved searchesFeature

PV-026 · Keep lookup under 200 msPerformance

TEST COVERAGEExample checks

75%3 of 4 sample checks passed

✓ Web responds✓ API health○ MCP lookup✓ Database read

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.

GET STARTED

From download to your first run.

Start with the included example. Then open a repository you already have and give its services, tests, and data a place you can see and control.

1. Download the Mac app

Get the free Apple Silicon preview. The desktop app and its source are open on GitHub.

Download free for Mac

2. Install and open it

Unzip, move the app to Applications, and launch it. Try the included example first; Node.js 20+ runs its example commands.

3. Open your own project

Open a repository. Let Codex or Claude Code help create .projectroom/project.yaml, then review it. Project Room reads the file and renders your services, tests, and data in a workspace you can run and inspect.

Agent guide ↗YAML schema ↗

Starting a new app? Copy the starter prompt

Give your next project the same setup.

For an existing repository, use the tailored prompt inside the desktop app. For a new idea, start here.

Build [my app idea] for [my audience] with Git, GitHub Spec Kit, and Project Room: https://github.com/OpenProjectRoom/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

Apple Silicon preview is unsigned and not notarized. View source and star on GitHub ↗

THE THREE REASONS TO OPEN IT

See the system.
Run it. Steer it.

Project Room brings the parts that disappear across terminals, browser tabs, and agent chats into one local workspace.

01 / SEE THE SYSTEM

Your project on one map.

See the services, databases, storage, and connections your app actually needs. Click through to the local component and its status.

Project MapComponentsData

02 / RUN & CHECK

Start it. Prove it works.

Start and stop local services, read logs, run tests, and inspect data in one place. You can see what ran and what passed.

ServicesLogsTests

03 / STEER THE PRODUCT

Keep the why beside the code.

Follow vision, roadmap, backlog, documentation, and GitHub Spec Kit requirements as your agent builds the next release.

VisionRoadmapSpec Kit

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 Project Room.

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 .projectroom/project.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 local services, read their output, and see the build timestamp, commit, optional version, and separate process start time when available.

View full demo screenshot ↗View full demo screenshot ↗

03 / VERIFY

Test Explorer

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 and resources, inspect build identity when provided, and try a tool deliberately.

05 / EXPLORE

CLI Explorer

Discover local command-line tools, read their options like a friendly manual, and identify the artifact build before running a trial.

06 / EXPLORE

API Explorer

Discover project OpenAPI files, register multiple HTTP APIs, send a request on purpose, and inspect status, timing, and response. Bearer tokens stay local.

07 / INSPECT

Data Explorer

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

08 / 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.

09 / TRACE

Spec Kit & requirements

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

10 / BROWSE

Workspaces & files

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

11 / CONTINUE

Product Chat

Keep coding in Codex, Claude Code, Cursor, or your editor. Product Chat is an optional way to ask a local agent about the same project; type or dictate in the desktop app.

12 / REVIEW

Activity history

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

13 / MONITORPlanned

CPU, memory & disk

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

FOR GITHUB SPEC KIT PROJECTS

The missing control panel for GitHub Spec Kit projects.

Follow specs and tasks in their standard files. Start your app, inspect its data, run tests, and see what your agent has actually built.

Spec Kit gives your agent a plan.
Project Room gives you the controls.

Explore GitHub Spec Kit

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. Project Room 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. Project Room reads those existing files.

Map what gets built

Have the agent inspect real commands and propose .projectroom/project.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.

THE PROBLEM

The agent built it fast.
Can you still run it next week?

How do I start this project again?

What is running, and where are its logs?

Which tests and data show it works?

What should the agent build next?

The IDE used to keep these controls close to the code. Project Room makes them visible again, alongside product direction and Spec Kit work. Return to the project without reconstructing it from old chats and shell history.

WHY I BUILT IT

The little dashboard I kept rebuilding.

Benedikt SauterCo-founder of Xentral

“I’m a bit of a control freak. I built app after app with coding agents, then kept asking the same questions: What’s running? Which build am I looking at? How do I stop it, inspect the data, or run its tests? I used to have those controls close by in an IDE or terminal.

So I made little dashboards for each project. Eventually I realized I needed one reusable project file and a local viewer that makes the software visible and operable. Now the product vision and Spec Kit work can sit beside the running app, too.”

A CONCRETE EXAMPLE

A small file.
A repeatable way back in.

This is the part your team commits with the code. It points Project Room 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.

Know what you started. The service uses the declared command. A build file written after a successful build supplies its timestamp, commit, and optional version.

Check the work. The suite appears in Test Explorer with its actual command one click away.

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

.projectroom/project.yamlSIMPLIFIED EXAMPLE

schemaVersion: 1
project:
  id: atlas
  name: Atlas

workspace:
  additionalViews: [vision, roadmap, north-star]
  apiSources:
    - id: atlas-api
      name: Atlas API
      baseUrl: http://127.0.0.1:4000
      spec: specs/001-order-lookup/contracts/openapi.yaml

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 }
    build: { file: dist/web/build-info.json }
    runtime:
      command: [node, dist/web/server.js]
      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.

Keep building in Codex, Claude Code, Cursor, or your usual editor. Product Chat is an optional way into the same project: connect a locally installed Codex CLI or Claude Code setup to ask what changed or discuss the next feature. Project Room shows the shared documents and local runtime while your agent edits the repository.

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 .projectroom/project.yaml for your review.

Ask about this project…↗

PRODUCT & DEVELOPER QUESTIONS

What Project Room
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. Project Room 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. Keep writing code in Codex, Claude Code, Cursor, or your editor. Project Room opens the same local repository to show its product context and run configured commands as local processes.

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. Project Room 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 .projectroom/project.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?

Project Room 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.

Project Room runs locally on macOS. The 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
Artifact build time, commit and optional version when build metadata exists
Test runs, data previews, CLI, MCP and API 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

PROJECT ROOM

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.

Download free for Mac

Your agent builds the app.You keep the controls.

One control surface for your local stack.

Run your project.

See the whole workspace. Then try it.

Everything at a glance.

Find the source behind the story.

Open a repo. Know what to check.

Verify the app, not just the YAML.

Give the agent a reason to build.

Make every order easy to find and trust.

Show what comes next.

Measure whether people get value.

Know what comes next and why.

Follow the promise into the build.

Customers can find one order by ID.

Keep the explanation with the work.

Run Atlas locally

See how the system fits together.

Know which build you started.

Spot what the system needs.

A manual you can actually use.

See what the MCP server exposes.

See the contract. Try the endpoint.

Open the data behind the app.

Check every part of the stack.

See what happened since you last looked.

Make the workspace yours.