How it works

Three parts, one loop

MOS is a set of skills an AI runs against your company's own files. How the parts fit together, what a skill actually is, and where your documents go when one runs.

01

The three parts

Your own files, a skill that does one job, and an AI that can read and write those files. The skills and the AI are replaceable. Your context is the part that compounds.

  1. 01

    Your context

    The files your company already has — intended use, user needs, risk file, design inputs. This is what makes the work specific to your device.

    You own it

  2. 02

    A MOS skill

    A folder you download: written instructions, the templates it fills, and any scripts it needs. One job each, versioned and replaceable.

    You download it

  3. 03

    The AI that runs it

    An AI that can read and write files in a folder — Claude Code, or another coding agent your company approves. Point it at the folder and ask for a skill by name.

    You set it up once

What comes back

The AI reads your context, follows the skill's instructions, asks you about the gaps, and writes a draft into your own files — your device, your terminology. You review it, and the outputs you approve build your context for the next skill.

02

From download to first draft

The first four you do once. The fifth is the one you repeat — for every skill, and every deliverable.

  1. 01

    Download MOS

    The download link lives in the Medtech Mindset community, and points at the current release. Download the ZIP, unzip it, and put it next to where your company's work lives. No MOS account, no installer, no Git.

    Inside are the charter, the context standard — the reference every skill is written against — and the skills themselves. Each skill is its own folder: the instructions your AI follows and the templates it fills. A shared lib/ folder holds the scripts for the steps that should not be improvised: writing Word documents, searching public databases, sizing studies. Most of what you download is text you can read before you run anything.

    The scripts are Python. Setup checks for it and asks before installing anything.

    Ends with a mos/ folder on your machine, next to your own files.

  2. 02

    Connect an AI to it

    MOS skills are run by an AI that can open, read and write files in a folder on your machine. A browser chat window cannot do it: paste a skill's instructions into one and you get a generic answer, because nothing has read your context.

    The products that can are usually called coding agents or AI code editors. The name fits badly — there is no coding in running a user needs skill — but it is what to look for. Claude Code is what MOS skills are built and tested against.

    This is the only step with nothing to do with medtech, and it is the one most people have never done before.

    Ends with an AI that can open the folder, read what is in it, and write back.

  3. 03

    Map the files you already have

    Tell MOS once where your existing work lives: this folder holds design inputs, that one is the risk file, this one is regulatory correspondence. You keep your folder names and your structure. Nothing is moved, renamed or copied.

    Starting fresh, with nothing to map? Skip it — setup creates the layout for you in the next step.

    Ends with your own folder structure, readable by every MOS skill.

  4. 04

    Run setup and answer the interview

    Ask your AI to run the setup skill. It interviews you about your device — what it is, who it is for, intended use, where you are in the lifecycle — and writes your answers into the context folder.

    Because you mapped your files first, the interview starts from what your company has already written rather than from nothing. It asks about what is missing, not about everything.

    Ends with a context folder that already describes your device.

  5. 05

    Run a skill

    Point the AI at the folder and ask for a skill by name — run the user needs skill. It reads the skill's instructions, reads your context, interviews you about the gaps, and writes a draft into your files.

    You review it. Every output must be reviewed and approved by qualified people at your company. What you approve builds your context, so the next skill starts further ahead.

    Ends with a draft you can take into review, and more context than you had.

03

The default layout

What MOS scaffolds when you have nothing yet. Two directories that matter: one you own, one you can throw away and re-download.

Acme Medical/                 <- your folder
├── mos/                      <- downloaded from MOS; replaceable
│   ├── CHARTER.md
│   ├── context-standard.md
│   ├── lib/                  <- shared scripts every skill can call
│   └── skills/               <- one folder per skill, same shape inside
│       ├── setup/
│       ├── user-needs/
│       │   ├── SKILL.md      <- the instructions the AI follows
│       │   └── templates/    <- the documents it fills in
│       ├── differentiation/
│       ├── product-code/
│       ├── precedent-search/
│       ├── reimbursement/
│       └── indications-strategy/
├── context/                  <- your data; MOS never gets a copy
│   ├── product/
│   ├── users-and-needs/
│   ├── risk/
│   ├── design/
│   ├── manufacturing/
│   ├── clinical/
│   ├── regulatory/
│   └── commercial/
└── outputs/                  <- drafts, in the same eight domains

04

You decide what the AI reads

MOS never receives your files. The AI you run the skills with does — and you set what it can reach, see what it opened, and approve everything that comes back.

MOS gets no copy

