tracecathq/tracecat/intelligence-requirements-builder

Intelligence Requirements Builder

This skill helps a CTI analyst convert an informal stakeholder request into formally codified intelligence requirements. The output should be precise enough that a CTI team could begin collection against it immediately, structured enough to slot into an existing intelligence requirements list, and concise enough that a busy analyst can scan it in under a minute. Favor brevity throughout: short phrases over full sentences in structured fields, and no filler.

Before producing requirements, read references/ir-definitions.md to ensure correct terminology, and read references/requirement-quality.md to ensure every requirement is written to the quality standard. Intelligence requirements have specific meanings inherited from military and government intelligence practice, and using the wrong term (for example, conflating prioritized intelligence requirements with Priority Intelligence Requirements) undermines the credibility of the output. Equally, a requirement that asks two questions at once, or asks a question that collection cannot answer, undermines the credibility of the whole set.

Workflow

Follow these six stages in order. Do not skip the clarification stage unless the user's request already contains the answers.

Stage 1: Intake

Parse the stakeholder ask and extract what is already known:

• Stakeholder: Who is asking, and what is their role? (CISO, SOC lead, fraud team, executive leadership, product team, etc.)
• Decision: What decision or action will this intelligence support? Every requirement must link to a decision; intelligence without a decision attached is trivia.
• Timeframe: Is this a one-off, time-bound need or an ongoing concern?
• Scope: Which assets, business units, geographies, technologies, or threat types are implicated?

State your initial read back to the user in two or three sentences before asking anything. This shows the analyst what you have inferred and lets them correct you early.

Stage 2: Clarify

Ask only the questions you cannot answer from the request itself, and ask no more than five. Prioritize in this order:

1. What decision will this intelligence inform, and who makes it?
2. When is the decision being made (or is this an enduring concern)?
3. What does the stakeholder already know or believe about this topic?
4. What would a useful answer look like to them (a briefing, a report, an alert, a recommendation)?
5. Are there constraints on scope (specific regions, subsidiaries, technologies, or threat actors)?

If the user cannot answer a question, proceed with a documented assumption rather than blocking. Mark every assumption clearly in the final output so it can be validated with the stakeholder later.

Stage 3: Classify

Determine whether the need is enduring or priority, and say which explicitly:

• Enduring requirement (GIR or SIR): An ongoing intelligence support need with no fixed end date. Example: "What ransomware groups are targeting the financial services sector in North America?"
• Priority Intelligence Requirement (PIR): A time-bound need with a short shelf life, usually landing as an unscheduled RFI, that pulls the team's attention and resourcing toward a decision that has to be made soon. Example: "Is the vulnerability disclosed yesterday in our VPN appliance being actively exploited in the wild?"

Apply this test: if the requirement still matters in 90 days in roughly its current form, it is likely enduring. If it expires once a specific decision is made or event passes, it is likely a PIR.

Do not label an enduring requirement as a PIR simply because the stakeholder is senior or the topic feels urgent. A team that ranks its enduring requirements has prioritized intelligence requirements; that is a different concept from a PIR, and the distinction matters. See references/ir-definitions.md for the full explanation.

Stage 4: Decompose

Decompose the ask into candidate requirements, then keep the final set small. If the stakeholder asked a single question, fully enrich only the 2 to 4 requirements most load-bearing for the decision identified in Stage 1, and never more than 6. If the stakeholder asked more than one distinct question, keep all the resulting requirements in one combined set and fully enrich 1 to 3 requirements per question; this budget applies per question, so three questions may yield up to nine enriched requirements in the single set. The questions stay distinct inside that one set: each requirement records which stakeholder question and decision it traces to (via its linked-decision field and, in the CSV, its Stakeholder and Decision_Supported columns), so context is never lost even though everything lives in one place. List any remaining valid questions in a single "Candidate requirements" section at the end of the set so the team can promote them later if capacity allows. Candidates get the question and a one-line rationale only, with no EEIs, collection guidance, or criticality scores, and they never enter the CSV ledger. Before writing any requirement, read references/requirement-quality.md for the full standard and worked examples of bad questions rewritten into good ones.

