Feature/require purple team before report

.claude/skills/exploit-development/SKILL.md

@@ -63,7 +63,8 @@ in the file, not just in your chat response.
      queue for actual delivery.
    - Once exploited successfully against the target, it's a **positive finding** —
      hand the technique, procedure, and CVSS estimate to `purple-team-atomic-tests`
-     for a detection-validation test.
+     **immediately** for a detection-validation test. Do not wait until close, and
+     do not skip this to start `harness-report`.
    - Feeds `harness-report`'s Detailed Findings fields directly: `cvss_score`
      (see `references/cvss-quick-reference.md`), `affected_entities_rt`,
      `description_rt`, `impact_rt`, `replication_steps_rt`,

.claude/skills/harness-report/SKILL.md

@@ -1,20 +1,38 @@
 ---
 name: harness-report
-description: Reporting agent that drafts the client-facing engagement report at the end of a harness run, following this project's Ghostwriter executive-report template (v3-ghostwriter-executive-document.docx). Use at the end of an engagement, or whenever asked to draft/update the report, fill in findings, or produce a Ghostwriter-compatible JSON/section draft.
+description: Reporting agent that drafts the client-facing engagement report at the end of a harness run, following Ghostwriter's executive-report flow (section order and Jinja field names in references/ghostwriter-executive-template.md). Use at the end of an engagement AFTER purple-team-atomic-tests has written atomics/ YAML+md for every positive finding. If those files are missing, run that skill first instead of drafting. Also use whenever asked to draft/update the report, fill in findings, or produce a Ghostwriter-compatible JSON/section draft.
 ---
 
 # Harness report (Ghostwriter executive template)
 
 You draft the engagement report at the end of a harness run, matching the structure
-and field names of this project's template,
-`v3-ghostwriter-executive-document.docx` (a [Ghostwriter](https://github.com/GhostManager/Ghostwriter)
-`docxtpl` template — repo root). Don't restructure the template's sections; fill them.
-Full section order and every Jinja variable name are in
+and field names of [Ghostwriter](https://github.com/GhostManager/Ghostwriter)'s
+executive `docxtpl` template. Don't restructure the template's sections; fill them.
+The `.docx` itself is **not** in this repo — operators keep it in Ghostwriter (or
+a local copy). Full section order and every Jinja variable name are in
 `references/ghostwriter-executive-template.md` — treat that as the schema.
 
 Follow the project's `CLAUDE.md` standing rules (scope gate, don't fabricate, v19
 taxonomy).
 
+## Skill-4 gate — stop if atomic tests are missing
+
+`purple-team-atomic-tests` is a required prior step, not optional reporting
+color. Before you draft (markdown or JSON):
+
+1. List the engagement's **positive findings** (techniques that succeeded).
+2. For each, confirm `atomics/<technique-id>/<technique-id>.yaml` and the
+   matching `.md` exist, with an Engagement evidence section citing real
+   ReaperC2 command output.
+3. If any are missing, **stop**. Run `purple-team-atomic-tests` for those
+   findings, then come back. Do not draft Validation by inventing
+   `ART-Txxxx-…` names or paraphrasing a test that was never written.
+
+A time-boxed close, a blocked later objective, or an operator "move to
+reporting" instruction does **not** waive this. If there were genuinely no
+positive findings (no technique succeeded), say so and leave Observations /
+Validation empty rather than fabricating tests.
+
 ## Gather inputs before drafting
 
 | Report section | Comes from |
@@ -23,7 +41,7 @@ taxonomy).
 | Goals & Objectives, Scope, Whitecards | Engagement planning / ROE — ask if missing, don't invent scope |
 | Executive Summary, Methodology, Scenario | Summarized from everything below once it exists — write this section last even though it appears early |
 | Attack Narrative (Critical Steps) | `red-team-operator`'s critical-step log for this engagement |
-| Observations / Recommendations / Validation | `purple-team-atomic-tests` output per positive finding — Validation text should point at the actual atomic test and the engagement command output it cites |
+| Observations / Recommendations / Validation | `purple-team-atomic-tests` output per positive finding — Validation text must point at the real `atomics/<id>/<id>.yaml` (and its Engagement evidence command output). Invented `ART-Txxxx-…` labels are not an atomic test |
 | Detailed Findings (severity, CVSS, affected hosts, description, impact, replication, host detection, solution) | Vulnerabilities found incidentally during the engagement, per `red-team-operator`/`reaperc2-operator` — Red Team engagements are not primarily vuln-hunting, so this section may legitimately be short or empty |
 | Mitre ATT&CK Killchain table + Navigator layer link | `reaperc2-operator`'s Notes & ATT&CK technique tags / Navigator layer export (STIX v19) |
 | Timeline (C2 logs, C2 sessions, attack simulation) | `reaperc2-operator`'s Ghostwriter CSV / logs export |
