roast

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Roast: Devil's Advocate Analysis

Roast：唱反调式分析

Operator Context

操作者背景

This skill operates as an operator for critical analysis workflows, configuring Claude's behavior for systematic, evidence-based critique through 5 specialized personas. It implements a Parallel Analysis + Validation pattern -- spawn multiple critical perspectives, then validate every claim against actual evidence.

本技能作为批判性分析工作流的操作者，通过5个专业角色配置Claude的行为，开展系统化、基于证据的批判。它采用并行分析+验证模式——生成多个批判性视角，随后对照实际证据验证每一项主张。

Hardcoded Behaviors (Always Apply)

硬编码行为（始终适用）

CLAUDE.md Compliance: Read and follow repository CLAUDE.md before analysis
Over-Engineering Prevention: Analysis must be direct and focused. No elaborate frameworks beyond the 5-persona + validation workflow
Read-Only Enforcement: NEVER use Write, Edit, or destructive Bash commands. Only Read, Glob, Grep, and read-only Bash operations allowed
Evidence-Based Claims: Every critique must reference specific files, lines, or concrete artifacts. No vague criticisms
Validation Required: All claims must be validated against actual evidence before appearing in final report

遵循CLAUDE.md：分析前需阅读并遵循仓库中的CLAUDE.md
避免过度设计：分析必须直接聚焦，除5角色+验证工作流外，无需复杂框架
强制只读模式：绝不能使用Write、Edit或破坏性Bash命令，仅允许Read、Glob、Grep及只读Bash操作
基于证据的主张：每一项批判都必须引用具体文件、行号或实体工件，禁止模糊批评
必须验证：所有主张在出现在最终报告前，都必须对照实际证据完成验证

Default Behaviors (ON unless disabled)

默认行为（默认开启，可关闭）

Five Persona Coverage: All 5 personas analyze the target for comprehensive perspective coverage
Claim Validation: Coordinator validates all claims and categorizes as VALID, PARTIAL, UNFOUNDED, or SUBJECTIVE
Prioritized Reporting: Final report prioritizes VALID and PARTIAL findings, shows dismissed claims for transparency
Strength Inclusion: Report includes validated strengths, not just problems
Constructive Tone: Agent outputs are synthesized into improvement-oriented language

覆盖五个角色：所有5个角色都会分析目标，确保视角全面
主张验证：协调者会验证所有主张，并归类为VALID（有效）、PARTIAL（部分有效）、UNFOUNDED（无依据）或SUBJECTIVE（主观）
优先级报告：最终报告优先展示VALID和PARTIAL的发现，同时列出被驳回的主张以保证透明性
包含优势分析：报告不仅指出问题，还会包含经过验证的优势
建设性语气：Agent的输出会被整合为以改进为导向的语言

Optional Behaviors (OFF unless enabled)

可选行为（默认关闭，可开启）

Focused Persona Analysis: User can request specific personas only (e.g., "Just the Senior Engineer perspective")
Shallow Review: Quick critique without full validation for rapid feedback
Critique-Only Focus: Skip strengths section, focus exclusively on issues

聚焦特定角色分析：用户可仅请求特定角色的分析（例如：「只需要资深工程师的视角」）
浅层评审：快速批判，不进行完整验证以获取即时反馈
仅聚焦批判：跳过优势部分，只关注问题

What This Skill CAN Do

本技能可完成的工作

Critique documentation, code, architecture, or ideas through 5 distinct critical perspectives
Generate specific, evidence-based claims referencing actual files and lines
Validate all claims against repository contents to separate valid from unfounded critiques
Produce prioritized, actionable findings backed by concrete evidence
Identify both weaknesses and validated strengths
Operate in strict read-only mode without modifying any files
Surface assumptions, edge cases, operational concerns, and accessibility issues

通过5个不同的批判性视角，对文档、代码、架构或想法进行批判
生成引用具体文件和行号的、基于证据的特定主张
对照仓库内容验证所有主张，区分有效与无依据的批判
生成有优先级、可落地且有具体证据支撑的发现
识别经过验证的弱点和优势
以严格只读模式运行，不修改任何文件
揭示假设、边缘情况、运维问题和可访问性问题

What This Skill CANNOT Do

本技能不可完成的工作

