# Guide by audience

Each role is losing something different. Whatever your position, the AI assistant is the entry point after login. The guidance and first three steps follow the role you chose when joining the project (PM / managing on your own, engineer, reviewer).

![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)

The longer explanation is in the role guides ([clients](https://pmonrails.com/en/method/client) / [PMs](https://pmonrails.com/en/method/pm) / [engineers](https://pmonrails.com/en/method/engineer)). This page is the door from your problem and the before / after into the screens.

## For PMs and people managing a project on their own

**Who:** The person between the stakeholder and development, chasing requirements and progress.

**The loss today:** Unsure what to ask, Slack answers never return to the spec, and the tracking pattern changes every engagement.

**What changes:** Meeting notes, open questions, Slack follow-ups, in-scope and out-of-scope calls, acceptance criteria and tasks stay in one flow. People go back to reviewing and deciding.

| Before | After |
| --- | --- |
| After each meeting you re-read the notes and update progress by hand | The follow-ups remain, and you decide scope and what done looks like |
| Slack answers never land back | Once the answer is recorded and the question resolved, spec update proposals are drafted automatically, and a person reviews and applies them |

**Why now:** The faster the build, the more expensive a vague requirement. Putting find, ask and reflect in now cuts weekly clean-up and late firefighting.

**Why this:** If requirements and tasks live in different tools, you are back to copying. One flow lets you leave chasing and go back to deciding.

![PM on Rails open-questions screen. Unresolved asks and waiting answers in one list. Before: the PM re-read notes and forgot to put Slack answers back. After: they return to review and decide.](https://pmonrails.com/docs-img/clarifications.png)

Screens to open next:

- [Collect into knowledge](https://pmonrails.com/en/docs/knowledge.md) — pile up meeting notes, documents and audio
- [Create requirement cards](https://pmonrails.com/en/docs/demands.md) — AI extraction, then split wishes from decisions
- [Decide the scope](https://pmonrails.com/en/docs/scope.md) — agree what you build and what you don't with MoSCoW
- [User stories](https://pmonrails.com/en/docs/stories.md) — expand into development units
- [Open questions](https://pmonrails.com/en/docs/clarifications.md) — see what still needs asking
- [Track progress](https://pmonrails.com/en/docs/progress.md) — roadmap, sprints, board and delay detection
- [AI assistant](https://pmonrails.com/en/docs/ai-assistant.md) — organise, summarise and check progress in conversation

## For engineers

**Who:** Anyone who has Claude Code or Codex writing code every day.

**The loss today:** Spec hunting is long, done is vague, and the board still needs a manual update.

**What changes:** You start implementing with background and acceptance criteria already connected. Pull request activity returns to the task and to progress.

| Before | After |
| --- | --- |
| You hunt for the spec and guess the place | You start after reading the background and acceptance criteria |
| Implementation moves, but the board still needs an update | The pull request returns to the task and to progress, so reporting work disappears |

**Why now:** If coding agents are in daily use, the quality of the map you hand them decides speed.

**Why this:** A tool that only passes a task title makes the agent guess. Requests, acceptance criteria, tasks and pull requests arrive connected, so you implement without returning to the board.

Screens to open next:

- [Claude Web, Claude Code and MCP](https://pmonrails.com/en/docs/mcp.md) — work with the same information from external AI tools
- [User stories and scenarios](https://pmonrails.com/en/docs/stories.md) — scenarios (Gherkin)
- [Design docs](https://pmonrails.com/en/docs/basic-design.md) — API and DB design documents (AI first drafts)
- [Task management](https://pmonrails.com/en/docs/tasks.md) / [Bugs and change management](https://pmonrails.com/en/docs/bugs-changes.md) — types, estimates, board, impact
- [GitHub integration](https://pmonrails.com/en/docs/github.md) — issue sync and pull request linking (a merge to a feature branch waits; it completes when that branch reaches main)
- [Track progress](https://pmonrails.com/en/docs/progress.md) — traceability and automatic estimates

Choosing "engineer" when you join guides you through the existing specification and documents → your work and assignments → connecting the AI you develop with, in that order.

![PM on Rails Claude Code / Codex integration. Background and acceptance criteria travel as one map. Before: engineers hunted specs and updated the board. After: they implement without returning to the screen.](https://pmonrails.com/docs-img/mcp-tools.png)

## For stakeholders (the people who ask for things)

**Who:** People (clients, the business side, internal requesters) who want to see how a request was reflected and when it will land. Read-only by default.

**The loss today:** After you delegate, the inside disappears, and you judge done right before delivery.

**What changes:** Requirement cards, scope decisions and the roadmap let you check what you asked for and when it arrives.

| Before | After |
| --- | --- |
| You wait for a report and cannot follow where your words went | As a viewer you can see requests, scope and the schedule |
| "Done / not what I expected" arrives at delivery | You can leave acceptance-test results and, if needed, a bug report |

**Why now:** The faster development gets, the larger the extra cost of invisible delegation.

**Why this:** You do not need to learn a new tool. The screens to look at are fixed, and anything you notice can be left as a comment.

Screens to open next:

- Once invited, you can see joined projects as a **viewer (read-only by default)**. You can also append comments, acceptance-test results, and bug reports linked to an acceptance scenario.
- [requirement cards](https://pmonrails.com/en/docs/demands.md) (how what you said became a request), [scope decisions](https://pmonrails.com/en/docs/scope.md) (how far we build this time), [roadmap](https://pmonrails.com/en/docs/progress.md) (when what ships)
- More on how permissions work → [Members and permissions](https://pmonrails.com/en/docs/members.md)

![PM on Rails roadmap. The plan and the chunk being built now. Before: stakeholders waited for a report. After: they can check what they asked for and when it will land.](https://pmonrails.com/docs-img/roadmap.png)

> Stakeholders are read-only by default. They can append comments, test results, and bug reports linked to an acceptance scenario, but cannot change existing records, specifications, or planning fields. Invite contractors who also do the work with a different role, such as editor ([Members and permissions](https://pmonrails.com/en/docs/members.md)).

---

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