ai-answer-triage

Purpose

Help a user decide which parts of an AI answer are safe to use now, which parts must be verified first, and which parts should only be treated as suggestions.

This skill is for risk sorting, not for silently fact-checking everything. It teaches a repeatable review habit that works across different AI products and agent environments.

Use this skill when

Use this skill when the user has an AI-generated answer and asks things like:

• “这个回答哪些能直接用，哪些要先核实？”
• “这段 AI 建议靠谱吗？”
• “我该怎么检查这份 AI 方案？”
• “这段代码 / 命令 / 配置能不能直接跑？”
• “这份总结、解释、计划里哪些风险最高？”

Typical inputs:

• a pasted AI answer
• a screenshot or transcript of an AI answer
• a code snippet, shell command, config patch, or checklist produced by AI
• a user question about whether an AI output is safe to apply directly

Do not use this skill when

• The user wants you to verify the claims themselves. Route to ai-output-fact-checker, which gives every claim a verification path; triage can still run first to decide which claims go there.
• The input is a whole block of AI-written code (a script, a module, a small repo) and the question is whether to trust, run or build on it. Use ai-code-onboarding-checklist. When code is only one part of a mixed answer, triage the answer here and hand the code blocks marked "test first" to that skill.
• The user wants you to improve the prompt before generation. Use prompt-brief-builder.
• The user wants a handoff summary for a long task. Use ai-session-handoff-writer.
• There is no actual AI answer to inspect yet. Ask for the answer first, or help the user prepare a request instead.

Core rule

Classify by claim type, not by confidence vibes.

Do not say “this looks good” or “this seems suspicious” without tying the judgment to the kind of claim being made.

Required inputs

Ask for the smallest missing piece needed to triage safely:

1. The AI answer itself — exact text, code, command, or screenshot.
2. Intended use — what the user plans to do with it.
3. Blast radius — what breaks if the answer is wrong.

If the answer contains code, commands, configs, medical/legal/financial guidance, or externally checkable facts, those details matter.

Output contract

Produce these sections in order:

1. 结论 — one short paragraph on what can be used now vs what must wait.
2. 分级表 — each important claim grouped by type, risk, and next action.
3. 先做什么 — the next 1–5 checks, in priority order.

Keep it concise. Do not rewrite the whole answer unless the user asks.

Claim types and default handling

Classify every material part of the AI answer into one of these buckets.

A. Low-risk draft material

Examples:

• wording, tone, headline variants
• brainstorming options
• structure suggestions for an outline
• non-factual paraphrases of user-provided content

Default handling:

• Can usually be used directly with a quick human read
• Still check fit, tone, and accidental overstatement

Say:

• “可直接当草稿用，但请做一次人工通读。”

B. Opinion or strategy suggestions

Examples:

• prioritization advice
• product or design suggestions
• tradeoff judgments
• “best approach” recommendations without hard evidence

Default handling:

• Use as options, not as facts
• Compare against goals, constraints, and alternatives

Say:

• “可以当候选方案，但不是事实结论。”

C. Checkable factual claims

Examples:

• dates, policies, prices, limits, quotas, deadlines
• library names, versions, API behavior, command flags
• paper titles, DOI, statistics, laws, regulations
• statements about what a tool, platform, school, or company officially requires

Default handling:

• Must be verified before being relied on
• Prefer primary sources or authoritative documentation

Say:

• “在核对来源前不要当成已确认事实。”

D. Executable or state-changing instructions

Examples:

• code to run
• shell commands
• migration steps
• infra changes
• config edits
• database operations
• automation steps with side effects

Default handling:

• Must be reviewed and tested before use
• The bigger the side effect, the stronger the review gate
• Treat destructive, privileged, or production-facing steps as high risk by default
• Ordering (Step 4): destructive or privileged D items go first of everything; other D items come after the factual claims that would cause rework

Say:

• “不能直接执行；先做代码审阅/沙箱测试/回滚准备。”

Escalation rules

Even if an answer looks polished, automatically raise the risk level when it includes any of the following:

• precise numbers, limits, or dates
• citations, links, laws, standards, or policy statements
• package names, versions, or command-line flags
• hidden assumptions about the user’s environment
• security, privacy, medical, legal, financial, or compliance claims
• production systems, irreversible actions, or large blast radius