@@ -56,9 +74,10 @@ describing them in prose.
 - **Produce BOTH outputs by default at the end of a harness run** — the markdown
   report *and* a Ghostwriter-ready JSON context object. The operator reviews the
   markdown; the JSON is what gets pasted into Ghostwriter's report data model (or
-  fed to `docxtpl` against `v3-ghostwriter-executive-document.docx`).
+  fed to `docxtpl` against the operator's Ghostwriter executive template — the
+  `.docx` is not in this repo).
   - Markdown: organized under the template's own H1/H2 headings, field names
-    annotated inline, so it can be transcribed straight into the docx.
+    annotated inline, so it can be transcribed straight into Ghostwriter.
   - JSON: a single object using the exact variable names from
     `references/ghostwriter-executive-template.md` as keys. Write it to
     `engagement_report_<engagement>.json` next to the markdown report. Validate it
@@ -89,8 +108,9 @@ with `\n\n` between paragraphs, not a run-on):
 - `attack_narrative`: `[ { step, tactic, techniques, narrative } ]` — one entry per
   Critical Step, tagged with the ATT&CK v19 tactic/techniques it exercises.
 - `observations_and_recommendations`: `[ { observation, recommendation, validation } ]`
-  — `validation` is the `purple-team-atomic-tests` atomic test (or a pointer to it)
-  plus the engagement command output it cites.
+  — `validation` must point at the real `atomics/<id>/<id>.yaml` (and its
+  Engagement evidence command output). Invented `ART-Txxxx-…` labels are not an
+  atomic test.
 - `attack_killchain`: `[ { tactic, tactic_name, techniques } ]` — one row per tactic
   in v19 matrix order (all 15, including the Stealth `TA0005` / Defense Impairment
   `TA0112` split); leave a tactic's `techniques` empty string if unused rather than

.claude/skills/harness-report/references/ghostwriter-executive-template.md

@@ -1,10 +1,11 @@
-# v3-ghostwriter-executive-document.docx — structure & field reference
-
-Extracted from `v3-ghostwriter-executive-document.docx` (repo root). This is a
-Ghostwriter `docxtpl` template: `{{ var }}` for plain text, `{{p var }}` for a
-rich-text subdoc (paragraphed prose/lists, not a single line), `{%tr for x in y %}
-... {%tr endfor %}` to repeat a table row, `{% cellbg finding.severity_color %}` to
-color a cell by severity. Section order below is the order in the document — keep it.
+# Ghostwriter executive template — structure & field reference
+
+Schema for Ghostwriter's executive `docxtpl` report. The `.docx` is not in this
+repo; operators keep it in Ghostwriter (or a local copy). `{{ var }}` is plain
+text, `{{p var }}` is a rich-text subdoc (paragraphed prose/lists, not a single
+line), `{%tr for x in y %} ... {%tr endfor %}` repeats a table row,
+`{% cellbg finding.severity_color %}` colors a cell by severity. Section order
+below is the order in the document — keep it.
 
 ## 1. Contacts and Resources (Heading 1)
 

.claude/skills/purple-team-atomic-tests/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: purple-team-atomic-tests
-description: Purple team agent that turns a red team's positive findings (techniques that succeeded against the target — i.e. detection/control gaps) into Atomic Red Team-style atomic tests the blue team can safely re-run in a controlled environment to validate detections. Includes the engagement's actual command and ReaperC2 command output as evidence. Use when a red team engagement produces a finding that needs a repeatable detection-validation test, or when asked to build/expand an atomic test library.
+description: Purple team agent that turns a red team's positive findings (techniques that succeeded against the target — i.e. detection/control gaps) into Atomic Red Team-style atomic tests the blue team can safely re-run in a controlled environment to validate detections. Includes the engagement's actual command and ReaperC2 command output as evidence. Use as soon as a technique succeeds — required before harness-report, not optional, and not only at engagement close. Also use when asked to build/expand an atomic test library.
 ---
 
 # Purple team — atomic test generation
@@ -16,6 +16,19 @@ against a controlled/lab environment the blue team owns, never back against the
 original client production target** without a separate, explicit authorization for
 that. Every test needs a cleanup step — leave nothing behind.
 
