Explore repeat lookups.
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 gives you one window to run the app, check tests, inspect data, and follow the product plan.
Apple Silicon preview Runs locally on your Mac MIT licensed
ILLUSTRATIVE WORKSPACE
One control surface for your local stack.
Your coding agent and Project Room work from the same repository. Build in your editor; run and inspect the app here. Even next week, you can see what starts and what works.
Project RoomEXAMPLE WORKSPACE
OVERVIEW / ATLAS WORKSPACE
Everything at a glance.
Services0 / 3running
Tests0 / 4passed
P95 response186 mssample
Development environment Start · Stop
▣Web appStopped
⌁API serviceStopped
⬡MCP serverStopped
Performance Last 4h
Latency 186 msCPU 18.6%
Your coding agentCodex · Claude Code · Cursor
SEPARATE TOOLYOU ASK“Add order lookup.”
AGENT UPDATES✓ spec.md✓ apps/api
One shared repositoryCode · specs · project config
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
OverviewEverything at a glance.
Development, quality, and product progress in one place.
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
FILES / REPOSITORY EXPLORER
FilesFind the source behind the story.
The same project files your agent edits are one click away.
ATLAS / PROJECT FILES▾ .projectroom/▾ .specify/▤ memory/constitution.md▾ specs/001-order-lookup/▤ plan.md · tasks.md▾ docs/▾ dist/web/▸ apps/ · tests/
.projectroom/project.yamlEXAMPLE FILE
project: {name: Atlas}
components:
- id: web
kind: service
name: Web app
build: {file: dist/web/build-info.json}
- id: api
kind: service
name: API service
- id: postgres
kind: databaseThe build pipeline writes the timestamp and revision to its build file after a successful build.
ONBOARDING / PROJECT SETUP
OnboardingOpen a repo. Know what to check.
A guided checklist turns a new folder into a usable workspace.
ATLAS SETUP · 4 OF 6 REVIEWED
✓Open project folderAtlas repository found
✓Read agent guideYAML contract available
✓Review Project Map5 components linked
✓Inspect Services3 commands registered
○Run Tests4 checks ready
○Open Data ExplorerPostgreSQL configured
NEXT STEP
Verify the app, not just the YAML.
Start each service, run the checks, and inspect a real data source before trusting the map.
VISION / LOCAL PRODUCT DOCUMENT
VisionGive the agent a reason to build.
The product purpose lives in a Markdown file everyone can revisit.
START WITH THE ESSENTIALSWho is it for?What hurts today?What should change?Shared product context · optional view
VISION DOCUMENT
docs/vision.mdEdit MarkdownMake every order easy to find and trust.
For support teams who answer customer questions about orders.
The problem is that finding an order means checking several systems.
First useful release lets a team find one order and see a reliable status.
ROADMAP / SHARED PROJECT YAML
RoadmapShow what comes next.
Place product outcomes in a clear status so the next task has context.
Draft1
Planned1
Share an order result.
In progress1
Find an order and trust its status.
Web · API · PostgreSQLDone1
Agree on the first outcome.
Roadmap status is a plan. Tests and runtime show what actually works.
NORTH STAR / MANUAL PRODUCT MEASURE
North StarMeasure whether people get value.
One outcome metric keeps product progress visible beside delivery.
WEEKLY TEAMS COMPLETING AN ORDER LOOKUP
12teams
Target: 100
Target: 100
Latest manually recorded value · example data
HISTORICAL PROGRESSManual measurements in this repository
Week 1Week 4
The target is a goal; the plotted values are manually entered observations.
BACKLOG / REPOSITORY ISSUES
BacklogKnow what comes next and why.
Requests, decisions, and bugs stay beside the code.
INBOXPV-032 · Saved searches
Support teams want to repeat common order lookups.
Idea · medium priorityIN PROGRESSPV-024 · Order lookup
Find an order by ID and trust the returned status.
Linked to specs/001-order-lookupNEEDS REVIEWPV-035 · Failed test detail
Make the exact failing check easy to inspect.
Bug · high priorityREQUIREMENTS / GITHUB SPEC KIT
RequirementsFollow the promise into the build.
The standard Spec Kit files connect product intent to implementation work.
specs/001-order-lookup
✓ spec.md What & why
✓ plan.md How
◌ tasks.md 3 / 4 done
✓ contracts/ API
REQUIREMENT → IMPLEMENTATION
Customers can find one order by ID.
FR-001 A valid order ID returns the matching order and its status.
T004 Verify the response against local data.
3 of 4 tasks complete · one verification task remains
DOCUMENTATION / PROJECT KNOWLEDGE
DocumentationKeep the explanation with the work.
Product and technical notes remain readable in the repository.
DOCS / MARKDOWN
▤ getting-started.md
▤ product-decisions.md
▤ architecture.md
GETTING STARTED
Run Atlas locally
1. Open the repository in Project Room.
2. Set DATABASE_URL locally.
3. Start Web, API, and MCP services.
4. Run the registered checks and inspect the order table.
PROJECT MAP / LOCAL WORKSPACE
Project MapSee how the system fits together.
Connected components show their state and, when available, the artifact build.
3 services · 1 database · 1 storage folder · example configuration
SERVICES / LOCAL WORKSPACE
ServicesKnow which build you started.
Build time and commit are separate from the moment a process starts.
Services3 configured · manual start
Web app Stoppednode dist/web/server.js · :3000 · v1.4.2Built 04 Nov 2026, 20:41:23 · a4c9e71Not started in this demo
API service Stoppednode dist/api/server.js · :4000Built 04 Nov 2026, 20:38:12 · b8f12d0Not started in this demo
MCP server Stoppednode dist/mcp/server.js · v0.7.0Built 04 Nov 2026, 20:32:07 · c39e2a4Not started in this demo
Example build metadata · select Start for a simulated local service.
ENVIRONMENT / LOCAL ONLY
EnvironmentSpot what the system needs.
Required variable names are visible; values stay on this computer.
REQUIRED BY API SERVICE
✓
DATABASE_URLPostgreSQL connection · value stays on this computer
Configured locally!
ATLAS_API_TOKENOptional request token · value never shown here
Not set locallyIn the desktop app, you set your own secret locally. The repository stores only its name.
CLI EXPLORER / LOCAL COMMANDS
CLI ExplorerA manual you can actually use.
Browse a project's commands and try one without guessing flags.
ATLAS CLI · COMMANDS
orders getRead one order by ID
orders listBrowse recent orders
healthCheck the local API
Last build · 04 Nov 2026, 20:36:04
Commit · d7a2f80
Version · v1.4.2
ORDERS GET · USAGE
atlas orders get <order-id>Argument order-id · required
Option --json · machine-readable output
$ atlas orders get ORD-1042 ORD-1042 Ada paid Last example run · repeat the command
MCP EXPLORER / LOCAL TOOL SERVER
MCP ExplorerSee what the MCP server exposes.
Inspect tool inputs and run a sample call deliberately.
ATLAS MCP SERVER · 3 TOOLS
Last build · 04 Nov 2026, 20:32:07
Commit · c39e2a4
Version · v0.7.0
SAMPLE MCP CALL
get_order({ id: "ORD-1042" })Last example: { "id": "ORD-1042", "customer": "Ada", "status": "paid" }
CLI EXPLORER atlas orders get ORD-1042API EXPLORER / HTTP ENDPOINTS
API ExplorerSee the contract. Try the endpoint.
OpenAPI gives you the routes; one deliberate request shows the actual response.
ATLAS API · OPENAPI 3
GET /orders/ORD-1042Find one order by ID
GET /ordersList recent orders
GET /healthCheck API readiness
Document: specs/001-order-lookup/contracts/openapi.yaml
REQUEST COMPOSER · EXAMPLE
GET
http://localhost:4000/orders/ORD-1042Bearer token name: ATLAS_API_TOKEN · value stays local
Last sample response · 200 OK · 84 ms
{ "id": "ORD-1042", "customer": "Ada", "status": "paid" }DATA EXPLORER / READ-ONLY PREVIEW
Data ExplorerOpen the data behind the app.
Browse a local structure without leaving your workspace.
POSTGRESQL · ATLAS LOCALRead-only preview · sample data
ORDERS / FIRST 3 ROWS
IDCUSTOMERSTATUS
ORD-1042AdaPaid
ORD-1043SamPending
ORD-1044LeePaid
IDNAMEORDERS
C-001Ada2
C-002Sam1
TEST EXPLORER / LOCAL VERIFICATION
Test ExplorerCheck every part of the stack.
Run the registered checks and see their results together.
LATEST SIMULATED RUN3 / 4 passed
Last sample run · MCP lookup needs a rerun
REGISTERED CHECKS
✓Web app respondsPassed
✓API healthPassed
○MCP order lookupNeeds rerun
✓PostgreSQL order readPassed
› Last sample run: 3 passed. Start MCP and rerun all checks.
ACTIVITY / LOCAL PROJECT HISTORY
ActivitySee what happened since you last looked.
Starts, inspections, and test runs leave a trail you can review.
ORDER LOOKUP · SIMULATED EXAMPLEReady to review ✓
From FR-001 to a running API, a visible order, and a check ready to rerun.
FR-001→API + MCP→ORD-1042→3/4 checks
Illustrative relationship · no live verification is performed here.RECENT ACTIVITY · SIMULATED
●Services startedWeb · API
●Order inspectedPostgreSQL
●Checks recorded3 of 4 passed
SETTINGS / WORKSPACE PREFERENCES
SettingsMake the workspace yours.
Keep the core navigation clear; enable extra views when they help.
APPEARANCE · THIS COMPUTER
ThemeLight / Dark
SidebarExpanded
AgentLocal coding CLI
ADDITIONAL VIEWS · PROJECT YAML
VisionEnabled
RoadmapEnabled
North StarEnabled
The tour shows these optional views so you can see how product direction fits alongside runtime.
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.
Try the included example, then use your coding agent to prepare a new or existing repository. Project Room opens the same folder and turns its verified configuration into a workspace.
1. Download the Mac app
Get the free Apple Silicon preview. The desktop app and its source are open on GitHub.
Download free for Mac2. 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
Copy the matching prompt below into your coding agent while it works in your repository. Once it creates .projectroom/project.yaml, open that folder in Project Room and check the detected services, tests, and data.
TWO WAYS IN
Start in your coding agent.
Run the prompt in your project folder. Your agent prepares the repository; Project Room reads it. You keep building in Codex, Claude Code, Cursor, or your usual editor.
01 / NEW PROJECTGit + Spec Kit + Project Room
Build from an idea
Give the agent your app idea. It asks about the first useful release, starts the official Spec Kit workflow, and adds Project Room as the app takes shape.
Describe your idea→Agent sets up the repo→Open Project Room
Ready for your agent
Read the 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 by telling me which folder to open in Project Room, what you configured, what remains uncertain, and what I should check there first.
02 / EXISTING REPOSITORYKeep your current structure
Connect what you already built
Paste this into the coding agent already working in your repository. It maps the existing code and Spec Kit files without moving or duplicating them.
Paste in your repo→Agent creates the YAML→Open & verify
Ready for your agent
Read the prompt
Add Project Room to this existing repository. Read its 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). Inspect the actual code, scripts, docs, tests, data sources, APIs, MCP and CLI tools, environment variable names, and any existing .specify/ and specs/ files. Keep the existing Spec Kit files and project structure. Create or update .projectroom/project.yaml from verified findings only. Do not create a second spec tree, put secrets in YAML, or start services and call external tools during setup. Validate the YAML and referenced paths. Finish with the exact folder to open in Project Room, what you linked, what is missing or uncertain, and the first service, test, and data source I should check manually.
When the agent finishes: open the reported folder in Project Room, refresh the analysis if it is already open, then use Onboarding to inspect the configured entries and verify the real commands and connections.
Apple Silicon preview is unsigned and not notarized. View source and star on GitHub ↗
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 direction→Spec Kit→Coding agent→Running evidence
Progress overview
See services, recent tests, and open work together. Task progress is read from your existing Spec Kit tasks.md files.
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.
Roadmap
Turn product milestones into a shared plan. Link them to components and show their declared status as the work moves forward.
North Star
Choose one product outcome, set a target, and record observations over time. The chart plots values entered by the team.
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.
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.
Project Map
See the real services, databases, storage, and persistent processes that make up your local system.
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 ↗Test Explorer
Run suites or individual discovered tests and inspect their output. Configured links show test evidence beside related requirements.
MCP Explorer
Connect project MCP servers, browse their tools and resources, inspect build identity when provided, and try a tool deliberately.
CLI Explorer
Discover local command-line tools, read their options like a friendly manual, and identify the artifact build before running a trial.
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.
Data Explorer
Collect every configured project source in one place. Inspect supported databases and local files with limited, read-only previews.
Environment variables
See the variable names your project needs and edit local values in its .env file. Keep secrets out of YAML, Git, and Product Chat.
Spec Kit & requirements
Read existing specs, plans, tasks, and project rules; follow the progress of work stored with the code.
Workspaces & files
Switch local repositories and browse their source trees, with folders collapsed until you open them.
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.
Activity history
See recorded starts, test runs, agent connections, and project changes so the next session has context.
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.
Project Room reads the standard Spec Kit files in your repository; it does not create another spec tree. Services and explorers also work without Spec Kit.
HOW IT WORKS
- 01Set directionVision and next milestone
- 02Specify workStandard Spec Kit files
- 03Map the appVerified commands and data
- 04Run and reviewServices, tests, evidence
“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.”
SHARED WITH THE CODE
One small file.
A way back in.
Your coding agent checks the real project, then records verified services, tests, data sources, and product documents in .projectroom/project.yaml. Your team commits that file with the code. Secret values stay in the project's ignored .env.
.projectroom/project.yamlEXCERPT
schemaVersion: 1
project: { id: atlas, name: Atlas }
product:
vision: docs/vision.md
components:
- id: web
kind: service
name: Web app
position: { x: 15, y: 80 }
runtime:
command: [npm, run, dev]
cwd: .
startup: manualPRODUCT & DEVELOPER QUESTIONS
What Project Room
actually does.
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 product context and run configured commands. Product Chat is an optional way to ask a local agent about the project.
Does it automatically know how every repo starts?
It can discover some project structure and tools. A coding agent can help draft .projectroom/project.yaml, 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 the existing constitution, specs, plans, and tasks from Spec Kit's standard files. Services and explorers work without Spec Kit, too.
Does it deploy my app to the cloud?
Project Room focuses on your local development system. Your cloud platform still handles deployment and hosted operations.
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.