Context Memory Review

Context Memory Review — Instructions

Purpose

Investigation workflows in this project lean on a tenant-context memory file — a local, gitignored living document that records environment-specific ground truth (known automation/orchestration fingerprints, known-good IPs, account classifications, honeypot/field-device inventory, validated personnel, and documented false-positive rules). Scan automations (e.g. the daily Threat Pulse) read that file to render accurate verdicts.

Over a week of scans, drill-down investigations validate new ground truth — new IPs, new personas, new FP classes, new device classes — that is not yet captured in the context file. This skill reads two evidence sources — the last N days of scan reports and the Mission Control findings log (state/findings.json, the structured record of analyst-triggered skill drill-downs) — compares them against the current context file, and produces a propose-only review document: a list of discrete, human-reviewable candidate changes (ADD / MODIFY / FLAG) with section anchors, proposed text, supporting evidence, recurrence counts, and confidence.

Memory file location. In this project the context file is a relative filename under .copilot/memories/repo/ (Copilot's own repo-memory folder, gitignored). The invoking prompt may pass just the basename; resolve it under that folder. The file is environment-specific and never committed.

This skill is the first half of a deliberate two-phase, human-in-the-loop workflow:

🔴 CRITICAL RULES — READ FIRST

1. PROPOSE-ONLY. NEVER edit the context file in this skill. Do not write, append to, or modify the context memory file. Do not git commit, push, or open a PR. The only file this skill writes is the review document in the output directory.

2. Read-only against the tenant. If any live queries are needed to corroborate a candidate change, they MUST be read-only (per the Remediation Output Policy). Prefer evidence already present in the reports — only query the tenant to disambiguate a contradiction.

3. ⛔ Feedback-loop guard (the single most important rule). Scan reports are partly downstream of the context file: a scan verdict may simply echo an existing context entry rather than independently confirm it. You MUST distinguish:

   • First-party validation — a drill-down in the report actually ran a query/enrichment and confirmed the fact (e.g. "enriched IP 203.0.113.10 → datacenter ASN, 0 abuse reports, recurred on 3 days"). This CAN drive a High-confidence proposal.
   • Context-derived echo — the report verdict only restated something the context file already said ("🟢 known orchestration IP per tenant context"). This must NOT be promoted into a new or strengthened entry. Promoting echoes entrenches errors. When unsure, classify as echo.

4. Never propose weakening or removing a documented FP/safety guardrail based solely on its absence from the week's reports. Absence of a finding ≠ obsolescence of a guardrail. Staleness candidates are FLAG-only, Low confidence, for human judgment — never auto-REMOVE.

5. Evidence-based only. Every proposed change cites the specific report file(s), date(s), and finding it derives from. Never invent entities, counts, IPs, UPNs, or dates. If the reports don't support a change, don't propose it.

6. PII stays local. The review document will contain live tenant entities (IPs, UPNs, device names). Write it ONLY to the gitignored output directory. Never commit it, never include it in a PR, never paste tenant PII into any git artifact.

Inputs (supplied by the invoking prompt / workflow)

The invoking workflow or user supplies these. If invoked interactively without them, ask once, then proceed with the defaults shown.

At least one of reports_dir or findings_file must yield evidence. When launched from Mission Control's Compact to memory button, findings_file is the primary source and reports are supplementary.

Execution Workflow

Phase 0 — Load inputs and current state

1. Read the context file in full (context_file). Build an internal index of its structure: every section heading (the anchor targets for proposals), and within sections the discrete entries — table rows (e.g. IP tables), bullet points, labelled sub-notes (e.g. "A.2", "Section C"), device entries. Note any validated YYYY-MM-DD provenance stamps.
2. Enumerate the reports in window. List files in reports_dir matching reports_glob, select those whose date (from filename YYYYMMDD if present, else file mtime) falls within lookback_days. Sort oldest→newest. If zero reports are in window and the findings log is empty, STOP and report "no reports or findings in window — nothing to review" (a normal quiet-week outcome, not a failure).
3. Read each in-window report. For large reports, read in ranges. Extract structured signal:
   • Concrete entities that appeared with a verdict: IPs, UPNs/accounts, device/host names, OAuth apps, incident IDs, CVEs.
   • For each: was the verdict reached by a first-party drill-down (a query/enrichment was executed in the report) or an echo of existing context? Capture the distinction — it gates confidence.
   • New FP classes / tuning notes the report's drill-downs articulated.
   • Any contradiction: a drill-down that concluded the opposite of an existing context entry.
   • Note in each report whether the context file was successfully loaded/applied during that scan (the reports state this) — echoes only count as echoes if context was actually applied.
4. Read the Mission Control findings log (findings_file, JSON). Each finding is a structured record the analyst produced by triggering a skill drill-down from the canvas — treat these as first-party validation (they are the product of an actual investigation, not a scan echo). For each finding extract: title, description, severity, the originating skill, any entity/IP/UPN referenced in the text, and the timestamp. Findings whose evidence duplicates a scan report are the same first-party signal — correlate, don't double-count. A finding that merely restates an existing context entry with no new evidence is still an echo (feedback-loop guard applies equally here).