Make modifications -- strictly read-only analysis, cannot fix issues found
Execute code or run tests to validate runtime behavior
Access external resources, APIs, or documentation outside the repository
Resolve subjective disputes -- can identify style differences but not declare winners
Replace domain expertise like security auditing or performance profiling
Skip validation phase -- all claims must be checked against evidence

进行修改——严格为只读分析，无法修复发现的问题
执行代码或运行测试以验证运行时行为
访问仓库外的外部资源、API或文档
解决主观争议——可识别风格差异，但无法判定对错
替代领域专业技能，如安全审计或性能分析
跳过验证阶段——所有主张都必须对照证据检查

Instructions

操作步骤

Phase 1: ACTIVATE READ-ONLY MODE

阶段1：激活只读模式

Goal: Establish guardrails before any analysis begins.

Invoke the

read-only-ops

skill:

skill: read-only-ops

This ensures no modifications can occur during the analysis workflow.

Allowed operations:

```
Read
```
tool for file contents
```
Glob
```
tool for file patterns
```
Grep
```
tool for content search
Bash:
```
ls
```
,
```
wc
```
,
```
du
```
,
```
git status
```
,
```
git log
```
,
```
git diff
```

Forbidden operations:

```
Write
```
tool -- no file creation
```
Edit
```
tool -- no file modification

Bash:

rm

mv

cp

mkdir

touch

git add

git commit

git push

Gate: Read-only mode active. Proceed only when gate passes.

目标：在开始任何分析前建立防护规则。

调用

read-only-ops

技能：

skill: read-only-ops

这确保分析工作流期间不会发生任何修改。

允许的操作：

用于读取文件内容的Read工具
用于匹配文件模式的Glob工具
用于内容搜索的Grep工具
Bash命令：
```
ls
```
,
```
wc
```
,
```
du
```
,
```
git status
```
,
```
git log
```
,
```
git diff
```

禁止的操作：

```
Write
```
工具——禁止创建文件
```
Edit
```
工具——禁止修改文件

Bash命令：

rm

mv

cp

mkdir

touch

git add

git commit

git push

检查点：只读模式已激活。仅当检查点通过后才可继续。

Phase 2: GATHER CONTEXT

阶段2：收集上下文

Goal: Understand the target thoroughly before spawning critical perspectives.

Step 1: Identify target type

Input	Target	Action
No argument	README.md + repo structure	Read README, survey project layout
`@file.md`	Specific file	Read that file, identify related files
Description	Described concept	Search repo for related implementation

Step 2: Read key files

Use Read tool to examine: README.md, main documentation, key implementation files relevant to the target.

Step 3: Survey structure

Use Glob to map the landscape:

```
**/*.md
```
for documentation coverage
Source code organization and entry points
Configuration files and dependency declarations

Step 4: Search for patterns

Use Grep to find: specific claims to verify, usage patterns, dependency references, related test files.

Step 5: Ground verbal descriptions

If user describes a concept rather than pointing to a file, search the repo for existing implementation. Critique grounded in actual code beats critique of a strawman every time.

Gate: Target identified and sufficient context gathered. Proceed only when gate passes.

目标：在生成批判性视角前，充分理解目标对象。

步骤1：确定目标类型

输入	目标	操作
无参数	README.md + 仓库结构	读取README，调研项目布局
`@file.md`	特定文件	读取该文件，识别相关文件
描述性内容	描述的概念	在仓库中搜索相关实现

步骤2：读取关键文件

使用Read工具查看：README.md、主文档、与目标相关的关键实现文件。

步骤3：调研结构

使用Glob工具映射整体情况：

```
**/*.md
```
用于查看文档覆盖范围
源代码组织方式和入口点
配置文件和依赖声明

步骤4：搜索模式

使用Grep工具查找：需要验证的特定主张、使用模式、依赖引用、相关测试文件。

步骤5：落地口头描述

如果用户描述的是一个概念而非指向某个文件，在仓库中搜索现有实现。基于实际代码的批判远优于对假想目标的批判。

检查点：已确定目标并收集足够上下文。仅当检查点通过后才可继续。

Phase 3: SPAWN ROASTER AGENTS (Parallel)

阶段3：生成Roaster Agent（并行）

Launch 5 general-purpose agents in parallel via Task tool, each embodying a roaster persona. Load the full persona specification from the corresponding agent file into each prompt.

The 5 parallel tasks:

