When: you're building an agent or a skill whose answers people will act on, and you need them to trust what it says.
Built from: SentinelOne's SOC analyst skills (see the source page). A SOC is a security operations centre: the team that watches for attacks and investigates alerts. Their skills turn Claude into one of those analysts. The thirteen methods below are their practice, restated. Nothing here is specific to security.
What we've run: none of it yet.
Checking: say only what the evidence holds
- Cite every number and name to the check that produced it. Make the claim after the data exists: "about 30 machines" needs the query that counted them. Every number points to its check in the same reply, so someone else can run the check and get your answer.
- Use the same five confidence words, and never a stronger one than the evidence holds.
- Confirmed: two independent sources agree, and an outside check backs it.
- Consistent with: matches a known pattern, with partial or single-source support.
- Suggests: one weak signal. Worth a look, not action.
- Possible: nothing for, nothing against.
- No evidence of: you ran the checks and they came back empty.
- There are two ways to fail: sounding sure without the data, and burying a strong answer under caveats. When the evidence is strong, say it plainly.
- Mark each assumption, and say what would disprove it. Two lines: "Assumption: this account belongs to a person, not a service. Disproved by: the account's type in the directory." If one check can settle it now, run it. If the answer is the same either way, say so and move on.
- Never make up a count, name, ID or address. A made-up specific reads exactly like a real one, and the reader can't tell. A placeholder is written as
<placeholder>, never as a plausible value. If the data isn't there yet, run the query first, or say so. - Report an empty result and a tool error as findings. "Zero alerts in seven days" is information, so it stays in the summary. A tool error gets reported. Never switch quietly to another source and report as if the first one worked.
Reuse: don't learn the same thing twice
- Keep each fact in one place, and link to it everywhere else. Two copies of a fact drift apart, and then someone has to work out which is right.
- Learn the environment once, save it with an expiry, and rediscover only what's missing. Discovery costs the most, so do it once per project. Save what you found with a timestamp and an expiry, and reuse it until it expires. When one part is missing, rediscover only that part. Never assume a field exists because its name sounds likely: check the saved copy, or look.
- Make every approval fail closed. A step that waits for a person does nothing when the wait runs out. Silence is not a yes. Test the timeout path itself, because it's the path nobody watches. Their own example: an approval gate that ran a destructive action (block, isolate, disable) when the wait timed out, because the empty answer passed the check.
- Pin each lesson with a test that names the failure it prevents. A lesson written in words can be erased by the next careless edit. A test can't. Test the examples too, because examples are what gets copied.
Skills: how to package a practice
- Give each layer one job. Four layers:
- the persona decides: one instruction file for how the agent thinks, its rules for evidence, and which skill to use;
- an umbrella skill runs whole jobs, with no mechanics of its own;
- small skills hold confirmed facts: exact request shapes, fields that really exist, the costliest mistakes;
- tools give live access to the real system. When the umbrella copies a small skill's mechanics, the two drift apart.
- Ask for the settings once, show a dry run, then deploy in order. Pick the job, or ask. Ask only for the settings it needs, in one short set with defaults filled in. Confirm the target and read what already exists before overwriting it. Show the finished config as a dry run. Deploy through the small skills in the order they depend on each other. Check with a real run, and report what came back.
- Merge each learning into the closest existing rule. At the end of a session, pull out what will still hold next time, and skip one-off details like an ID or a hostname. Merge each one into the closest rule already written, because a new note beside an old one is how duplicates start. Show the change and wait: the agent never edits its own instructions without a yes.
- Ship every skill with evals. Each eval is a realistic request plus what a good answer contains. Without them, an edit that makes the skill worse looks the same as one that makes it better.