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:

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.