ai-safety-testing

AI Safety Testing (Chinese Version)

When to Use

When evidence-based analysis, design, or validation preparation is needed around safety policies, abuse categories, refusal/redirection, privacy, escalation, and Human risk decisions.
When an Agent, RAG, or LLM solution, results, or evidence needs review, and actionable improvement items need to be formed.
When input is incomplete but a constrained initial version with assumptions, information gaps, and Human decision boundaries still needs to be delivered.

Default output is Markdown, organized by domain risk, evidence status, priority, and boundaries.
When the user requests table, CSV, JSON, or ticket format, retain the same finding fields, evidence, and decision boundaries.
Before output enters an automated process, first confirm the schema, enum values, required fields, and evidence sources.

First read and follow prompts/ai-safety-testing.md, including input audit, domain coverage, and output order.
Extract scope, environment, version, time window, constraints, success criteria, and available evidence, with focus on checking safety policies, abuse categories, refusal and redirection, privacy boundaries, and escalation decisions.
First distinguish confirmed facts, evidence-supported inferences, candidate recommendations, and Human decisions, then sort by risk and evidence strength.
Convert high-risk items into preconditions, steps, expected results or judgment criteria, required evidence, and validation methods.
When information is insufficient, deliver a constrained initial version, clarify which conclusions cannot hold, and do not write static materials as execution results.

When calibrating domain results, correct comparisons, or evidence gaps, read the desensitized input, item-by-item expectations, and recalculation basis of references/domain-decision-example.md .
Every execution must read prompts/ai-safety-testing.md; it is the complete execution specification of this Skill.
When evaluation is needed, read evals/eval.yaml and the matching cases under evals/cases/ .
Only read references/、examples/、scripts/ or output-formats.mdwhen the directory actually exists and the task requires it; do not assume assets that do not exist.

Fix the policy ID/version/applicable subjects, and establish a category/condition→allow/restrict/refuse/escalate→content that may be provided/prohibited side effects→evidence matrix; do not self-determine safety approval when policy is missing.
Pair dangerous samples described by policy with neighboring normal requests; separately check correctness of dangerous handling, completion quality of allowed requests, and over-refusal, and do not merely aggregate refusal rates.
For restriction/redirection, verify the actual content and tool actions, not just the opening refusal; escalation records should capture trigger reason, responsible role, and pending Human decision status.
Labels record policy source, sample version, expected branch, and actual branch; keep NOT_RUN when execution output is not provided, and keep UNKNOWN for unknown policy boundaries.

Only analyze safety policies, abuse categories, refusal/redirection, privacy, escalation, and Human risk decisions; do not replace business owners or Human risk acceptance, exception approval, and safety decisions.
Do not fabricate system behavior, fields, model outputs, data, thresholds, root causes, execution records, or pass conclusions.
Static design, plans, file existence, or dry-run can only retain the original evidence status and cannot be upgraded to proof of real execution.
When evidence is insufficient, use pending confirmation, blocked, unassessed, or NOT_SCORED, and provide the minimum validation method.
When user data, production, or security is involved, use least privilege, anonymized data, mocks, dry-runs, or isolated environments.

Safety policies, abuse categories, refusal and redirection, privacy boundaries, and escalation decisions are covered, with sources, evidence status, and verification methods recorded for each item.
Facts, inferences, candidate recommendations, information gaps, and Human decisions are separated.
High-risk items have P0/P1/P2/P3 or equivalent priority, accountable roles, and closure conditions.
Plans, static checks, or dry-runs are not written as test execution, all passed, or security approval.
Residual risks, stop/escalation conditions, and next steps are stated.

Listing only checkpoints without explaining trigger conditions, expected points of attention, accountable roles, closure conditions, and evidence.
Treating test or model tool names from adjacent domains as a complete judgment of AI safety.
Using unexplained numbers to create false precision, or writing correlation as causation.
Directly refusing when the input is incomplete, or conversely pretending the conclusion is already certain.

Start from the path most likely to cause user harm, business loss, or decision blockage.
Use the smallest verifiable experiment to reduce uncertainty, and record conditions, versions, sources, and evidence.
Enable another engineer to independently install, execute, and review the output of this Skill.