Skeptical Senior (
```
agents/reviewer-skeptical-senior.md
```
) Focus: Sustainability, maintenance burden, long-term viability
Well-Actually Pedant (
```
agents/reviewer-pedant.md
```
) Focus: Precision, intellectual honesty, terminological accuracy
Enthusiastic Newcomer (
```
agents/reviewer-newcomer.md
```
) Focus: Onboarding experience, documentation clarity, accessibility
Contrarian Provocateur (
```
agents/reviewer-contrarian.md
```
) Focus: Fundamental assumptions, alternative approaches
Pragmatic Builder (
```
agents/reviewer-pragmatic-builder.md
```
) Focus: Production readiness, operational concerns

Each agent must:

Invoke
```
read-only-ops
```
skill first
Follow their systematic 5-step review process
Tag ALL claims as
```
[CLAIM-N]
```
with
```
file:line
```
references
Provide specific evidence for every claim

See

references/personas.md

for full prompt template and claim format.

CRITICAL: Wait for all 5 agents to complete before proceeding to Phase 4. Do not begin validation on partial results -- all perspectives must be collected first.

Gate: All 5 agents complete with tagged claims. Proceed only when gate passes.

通过Task工具并行启动5个通用Agent，每个Agent对应一个批判角色。将对应Agent文件中的完整角色规范加载到每个提示中。

5个并行任务：

持怀疑态度的资深工程师（
```
agents/reviewer-skeptical-senior.md
```
）聚焦：可持续性、维护负担、长期可行性
较真的挑错者（
```
agents/reviewer-pedant.md
```
）聚焦：精确性、学术诚实、术语准确性
热情的新手（
```
agents/reviewer-newcomer.md
```
）聚焦：入门体验、文档清晰度、可访问性
唱反调的挑衅者（
```
agents/reviewer-contrarian.md
```
）聚焦：基本假设、替代方案
务实的构建者（
```
agents/reviewer-pragmatic-builder.md
```
）聚焦：生产就绪性、运维问题

每个Agent必须：

首先调用
```
read-only-ops
```
技能
遵循其系统化的5步评审流程
将所有主张标记为
```
[CLAIM-N]
```
，并附带
```
file:line
```
引用
为每一项主张提供具体证据

请查看

references/personas.md

获取完整提示模板和主张格式。

关键提示：等待所有5个Agent完成后再进入阶段4。不要基于部分结果开始验证——必须收集所有视角后再进行下一步。

检查点：所有5个Agent已完成并提交带标记的主张。仅当检查点通过后才可继续。

Phase 4: COORDINATE (Validate Claims)

阶段4：协调（验证主张）

Collect and validate every

[CLAIM-N]

from all 5 agents.

Step 1: Collect all claims

Extract every

[CLAIM-N]

tag from all 5 agent outputs. For each, track:

Claim ID and text
Source persona (Senior, Pedant, Newcomer, Contrarian, Builder)
Referenced file:line location

Step 2: Validate each claim

For each

[CLAIM-N]

, read the referenced file/line using Read tool and assign a verdict:

Verdict	Meaning	Criteria
VALID	Claim is accurate	Evidence directly supports it
PARTIAL	Overstated but has merit	Some truth, some exaggeration
UNFOUNDED	Not supported	Evidence contradicts or doesn't exist
SUBJECTIVE	Opinion, can't verify	Matter of preference/style

Step 3: Cross-reference

Note claims found independently by multiple agents -- these carry higher confidence. If 3+ personas independently identify the same issue, escalate to HIGH priority regardless of individual severity.

Step 4: Prioritize

Sort VALID and PARTIAL findings by impact:

HIGH: Core functionality, security, or maintainability
MEDIUM: Important improvements with moderate impact
LOW: Minor issues or polish

Gate: All claims validated with evidence. Proceed only when gate passes.

收集并验证所有5个Agent提出的每一个

[CLAIM-N]

。

步骤1：收集所有主张

从所有5个Agent的输出中提取每一个

[CLAIM-N]

标记。针对每一个主张，记录：

主张ID和文本
来源角色（资深工程师、挑错者、新手、挑衅者、构建者）
引用的file:line位置

步骤2：验证每一项主张

针对每一个

[CLAIM-N]

，使用Read工具读取引用的文件/行，并给出判定：

判定	含义	标准
VALID	主张准确	证据直接支持该主张
PARTIAL	主张有所夸大但有价值	部分属实，部分夸张
UNFOUNDED	无证据支持	证据反驳该主张或不存在相关证据
SUBJECTIVE	主观意见，无法验证	偏好/风格问题