No account, no server, nothing to upload. What you download is a folder of instructions and templates. Your files stay where they are.

Your AI provider reads them, not MOS

When a skill runs, the contents of the files it opens are sent to that provider as prompt text — the same as pasting them into a chat window yourself. Retention, training and data residency are governed by the agreement your company already signed with them. MOS is not a party to it.

Public databases get search terms, never files

Five skills search government records: FDA and the eCFR, the National Library of Medicine, ClinicalTrials.gov and Medicare's coverage database. The requests go from your machine straight to the agency and carry only generic terms — a device type, a product code, a condition. Never your product's name, its indications, its claims or any file's contents. Each request is shown to you before it runs, and logged in the document it produces.

Nothing is read unless you point at it

Skills work from the map you make at setup. A folder you have not mapped is not part of the job, and a file nobody classified is a file nobody reads.

Outside the map, a skill asks

When a skill needs something you have not mapped, it asks for it by name and records your answer. The decision sits where you have the context to make it, rather than up front across everything your company owns.

You can see what was opened

Skills read whole files by name, so what the AI saw is a list you can read. There is no search index pulling fragments out of documents you thought were out of scope.

You approve every output

Drafts land in outputs/, outside your quality system, until a qualified person at your company reviews, approves and imports them.

What this is not

These are rules the AI follows, not a lock on your files. They make what gets read predictable and visible; they do not make a mistake impossible. A company that cannot tolerate a single one should set file permissions on the machine — an operating-system job, not a job for a convention.

How uploaded differs from sent as a prompt, what to ask your AI vendor, and what to do if nothing may leave your company at all — the FAQ.

05

Skills: one job each, in a package

A MOS skill is not a document you read. It is a folder your AI executes: instructions and the templates it fills, calling shared scripts where a step must be exact.

What is inside a skill

01 Instructions

A SKILL.md naming the skill, when to use it, and the numbered steps to execute.

02 Templates

The documents the skill fills in — the deliverable's actual shape.

03 Shared scripts

Deterministic helpers for the parts that should not be improvised — Word documents, database searches, study sizes. Kept in mos/lib/ and called by any skill that needs them.

04 A named maintainer

A person who owns it and reviews changes to it.

Skills are versioned, and each one does a single job. If it cannot be described in one sentence, it is two skills.

06

The AI: one that works in your files

MOS does not ship an AI and does not sell one. It needs one that can read and write files in a folder on your machine.

What it has to be able to do

Open, read and write files in a folder you point it at. That rules out a browser chat window and rules in a coding agent — Claude Code, or another your company approves. Skills are designed and tested on Claude first; where one fails on another runtime, that is a bug in the skill.

Runs where you are

The AI reads the folder on your machine. There is no MOS account and nothing to upload to MOS. What you configure is your own AI's access to the folder, once.

You invoke it by name

Point the AI at the folder and ask for the skill — run the user needs skill. It reads the instructions, reads your existing context, interviews you about the gaps, and writes a draft back into your own files.

You approve everything

Output is a draft. Every one must be reviewed and approved by qualified people at your company before it goes anywhere.

07

Why the three compound

Every skill works with no context at all. It gets better as your context fills in, which is the whole reason the loop is worth running.

No context. A good template and an expert-written process — roughly what free template libraries offer today.

Day one

Partial context. Drafts specific to your device rather than generic boilerplate.

A few skills in

Full context. New work traceable to what already exists, with contradictions between documents flagged.

Compounding

Early skills are chosen to build context rather than only consume it. That is why setup comes first and user needs soon after — setup describes the device, user needs starts design controls, and everything downstream reads both.

What never happens

Nothing company-specific ever enters the public MOS repository. Contributions are skills and templates, never anyone's device data.

See which skills apply to your stage

08

You are not expected to already know this

Most people arriving at MOS have never run design controls and have never set up an AI to work against their own files. Both are taught, step by step.

The education layer exists because knowing what to produce is only half of it. Every skill is paired with an explanation of why that step exists and what a reviewer is looking for, so you are learning the discipline while you produce the deliverable — not filling in a form you do not understand.

Getting set up

Start from zero

Walkthroughs for the parts that have nothing to do with medtech: creating your context folder, connecting the AI you use, and running your first skill end to end.

Every skill

Written instructions

Each skill is plain-language Markdown: the steps it follows, what it reads and what it writes. You can read it through before you run anything.

Classroom

Video walkthroughs

Recorded sessions in the Medtech Mindset Classroom covering the same ground on screen, for people who would rather watch it done once.

The education layer is being built alongside the skills. Its current state is listed on the home page.