Every requirement must pass all five tests below. If it fails any one, rewrite or split it before moving on. According to CTI best practices, a strong requirement is singular, atomic, decision-centric, and timely: it asks only one question, focuses on a specific fact, event, or activity, and supports a single decision. This skill adds a fifth test, answerability, which commercial CTI practice makes necessary.

1. Singular. One question per requirement, asking one thing. If the question contains "and" joining two distinct asks (actors and techniques, footprint and pipeline), split it into separate requirements. A parenthetical enumeration of categories within a single fact is acceptable; a second question clause is not.
2. Atomic. The requirement targets a specific fact, event, or activity. "What is happening with ransomware?" is a topic. "Which ransomware operations have claimed victims in our sector in the past 12 months?" is a fact to establish.
3. Decision-centric. Answering the requirement supports one decision identified in Stage 1. Note the linkage explicitly in the requirement's linked-decision field. If a requirement supports no decision, cut it. If the ask spanned several questions, the set may serve several decisions, but each individual requirement must still map to exactly one of them.
4. Time-bound. The question states its timeframe inside the requirement itself ("over the past 12 months", "before the Q3 board decision"). A requirement without a timeframe cannot be judged answered, current, or stale.
5. Answerable with CTI. The question must be answerable through collection and analysis of observable evidence, internal or external. Questions that ask the team to predict the organization's own future ("How likely are we to be breached?") are risk judgments, not intelligence requirements. Do not write them. Instead, decompose them into the observable questions that feed the judgment (incident frequency among comparable organizations, evidence of targeting, evidence of techniques defeating controls equivalent to ours) and state in the requirement set that the final risk call is the stakeholder's synthesis of that evidence.

In all cases, a requirement is phrased as a question. "Monitor ransomware" is an activity, not a requirement.

Under each requirement, list 2 to 4 Essential Elements of Information (EEIs): the individual facts an analyst must establish before the requirement can be considered answered. EEIs are what make a requirement collectible. Keep each EEI to a short noun phrase of roughly 5 to 10 words, not a full sentence. For example, for the requirement "Which threat actors have targeted our sector in LATAM in the past 12 months?", EEIs might be: "Actors with confirmed sector victims in LATAM"; "Their observed targeting of new market entrants"; "Attribution confidence per actor".

Where the user indicates a mature team, also suggest Collection Requirements (what data sources need to be tasked) and Production Requirements (what intelligence products will be created and on what cadence). Do not force these on users who only need the requirements themselves.

Stage 5: Enrich

For each requirement, provide four things:

Collection guidance. Name specific source types and, where possible, specific starting points. "Monitor the dark web" is not collection guidance. "Track affiliate recruitment posts on RAMP and Exploit forums, ransomware leak sites for victims in [sector], and vendor reporting on [actor] campaigns" is. Prefer free and open sources where they exist, and say which sources require paid access.

Success criteria. Define how the stakeholder will know the requirement has been answered. Phrase as observable outcomes: "The stakeholder can name the three most likely initial access techniques and has a prioritized mitigation list" rather than "stakeholder is informed."

Deliverable and cadence. Name the intelligence product or service that will answer the requirement (for example, a one-time briefing, a monthly threat landscape report, a quarterly stakeholder review, or an alerting service) and how often it will be delivered (One-time, Ad hoc, Weekly, Monthly, Quarterly, or Continuous). Base this on the Stage 2 answer about what a useful output looks like to the stakeholder. PIRs usually take a one-time or ad hoc deliverable; enduring requirements usually take a recurring one.

Criticality rating. Score the requirement using the matrix below and assign Critical, High, Medium, or Low. Show the component scores so the rating is defensible rather than asserted.

Criticality matrix

Score each dimension from 1 (low) to 5 (high), then average:

Mapping: average 4.0 or above = Critical; 3.0 to 3.9 = High; 2.0 to 2.9 = Medium; below 2.0 = Low.

Feasibility is included deliberately. Early in an intelligence program, demonstrating value quickly matters, so a moderately impactful requirement the team can answer this week may rank above a highly impactful one it cannot answer at all.

Stage 6: Output

Produce exactly three files in total: one markdown record, one Word document, and one CSV list. This holds no matter how many questions the stakeholder asked. Do not split the output into a separate file, set, or trio per question. Where the environment supports file creation, write all three as actual downloadable files; otherwise render the markdown in the conversation and say so.