# Skywatch Ozone Comment Triage

> Queue-workflow triage with Ozone-comment output mode. Use when the user asks to review Ozone reports and post evidence/recommendations directly as Ozone comments for later human review, rather than presenting the batch in chat. Covers the full per-subject evidence workflow — ClickHouse rule hits, content context, profile, moderation history, reply threads — with output written as Ozone comments and account escalations instead of in-chat detail blocks.

- Skill: `skywatch-bsky/skywatch-ozone-comment-triage` (Agent Skill)
- Install (CLI): `npx skillmds@latest add skywatch-bsky/skywatch-ozone-comment-triage`
- Raw SKILL.md: https://api.skillmd.com/api/skills/skywatch-bsky/skywatch-ozone-comment-triage/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Productivity
- Author: skywatch-bsky (https://skillmd.com/u/skywatch-bsky)
- Updated: 2026-09-21
- Page: https://skillmd.com/skills/skywatch-bsky/skywatch-ozone-comment-triage

---


# Ozone-Comment Triage

This skill is the normal queue workflow (`skywatch-working-the-queue`) with a
different **output mode**: instead of presenting evidence and recommendations
in chat for the analyst to read and confirm, the triage agent writes each
subject's evidence and recommendation directly to Ozone as comments on the
reported subject. The analyst reviews the comments later in the Ozone UI.

Everything else — evidence gathering depth, classification schema, policy
basis, bias checks, escalation triggers — matches `skywatch-working-the-queue`
exactly. Only the output channel changes.

## When to use this skill

The analyst wants to review Ozone reports with full queue-triage evidence but
does not want to sit through a batch presentation in chat. Common triggers:

- "Go through each report and post your evidence as a comment"
- "Work the queue but put your notes in Ozone"
- "Review today's reports and comment your findings"
- "Post evidence to each report for me to review later"

If the analyst wants interactive batch review (present, discuss, confirm,
act), use `skywatch-working-the-queue` instead.

## Prerequisites

Load these skills first:

- `skywatch-working-the-queue` — the evidence workflow, classification schema,
  and bias checks this skill inherits.
- `skywatch-querying-ozone` — Ozone tool parameter guidance.
- `skywatch-labeling-standards` — evidence comment format and citation
  thresholds (loaded when building comments).

Check for `.policies/` in the current working directory and read all label
definitions and precedents, exactly as in `skywatch-working-the-queue`.

## What stays the same

All of these are identical to the normal queue workflow:

- **Entry point** — what reports to pull (recent, by tag, by date window, etc.)
- **Batch size** — how many subjects to process
- **Phase 1 evidence gathering** — ClickHouse-first rule hits, 5 recent posts,
  profile, moderation history, report content, reply thread context
- **Classification schema** — `label`, `no_action`, `investigate_further`,
  `escalate`, `defer` with all fields populated
- **Subject granularity** — each reported AT-URI is its own subject; account
  reports are account-level
- **Account-level escalation triggers** — when post reports reveal an account
  pattern, recommend account-level action
- **Bias checks** — each subject evaluated independently; reporter comments
  are never evidence
- **Data limitations** — ClickHouse is primary; PDS is fallback; never
  conclude "no content" from thin ClickHouse alone

Do not shortcut any of these. The evidence quality must match
`skywatch-working-the-queue` exactly.

## What changes: output mode

### No in-chat batch presentation

Do not produce the Phase 2 summary table and per-subject detail blocks from
`skywatch-working-the-queue`. Instead, proceed directly from evidence gathering
to writing Ozone comments.

### Comment per subject

For each report subject, post an Ozone comment containing:

1. **Report reference** — event ID and report reason/comment (reporter's words
   are pointers, never evidence).
2. **Evidence reviewed** — verbatim reported content, relevant recent posts
   with AT-URIs, profile, rule-hit summary, moderation history context. Use
   the same evidence standard as the in-chat detail block.
3. **Classification** — `label`, `no_action`, `investigate_further`,
   `escalate`, or `defer` with confidence and policy basis.
4. **Recommendation** — what the reviewer should do when they read this
   comment.
5. **Limitations** — explicitly state what evidence was unavailable
   (ClickHouse denied, image not reviewed, PDS takendown, etc.). Never imply
   evidence was checked when it was not.

Post the comment on the **reported subject** — the same DID or AT-URI that the
report targets.

### Account escalation from post reports

If a post-level report reveals an account-level pattern (multiple violating
posts, sustained rule hits, bio/profile signals), post the evidence comment on
the **account DID** rather than (or in addition to) the post AT-URI, and
escalate the account via `mcp__skywatch-mcp__ozone_escalate`.

This matches the `skywatch-working-the-queue` account-escalation triggers:

- Multiple reported posts from the same account show a consistent violation
  pattern
- Reviewing a post's content context reveals broader violating behaviour
- Rule-hit history shows sustained matches against the same rules

### No labels, no acknowledgements

Unless the analyst explicitly requests labels or report closures, this skill
posts **comments and escalations only**. Do not apply labels via
`mcp__skywatch-mcp__ozone_label`. Do not acknowledge/close reports via
`mcp__skywatch-mcp__ozone_acknowledge`.

The analyst reviews the comments and makes the final call on labels and
closures.

## Workflow

### Step 1: Pull reports

Query `mcp__skywatch-mcp__ozone_query_events` with `types: ["report"]` and the
analyst-specified time window or entry point. Paginate until all same-window
reports are collected. Note any reports that arrive during processing — they
are in scope.

### Step 2: Gather evidence per subject

Dispatch `data-analyst` subagents to gather queue-standard evidence for each
report subject, exactly as in `skywatch-working-the-queue` Phase 1:

- Rule hits (ClickHouse, 30d, grouped by rule with counts)
- 5 most recent posts (ClickHouse-first, PDS fallback)
- Profile (verbatim handle, display name, bio)
- Moderation history (`mcp__skywatch-mcp__ozone_query_events`)
- Reported content (verbatim for post subjects)
- Reply thread context (parent chain up to 3 levels for replies)

**Completion criterion:** every report subject has been processed by a
data-analyst subagent and has a returned evidence manifest with classification,
or the subagent has explicitly noted what evidence was unavailable and why.

If a subagent's ClickHouse access is blocked by the tool-security layer, the
subagent must state that ClickHouse was denied and proceed with Ozone/PDS
fallback. The evidence manifest must explicitly note which sources were
available and which were not.

### Step 3: Build and post comments

For each report subject, the triage agent builds an evidence comment from the
subagent's manifest and posts it via `mcp__skywatch-mcp__ozone_comment`. Use a
single `batchId` for the session (e.g., `YYYY-MM-DD-ozone-comment-triage`).

Dispatch comment posting to a `general-purpose-mini` subagent with a
pre-built manifest: subject, comment text, and any escalation actions. The
subagent executes mechanically — no judgment.

### Step 4: Post account escalations

For subjects where the evidence supports account-level review (post report
revealing account pattern, or account report with sufficient evidence),
escalate via `mcp__skywatch-mcp__ozone_escalate` on the account DID.

Post the evidence comment on the account DID before or alongside the
escalation, so the reviewer sees the evidence when they pick up the escalation.

### Step 5: Verify

Query `mcp__skywatch-mcp__ozone_query_events` with
`types: ["comment", "escalate"]` and the session time window. Confirm all
comments and escalations were created under the batch ID. Note any failures
or duplicates.

## Comment format

Use this template for every subject's evidence comment:

```
Queue review [date] report [event_id]: [one-line summary of finding]

Evidence reviewed:
- Reported content: [verbatim text or "n/a account report"]
- Profile: [handle, display name, bio excerpt]
- Rule hits (30d): [rule name: count, or "ClickHouse unavailable: [reason]"]
- Recent posts: [N posts reviewed, key examples with AT-URIs]
- Moderation history: [prior labels/reports/actions, or "none"]
- Thread context: [parent chain for replies, or "n/a"]

Classification: [label/no_action/investigate_further/escalate/defer]
Confidence: [high/medium/low]
Policy basis: [policy reference or "no applicable policy"]
Recommendation: [what the reviewer should do]
Limitations: [what evidence was unavailable and why]
```

Rules:

- Every field must be populated. If a field is empty, write "none" or "n/a".
- Reported content is always verbatim. If the content is an image, note
  "[image]" and the AT-URI; do not classify based on text alone if the image
  is the evidence.
- Limitations must explicitly state what was checked and what was not. Never
  imply evidence was gathered when it was unavailable.
- The comment is the reviewer's primary evidence surface. Write it as though
  the reviewer will make their decision from this comment alone.

## Delegation pattern

Same as `skywatch-working-the-queue`:

| Task | Subagent | Rationale |
|------|----------|-----------|
| Per-subject evidence collection | `data-analyst` | ClickHouse + Ozone queries |
| Comment/escalation execution | `general-purpose-mini` | Mechanical write manifest |

The triage agent owns all classification decisions and builds the full comment
text before handing off to the write subagent.

## Failure modes specific to this skill

- **Thin comments from summary-only subagent output.** If a data-analyst
  subagent returns only a summary (classification + one-line rationale) rather
  than a full evidence manifest, do not post a comment from the summary alone.
  Either rerun the evidence gathering with explicit instructions to return the
  full manifest, or post a comment that explicitly says "initial review
  incomplete — additional evidence needed before action."
- **Implying evidence was checked when it was not.** If ClickHouse was
  unavailable, the comment must say so. If an image was not reviewed, the
  comment must say so. A reviewer reading the comment must know exactly what
  was and was not checked.
- **Posting comments without full evidence gathering.** This is the core
  failure this skill exists to prevent. The output mode changed; the evidence
  depth did not. If you catch yourself posting comments from a quick look at
  the reported subject without ClickHouse rule hits, profile, moderation
  history, and thread context, stop and gather the missing evidence first.
- **Duplicate writes from retry behavior.** Write subagents may retry failed
  writes and create duplicate comments/escalations. Verify after each batch and
  note duplicates in the session summary. Do not delete Ozone events unless the
  analyst asks.