The threat-scorer agent is a sub-agent that emits a single JSON object to be consumed by the orchestrator — not a human-readable report. Adding <details> wrapping guidance is nonsensical there and may confuse the model.

The ### Output Format section should be appended after the final ## agent: block (i.e., at the very end of the file or before {{#runtime-import shared/noop-reminder.md}}), where it applies to the top-level workflow agent that produces the user-facing report — not to the inner threat-scorer sub-agent.

Replace the inlined block with a single {{#runtime-import shared/reporting.md}} import (following the same pattern used for noop-reminder.md). This keeps workflows DRY and ensures they pick up any future refinements to the shared guidance automatically.

If only a subset of the three directives applies to a given workflow, consider adding targeted subsection imports or a filtered variant of shared/reporting.md rather than duplicating prose.

Remove the structure-report directive and keep only the <details> wrapping guidance, which is genuinely applicable if the explanation grows. Alternatively, simplify the Output Format to just: Keep your explanation concise — one or two sentences is sufficient.

Applying generic report-structure guidance uniformly across all workflow types (including simple tool-call tests) dilutes its signal where it matters.

Markdown convention is a single blank line between sections. The double blank is a minor cosmetic inconsistency but it does appear in the compiled .lock.yml prompt and could make workflows slightly harder to read at a glance.

Affected files include: blog-auditor.md, commit-changes-analyzer.md, daily-caveman-optimizer.md, daily-choice-test.md, daily-compiler-threat-spec-optimizer.md, and others. A follow-up pass to normalise these would be worthwhile.

Either remove the Structure reports as line entirely, or replace it with guidance appropriate to the actual output — a brief one-sentence explanation of the chosen configuration:

### Output Format

Respond with a single short paragraph explaining the chosen environment, test type, and the day-based rationale.

The Structure reports as: overview → key metrics/issues → collapsible detail → next actions template is designed for multi-section diagnostic reports, not a one-sentence configuration choice. The existing workflow body already specifies "Provide a brief explanation of why you chose this configuration."

The explicit template already embedded in the workflow body is the authoritative contract. Remove the appended Structure reports as line to avoid contradicting it. If the <details> wrap guidance is missing from the existing template, add it there inline instead:

### Output Format

Use `###` (or lower) headers only. The issue body template above is authoritative — do not deviate from it.

Adding a generic report-structure directive after a precise per-field template will cause drift in issue formatting across runs.

Add the missing structure directive so the full block is consistent with the other scan workflows in this PR:

### Output Format

Use `###` (or lower) headers only.

Structure reports as: overview → key metrics/issues → collapsible detail → next actions.

Wrap long content with `<details><summary><b>View Details</b></summary>...</details>`.

Without the structure directive, the semgrep agent has no guidance on how to organise its narrative security assessment relative to other scan reports — an inconsistency introduced by this normalization PR.

### Output Format

Use `###` (or lower) headers only.

Structure reports as: overview → key metrics/issues → collapsible detail → next actions.

Wrap long content with `<details><summary><b>View Details</b></summary>...</details>`.

The blog-auditor discussion body is lengthy and benefits most from structure guidance. Omitting both directives while applying <details> wrap alone is inconsistent with the stated goal of this PR.