Claude Code Tools

Security Prompts for One-Person Teams: 6 That Prioritise Instead of Listing

OpenAI put water systems and local government defenders first in its Daybreak pilot, and paired the access with training — because the constraint on a one-person security team is never detection, it is capacity to act on what gets found. These six prompts are built for that: triage over enumeration, and a defensible order rather than a longer list.

⌨️ 6 prompts 🕐 Updated Sep 5, 2026

💡 How to use these prompts: Replace everything in [BRACKETS] with your specific details before sending. Click Copy to copy any prompt to your clipboard instantly.

Tell me what to fix first

Scanners produce lists. The last instruction is what turns one into a plan.

Here are the findings from a scan: [PASTE]

Do not summarise them. Rank them by what I should fix first, given I am one person with limited time.

For each of the top five: why it ranks there, what fixing it actually involves, and what happens if I leave it another month.

Then tell me which of the rest I can safely ignore, and say so plainly.

Work out what an attacker would try first

Attacker order and severity order are different. Defending in attacker order protects you sooner.

Here is my environment: [DESCRIBE]

Walk through what someone would attempt first, and why. Order by what they would actually do rather than what is theoretically possible.

For each step, tell me what would stop it and whether that control exists in what I described.

Check whether a finding is real

False positives eat small teams alive. Confirming before acting is the highest-value habit.

A scanner reported this: [PASTE FINDING]

Tell me:
- What it is claiming, in plain terms
- What would confirm it is genuine
- What would show it is a false positive
- Whether it is exploitable in my context: [DESCRIBE]

If you cannot tell from what I have given you, say what else you need.

Write the fix and the test together

Fixing one instance of a bug class leaves the rest. Asking for the class is the difference.

I need to fix this: [DESCRIBE THE ISSUE]

Give me:
- The change
- A test that proves the fix works
- A test that would have caught it originally
- What else in my system probably has the same problem

The last one matters most. I want the class, not the instance.

Prepare for the thing I cannot prevent

Written beforehand this is a runbook. Written afterwards it is an inquest.

Assume this happens: [SCENARIO]

Write the runbook. What I check first, how I stop it spreading, what evidence to preserve, who to notify and in what order, and how I would know it was over.

Write it as steps I could follow at 2am with no sleep. Not principles.

Make the case for resources

The last line keeps it credible. Overstated risk gets discounted next time you ask.

I need to explain to non-technical decision makers why this needs funding: [DESCRIBE THE RISK]

Write it in terms of consequence rather than technology. No jargon.

Include what happens if nothing is done, what the smallest useful investment achieves, and what it does not cover.

Do not exaggerate. If the honest case is weak, tell me that instead.