Triage procedure

Follow this procedure every time.

Step 1: Identify the intended action

Ask: “What will the user do if they trust this answer?”

Examples:

• send it
• publish it
• run it
• submit it
• buy based on it
• change a system based on it

The same sentence can be low-risk in a draft and high-risk in production.

Step 2: Split the answer into claims

Break the answer into the smallest useful units.

Good units:

• one factual assertion
• one recommendation
• one command block
• one code block
• one policy statement

Do not lump unrelated claims together.

Step 3: Classify each claim

For each unit, assign:

• 类型: A / B / C / D
• 风险: low / medium / high
• 原因: why this class needs that handling
• 动作: use now / use as draft / verify first / test first / stop

Step 4: Prioritize by blast radius

Review first:

1. destructive or privileged commands
2. factual claims that would cause rework, rejection, or embarrassment if wrong
3. code or config changes
4. strategic recommendations
5. low-risk draft wording

Step 5: Give the smallest next checks

Recommend the minimum practical checks, such as:

• open the official docs page
• compare version/flag names
• run tests locally
• try in a sandbox
• ask the user to confirm one environment assumption
• mark a sentence as opinion rather than fact

Deterministic checklist

Use this checklist mechanically before finalizing:

• Did you inspect the actual AI answer, not just the user’s summary of it?
• Did you state the intended use?
• Did you separate facts, opinions, draft text, and executable steps?
• Did every high-risk item get a concrete next action?
• Did any code or command get marked must test first?
• Did any factual claim with numbers/dates/versions get marked verify first?
• Did you avoid claiming that verification already happened if it did not?

Suggested output template

## 结论
- 可直接用：...
- 先别直接用：...

## 分级表
| 项目 | 类型 | 风险 | 为什么 | 下一步 |
|---|---|---|---|---|
| ... | A/B/C/D | low/medium/high | ... | ... |

## 先做什么
1. ...
2. ...
3. ...

If tables are awkward in the target environment, use bullet points with the same fields.

Failure modes to avoid

• giving a vague overall vibe-check without claim-level classification
• calling something “safe” just because it sounds fluent
• treating recommendations as facts
• treating code as trustworthy because it is syntactically plausible
• claiming a link, version, or policy is correct without checking
• recommending a giant verification workflow when 1–2 quick checks would do

Example scenarios

Example 1: Marketing copy draft

User asks whether an AI-written product blurb can be used.

Good handling:

• classify most lines as A. Low-risk draft material
• flag any performance promises or customer counts as C. Checkable factual claims
• recommend a quick human tone pass plus fact verification for claims

Example 2: Shell command from an AI assistant

User asks whether a suggested command can be run.

Good handling:

• classify the command block as D. Executable or state-changing instructions
• identify side effects and assumptions
• recommend dry-run, sandbox, backup, or rollback steps before execution

Example 3: “This library supports feature X in version Y”

Good handling:

• classify as C. Checkable factual claim
• say not to rely on it before checking official docs or release notes

Boundaries

This skill does not:

• perform external verification by default
• guarantee correctness of code, strategy, or facts
• replace testing, review, or source checking
• make risk disappear; it only helps the user spend attention where it matters most

Handoff note

If the user wants verification after triage, hand over to ai-output-fact-checker (code blocks to ai-code-onboarding-checklist) and pass along:

• the extracted high-risk claims
• the intended use
• the blast radius
• the recommended check order

That makes the next verification step faster and more reliable.

变更记录 / Changelog

版本	日期	变更	类型
0.1.1	2026-09-26	可执行类（D 类）的处置在 description 与正文统一为"不能直接执行；先做代码审阅/沙箱测试/回滚准备"，去掉容易读成"先跑一下看看"的"必须先实跑"，并写明排序：破坏性或提权的排最前，其余 D 类排在会导致返工的事实声明之后；三条泛称路由改成实名（ai-output-fact-checker、prompt-brief-builder、ai-session-handoff-writer），整段代码转 ai-code-onboarding-checklist	patch
0.1.0	2026-08-30	初始版本	minor