Your agent builds the app. You keep the controls.
Build in Codex, Claude Code, Cursor, or your usual editor. Project Room opens the same local repository and gives you one window to run the app, check tests, inspect data, and follow the product plan. It is a free, open-source desktop app for people building software with coding agents and the teammates who need to understand that software later.
Download for Mac · Download Windows preview · Connect an existing repository · Start a new app · Watch the 60-second demo
The Apple Silicon Mac release is signed and notarized. The Windows 11 x64/ARM64 preview is unsigned and may trigger SmartScreen; its real-project integrations and installed-to-installed updater still need the final Windows test.
If this is the control window you've been missing, click Star in the GitHub repository header. It saves Project Room for later and helps other builders discover it.
Illustrative project. Your coding agent edits the repository; Project Room opens that same folder and gives you controls for the running app. Explore the interactive tour.
- Download and open the Apple Silicon Mac app or Windows 11 preview. On Mac, unzip and move Project Room.app to Applications. On Windows, run the installer.
- Open your project folder in Codex, Claude Code, Cursor, or your usual coding agent. Paste the prompt for an existing repository or a new app. For an existing repository, the agent first summarizes what it found and waits for your answer before preparing
.projectroom/project.yaml. - Choose Open project folder in Project Room and select that same folder. Review Onboarding and Project Map, then start one configured service and run one test. Nothing starts just because you opened the folder.
Use this in the coding agent already working in your repository. Spec Kit is optional here; your existing code, docs, and specs stay where they are.
Show the copyable existing-repository prompt
Add Project Room to this repository. Read the agent guide (https://github.com/OpenProjectRoom/desktop/blob/main/agent/project-room/SKILL.md) first. Complete every row of the guide’s source audit without changing files: trace entry points and wrappers into product context, services, HTTP APIs, MCP servers (including stdio subcommands), CLI tools, tests, data and runtime evidence, even when no client configuration lists them. Make a second source pass before reporting a capability absent. Cite the files that prove each finding and separate uncertainties from verified implementations. Summarize whether GitHub Spec Kit is present and what Project Room could show. Ask only the decisions you cannot safely infer. Wait for my answer before creating or updating the configuration. Then follow the guide. Finish with the Project Room download and installation steps for my operating system, the exact folder to open in Project Room, and what I should verify there first.
Use this in the folder where you want your new app. Replace the two bracketed placeholders with your idea and audience.
Show the copyable new-project prompt
Build [my app idea] for [my audience] in this folder with Git, the official GitHub Spec Kit (https://github.com/github/spec-kit), and Project Room. First ask me who it is for, what problem it solves, and what the first useful release should do.
Read the Project Room guide (https://github.com/OpenProjectRoom/desktop/blob/main/agent/project-room/SKILL.md) and schema (https://github.com/OpenProjectRoom/desktop/blob/main/schemas/projectroom.schema.json). Keep the constitution, specs, plans, and tasks in Spec Kit's standard files. Create .projectroom/project.yaml from real code and commands as they appear; no parallel spec tree, invented components, or secrets. Use manual startup and validate the YAML.
Finish with the Project Room download and installation steps for my operating system, the exact folder to open in Project Room, what you configured, what remains uncertain, and what I should verify there first.
The agent guide and YAML schema describe the shared format. The website has copy buttons for both prompts.
project-room-60s.mp4
The film follows download → open a repository → review the agent's findings → run and inspect the app. Short English captions and closer views show the service changing state, its memory history, an MCP result, an API response, data, and passing tests. Setup scenes illustrate the recommended workflow. The app panels use captured screens from Order Desk, a separate local sample project. Camera moves and transitions are illustrated; this is not a recording of unattended agent activity. The website's interactive tour is a separate labeled simulation.
Real Order Desk workspace: two services started manually, an actual test result, and CPU history sampled during that app session. Click for the full-size screenshot.
Your coding agent edits the code and GitHub Spec Kit files in the repository. Project Room reads that same repository, shows its product context, and runs verified local commands only when you click. It is a control surface beside your editor, with no need to move your code or specifications.
You → Codex / Claude Code / Cursor → shared Git repository
↕
Project Room Desktop
↓
Local services · tests · data
| You want to… | Open… | What you see or do |
|---|---|---|
| Get your bearings | Overview, Files, Onboarding | Current services, recorded test runs, backlog, repository files, and which setup entries were actually found. |
| Keep the product direction visible | Vision, Roadmap, North Star, Backlog, Documentation | Markdown product context and repository-backed work. Vision, Roadmap, and North Star are optional navigation views. |
| Follow product work | Backlog | Ideas, features and bugs from local Markdown and Spec Kit, with original files and feature task progress at each item. |
| Understand and run the local stack | Project Map, Services | Services, databases, storage, dependencies, start/stop controls, logs, build identity, and CPU/memory history. |
| Explore interfaces | API Explorer, MCP Explorer, CLI Explorer | OpenAPI operations and responses; MCP tools, resources, and prompts; command help, arguments, and local output. |
| Inspect and verify | Data Explorer, Test Explorer, Activity | Read-only data previews, test suites and individual supported cases, plus recorded workspace events. |
| Set local values | Environment | Required variable names and values in the project's ignored .env; secrets stay out of the shared YAML. |
Product Chat is optional: connect a locally installed Codex CLI or Claude Code setup to ask about the open project. Your normal coding agent and editor remain your primary development tools.
Project Room keeps the why visible beside the running software. The product owner can edit a vision, maintain a local backlog and roadmap, and record one North Star outcome. The coding agent and developers can read the same files in Git.
Spec Kit stays in its standard files. Project Room reads .specify/ and specs/ rather than creating a parallel specification tree. Backlog shows feature specs and task progress alongside Spec Kit bug reports and idea assessments; optional YAML links connect feature requirement IDs to real components and test suites. A checked task is not treated as proof that a service is running or a requirement passes.
The Project Map contains runtime resources: services, databases, storage, and persistent command servers. Tests, specifications, and backlog items have their own views. Services start manually and show the command, current process state, build timestamp, commit, optional version, and output.
Project Room samples CPU and resident memory for services it starts, including child processes, every five seconds. The Overview combines their usage; Services shows a selected service's history. Measurements live only in memory for this app session and do not measure external processes, detached containers, disk usage, or API latency.
In the Order Desk sample, the HTTP API, PostgreSQL tables, CLI command, and MCP tool all read the same order. Project Room makes each interface inspectable without treating one successful response as proof of every requirement.
| API Explorer | Data Explorer |
|---|---|
 |
 |
| Discover OpenAPI files, inspect operations and schemas, compose a request, and send it explicitly. | Inspect PostgreSQL, MySQL/MariaDB, SQLite, or local files with small, read-only previews. |
| CLI Explorer | MCP Explorer |
|---|---|
 |
 |
| Discover likely project commands, read help on request, and run a bounded local trial after reviewing arguments. | Connect project MCP servers on request, browse advertised tools/resources/prompts, inspect schemas, and invoke an item deliberately. |
Test Explorer runs a configured suite or a supported individual Node/Rust test entry, then keeps the actual exit status and output. Its result is evidence of that command, not a fabricated coverage percentage.
- Download the signed Apple Silicon Mac app or the unsigned Windows 11 preview. On Mac, unzip it and move Project Room.app to Applications. On Windows, run the installer.
- Open Project Room and choose Try working example. It copies a small project to
~/Documents/Project Room Examples/hello-workspaceand opens it without starting a process. - With Node.js 20+ installed, start Notes web service, inspect its API and JSON storage, run Node endpoint tests, and open the linked Spec Kit feature in Backlog. Node is needed for this example's commands, not for the desktop app itself.
The included example has a real service, tests, local JSON storage, a constitution, and Spec Kit feature files. It needs no account, database server, or cloud deployment. The separate Order Desk screenshots above show a richer project with PostgreSQL, CLI, and MCP interfaces; Order Desk is not bundled with the desktop download.
Project Room's shared .projectroom/project.yaml belongs in your repository alongside the code. It points to verified services, tests, data sources, tools, and product documents. Secret values stay in the project's ignored .env. The app scans a folder for clues, while your coding agent can create or refine the YAML after inspecting the repository. Configured does not mean running or tested: check the entries in Project Room and run what you need. See the repository contract for the full format and behavior.
Project Room opens a local project folder. Processes, requests, tests, MCP connections, and data inspection require deliberate actions. The packaged browser demo and website tour use labeled sample data. Live GitHub/Linear issue synchronization, external telemetry adapters, database editing, and arbitrary SQL are not part of the current preview. Windows x64 and ARM64 support is being validated; the unsigned installer is an early preview, with real-project and update tests still open. Linux packages have not been tested.
npm ci
npm test
npm run validate:config
npm start
On Apple Silicon macOS, npm run package:mac:app builds a local app bundle. The Mac release workflow builds signed and notarized downloads and update metadata. On Windows, npm run package:win:app prepares an unpacked x64 build; the Windows release checklist covers the combined x64/ARM64 installer, final validation, signing, and updates. Read CONTRIBUTING.md before a pull request; use Issues for focused bugs and feature requests and SECURITY.md for sensitive reports.
MIT licensed. See LICENSE.