# What is PM on Rails?

PMs, engineers, clients and owners going in-house. A different loss in each role, stopped by one flow from meeting notes to acceptance criteria and progress. It does not stop at being a requirements tool: you can trace what you are building, why, what done looks like, and how far it has gone.

![PM on Rails AI assistant. Conversation and the next step are visible; requirement cards, questions and tasks are created only after you approve a confirmation card. Before: you re-read documents and picked out open questions by hand. After: review and run, and organisation starts.](https://pmonrails.com/docs-img/chat.png)

## Whose problem it stops

| Who | The loss today | The result |
| --- | --- | --- |
| PM | Unsure what to ask; Slack answers never return to the spec | You go back to reviewing and deciding |
| Engineer | Spec hunting is long and done is vague | You start implementing without guessing |
| Stakeholder (the person asking) | After you delegate, what you asked for and how far it has gone disappear | You can follow the current state yourself |
| Owner | After going in-house, delays and change reasons stay invisible | A practice remains that does not live in one head |

![PM on Rails requirement card list. Each role's loss stays as a request, background and acceptance conditions. Before: whose problem it was hid behind a feature list. After: you can read whose loss this stops first.](https://pmonrails.com/docs-img/demands.png)

Read more in the [guide by audience](https://pmonrails.com/en/docs/audiences.md) and the role guides ([clients](https://pmonrails.com/en/method/client) / [PMs](https://pmonrails.com/en/method/pm) / [engineers](https://pmonrails.com/en/method/engineer)).

## Before and after

| Before | After |
| --- | --- |
| Meetings, Slack, tasks and pull requests are disconnected | Requests, scope, acceptance criteria, tasks and pull requests stay in one flow |
| People organise and people update progress | AI organises and reflects; people review and decide |
| You judge done right before delivery | You agree acceptance criteria first, then follow them on the dashboard and roadmap |

![PM on Rails dashboard. Requirement readiness, delays and the cycle in one list. Before: meetings, Slack, tasks and pull requests were split. After: the material for review and decisions stays in one flow.](https://pmonrails.com/docs-img/dashboard.png)

## Why now

Implementation got faster with AI. The same speed, pointed at a vague requirement, raises the cost of rework. Installing the find, ask and reflect practice before headcount grows is when the return is highest.

## Why this product

The point is not more features. It is one flow that finds what is vague, asks about it, reflects the answer and sends development activity back to progress. Generation is a proposal; people confirm. The same information is available in the UI, Slack, and Claude Code / Codex.

![PM on Rails scope board. Cards in Must / Should / Could / Won't. A requirements tool or a task tracker is not enough, because agreed scope has to stay connected through to development units.](https://pmonrails.com/docs-img/moscow.png)

![PM on Rails Claude Code / Codex integration. The coding agent reads the same acceptance criteria. The UI, Slack and implementation do not become three sources of truth — that is why this product.](https://pmonrails.com/docs-img/mcp-tools.png)

## The AI assistant is the front door

When you log in, the **AI assistant** for your selected project opens. You can start by attaching documents and talking it through; requirement cards, open questions and tasks are created only after you review a **confirmation card** and press "Run". While you work, every screen has "Ask AI" in the header, which opens a **chat on the right** so you can continue the conversation (you can point at "this screen" or "this story"). The dashboard is still there under "Home" in the sidebar.

On **narrow (phone) screens**, use "Open menu" at the top left to open the same navigation as the sidebar in a left drawer. Major screens such as the board switch to layouts suited to narrow widths (on desktop widths the left sidebar stays visible as before).

## The overall flow

1. **Collect** — gather meeting notes, memos, documents and audio into knowledge
2. **Organise** — AI generates requirement cards automatically, separating wishes from decisions
3. **Decide** — settle the scope (what you build and what you don't) with MoSCoW
4. **Design** — expand into user stories, scenarios and API / DB design docs
5. **Build** — read and write the same connections from Claude Web, Claude Code and Codex over MCP
6. **Progress** — manage progress with the roadmap, sprints and the board
7. **Export** — write out to Markdown or GitHub issues / pull requests
8. **Feed back** — carry change requests, bugs, open questions and feedback into the next round of improvement

![PM on Rails user stories. Requests expand into development units and acceptance criteria. The screen for Design after Collect, Organise and Decide.](https://pmonrails.com/docs-img/stories.png)

![PM on Rails board. Tasks move from to-do to done. Build and Progress stay on the same board, under the acceptance criteria.](https://pmonrails.com/docs-img/kanban.png)

The central chain:

> requirement card → requirement → user story → scenario / development task

| Connection | What it means |
| --- | --- |
| Document → requirement card | The meeting notes and documents the request came from |
| Adoption decision → requirement | A "we'll build it" decision produces a requirement |
| Bug → scenario, requirement | The area the defect affects |
| New version → old version | The history of a spec change |
| Story → sprint, roadmap | The assignment of when it gets built |
| Open question, feedback → request / proposed change | Answers to open questions and voices from live operation feed the next improvement |

The AI assistant answers by following related information. See [How the AI works](https://pmonrails.com/en/docs/graphrag.md) for the benefit.

## Terms

| Term | What it means |
| --- | --- |
| Workspace | The top-level unit that manages projects and members |
| Project | One engagement. Requests, stories and tasks belong to a project |
| Requirement card | A stakeholder request organised in the form "as a [who], I want to [what]" |
| Requirement | A non-functional requirement or constraint. Functional specs go in the user story overview |
| User story | The development unit raised from a request. The overview holds the functional spec, and it bundles scenarios and tasks |
| Scenario | The "is it done?" criterion, written as "in this situation, if you do this, this happens" |
| MCP | The connection point for working from external AI tools such as Claude Web, Claude Code and Codex |

> Ready for the steps? Go to the [quickstart](https://pmonrails.com/en/docs/quickstart.md). Reading by role? Go to the [guide by audience](https://pmonrails.com/en/docs/audiences.md).

---

https://pmonrails.com/en/docs/overview