Prompt Engineering for Security Professionals
The anatomy of an effective prompt
Every effective prompt has three components. Most bad prompts are missing at least one.
Context is what Claude needs to know to produce relevant output. Without context, Claude defaults to the broadest interpretation. “Write a KQL query” produces generic output. “Write a KQL query for Microsoft Sentinel that investigates sign-in anomalies for a user whose account was compromised via AiTM phishing 3 days ago” produces targeted output. The more specific the context, the more specific the result.
Constraints define what the output must include, exclude, or conform to. “Use the SigninLogs table. Include both interactive and non-interactive sign-ins. Time range: 7 days. Exclude known corporate IPs from the CorporateExternalIPs watchlist.” Without constraints, Claude makes assumptions — and its assumptions may not match your environment.
Output format specifies what the response should look like. “Return the query as a code block with inline comments explaining each operator.” Or: “Return a markdown table with columns: Finding, Evidence, Severity, Recommendation.” Specifying format eliminates the most common frustration: Claude producing a great analysis buried in paragraphs of prose when you wanted a structured checklist.
The three components work together. Context tells Claude what to think about. Constraints tell Claude what to include and exclude. Output format tells Claude how to present the result. Miss one, and the output degrades.
XML tags for structured prompts
Claude is specifically trained to follow XML tag structures. When you wrap sections of your prompt in XML tags, Claude processes each section with its intended purpose. This is not a general AI tip — Anthropic explicitly recommends XML tags as the most effective way to structure complex prompts for Claude.
Worked artifact — XML-structured security prompt:
<context> A user account (j.morrison@northgateeng.com) was compromised via AiTM phishing 3 days ago. Containment was executed: password reset, token revocation, MFA re-registration. We need to verify that no attacker activity persists. </context> <task> Write a KQL query that checks for any sign-in activity from non-corporate IPs in the 72 hours following containment. </task> <constraints> - Use SigninLogs and AADNonInteractiveUserSignInLogs (check both) - Exclude IPs in the CorporateExternalIPs watchlist - Include: TimeGenerated, IPAddress, AppDisplayName, AuthenticationRequirement, ResultType - Time range: 72 hours from containment at 2026-03-20T14:00:00Z </constraints> <output_format> KQL code block with inline comments. No prose explanation needed. </output_format>This prompt will produce a focused, deployable KQL query on the first attempt because every component is explicit. Copy the structure and replace the content for your own investigation scenarios.
The XML tags you use most frequently in security work are <context> (incident details, environment specifics), <task> (what you want Claude to do), <constraints> (requirements the output must satisfy), <output_format> (how to structure the result), <data> (log entries, alert details, or other evidence to analyze), and <examples> (sample outputs showing the format you want).
You do not need to memorize tag names. Claude responds to any descriptive XML tag. <investigation_notes> works as well as <data>. The tags serve as section boundaries that help Claude parse the different parts of your prompt.
System prompts and Project Instructions
System prompts (called “Project Instructions” in Claude.ai Projects) set persistent behavior. They are processed before every user message and shape how Claude responds across an entire project. Think of them as standing orders — you write them once and they apply to every conversation.
A strong security operations system prompt eliminates the “Claude gave me a generic response” problem. Every conversation in the project produces output calibrated to your environment because the system prompt already contains your Sentinel workspace details, your naming conventions, your reporting format, and your operational constraints.
The system prompt from F2’s worked artifact is the starting point. Refine it as you use Claude — if you notice Claude consistently making an incorrect assumption, add a correction to the system prompt. If you find yourself repeating the same instruction in every conversation, move that instruction into the system prompt. Over time, your system prompt becomes a comprehensive configuration that makes Claude behave like a team member who understands your environment.
Few-shot examples for consistent formatting
When you need Claude to produce output in a specific format — and that format is complex or unusual — the most effective technique is providing an example of the desired output in the prompt.
Worked artifact — few-shot example for detection rule documentation:
<task> Document the following detection rule using the format shown in the example. </task> <example_format> ## [Rule Name] **MITRE ATT&CK:** [Technique ID] — [Technique Name] ([Tactic]) **Severity:** [High/Medium/Low] **Data Source:** [Sentinel table(s)] **Trigger Condition:** [Plain English description] **Expected False Positives:** [Scenarios that fire this rule legitimately] **Tuning Guidance:** [Parameters to adjust for your environment] **Entity Mapping:** [Account, IP, Host — as applicable] ### KQL [Query with inline comments] ### Investigation Steps 1. [First action when this rule fires] 2. [Second action] 3. [Escalation criteria] </example_format> <rule_to_document> A query that detects inbox rules containing financial keywords (invoice, payment, wire, bank) created from non-corporate IPs. Uses OfficeActivity table. </rule_to_document>Claude will produce documentation matching your example format exactly. This technique scales — once you have a good example, reuse it as the template for every detection rule you document. Better yet, save it as a Skill (see below).
Few-shot examples work because Claude is pattern-completing by nature — given an example of the desired pattern, it extends that pattern to new content. The example does not need to be perfect. It needs to show the structure, the sections, the level of detail, and the tone you expect.
Chain-of-thought for investigation reasoning
For complex analytical tasks — determining whether a sign-in anomaly is a compromise or a false positive, reconstructing a multi-stage attack timeline, or evaluating whether a set of conditions justifies invoking the incident response plan — Claude produces better output when you ask it to reason through the problem step by step.
The technique is simple: add “Think through this step by step” or “Walk me through your reasoning before reaching a conclusion” to the prompt. Combined with Extended Thinking (F2), this produces structured analytical output that mirrors how an experienced analyst approaches an ambiguous situation: identify the evidence, consider alternative explanations, evaluate each against the evidence, and reach a conclusion with stated confidence.
For security work, chain-of-thought is particularly valuable when the answer is not obvious — when the evidence could support multiple conclusions and the analyst needs to evaluate each possibility systematically.
Skills — persistent reusable workflows
Skills are the next level above few-shot examples. Where a few-shot example shows Claude the format once (and you must include it every time), a Skill persists across sessions and is applied automatically when the task matches.
You create a Skill in Claude.ai by navigating to your profile settings or by typing /skill in a conversation. A Skill consists of a name (what it does), trigger conditions (when Claude should apply it), and instructions (the format, conventions, and requirements).
For security professionals, Skills codify your team’s standards. A detection rule documentation Skill ensures every rule is documented in the same format with MITRE mapping, severity, false positives, tuning guidance, and investigation steps. An IR report Skill ensures every report follows your organizational template with the correct sections, tone, and level of detail. A KQL style Skill ensures every query uses your naming conventions, comment standards, and operator preferences.
The Skills marketplace (skillhub.club) has over 7,000 community-created Skills with quality scores. For Team and Enterprise plans, administrators can distribute approved Skills across the organization — ensuring every analyst’s Claude output meets the same standard without each person building Skills from scratch.
Try it: Apply the three-component structure
Open your Security Operations project (from F2). Write a prompt using the XML tag structure from the worked artifact above — with <context>, <task>, <constraints>, and <output_format> tags. Ask Claude to generate a KQL query for a security scenario relevant to your environment (failed MFA attempts, suspicious inbox rules, sign-ins from unexpected locations). Compare the output quality to what you get from a plain-text prompt without the structure. The difference in specificity and deployability is the value of structured prompting.
Try it: Create your first custom Skill
Identify the output format you use most frequently in your security work — detection rule documentation, alert triage notes, IR report sections, or threat briefings. Create a Skill that defines this format: the required sections, the naming conventions, the level of detail, and any standard fields (MITRE mapping, severity, entity mapping). Then test it by asking Claude to produce that output type in a new conversation — the Skill should apply automatically without you specifying the format. If the output does not match your expectations, refine the Skill instructions and test again.
Knowledge checks
Check your understanding
1. You ask Claude to "write a KQL query for sign-in anomalies" and the output is a generic query that does not reference your specific tables, watchlists, or time constraints. What is missing from your prompt?
2. You want every detection rule your team documents to include the same sections: MITRE ATT&CK mapping, severity, data source, trigger condition, expected false positives, tuning guidance, entity mapping, KQL query, and investigation steps. What is the most effective way to ensure this consistency across all analysts?
3. During an investigation, you need Claude to analyze ambiguous sign-in data and determine whether the activity represents a genuine compromise or a legitimate scenario (the user recently travelled). What prompting technique improves the quality of Claude's analysis?
Key takeaways
Every effective prompt has three components. Context (what Claude needs to know), constraints (what the output must include/exclude), and output format (how to present the result). Miss one and the output degrades.
XML tags structure complex prompts. Claude is specifically trained to follow XML tag boundaries. Use <context>, <task>, <constraints>, <output_format>, <data>, and <examples> to separate the components of complex prompts.
Few-shot examples ensure format consistency. Show Claude one example of the desired output and it extends the pattern to new content.
Chain-of-thought improves investigation analysis. Ask Claude to reason step by step for ambiguous evidence analysis. Combined with Extended Thinking, this produces systematic analytical output.
Skills codify your team’s standards. Create Skills for your most common output formats. Distribute them across the team for consistent quality without individual effort.