Team Workflow Guide

One team, every role,
one shared brain.

How PM, Developer, QA and Documentation work together through mxLore — from the first idea to shipped and documented — without losing context along the way. The secret: you talk, the AI handles the tools.

See it end-to-end Connect your team

// The big picture

A shared brain and workspace

Every piece of knowledge your team produces — specifications, plans, architectural decisions, bug reports, feature requests, QA findings, lessons learned — lives in one place, visible to everyone, and recalled automatically whenever it's relevant.

The most important thing to understand:
you don't have to learn any tools or commands. You talk; the AI acts.

There are two ways your people interact with the same shared brain:

Surface	Who uses it	How it feels
Claude Code CLI / IDE	Developers	The full mx-skills — `/mxSpec`, `/mxPlan`, `/mxOrchestrate`, `/mxSave`, `/mxBugChecker`. Structured and automated.
Claude chat claude.ai + MCP	PM, QA, Documentation — anyone non-coding	Just describe what you want in plain language. The AI reaches into mxLore and picks the right tool itself. No commands to memorize.

A PM never types a command. They say "write this up as a feature and hand it to the dev team" — and Claude creates the document and notifies the developers. A developer gets the extra power of skills, but underneath it's the same knowledge base everyone shares.

Because the knowledge is shared and recalled automatically, handoffs carry their full context. Nobody copies text between tools. Nobody re-explains last week's decision. When the next person — or their AI — opens the topic, the history is already there.

// One server, many workspaces

Many projects, many people — name your project

mxLore is a shared server. It usually hosts several projects and several team members at once — each with its own specs, plans, decisions and history, and each member only sees the projects their key grants them.

one server → webshop mobile-app internal-erp website …

Because of that, every piece of work is scoped to a project. You still just talk — you only name the project once.

In Claude Code

Automatic

The project is set from the folder you're working in — its CLAUDE.md carries the project name. The session already knows it's the webshop project. You don't have to say it.

In Claude chat

Name it once

There is no folder, so tell Claude which project you mean the first time: "In the webshop project, write a feature for…" Claude keeps it in mind for the rest of the chat. Unsure? Ask "which projects can I access?"

This is how a PM keeps different products apart: a feature request created "in the webshop project" lands in the webshop's knowledge, is recalled for webshop developers, and never bleeds into the ERP project. One server, many clearly separated workspaces.

Rule of thumb: in a browser chat, start with the project — "In project X, …". In Claude Code, the folder already answers that for you.

// The cast

The roles at a glance

These four roles are conventions, not something mxLore enforces. Use them as-is, rename them, or add your own. They simply describe who tends to produce what.

PM / Product

The "what" & "why"

Owns direction and priorities

Feature requests
Specifications
Change requests

via claude.ai chat

Developer

The "how" & the code

Owns implementation

Plans
Decisions (ADRs)
The build & bug fixes

via Claude Code (skills)

Quality & proof

Owns sign-off

Review findings
Verified bug reports
Sign-off

via Claude Code or chat

Documentation

The user-facing story

Owns the docs

End-user docs
Release notes
How-tos

via claude.ai chat

// One feature, idea → shipped → documented

Follow a real feature through every handoff

Let's track one feature — "Add two-factor authentication (2FA) to login" — through every role. Watch how the work moves without anyone copy-pasting or re-explaining.

PMspec

Developerplan + build

QAreview

Documentationuser docs

changePM pushes a mid-flight requirement → the Developer's AI surfaces it from the inbox at the next session.

bugQA finds an issue → it flows back to the Developer, linked to the spec, then forward again once fixed.

every arrow is just a person talking to Claude — mxLore carries the context

PM · Paula

Start the topic

Paula opens claude.ai and describes the idea in plain language:

We need two-factor authentication on login. Write it up as a specification: authenticator-app support, optional per user, needed for the enterprise tier.

Claude writes a proper specification into mxLore — acceptance criteria, constraints, the "why". Paula reviews it, then: "Looks good — hand this to the dev team."

Behind the scenes: spec creation + agent messaging. Paula never names a tool.

Developer · Dario

Pick it up — with full context

Dario starts a Claude Code session the next morning. Before he asks anything, Claude recalls Paula's new spec and the handoff. He says "let's plan the 2FA feature" and /mxPlan turns the spec into milestones.

Hitting a design fork — authenticator app (TOTP) vs SMS — he records the choice so nobody re-litigates it:

