Documentation
How to use PM on Rails
From collecting meeting notes and documents through organising requirements, design, handing work to the development team, progress and change management. Start with the quickstart if this is your first visit.
Getting started
What is PM on Rails?
The big picture, the data model, and the flow from collecting to organising, handing over and tracking progress.
Quickstart
The shortest path from creating an account to your first requirement card.
Guide by audience
Where PMs, engineers and stakeholders each get the most out of it.
The basic vocabulary (terms and relationships)
Projects, requests, requirements, stories, scenarios, tasks and the other core concepts, for non-engineers.
Recommended ways of working (by phase)
The rhythm shared by every phase (AI drafts, people decide), plus how to use it phase by phase, from requirements definition through implementation, testing and the spec-change loop.
Pulling requests together (the PM flow)
Collect into knowledge
Bring meeting notes, documents, audio and Word/Excel files together, with version history and review.
Create requirement cards
Automatic generation, scoring, the 5 Whys, FM priority, duplicate detection and adoption decisions for requirement cards.
Decide the scope (MoSCoW)
Agree what you build and what you don't with MoSCoW, and get priorities in order.
Design and break down work
User stories and scenarios
Raise stories from requirements and define what counts as done with Gherkin scenarios.
Design documents (API design and database design)
Build API and database design documents from your requirements. Supports AI drafts and mermaid diagrams (ER diagrams and sequence diagrams).
Task management
Task kinds, assignees, priority, due dates, estimates, AI estimates, labels, the four board states, subtask hierarchy and pull request links.
Bugs and change management
Raising bugs, impact scope, resolution records, turning prevention into requirements, change requests and version history.
Build and ship
Manage and build with Claude Web, Claude Code, and Codex
Manage and implement the requirements you shaped in the UI from Claude Web, Claude Code, and Codex over MCP.
Claude Web, Claude Code, and MCP integration
Work on the graph over MCP from Claude Web, Claude Code, Codex, and more. When to use which, plus examples.
MCP feature reference
A complete guide to what the PM on Rails MCP can do, in plain language, with tool names for those who need them.
GitHub integration
The outbound integration for the MCP development flow: issue sync, pull request linking, auto-done on merge.
Change tracking and diff checks
Automatic updates from re-ingesting meeting notes, diff checks, impact analysis, change notifications, and update markers.
Track progress
Progress you can see
Progress that updates itself (done on pull request merge), automatic delay detection, roadmap, sprints, burndown, velocity, capacity, traceability and automatic estimates.
Testing
Collects pass/fail results for scenarios and the defects that were found (individual bugs). See how complete things are, from requirement to implementation.
Jobs (background processing)
Run time-consuming work without blocking the screen. Check progress, completion and failure.
AI features
Admin and settings
Members and permissions
Workspace invitations, joining projects, roles and how visibility works.
Managing stakeholders
Managing customer contacts, sorting them with tags, and inviting them as viewer.
Open questions
Collect the things to ask the customer, raised by AI reviews and elsewhere, and manage them through to an answer and a resolution.
Feedback
Receive comments from customers and users, with the screen involved, the ideal, the current behaviour and steps to reproduce.
Notifications and Slack
Assignments, mentions, due dates, delays, accepted invitations, sprint completion, Slack (the morning delivery summary), digests, unread and snooze.
Settings
Members, integrations, choosing AI models, capacity and issuing tokens, all in one place.
Reference
Reverse engineering (analysing an existing system)
On modernisation work, analyse the existing system to make its current state and constraints visible, and carry that into requirement cards for the change.
Recording decisions (requirement calls and ADRs)
Keep the history of adopt, reject and hold calls, and the decisions made about the design (ADRs).
Frequently asked questions
The points people trip over, and what to do about them.