步骤3：交叉引用

记录被多个Agent独立发现的主张——这些主张的可信度更高。如果3个及以上角色独立识别出同一个问题，无论单个严重程度如何，都将其升级为高优先级。

步骤4：确定优先级

按影响程度对VALID和PARTIAL的发现进行排序：

高：核心功能、安全或可维护性问题
中：重要改进，影响中等
低：小问题或优化点

检查点：所有主张已通过证据验证。仅当检查点通过后才可继续。

Phase 5: SYNTHESIZE (Generate Report)

阶段5：合成（生成报告）

Goal: Transform aggressive persona outputs into constructive, actionable report.

Follow the full template in

references/report-template.md

. Key synthesis rules:

Filter by verdict: Only VALID and PARTIAL claims appear in improvement opportunities
Dismissed section: UNFOUNDED claims go in dismissed section with evidence showing why
Subjective section: SUBJECTIVE claims noted as opinion-based, user decides
Strengths required: Coordinator validates what works well -- not just problems
Constructive tone: Strip sarcasm, mockery, dismissive language from agent outputs. Preserve technical accuracy and file references.
Implementation roadmap: Group actions by immediacy (immediate / short-term / long-term)

markdown

undefined

目标：将尖锐的角色输出转化为建设性、可落地的报告。

遵循

references/report-template.md

中的完整模板。关键合成规则：

按判定过滤：仅将VALID和PARTIAL的主张纳入改进建议部分
被驳回部分：UNFOUNDED的主张放入被驳回部分，并附上证据说明原因
主观部分：SUBJECTIVE的主张标注为基于意见，由用户决定
必须包含优势：协调者需验证有效的优势——不能只关注问题
建设性语气：去除Agent输出中的讽刺、嘲笑和轻蔑语言，保留技术准确性和文件引用
实施路线图：按紧急程度分组行动（立即/短期/长期）

markdown

undefined

Claim Validation Summary

主张验证摘要

Claim	Agent	Verdict	Evidence
[CLAIM-1]	Senior	VALID	[file:line shows X]
[CLAIM-2]	Pedant	PARTIAL	[true that X, but Y mitigates]
[CLAIM-3]	Newcomer	UNFOUNDED	[code shows otherwise]


**Gate**: Report complete with all sections populated. Analysis done.

---

主张	Agent	判定	证据
[CLAIM-1]	资深工程师	VALID	[file:line 显示X]
[CLAIM-2]	挑错者	PARTIAL	[X属实，但Y可缓解]
[CLAIM-3]	新手	UNFOUNDED	[代码显示情况相反]


**检查点**：报告完成，所有部分已填充。分析结束。

---

Examples

示例

Example 1: Roast a README

示例1：批判README

User says: "Roast this repo"

skill: roast

Actions:

Activate read-only mode (Phase 1)
Read README.md, survey repo structure, identify key files (Phase 2)
Spawn 5 persona agents in parallel, each analyzing README + structure (Phase 3)
Collect all [CLAIM-N] tags, validate each against actual files (Phase 4)
Synthesize constructive report with prioritized improvement opportunities (Phase 5) Result: Evidence-based critique with actionable improvements and validated strengths

用户说：「Roast这个仓库」

skill: roast

操作：

激活只读模式（阶段1）
读取README.md，调研仓库结构，识别关键文件（阶段2）
并行生成5个角色Agent，每个Agent分析README+结构（阶段3）
收集所有[CLAIM-N]标记，对照实际文件验证每一个（阶段4）
合成建设性报告，包含有优先级的改进建议（阶段5）结果：基于证据的批判，附带可落地的改进建议和经过验证的优势

Example 2: Roast a Design Doc

示例2：批判设计文档

User says: "Poke holes in the architecture doc"

skill: roast @README.md

Actions:

Activate read-only mode, read the target document (Phases 1-2)
Survey related implementation files referenced by the doc (Phase 2)
Spawn 5 agents focused on that document and its claims (Phase 3)
Validate claims against both doc content and referenced code (Phase 4)
Report with architecture-specific improvements and alternatives (Phase 5) Result: Multi-perspective architecture review grounded in implementation

用户说：「找出这个架构文档的漏洞」

skill: roast @README.md

操作：

