reviewer-creator

Reviewer Creator

Scaffold a project-level custom reviewer file for the deep-review skill. The generated file is located at docs/rules/review/<name>.mdand will be automatically discovered by the dispatcher at dispatch time (based on the discovery rules in step 2 of deep-review/SKILL.md ).

When to use

• The user wants to add a project-specific review concern not covered by the 11 built-in reviewers (for example "migration safety", "feature flag cleanup", "i18n key consistency", "schema version compatibility", "telemetry naming")
• The user invokes /reviewer-creator
• The team is introducing a new convention and wants to enforce it at the pull request stage

Two positionings (declared by the extends field): A custom reviewer is either (a) a project-specific supplement / narrowing of a built-in dimension（extends: <内置名>, absorbed by deep-review into the same host for review together), or (b) a completely new independent dimension（extends: standalone). Most project-specific concerns belong to (a); prefer absorption to control the number of subagents.

Skip for: Generic concerns already covered by built-in reviewers and requiring no project-specific supplement.

Prerequisites

• Installed the auriga-workflow plugin (this skill is distributed with the plugin alongside the deep-review skill)
• docs/rules/review/ The directory will be created on demand if it does not exist
• references/template.md(located under this skill directory) is the canonical template

Frontmatter schema

The generated file carries machine-readable orchestration metadata in the YAML frontmatter at the top of the file. Field contract:

Required (all reviewers):

• name — kebab-case, equal to the file name stem
• best_for — one-sentence responsibility; when extends is missing, it is also used for semantic overlap determination
• trigger — always | tag:<logic|auth-sensitive|ui|perf|arch> | non-trivial | detection-driven
• reasoning — flagship | workhorse
• tools — streaming list; default read-only [Read, Grep, Glob], add Bash
• value — value statement: what problem this dimension can prevent that built-in reviewers would miss

Optional:

• extends — <内置审查者名>(absorbed into that host) | standalone(force independent dispatch).Only used by custom reviewers; when omitted, deep-review decides semantically and leans toward absorption. built-in is a host and never sets extends。
• effort — xhigh(default) | high | medium | max; fill in only when the default needs to be overridden.

