Project Room

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

Your agent builds the app.
You keep the controls.

Your IDE once kept Run, Stop, logs, and tests close to the code. With coding agents, those controls get scattered across chats and terminals. Project Room brings them back with your data and product plan in one local workspace.

Download free for MacExplore 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 Web app, API, MCP server, and database run as separate parts. Project Room lets you start and inspect them from one place.

ATLAS REPOSITORY · INTERACTIVE SIMULATION
Project RoomATLAS WORKSPACE
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 ↗
3 services ready to start · PostgreSQL configuredLast simulated run · no checks yetIllustration · local processes, managed from Project Room
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.

Atlas/ Project Room INTERACTIVE EXAMPLE
OVERVIEW / ATLAS WORKSPACE

Everything at a glance.

One starting point for product progress and the running app.

Overview
RUNNING SERVICES · EXAMPLE2 / 3Web and API online
LATEST CHECKS · EXAMPLE3 / 41 check to review
OPEN BACKLOG03Order lookup · 2 next
SPEC KIT TASKS3 / 4Order lookup feature
DEVELOPMENT ENVIRONMENT
▣Web app:3000 · v1.4.2Running
⌁API service:4000 · b8f12d0Running
⬡MCP serverv0.7.0 · c39e2a4Stopped
NEXT TO REVIEW
PV-024 · Verify order lookupIn progress

FR-001 is built. The remaining task checks the API response against PostgreSQL.

✓ Web responds✓ API health○ MCP lookup✓ Database read
Open Requirements to follow the link.
LAST BUILD · SAMPLEWeb app · v1.4.204 Nov 2026, 20:41:23 · a4c9e71
LAST API RESPONSE · SAMPLE200 OK · 84 msORD-1042 · Ada · paid
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

Choose a repository. Project Room scans for project clues and prepares a tailored agent prompt. Codex or Claude Code proposes .projectroom/project.yaml; review it, then start a service or test.

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 & GitHubInstall 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

Ask a local coding agent about the project, its tools, and next steps. 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.

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

03

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.

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.

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.

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

01

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

02

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.

03

Check the work. The suite appears in Test Explorer 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.

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

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