Every system has a tier. Know yours before you build.
Before you connect anything to anything, one question decides almost everything else: what are you about to touch, and what are you about to do to it? SRI keeps a running answer to that question so you never have to guess. It lives inside the /access-request skill, and Pat keeps it current.
The trick: it's not just "which system." It's "which system, doing what."
The same system can sit in two different tiers depending on what you're doing to it. Pulling a read-only report from Airtable is a completely different risk than writing to or deleting from Airtable, even though it's "the same system." So the tier comes from a combination: the system, plus whether you're only looking, or also changing something.
Just reading / looking
Pulling a report, exporting your own view, checking on something. Nothing changes for anyone else. Usually Green.
Creating, changing, or deleting
Updating records, posting messages, removing rows, moving files. Something changes that other people might depend on. Usually Yellow or higher.
A few examples from the live reference list
Green
Reading from Airtable, Slack, HubSpot, or company Google Drive. You're looking, not touching. Nobody else's work is affected.
Yellow
Writing to, updating, or deleting from those same systems. Same system, but now you're changing something other people may rely on. Needs Pat's review first.
Red
AWS (anything, any service) and DocuSign. These touch infrastructure, legal documents, or data sensitive enough that they're never automated directly. Pat or an engineer builds the interface for you instead.
Don't see your system on the list? That's not a dead end. It just means it hasn't come up yet. Mention it when you run /access-request, and the agent will help you reason through where it belongs using the same logic above, then flag it for Pat to add. The list grows as real projects come up and is never meant to be "finished."
Two skills, one ritual: /security-check → /access-request
You don't have to remember a checklist, fill out a form from scratch, or guess whether your work is "ready." Two skills handle the whole thing, built to chain together so you only ever have to think about the second one.
/security-check: your agent reviews your own work first
Run this on anything you've built, even a rough first version. It's a conversation, not a form: your agent reads through what you've made, asks for anything it can't find on its own, then walks the whole thing looking for real risks.
1
It reads your project and asks for anything it's missing: docs, notes, context about what it's supposed to do.
2
It checks for the things that actually cause problems: exposed passwords or keys, shaky or fake third-party packages, actions that delete or overwrite data with no way back, anything touching sensitive data, and permissions that ask for more than the job needs.
3
For every finding, it explains what it found and why it matters in plain language, then gives you the exact words to say to your agent to fix it. No guessing how to phrase the fix.
4
It always writes a dated report file into your project folder, even when everything looks clean. That report is your proof the check happened, your working notes for fixing anything, and the exact thing to send Pat if you ever get stuck, so he has full context immediately.
What the severity levels actually mean for you
Low
Worth knowing, unlikely to cause real harm. Just informational. It never stops you from moving forward.
Medium
Could cause a real problem if left alone, but you can fix it yourself with your agent's help, using the exact instruction the report hands you. Fix it, run the check again, move on.
High
Worth real attention before moving forward. Your agent will walk you through understanding and fixing it. Think of it as a teaching moment, not a wall. (The one exception: if something has already been exposed, like a real password sitting in a file, your agent will tell you to loop Pat in immediately too, because that kind of clean-up needs his help.)
/access-request: generates what Pat needs to say yes quickly
This is the skill you'll actually run when you're ready to ask for access. It interviews you in plain language, works out your tier using the live reference list, and produces two documents: a two-minute summary for Pat, and a full implementation doc his agent reviews for technical risk.
Here's the part that removes a step for you: if you haven't run /security-check yet, or your code has changed since the last time you did, /access-request notices and runs it for you automatically before continuing. You never have to remember to do it separately. One command, and the whole ritual happens in order.
If that automatic check turns up something High-severity, /access-request pauses right there. It won't generate your documents until you've worked through it with your agent (or, for the rare "already happened" cases, looped Pat in). That's the only thing that can slow this down, and it's there for a good reason.
Step 2 of 5
Step 3How it actually plays out
Real projects happen in phases. So do real requests.
You will rarely build something that touches only one system, and you will rarely need every piece of access on day one. Most projects unfold in stages, and the request process is built to move at the same pace you do.
Walkthrough: an Airtable-to-Notion sync
Phase 1
You're building something that pulls data from Airtable and reformats it into Notion. You can't build the Notion-posting half until you can see real, formatted data coming out of the Airtable half, so you start there. Once you have a rough version pulling from Airtable working, you run /security-check, work through anything it flags, then run /access-request. You explain you only need Airtable access for now.
What Pat sees: A focused, scoped request for "Airtable read access for a Notion sync project," with a current security check already attached. Easy to say yes to quickly.
Phase 2, weeks later
With Airtable access approved, you keep building. Now you're ready for the Notion half. You run /access-request again. It asks: "Is this a new project, or a continuation of something you've already requested?" You say it's a continuation, same sync project, now you need Notion too. The skill carries that thread forward for you.
What Pat sees: "Continuation of [Phase 1 request], same project. Here's what's new: Notion write access." He doesn't have to remember the whole history; the thread is right there in the doc.
The takeaway: never feel like you have to map out your entire project before asking for the first piece of access. Ask for what you need right now to keep moving. The process is designed to grow with your project, not to make you predict it in advance.
Step 3 of 5
Step 4Safe build practices
Good checkpoints, good habits
You don't need to be technical to build safely. You just need to know when to pause and check in, both with your agent and with the process. Here's the rhythm that keeps things moving without anything slipping through.
When to run /security-check
Once you've got a rough prototype working. Don't wait until the very end. Catching something early means fixing one small thing instead of unwinding a finished project.
Right before you ask for access to anything. This one's covered for you automatically by /access-request, but running it yourself first means no surprises mid-request.
Any time something feels "off." A script behaving unexpectedly, a new dependency you're not sure about, a system you've never touched before. That instinct is worth listening to. Run the check and see what it finds.
What happens after you submit a request
1
Pat reads your two-minute summary and skims the full doc. His agent has already reviewed it for technical risk, so he's not starting from zero.
2
He approves, denies, or comes back with questions. Don't acquire credentials through any other channel while you wait. If something's missing from your request, he'll ask.
3
Once approved, you're clear to build with real access, starting small, testing on samples, exactly like you practiced in Module 3.
One more habit worth building: once something you've made is actually working, consider running /documentation on it. It writes up a plain-language explainer covering what it does, why it exists, how to run it, and what to watch out for. That way, if you ever hand it off, move teams, or just don't touch it for six months, the next person (possibly future-you) isn't starting from a blank page. It's optional, it doesn't block anything, and it's one of the most useful five minutes you can spend on a finished project.
Step 4 of 5
Step 5Assignment
Run the ritual on something real
Three tasks. Together they walk you through the exact sequence you'll use every time you're ready to build something real: from "what tier is this?" to "here's my request, ready for Pat."
What you're practicing
The full pre-request sequence, on your own idea
Pick one real automation idea from your own role, even a rough one. You'll classify it, run a security check on whatever you've built so far (even a few lines count), and see exactly what your access request would look like.
Complete all three tasks
Classify your idea before you write a line of code
Describe your automation idea to Claude and ask it to work out the tier using the same read-vs-write logic from Step 1: Green, Yellow, or Red, and why. This is the same muscle you'll use every time you're about to build something new.
Apply It
Use this prompt:
"Here's something I want to build: [describe your idea]. Based on what it touches and whether it only reads or also writes/changes/deletes something, what access tier would this be (Green, Yellow, or Red) and why?"
Run /security-check on whatever you've built so far
Even a rough draft or a few lines count. The point is to see the process work on something real. Read through the report it generates. If it finds anything, work through it with your agent using the exact wording it gives you, then run the check again to see it clear.
Setup
Say this to start:
"Run a security check on this project before I go any further with it."
Walk through /access-request, even if you're not ready to submit
Run the skill and go through the conversation. Notice how it already knows about your security check (it'll find the report from the last task), how it works out your tier from the live reference list, and what the two finished documents actually look like. You don't have to submit anything yet. The goal is to see exactly what "ready" looks like before you get there for real.
Verify
Say this to start:
"I want to walk through what an access request for this project would look like. Let's go through the /access-request process."
0 of 3 tasks completed
✓ Module 4 complete
You know how to read the tier list, you've seen /security-check and /access-request work together on something real, and you know exactly what "ready to ask Pat" looks like. You're cleared to start building for real.
From here on, the ritual is the same every time: build a rough version → run /security-check → fix what it finds → run /access-request when you need access → Pat reviews → you build for real. No new process to learn as your projects grow. Just the same loop, repeated.