激活只读模式，读取目标文档（阶段1-2）
调研文档引用的相关实现文件（阶段2）
生成5个聚焦该文档及其主张的Agent（阶段3）
对照文档内容和引用的代码验证主张（阶段4）
生成包含架构特定改进和替代方案的报告（阶段5）结果：基于实现的多视角架构评审

Example 3: Roast an Approach

示例3：批判一种方案

User says: "Devil's advocate on using SQLite for the error learning database"

skill: roast the idea of using SQLite for the error learning database

Actions:

Search repo for existing SQLite implementation and related code (Phase 2)
Spawn agents to critique both the concept AND actual code found (Phase 3)
Validate claims against implementation evidence (Phase 4)
Report grounded in real code, not just theoretical critique (Phase 5) Result: Critique anchored in actual implementation, not a strawman

用户说：「对使用SQLite作为错误学习数据库的方案唱反调」

skill: roast the idea of using SQLite for the error learning database

操作：

在仓库中搜索现有的SQLite实现和相关代码（阶段2）
生成Agent，同时批判概念和找到的实际代码（阶段3）
对照实现证据验证主张（阶段4）
生成基于真实代码而非假想目标的报告（阶段5）结果：基于实际实现的批判，而非针对假想目标

Error Handling

错误处理

Error: "Agent Returns Claims Without File References"

错误：「Agent返回的主张无文件引用」

Cause: Persona agent skipped evidence-gathering or analyzed verbally Solution:

Dismiss ungrounded claims as UNFOUNDED
If majority of claims lack references, re-run that specific agent with explicit instruction to cite file:line
Never promote ungrounded claims to the validated findings section

原因：角色Agent跳过了证据收集或仅基于口头描述分析解决方案：

将无依据的主张标记为UNFOUNDED并驳回
如果大部分主张都没有引用，重新运行该特定Agent并明确要求其引用file:line
绝不能将无依据的主张纳入已验证的发现部分

Error: "Read-Only Mode Not Activated"

错误：「未激活只读模式」

Cause: Phase 1 skipped or

read-only-ops

skill invocation failed Solution:

Stop all analysis immediately
Invoke
```
read-only-ops
```
before proceeding
If skill unavailable, manually enforce: no Write, Edit, or destructive Bash

原因：跳过了阶段1或

read-only-ops

技能调用失败解决方案：

立即停止所有分析
在继续前调用
```
read-only-ops
```
如果该技能不可用，手动强制执行：禁止使用Write、Edit或破坏性Bash命令

Error: "Agent Attempts to Fix Issues"

错误：「Agent尝试修复问题」

Cause: Persona agent crossed from analysis into implementation Solution:

Discard any modifications attempted
Extract only the analytical findings from that agent's output
Remind: this is read-only analysis, fixes are the user's decision

原因：角色Agent从分析跨越到了实现环节解决方案：

丢弃所有尝试的修改
仅从该Agent的输出中提取分析发现
提醒：这是只读分析，修复决策由用户做出

Error: "No Target Found or Empty Repository"

错误：「未找到目标或仓库为空」

Cause: User invoked roast without specifying target and no README.md exists Solution:

Check for alternative entry points: CONTRIBUTING.md, docs/, main source files
If repo has code but no docs, analyze the code structure and entry points
If truly empty, inform user and ask for a specific file or concept to analyze

原因：用户调用roast但未指定目标，且仓库中无README.md 解决方案：

检查替代入口点：CONTRIBUTING.md、docs/、主源代码文件
如果仓库有代码但无文档，分析代码结构和入口点
如果确实为空，告知用户并请求提供具体文件或概念进行分析

Anti-Patterns

反模式

Anti-Pattern 1: Vague, Unsupported Claims

反模式1：模糊、无依据的主张

What it looks like:

[CLAIM-1] The error handling seems insufficient

Why wrong: No file/line reference, cannot be validated, not actionable Do instead:

[CLAIM-1] No error handling in process_request() (server.py:45-67)

表现：

[CLAIM-1] 错误处理似乎不足

问题：无file:line引用，无法验证，不可落地 正确做法：

[CLAIM-1] process_request()中无错误处理（server.py:45-67）

Anti-Pattern 2: Skipping Validation Phase

反模式2：跳过验证阶段

What it looks like: Generating 5 persona critiques then jumping straight to action items Why wrong: Persona critiques may be incorrect or overstated. Unfounded claims pollute findings. Do instead: Validate every claim against actual evidence before including in report