Use TOTP (RFC 6238), not SMS — SMS is phishable and adds carrier cost.

Behind the scenes: the decision is stored and linked to the spec as part of the workflow.

PM · mid-flight change

Push a change — without an email thread

Partway through, Paula learns compliance also requires backup recovery codes. From claude.ai:

Add a requirement to the 2FA spec: users must be able to generate one-time backup recovery codes.

Claude updates the spec and flags Dario. At his next session, Claude surfaces it: "Heads up — the 2FA spec changed: backup codes are now required." He adjusts the plan and implements them. The change traveled with the work.

Developer → QA

Hand off to QA

When the implementation is done, Dario says "mark the 2FA feature ready for QA." QA is notified, with the spec, the plan, and the TOTP decision all attached.

QA · Quinn

Review — and find something

Quinn reviews the change — in Claude Code with /mxBugChecker, or simply by asking chat to review it against the 2FA spec. Claude finds the backup-code endpoint isn't rate-limited. Quinn logs it:

File a bug: backup recovery codes can be brute-forced — no rate limit on the verify endpoint.

The bug is stored, linked to the spec, and Dario is notified. He fixes it, re-flags QA, and this time the review passes. The bug ↔ spec ↔ fix chain is now permanent history.

Documentation · Dana

Close the loop

Dana opens claude.ai:

Write end-user documentation for the new 2FA feature — how to turn it on, how backup codes work.

Claude recalls the final spec, the TOTP decision, and the as-shipped behavior, and drafts the user docs from the real source of truth — not from a guess about what was built.

∞

And later…

The knowledge stays

Three months on, someone asks "why did we choose TOTP over SMS again?" Anyone — PM, new hire, support — asks Claude, and the decision from step 2 comes back instantly, with its reasoning. The knowledge didn't leave with the person who made it.

// Why it stays smooth

Handoffs without friction

Three mechanisms make the choreography above smooth. None of them require a human to manage them — they're just there.

Shared knowledge

Specs, plans, decisions, bugs and findings live in one database. Every role sees the same source of truth. When the spec changes, it changes for everyone — no stale copies.

Agent messaging

When you say "hand this to the devs" or "this is ready for QA", Claude leaves the handoff in mxLore's inbox. The next person's AI checks that inbox when it starts a session — automatically in Claude Code, on demand in a browser chat — so nothing falls through the cracks.

Automatic recall

Open a topic next week or next quarter and Claude pulls back the relevant history — the original spec, the decision, the bug that was found and fixed — without anyone searching for it.

The net effect: no copy-paste between tools, no lost context, no "who has the latest version?" The work moves; the context moves with it.

// Under the hood (optional reading)

Capability cheat-sheet

You don't need this to use mxLore — the AI picks the right tool for you. It's here for the curious, and so developers know which skill maps to which intent.

What you want to do	Developer in Claude Code	Anyone in chat — just say…
Capture a feature or write a spec	`/mxSpec`	"write a spec for…"
Turn a spec into a plan	`/mxPlan`	"turn this into a plan"
Record an architectural decision	`/mxDecision`	"record the decision to use X over Y, and why"
Find / recall existing knowledge	automatic, or just ask	"what do we know about…?"
Review code/design vs the spec	`/mxDesignChecker`	"review this against the spec"
Find bugs with proof	`/mxBugChecker`	"review this change for bugs"
Hand work to another role	"notify QA this is ready"	"let the dev team know this is ready"
Persist the session	`/mxSave`	nothing to do — saved as created

The pattern: a developer's /mxSpec and a PM's "write a spec for…" do the same thing — one through a skill, one through plain conversation.

// Not a straitjacket

Roles are conventions, not configuration

mxLore does not hard-code "PM" or "QA". The roles here are a way of working, not a setting.

Want light gating? Each team member's access key can be readwrite or readonly. Give Documentation readonly so they consume and reference specs but don't alter them, or keep everyone readwrite for a small, high-trust team. This is optional — see the onboarding guide for how keys and access levels are issued.

Mix surfaces freely. A developer can review in Claude Code while a PM watches the same spec evolve in claude.ai. One shared brain, two windows into it.

Everyone talks to the same brain — in their own way.

Connect your team, run this 2FA-style flow once on a small real feature, and the handoffs become second nature. You'll have a living example in your knowledge base to point new people at.

Onboard your team Quick start

▸ Built with mxLore, about mxLore, for the teams adopting mxLore.