Legacy reviewers without frontmatter can still be read by deep-review in degraded mode (falling back to the body ## Metadata section), but new files always use frontmatter.

Steps

1. Gather metadata via AskUserQuestion / request_user_input

Collect in order (the order can be adjusted — item 8, dispatch mode, determines the positioning of the entire file, so it is recommended to confirm it first):

1. Name — kebab-case (for example migration-safety、i18n-keys). Validation:
   • all lowercase / hyphen-separated / no spaces or special characters
   • reject names that duplicate a built-in reviewer：spec-conformance、correctness、test-quality、docs-sync、robustness、security、ux、performance、architecture、code-quality、skill-plugin-quality — duplicating a built-in name will be regarded by deep-review as an inevitable overlap and directly absorbed into the built-in reviewer of the same name; a custom reviewer should take a name distinct from the built-in ones to avoid being accidentally absorbed
2. One-line "Best for" — a short responsibility description (12–25 characters)
3. Domain — a phrase used for the scope preamble (for example "migration safety", "feature flag cleanup")
4. Trigger category — choose exactly one:
   • always — triggered on every pull request (use with caution; costs accumulate)
   • tag:<name> — triggers only when an existing label is set (logic / auth-sensitive / ui / perf / arch）
   • non-trivial — triggers on any non-trivial change
   • detection-driven — triggers only when a Detection signal matches (the recommended default for narrow concerns)
5. Detection signals — at least 3 grep-able rules (path globs / import patterns / API call patterns).detection-driven Required; for other categories it can serve as a concern hint
6. Reasoning tier — flagship(requires deep multi-hop reasoning—e.g., defect triage, architectural judgment) or workhorse(pattern matching / checklist verification). The tier is resolved at dispatch time by the runtime platform according to the current model lineup: flagship → that platform's current strongest reasoning model; workhorse → a model one tier below flagship with better cost-effectiveness. Do not hardcode specific model names in reviewer files—the tier semantics stay the same as model generations change. Default workhorse, unless that reviewer needs to reason cross-cuttingly about the diff
7. One worked scenario — concrete file:line-style examples of issues this reviewer will catch (used to fill the Worked scenarios section; also keep ≥2 as TODO)
8. Dispatch mode (extends） — (recommended to confirm first, as it determines the positioning of the entire file) Ask: is this reviewer (a) a project-specific supplement to a built-in dimension, or (b) a completely new independent dimension？
   • (a) Select a built-in reviewer name (spec-conformance / correctness / test-quality / docs-sync / robustness / security / ux / performance / architecture / code-quality / skill-plugin-quality) → write extends: <内置名>。deep-review will absorb its Checklist and worked scenarios into that host for review together, without using an extra subagent.
   • (b) None of the 11 built-in ones covers it and independent dispatch is needed → write extends: standalone。
   • Most project-specific reviewers fall under (a); prefer absorption to control the number of subagents. When unsure, compare against deep-review/SKILL.md Step 2's absorption examples and choose the closest host.

2. Generate the file

The output directory is anchored to the repository root (cwd may not be the repository root, e.g., when started from a monorepo subdirectory); for non-git repositories, fall back to the current working directory—command substitution without a fallback expands to an empty string in non-git directories, creating the directory at the filesystem root:

mkdir -p "$(git rev-parse --show-toplevel 2>/dev/null || pwd)/docs/rules/review/"

In a monorepo, if this reviewer constrains only a certain subpackage, you can instead write it into that subpackage's docs/rules/review/——deep-review collects both levels, and the subpackage level is treated as a supplement/narrowing of the repository level.

Read this skill's references/template.md. Replace:

Placeholder	Source
<NAME>	Step 1's Name (kebab-case, = filename stem, written into frontmatter name）
<TITLE>	name → human-readable form (e.g., migration-safety → "Migration Safety"）
<DOMAIN>	Step 1's domain phrase
<BEST_FOR>	Step 1's "Best for" one-liner
<TRIGGER>	Step 1's Trigger category
<REASONING>	Step 1's Reasoning tier
<DETECTION_ROWS>	Markdown table rows assembled from Detection signals
<WORKED_SCENARIO_1>	The scenario provided in Step 1
<EXTENDS>	Step 8's Dispatch mode (extends: <内置名> or extends: standalone）

Write the replaced content to <仓库根>/docs/rules/review/<name>.md(or the selected subpackage-level directory).

The frontmatter's value field, as well as the remaining <TODO: ...> placeholders in the body (Checklist body, scenarios 2 and 3, Output contract details), are left for the user to fill in—they require domain expertise that this skill cannot synthesize.

3. Tell the user what to do next

Print a brief summary:

1. File created at docs/rules/review/<name>.md
2. Edits that must be completed before use:
   • Fill in the value field in the frontmatter
   • Replace the <TODO: ...> placeholder in the Checklist with 5–10 specific, actionable review questions
   • Then add 2 more Worked scenarios (concrete file:line-style examples)
   • If this reviewer needs special lens/category tags, optionally adjust the Output contract
3. Verification:
   • Run on a pull request that should trigger the new reviewer /deep-review
   • Check that the list of dispatched reviewers includes <name>
   • Confirm that the synthesis output includes findings from this custom reviewer
4. If the trigger is set incorrectly: Edit the trigger field in the frontmatter and re-run; no other changes are needed

Anti-patterns

• ❌ Use the name of a built-in reviewer——deep-review will absorb a custom reviewer with the same name into the built-in reviewer of that name; to add a new dimension, choose a name different from the built-ins
• ❌ Set always triggers for narrow concerns——every pull request incurs a dispatch cost; prefer detection-driven
• ❌ Omit Detection signals——detection-driven is required, and it can also serve as a focus hint in other scenarios
• ❌ Delete the "starting point, not boundary" scope preamble——reviewers lacking it tend to miss findings outside the checklist (newer reasoning models tend to treat enumerated lists as closed sets)
• ❌ Declare a project-specific narrowing of a built-in dimension as extends: standalone(or omit extends while writing Scope as if it were an entirely new dimension)——it will be dispatched independently, duplicating the host's reports on the same file:line and wastefully consuming subagents. If it is essentially a narrowing of a built-in dimension, use extends: <内置名> to declare absorption; only concerns not covered by any of the 11 built-ins should use standalone

Example session

User: /reviewer-creator
Assistant: [走完 8 个问题；用户提供：
            name=migration-safety, best_for="捕捉不安全的数据库迁移",
            domain="迁移安全", trigger=detection-driven, signals=
            (*.sql 文件、ALTER TABLE 模式、drop_column 调用、
            migrations/ 目录), reasoning=workhorse, 1 个场景,
            extends=standalone（迁移安全是内置维度未覆盖的全新维度）]
Assistant: [生成 docs/rules/review/migration-safety.md]
Assistant: "文件已创建。接下来：填写 Checklist（5–10 条具体的安全检查，
            如'添加 NOT NULL 却没有回填？'、'并发索引创建？'），
            补 2 个 Worked scenarios，然后在一个含迁移的拉取请求上运行
            /deep-review 以验证分派。"