This lesson is being recorded
Every video of this course is being uploaded to my YouTube channel. Subscribe so you do not miss it.
Bruno Ashford @brunoashfordSubscribeModule 13 · Lesson 13.3 · 11 min
Roles, Access and Owners
Define who builds, who approves, who uses and who maintains every skill and routine.
Use ← → to move. The marker highlights text and the pencil draws on the slide; navigation locks while you annotate. Undo removes the last mark, Esc exits.
1Define four roles
Builder: creates and edits skills and the plugin. Approver: signs off on changes and on sensitive outputs before they go out. User: runs the skills in daily work. Maintainer: keeps the shared CLAUDE.md and plugin versions current. In a small business one person can hold several roles, but every role needs a name.
2Fill the RACI matrix
Open the Roles and Access RACI matrix from this module's materials. One row per skill, agent or routine, one column per person or role. Put exactly one A in every row. Two accountable people means nobody is accountable.
Here is my team list with job titles (below) and the list of skills and routines in our acme-ops plugin. Draft a RACI matrix with one row per skill or routine and one column per person. Exactly one Accountable per row. Flag any row where the Accountable person would also be the only reviewer of sensitive output, and suggest a second approver.3Match access to role
Users need the plugin and only the connectors their work requires. Builders need write access to the plugin repository. Only approvers and admins should hold keys to finance or client systems. Use permission settings in the shared .claude/settings.json to deny risky actions for everyone, as covered in Module 11.
4Protect the approval gates
Anything that sends to clients, moves money or deletes data keeps a human approval step, no matter how senior the user. Write the approver's name next to every gate in the RACI. The gate is a rule, not a person's mood on a busy day.
5Review access every quarter
People change roles and leave. Once a quarter, compare the RACI with who actually has access to the repository, connectors and API keys. Remove what is no longer needed the same day someone leaves.
Ask a team "who owns the invoice follow-up routine?" and you will get three answers or silence. When something goes wrong, silence is expensive: a wrong reminder goes to a good client and nobody knows who should have caught it.
A RACI matrix fixes this in one page. For every skill and routine: who is Responsible for running it, who is Accountable for its output, who Contributes input when it changes, and who is Informed.
Key points
- Four roles: Builder, Approver, User, Maintainer.
- Exactly one Accountable person per skill or routine.
- Access follows role, not seniority.
- Client, money and deletion actions always keep a named approver.
Avoid
- Giving everyone builder access "to encourage experimentation" on the shared plugin.
- Two Accountable people on the same row.
- Forgetting to remove access when someone leaves.
- Letting the approval gate depend on who happens to be around.
An eight person accounting practice gave everyone the same access to its AI tools. When a junior accidentally ran a client reminder routine twice, two clients received duplicate chasers. The partners built a RACI: the practice manager became Accountable for all client-facing routines, juniors became Users with an approval step before sending, and only two people could edit the plugin. No duplicate has gone out since.