表现：生成5个角色的批判后直接跳到行动项问题：角色批判可能不正确或夸大，无依据的主张会污染发现结果 正确做法：在将主张纳入报告前，对照实际证据验证每一项主张

Anti-Pattern 3: All-Negative Critique

反模式3：全负面批判

What it looks like: 5 personas list problems, report ends with 15 prioritized issues, no strengths Why wrong: Demotivating, ignores what works, unbalanced perspective Do instead: Coordinator validates strengths too. Include "Validated Strengths" section.

表现：5个角色列出问题，报告结尾有15个有优先级的问题，但无优势分析问题：打击积极性，忽略有效的部分，视角失衡 正确做法：协调者也要验证优势，包含「经过验证的优势」部分

Anti-Pattern 4: Fixing Instead of Reporting

反模式4：修复而非报告

What it looks like: Builder agent finds missing error handling, uses Edit tool to add it Why wrong: Violates read-only constraint. User didn't ask for changes. Do instead: Report the finding with evidence and suggested action. User decides.

表现：构建者Agent发现缺失的错误处理，使用Edit工具添加问题：违反只读约束，用户未要求修改 正确做法：报告该发现并附上证据和建议的行动，由用户决定是否修复

Anti-Pattern 5: Analyzing Without Context

反模式5：无上下文分析

What it looks like: User says "roast this approach", agent critiques verbal description without checking repo Why wrong: Misses existing implementation, may critique a strawman Do instead: Search repo for related code first. Ground critique in actual evidence.

表现：用户说「批判这个方案」，Agent仅基于口头描述批判而未检查仓库问题：忽略现有实现，可能批判的是假想目标 正确做法：先在仓库中搜索相关代码，基于实际证据开展批判

References

参考

This skill uses these shared patterns:

Anti-Rationalization - Prevents shortcut rationalizations
Verification Checklist - Pre-completion checks

本技能使用以下共享模式：

反合理化 - 防止捷径式合理化
验证清单 - 完成前检查

Domain-Specific Anti-Rationalization

特定领域的反合理化

Rationalization	Why It's Wrong	Required Action
"I can see the issue, no need to validate"	Visual inspection misses nuance	Validate every claim against evidence
"All 5 agents agree, must be true"	Consensus doesn't mean correct	Still verify against actual files
"User just wants a quick roast"	Quick doesn't mean unvalidated	Run validation, skip only if shallow mode
"This claim is obviously valid"	Obviously is a rationalization word	Read the file, check the line

合理化	问题	要求的操作
「我能看到问题，无需验证」	视觉检查会忽略细节	对照证据验证每一项主张
「所有5个Agent都同意，肯定是对的」	共识不代表正确	仍需对照实际文件验证
「用户只是想要快速批判」	快速不代表无需验证	运行验证，仅在浅层模式下可跳过
「这个主张显然是有效的」	「显然」是合理化词汇	读取文件，检查行号

Reference Files

参考文件

```
${CLAUDE_SKILL_DIR}/references/report-template.md
```
: Full report output template with tone transformation rules
```
${CLAUDE_SKILL_DIR}/references/personas.md
```
: Persona specifications, prompt template, and claim format
```
agents/reviewer-skeptical-senior.md
```
: Senior engineer persona
```
agents/reviewer-pedant.md
```
: Pedant persona
```
agents/reviewer-newcomer.md
```
: Newcomer persona
```
agents/reviewer-contrarian.md
```
: Contrarian persona
```
agents/reviewer-pragmatic-builder.md
```
: Builder persona

```
${CLAUDE_SKILL_DIR}/references/report-template.md
```
：完整报告输出模板，包含语气转换规则
```
${CLAUDE_SKILL_DIR}/references/personas.md
```
：角色规范、提示模板和主张格式
```
agents/reviewer-skeptical-senior.md
```
：资深工程师角色
```
agents/reviewer-pedant.md
```
：挑错者角色
```
agents/reviewer-newcomer.md
```
：新手角色
```
agents/reviewer-contrarian.md
```
：挑衅者角色
```
agents/reviewer-pragmatic-builder.md
```
：构建者角色

Dependencies

依赖

read-only-ops skill: Enforces no-modification guardrails during analysis

read-only-ops技能：在分析期间强制执行无修改防护规则