conops-template

# Concept of Operations (CONOPS) Generator The CONOPS bridges the legal RoE and the tactical OPPLAN. It must be **readable by a CEO** while containing **enough detail for operators**. ## When to Use - After `plan/roe.json` exists - User says "create CONOPS", "design the operation", "build threat model" - Before OPPLAN can be generated ## Prerequisites Read `plan/roe.json` first — scope and boundaries constrain the CONOPS. See `../references/schema-quick-reference.md` for the `CONOPS`, `ThreatActor`, `KillChainPhase`, and `DeconflictionPlan` schema fields. ## Workflow ### Step 1: Interview the User Use the tier table and RoE Constraint→Profile Implication table in `threat-profile/SKILL.md` to propose a threat profile. Ask the operator about material choices such as motivation, initial access, operation sequence, and success criteria when these are not already confirmed. **Question 1 — Threat actor tier** (single-select, use `threat-profile` skill for detailed profiling): - a) Opportunistic external attacker (low) - b) Targeted cybercriminal (medium) - c) APT / nation-state (high) - d) Insider threat - e) Custom — describe Use `threat-profile/references/adversary-archetypes.md` to propose **motivation** and **initial access vector**, then confirm them when they affect the operation. **Question 2 — Success criteria** — the crown-jewel / measurable win condition. Required; no default (every engagement needs an explicit end-state). **Agent-drafted, not asked:** - **Attack narrative** — write the 2-3 sentence scenario yourself from RoE scope + tier + success criteria. This is the agent's job, not the operator's homework. - **Ultimate objectives** — derive from success criteria; do not ask as a separate dimension. - ~~Communication plan~~ — REMOVED. `CONOPS.communication_plan` is DEPRECATED (see SCHEMA_REFERENCE in soundwave.md); `ContactPlan` (contact-template skill) owns this now. Asking about it here duplicates a question and writes to a dead field. - **Deconfliction method** — default to standard red-team markers/headers (see `deconfliction-template` reference) unless the operator's RoE/contact answers already flagged a SOC integration endpoint; do not spend a dedicated question on it. ### Step 2: Design Kill Chain Based on RoE scope + threat profile, select applicable phases. See `references/kill-chain-templates.md`. **Key rule**: Don't include phases outside RoE scope. Recon-only engagement → only `recon` phase. ### Step 3: Generate Documents 1. `plan/conops.json` — matching `CONOPS` schema 2. `plan/deconfliction.json` — matching `DeconflictionPlan` schema ### Step 4: Validate - Executive summary contains no jargon or tool names - Kill chain phases align with RoE scope - All MITRE ATT&CK technique IDs are valid - Timeline has concrete date ranges - At least 2 success criteria defined ## Generation Rules 1. **Executive summary = non-technical** — no tool names, no jargon 2. **Threat actor TTPs must reference MITRE ATT&CK IDs** 3. **Kill chain scoped to RoE** — no exploitation phase in recon-only engagement 4. **Timeline uses absolute dates** — never relative 5. **Deconfliction defaults to standard red-team markers/headers** unless a SOC integration endpoint was already flagged; `communication_plan` is DEPRECATED — write coordination details to `ContactPlan` instead