+## When to run (mandatory)
+
+This skill is **required for every positive finding**, not a close-out extra.
+
+- Run it **as soon as the technique succeeds** — do not wait until objectives are
+  done, until LPE is exhausted, or until someone says "write the report."
+- Write the files under `atomics/` **before** `harness-report` starts. Validation
+  sentences in a report are not this skill's deliverable.
+- A time-boxed close, a blocked later objective, or "move to reporting" does
+  **not** skip this. If `harness-report` is about to run and `atomics/<id>/`
+  is missing for a successful technique, run this skill first.
+- Do not mark this skill complete unless those YAML + markdown files exist.
+
 ## Input: what makes a finding "positive"
 
 A finding is in scope for this skill when the red team confirmed a technique
@@ -81,8 +94,9 @@ Ghostwriter executive template — see `harness-report`):
 Default to an `atomics/` directory laid out the same way as the upstream Atomic Red
 Team repo: `atomics/T1059.001/T1059.001.md` (human-readable) next to
 `atomics/T1059.001/T1059.001.yaml` (machine-readable), one directory per technique.
-If this project doesn't have an `atomics/` directory yet and the operator wants tests
-committed, create it there rather than inventing a different layout.
+If this project doesn't have an `atomics/` directory yet, create it there rather
+than inventing a different layout. Creating those files is the skill's job, not
+an optional extra the operator has to request.
 
 ## Safety checklist before handing a test off
 

.claude/skills/reaperc2-operator/SKILL.md

@@ -65,7 +65,9 @@ this confusion; see Troubleshooting below.
    `remote_path`. Prefer small, sequenced commands over noisy one-liners so output is
    easy to attribute. After output lands, pull it (`GET /api/beacon-command-output`)
    — that is what Notes & ATT&CK and `purple-team-atomic-tests` cite. Do not invent
-   stdout.
+   stdout. A successful technique is a positive finding: hand it to
+   `purple-team-atomic-tests` as soon as that output lands. Do not wait for
+   `harness-report`.
 4. **Topology** (`/topology`, `GET /api/topology`) — pivot chain and beacon liveness
    (green = on time, yellow = missed one interval, gray = offline/unknown, relative
    to the beacon's configured interval). Check this before opening a new lateral-move

.claude/skills/red-team-operator/SKILL.md

@@ -46,11 +46,12 @@ engagement's Notes & ATT&CK page (its matrix version selector should be set to v
   "Attack Narrative → Critical Step N" entries.
 - **Positive finding** — a technique that *succeeded* against the target, meaning it
   represents a detection or control gap the blue team should be able to catch next
-  time. Hand each one to the `purple-team-atomic-tests` skill (technique ID +
-  procedure + **the ReaperC2 command output from the successful run** + what
-  was/wasn't detected) so it can produce a validation test. Don't invent detection
-  outcomes or stdout — only report what was actually observed (command output,
-  logs, EDR alerts, absence of either).
+  time. Hand each one to the `purple-team-atomic-tests` skill **immediately**
+  (technique ID + procedure + **the ReaperC2 command output from the successful
+  run** + what was/wasn't detected) so it can produce a validation test. Do not
+  wait until close, and do not defer this to `harness-report`. Don't invent
+  detection outcomes or stdout — only report what was actually observed (command
+  output, logs, EDR alerts, absence of either).
 
 ## Response format
 
@@ -68,5 +69,7 @@ When an action should be executed against a beacon, say so explicitly and hand o
 the `reaperc2-operator` skill for the exact command/API call — this skill plans
 tradecraft, it doesn't reimplement ReaperC2's operator surface.
 
-At engagement close, hand your accumulated critical-step and technique log to the
-`harness-report` skill.
+At engagement close, confirm `purple-team-atomic-tests` has written
+`atomics/<id>/` YAML + markdown for every positive finding, then hand your
+accumulated critical-step and technique log to the `harness-report` skill. Do
+not start the report while those files are missing.

.dockerignore

@@ -3,3 +3,4 @@ sessions/
 .env
 *.md.bak
 bin/
+v3-ghostwriter-executive-document.docx

.gitignore

@@ -6,3 +6,6 @@
 
 # Local secrets for docker compose
 .env
+
+# Ghostwriter executive .docx lives in Ghostwriter (or a local copy) — not VCS.
+v3-ghostwriter-executive-document.docx

CLAUDE.md

@@ -14,14 +14,19 @@ engagement ("harness run"), launched via the `harness` Go binary (`cmd/harness`)
 3. **`exploit-development`** — turns a confirmed, in-scope vulnerability into a
    working proof-of-concept, mapped to ATT&CK v19. Every exploit artifact it
    produces carries a mandatory educational/authorized-testing-only notice.
-4. **`purple-team-atomic-tests`** — for each positive finding (a technique that
-   succeeded against the target, i.e. a detection/control gap), generates Atomic Red
-   Team-style validation tests the blue team can re-run in a controlled environment,
-   including the engagement's command output. Its output fills the report's
-   Validation fields.
+4. **`purple-team-atomic-tests`** — **required, not optional.** For each positive
+   finding (a technique that succeeded against the target, i.e. a detection/control
+   gap), generates Atomic Red Team-style validation tests the blue team can re-run
+   in a controlled environment, including the engagement's command output. Runs
+   **as soon as the technique succeeds**, not at close. Its YAML/markdown under
+   `atomics/` fills the report's Validation fields. `harness-report` must not
+   start until those files exist for every positive finding.
 5. **`harness-report`** — at the end of the engagement, drafts the client-facing
-   report against `v3-ghostwriter-executive-document.docx`, using the technique log,
-   ReaperC2 exports, exploit findings, and atomic-test validations gathered above.
+   report against Ghostwriter's executive template (schema in
+   `harness-report/references/ghostwriter-executive-template.md`; the `.docx` is
+   not in this repo), using the technique log, ReaperC2 exports, exploit findings,
+   and atomic-test validations gathered above. A time-boxed close or a blocked
+   later objective does not skip skill 4.
 
 ## Starting an engagement
 
@@ -71,6 +76,11 @@ operator has stated it in the conversation.
 - **Scope gate first.** Nothing in this harness is used outside the active,
   authorized engagement (named client, dates, written rules of engagement). If scope
   isn't established, stop and ask for it before planning or executing anything.
+- **Purple-team before report.** Every positive finding must produce
+  `purple-team-atomic-tests` artifacts under `atomics/` (YAML + markdown with
+  engagement command output) **before** `harness-report` runs. Do not skip this
+  for a time-boxed close, a blocked later objective, or "move to reporting."
+  Validation prose in the report is not a substitute for those files.
 - **Recommend, don't auto-execute.** These skills draft plans, commands, tests, and
   report text for a human operator to review and run/approve — they don't fire
   implant commands or send client deliverables on their own.

Dockerfile

@@ -55,7 +55,6 @@ WORKDIR /workspace
 COPY --from=builder /out/harness /usr/local/bin/harness
 COPY CLAUDE.md ./CLAUDE.md
 COPY .claude ./.claude
-COPY v3-ghostwriter-executive-document.docx ./v3-ghostwriter-executive-document.docx
 
 RUN mkdir -p /workspace/sessions && chown -R harness:harness /workspace
 

README.md

@@ -7,13 +7,16 @@ standing rules; this file covers building and running the `harness` launcher.
 
 ## What's here
 
-- `.claude/skills/` — five Claude Code skills: `red-team-operator`,
-  `reaperc2-operator`, `exploit-development`, `purple-team-atomic-tests`,
-  `harness-report`.
+- `.claude/skills/` — five Claude Code skills, used in sequence:
+  `red-team-operator`, `reaperc2-operator`, `exploit-development`,
+  `purple-team-atomic-tests`, `harness-report`. `purple-team-atomic-tests` is
+  required for every positive finding (real files under `atomics/`) and must
+  finish before `harness-report` drafts; a time-boxed close does not skip it.
+  `harness-report` drafts against Ghostwriter's executive template; the schema
+  lives in `.claude/skills/harness-report/references/ghostwriter-executive-template.md`
+  (the `.docx` is not in this repo).
 - `cmd/harness`, `internal/harness` — the Go launcher that validates engagement
   inputs, builds the initial session prompt, and starts `claude`.
-- `v3-ghostwriter-executive-document.docx` — the Ghostwriter report template
-  `harness-report` drafts against.
 - `Dockerfile`, `docker-compose.yml` — containerized build/run, multi-arch
   (`linux/amd64`, `linux/arm64`).
 

internal/harness/prompt_test.go

@@ -45,6 +45,7 @@ func TestBuildPromptOmitsPasswordAndListsSkills(t *testing.T) {
 		cfg.Client, cfg.Engagement, cfg.Authorization, cfg.ReaperURL, cfg.ReaperC2URL, cfg.ReaperUsername,
 		"Get domain admin", "Reach the finance share",
 		"$REAPER_C2_URL", "Notes & ATT&CK", "command output",
+		"Skill-4 gate", "atomics/", "Do not start **harness-report**",
 	} {
 		if !strings.Contains(prompt, want) {
 			t.Errorf("prompt missing expected content %q", want)