code-review

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Code Review

代码评审

Review code for AEM Edge Delivery Services (EDS) projects following established coding standards, performance requirements, and best practices.
针对AEM Edge Delivery Services(EDS)项目,按照既定编码标准、性能要求和最佳实践进行代码评审。

When to Use This Skill

何时使用该技能

This skill supports two modes of operation:
该技能支持两种操作模式

Mode 1: Self-Review (End of Development)

模式1:自我评审(开发末期)

Use this mode when you've finished writing code and want to review it before committing or opening a PR. This is the recommended workflow integration point.
When to invoke:
  • After completing implementation in the content-driven-development workflow (between Step 5 and Step 6)
  • Before running
    git add
    and
    git commit
  • When you want to catch issues early, before they reach PR review
How to invoke:
  • Automatically: CDD workflow invokes this skill after implementation
  • Manually:
    /code-review
    (reviews uncommitted changes in working directory)
What it does:
  • Reviews all modified/new files in working directory
  • Checks code quality, patterns, and best practices
  • Validates against EDS standards
  • Identifies issues to fix before committing
  • Captures visual screenshots for validation
当你完成代码编写,希望在提交或发起PR前进行评审时,使用此模式。这是推荐的工作流集成节点。
调用时机:
  • 内容驱动开发工作流中完成实现后(第5步和第6步之间)
  • 执行
    git add
    git commit
    之前
  • 希望在问题进入PR评审阶段前提前发现问题时
调用方式:
  • 自动触发:CDD工作流在实现完成后自动调用该技能
  • 手动触发:
    /code-review
    (评审工作目录中未提交的变更)
功能说明:
  • 评审工作目录中所有已修改/新增的文件
  • 检查代码质量、模式和最佳实践
  • 验证是否符合EDS标准
  • 识别提交前需要修复的问题
  • 捕获截图用于视觉验证

Mode 2: PR Review

模式2:PR评审

Use this mode to review an existing pull request (your own or someone else's).
When to invoke:
  • Reviewing a PR before merge
  • Automated review via GitHub Actions workflow
  • Manual review of a specific PR
How to invoke:
  • Manually:
    /code-review <PR-number>
    or
    /code-review <PR-URL>
  • Automated: Via GitHub workflow on
    pull_request
    event
What it does:
  • Fetches PR diff and changed files
  • Validates PR structure (preview URLs, description)
  • Reviews code quality
  • Posts review comment with findings and screenshots
  • Provides actionable fixes via GitHub suggestions or commits
  • Explains reasoning for each fix with references to review feedback

使用此模式评审现有拉取请求(自己或他人的)。
调用时机:
  • 合并前评审PR
  • 通过GitHub Actions工作流自动评审
  • 手动评审特定PR
调用方式:
  • 手动触发:
    /code-review <PR-number>
    /code-review <PR-URL>
  • 自动触发:通过GitHub工作流在
    pull_request
    事件时触发
功能说明:
  • 获取PR差异和变更文件
  • 验证PR结构(预览URL、描述)
  • 评审代码质量
  • 在PR评论中发布评审结果和截图
  • 通过GitHub建议或提交代码提供可操作的修复方案
  • 结合评审反馈说明每个修复的理由

Review Workflow

步骤1:确定评审模式并收集上下文

Step 1: Identify Review Mode and Gather Context

For Self-Review (no PR number provided):
bash
undefined
自我评审模式(未提供PR编号):
bash
undefined

See what files have been modified

查看已修改的文件

git status
git status

See the actual changes

查看具体变更内容

git diff
git diff

For staged changes

查看已暂存的变更

git diff --staged

**Understand the scope:**
- What files were modified?
- What type of change is this? (new block, bug fix, feature, styling, refactor)
- What is the test content URL? (from CDD workflow)

**For PR Review (PR number provided):**

```bash
git diff --staged

**明确评审范围:**
- 修改了哪些文件?
- 这属于哪种类型的变更?(新增模块、bug修复、功能开发、样式调整、重构)
- 测试内容的URL是什么?(来自CDD工作流)

**PR评审模式(提供PR编号):**

```bash

Get PR details

获取PR详情

gh pr view <PR-number> --json title,body,author,baseRefName,headRefName,files,additions,deletions
gh pr view <PR-number> --json title,body,author,baseRefName,headRefName,files,additions,deletions

Get changed files

获取变更文件

gh pr diff <PR-number>
gh pr diff <PR-number>

Get PR comments and reviews

获取PR评论和评审记录

gh api repos/{owner}/{repo}/pulls/<PR-number>/comments gh api repos/{owner}/{repo}/pulls/<PR-number>/reviews

**Understand the scope:**
- What type of change is this? (new block, bug fix, feature, styling, refactor)
- What files are modified?
- Is there a related GitHub issue?
- Are there test/preview URLs provided?

---
gh api repos/{owner}/{repo}/pulls/<PR-number>/comments gh api repos/{owner}/{repo}/pulls/<PR-number>/reviews

**明确评审范围:**
- 这属于哪种类型的变更?(新增模块、bug修复、功能开发、样式调整、重构)
- 修改了哪些文件?
- 是否有相关的GitHub issue?
- 是否提供了测试/预览URL?

---

Step 2: Validate Structure (PR Review Mode Only)

步骤2:验证结构(仅PR评审模式)

Skip this step for Self-Review mode.
Required elements for PRs (MUST HAVE):
ElementRequirementCheck
Preview URLsBefore/After URLs showing the changeRequired
DescriptionClear explanation of what changed and whyRequired
Scope alignmentChanges match PR title and descriptionRequired
Issue referenceLink to GitHub issue (if applicable)Recommended
Preview URL format:
  • Before:
    https://main--{repo}--{owner}.aem.page/{path}
  • After:
    https://{branch}--{repo}--{owner}.aem.page/{path}
Flag if missing:
  • Missing preview URLs (blocks automated PSI checks)
  • Vague or missing description
  • Scope creep (changes unrelated to stated purpose)
  • Missing issue reference for bug fixes

自我评审模式跳过此步骤。
PR必填元素(必须包含):
元素要求检查项
预览URL展示变更的前后对比URL必填
描述清晰说明变更内容和原因必填
范围一致性变更内容与PR标题和描述匹配必填
Issue关联链接到GitHub issue(如适用)推荐
预览URL格式:
  • 变更前:
    https://main--{repo}--{owner}.aem.page/{path}
  • 变更后:
    https://{branch}--{repo}--{owner}.aem.page/{path}
缺失时标记问题:
  • 缺少预览URL(会阻碍自动化PSI检查)
  • 描述模糊或缺失
  • 范围偏离(变更与声明目的无关)
  • bug修复未关联issue

Step 3: Code Quality Review

步骤3:代码质量评审

3.1 JavaScript Review

3.1 JavaScript评审

Linting & Style:
  • Code passes ESLint (airbnb-base configuration)
  • No
    eslint-disable
    comments without justification
  • No global
    eslint-disable
    directives
  • ES6+ features used appropriately
  • .js
    extensions included in imports
Architecture:
  • No frameworks in critical rendering path (LCP/TBT impact)
  • Third-party libraries loaded via
    loadScript()
    in blocks, not
    head.html
  • Consider
    IntersectionObserver
    for heavy libraries
  • aem.js
    is NOT modified (submit upstream PRs for improvements)
  • No build steps introduced without team consensus
Code Patterns:
  • Existing DOM elements re-used, not recreated
  • Block selectors scoped appropriately
  • No hardcoded values that should be configurable
  • Console statements cleaned up (no debug logs)
  • Proper error handling where needed
Common Issues to Flag:
javascript
// BAD: CSS in JavaScript
element.style.backgroundColor = 'blue';

// GOOD: Use CSS classes
element.classList.add('highlighted');

// BAD: Hardcoded configuration
const temperature = 0.7;

// GOOD: Use config or constants
const { temperature } = CONFIG;

// BAD: Global eslint-disable
/* eslint-disable */

// GOOD: Specific, justified disables
/* eslint-disable-next-line no-console -- intentional debug output */
代码检查与风格:
  • 代码通过ESLint检查(采用airbnb-base配置)
  • 无无理由的
    eslint-disable
    注释
  • 无全局
    eslint-disable
    指令
  • 合理使用ES6+特性
  • 导入语句中包含
    .js
    扩展名
架构:
  • 关键渲染路径中未使用框架(避免影响LCP/TBT)
  • 第三方库通过块中的
    loadScript()
    加载,而非
    head.html
  • 大型库考虑使用
    IntersectionObserver
  • 不得修改
    aem.js
    (如需改进请提交上游PR)
  • 未经团队共识不得引入构建步骤
代码模式:
  • 复用现有DOM元素,而非重新创建
  • 块选择器作用域合理
  • 不应硬编码可配置的值
  • 清理控制台语句(移除调试日志)
  • 必要时添加适当的错误处理
需标记的常见问题:
javascript
// 不良实践:在JavaScript中写CSS
element.style.backgroundColor = 'blue';

// 最佳实践:使用CSS类
element.classList.add('highlighted');

// 不良实践:硬编码配置
const temperature = 0.7;

// 最佳实践:使用配置或常量
const { temperature } = CONFIG;

// 不良实践:全局禁用ESLint
/* eslint-disable */

// 最佳实践:特定、有理由的禁用
/* eslint-disable-next-line no-console -- intentional debug output */

3.2 CSS Review

3.2 CSS评审

Linting & Style:
  • Code passes Stylelint (standard configuration)
  • No
    !important
    unless absolutely necessary (with justification)
  • Property order maintained (don't reorder in functional PRs)
Scoping & Selectors:
  • All selectors scoped to block:
    .{block-name} .selector
    or
    main .{block-name}
  • Private classes/variables prefixed with block name
  • Simple, readable selectors (add classes rather than complex selectors)
  • ARIA attributes used for styling when appropriate (
    [aria-expanded="true"]
    )
Responsive Design:
  • Mobile-first approach (base styles for mobile, media queries for larger)
  • Standard breakpoints used:
    600px
    ,
    900px
    ,
    1200px
    (all
    min-width
    )
  • No mixing of
    min-width
    and
    max-width
    queries
  • Layout works across all viewports
Frameworks & Preprocessors:
  • No CSS preprocessors (Sass, Less, PostCSS) without team consensus
  • No CSS frameworks (Tailwind, etc.) without team consensus
  • Native CSS features used (supported by evergreen browsers)
Common Issues to Flag:
css
/* BAD: Unscoped selector */
.title { color: red; }

/* GOOD: Scoped to block */
main .my-block .title { color: red; }

/* BAD: !important abuse */
.button { color: white !important; }

/* GOOD: Increase specificity instead */
main .my-block .button { color: white; }

/* BAD: Mixed breakpoint directions */
@media (max-width: 600px) { }
@media (min-width: 900px) { }

/* GOOD: Consistent mobile-first */
@media (min-width: 600px) { }
@media (min-width: 900px) { }

/* BAD: CSS in JS patterns */
element.innerHTML = '<style>.foo { color: red; }</style>';

/* GOOD: Use external CSS files */
代码检查与风格:
  • 代码通过Stylelint检查(采用标准配置)
  • 除非绝对必要(且有理由),否则不使用
    !important
  • 保持属性顺序(功能性PR中不要重新排序)
作用域与选择器:
  • 所有选择器都限定在块范围内:
    .{block-name} .selector
    main .{block-name}
  • 私有类/变量以块名称为前缀
  • 使用简洁、易读的选择器(添加类而非复杂选择器)
  • 合适时使用ARIA属性进行样式控制(
    [aria-expanded="true"]
响应式设计:
  • 采用移动优先的方法(基础样式针对移动端,媒体查询针对更大屏幕)
  • 使用标准断点:
    600px
    900px
    1200px
    (均为
    min-width
  • 不要混合使用
    min-width
    max-width
    查询
  • 布局在所有视口下都能正常工作
框架与预处理器:
  • 未经团队共识不得使用CSS预处理器(Sass、Less、PostCSS)
  • 未经团队共识不得使用CSS框架(Tailwind等)
  • 使用原生CSS特性(受现代浏览器支持)
需标记的常见问题:
css
/* 不良实践:未限定作用域的选择器 */
.title { color: red; }

// 最佳实践:限定在块范围内
main .my-block .title { color: red; }

/* 不良实践:滥用!important */
.button { color: white !important; }

/* 最佳实践:提高选择器特异性 */
main .my-block .button { color: white; }

/* 不良实践:混合断点方向 */
@media (max-width: 600px) { }
@media (min-width: 900px) { }

/* 最佳实践:一致的移动优先方式 */
@media (min-width: 600px) { }
@media (min-width: 900px) { }

/* 不良实践:JS中嵌入CSS模式 */
element.innerHTML = '<style>.foo { color: red; }</style>';

/* 最佳实践:使用外部CSS文件 */

3.3 HTML Review

3.3 HTML评审

  • Semantic HTML5 elements used appropriately
  • Proper heading hierarchy maintained
  • Accessibility attributes present (ARIA labels, alt text)
  • No inline styles or scripts in
    head.html
  • Marketing tech NOT in
    <head>
    (performance impact)

  • 合理使用语义化HTML5元素
  • 保持正确的标题层级
  • 包含可访问性属性(ARIA标签、替代文本)
  • head.html
    中无内联样式或脚本
  • 营销技术代码不要放在
    <head>
    中(影响性能)

Step 4: Performance Review

步骤4:性能评审

Critical Requirements:
  • Lighthouse scores green (ideally 100) for mobile AND desktop
  • No third-party libraries in critical path (
    head.html
    )
  • No layout shifts introduced (CLS impact)
  • Images optimized and lazy-loaded appropriately
Performance Checklist:
  • Heavy operations use
    IntersectionObserver
    or delayed loading
  • No synchronous operations blocking render
  • Bundle size reasonable (no minification unless measurable Lighthouse gain)
  • Fonts loaded efficiently
Preview URL Verification: If preview URLs provided, check:
  • PageSpeed Insights scores
  • Core Web Vitals (LCP, CLS, INP)
  • Mobile and desktop performance

关键要求:
  • 移动端和桌面端的Lighthouse评分均为绿色(理想值为100)
  • 关键路径(
    head.html
    )中无第三方库
  • 未引入布局偏移(影响CLS)
  • 图片已优化并合理启用懒加载
性能检查清单:
  • 重型操作使用
    IntersectionObserver
    或延迟加载
  • 无阻塞渲染的同步操作
  • 包大小合理(除非Lighthouse评分有可衡量的提升,否则不要压缩)
  • 字体加载高效
预览URL验证: 如果提供了预览URL,检查:
  • PageSpeed Insights评分
  • Core Web Vitals(LCP、CLS、INP)
  • 移动端和桌面端性能

Step 5: Visual Validation with Screenshots

步骤5:截图视觉验证

Purpose: Capture screenshots of the preview URL to validate visual appearance. For self-review, this confirms your changes look correct before committing. For PR review, this provides visual evidence in the review comment.
When to capture screenshots:
  • Always capture at least one screenshot of the primary changed page/component
  • For responsive changes, capture mobile (375px), tablet (768px), and desktop (1200px)
  • For visual changes (styling, layout), capture before AND after for comparison
  • For block changes, capture the specific block area
How to capture screenshots:
Option 1: Playwright (Recommended for automation)
javascript
// capture-screenshots.js
import { chromium } from 'playwright';

async function captureScreenshots(afterUrl, outputDir = './screenshots') {
  const browser = await chromium.launch();
  const page = await browser.newPage();

  // Desktop screenshot
  await page.setViewportSize({ width: 1200, height: 800 });
  await page.goto(afterUrl, { waitUntil: 'networkidle' });
  await page.waitForTimeout(1000); // Wait for animations
  await page.screenshot({
    path: `${outputDir}/desktop.png`,
    fullPage: true
  });

  // Tablet screenshot
  await page.setViewportSize({ width: 768, height: 1024 });
  await page.screenshot({
    path: `${outputDir}/tablet.png`,
    fullPage: true
  });

  // Mobile screenshot
  await page.setViewportSize({ width: 375, height: 667 });
  await page.screenshot({
    path: `${outputDir}/mobile.png`,
    fullPage: true
  });

  // Optional: Capture specific block/element
  const block = page.locator('.my-block');
  if (await block.count() > 0) {
    await block.screenshot({ path: `${outputDir}/block.png` });
  }

  await browser.close();

  return {
    desktop: `${outputDir}/desktop.png`,
    tablet: `${outputDir}/tablet.png`,
    mobile: `${outputDir}/mobile.png`
  };
}

// Usage
captureScreenshots('https://branch--repo--owner.aem.page/path');
Option 2: Using MCP Browser Tools
If you have MCP browser or Playwright tools available:
  1. Navigate to the After preview URL
  2. Take screenshots at different viewport sizes
  3. Optionally take element-specific screenshots of changed blocks
Option 3: Manual capture with guidance
Instruct the reviewer or PR author to:
  1. Open the After preview URL
  2. Use browser DevTools to set viewport sizes
  3. Take screenshots and attach to PR
Uploading screenshots to GitHub:
bash
undefined
目的: 捕获预览URL的截图以验证视觉效果。自我评审时,这能确认你的变更在提交前显示正常;PR评审时,这能在评审评论中提供视觉证据。
捕获截图的时机:
  • 至少捕获一张主要变更页面/组件的截图
  • 响应式变更需捕获移动端(375px)、平板(768px)和桌面(1200px)截图
  • 视觉变更(样式、布局)需捕获变更前后的对比截图
  • 块变更需捕获特定块区域的截图
捕获截图的方式:
选项1:Playwright(推荐用于自动化)
javascript
// capture-screenshots.js
import { chromium } from 'playwright';

async function captureScreenshots(afterUrl, outputDir = './screenshots') {
  const browser = await chromium.launch();
  const page = await browser.newPage();

  // 桌面端截图
  await page.setViewportSize({ width: 1200, height: 800 });
  await page.goto(afterUrl, { waitUntil: 'networkidle' });
  await page.waitForTimeout(1000); // 等待动画完成
  await page.screenshot({
    path: `${outputDir}/desktop.png`,
    fullPage: true
  });

  // 平板端截图
  await page.setViewportSize({ width: 768, height: 1024 });
  await page.screenshot({
    path: `${outputDir}/tablet.png`,
    fullPage: true
  });

  // 移动端截图
  await page.setViewportSize({ width: 375, height: 667 });
  await page.screenshot({
    path: `${outputDir}/mobile.png`,
    fullPage: true
  });

  // 可选:捕获特定块/元素
  const block = page.locator('.my-block');
  if (await block.count() > 0) {
    await block.screenshot({ path: `${outputDir}/block.png` });
  }

  await browser.close();

  return {
    desktop: `${outputDir}/desktop.png`,
    tablet: `${outputDir}/tablet.png`,
    mobile: `${outputDir}/mobile.png`
  };
}

// 使用示例
captureScreenshots('https://branch--repo--owner.aem.page/path');
选项2:使用MCP浏览器工具
如果有MCP浏览器或Playwright工具:
  1. 打开变更后的预览URL
  2. 不同视口尺寸下截图
  3. 可选:对变更的块进行元素特定截图
选项3:手动捕获(带指导)
指导评审者或PR作者:
  1. 打开变更后的预览URL
  2. 使用浏览器开发者工具设置视口尺寸
  3. 截图并附加到PR
上传截图到GitHub:
bash
undefined

Upload screenshot as PR comment with image

上传截图作为PR评论中的图片

First, upload to a hosting service or use GitHub's image upload

先上传到托管服务或使用GitHub的图片上传功能

Option A: Embed in PR comment (drag & drop in GitHub UI)

选项A:在PR评论中嵌入(GitHub UI中拖放)

gh pr comment <PR-number> --body "## Visual Preview
gh pr comment <PR-number> --body "## 视觉预览

Desktop (1200px)

桌面端(1200px)

Desktop Screenshot
Desktop Screenshot

Mobile (375px)

移动端(375px)

Mobile Screenshot "
Mobile Screenshot "

Option B: Use GitHub's attachment API (for automation)

选项B:使用GitHub的附件API(用于自动化)

Screenshots can be uploaded as part of the comment body

截图可作为评论正文的一部分上传


**Screenshot checklist:**
- [ ] Primary page/component captured at desktop width
- [ ] Mobile viewport captured (if responsive changes)
- [ ] Specific block/component captured (if block changes)
- [ ] Before/After comparison (if significant visual changes)
- [ ] No sensitive data visible in screenshots
- [ ] Screenshots uploaded and embedded in PR comment

**Visual issues to look for:**
- Layout breaks or misalignment
- Text overflow or truncation
- Image sizing or aspect ratio issues
- Color/contrast problems (especially in dark mode)
- Missing or broken icons
- Responsive layout issues at breakpoints
- Unexpected visual differences from main branch

---

**截图检查清单:**
- [ ] 已捕获主要页面/组件的桌面端截图
- [ ] 已捕获移动端视口截图(如涉及响应式变更)
- [ ] 已捕获特定块/组件截图(如涉及块变更)
- [ ] 已捕获变更前后对比截图(如涉及重大视觉变更)
- [ ] 截图中无敏感数据
- [ ] 截图已上传并嵌入到PR评论中

**需关注的视觉问题:**
- 布局断裂或对齐错误
- 文本溢出或截断
- 图片尺寸或宽高比问题
- 颜色/对比度问题(尤其是深色模式)
- 图标缺失或损坏
- 断点处的响应式布局问题
- 与主分支的意外视觉差异

---

Step 6: Content & Authoring Review

步骤6:内容与创作评审

Content Model (if applicable):
  • Content structure author-friendly
  • Backward compatibility maintained with existing content
  • No breaking changes requiring content migration
  • New content features only available after preview/publish
Static Resources:
  • No binaries/static assets committed (unless code-referenced)
  • User-facing strings sourced from content (placeholders, spreadsheets)
  • No hardcoded literals that should be translatable

内容模型(如适用):
  • 内容结构对创作者友好
  • 与现有内容保持向后兼容
  • 无需要内容迁移的破坏性变更
  • 新内容功能仅在预览/发布后可用
静态资源:
  • 未提交二进制/静态资源(除非代码引用)
  • 用户可见的字符串来自内容(占位符、表格)
  • 不应硬编码可翻译的文字

Step 7: Security Review

步骤7:安全评审

  • No sensitive data committed (API keys, passwords, secrets)
  • No XSS vulnerabilities (unsafe innerHTML, unsanitized user input)
  • No SQL injection or command injection vectors
  • CSP headers appropriate for tool pages
  • External links have
    rel="noopener noreferrer"

  • 未提交敏感数据(API密钥、密码、机密信息)
  • 无XSS漏洞(不安全的innerHTML、未净化的用户输入)
  • 无SQL注入或命令注入风险
  • 工具页面的CSP头配置合理
  • 外部链接包含
    rel="noopener noreferrer"

Step 8: Generate Review Summary

步骤8:生成评审总结

Output depends on the review mode:
输出内容取决于评审模式:

For Self-Review Mode (End of Development)

自我评审模式(开发末期)

Report findings directly to continue the development workflow:
markdown
undefined
直接向开发工作流报告结果:
markdown
undefined

Code Review Summary

代码评审总结

Files Reviewed

已评审文件

  • blocks/my-block/my-block.js
    (new)
  • blocks/my-block/my-block.css
    (new)
  • blocks/my-block/my-block.js
    (新增)
  • blocks/my-block/my-block.css
    (新增)

Visual Validation

视觉验证

Desktop Screenshot
✅ Layout renders correctly across viewports ✅ No console errors ✅ Responsive behavior verified
Desktop Screenshot
✅ 布局在各视口下渲染正常 ✅ 无控制台错误 ✅ 响应式行为已验证

Issues Found

发现的问题

Must Fix Before Committing

提交前必须修复

  • blocks/my-block/my-block.js:45
    - Remove console.log debug statement
  • blocks/my-block/my-block.css:12
    - Selector
    .title
    needs block scoping
  • blocks/my-block/my-block.js:45
    - 移除console.log调试语句
  • blocks/my-block/my-block.css:12
    - 选择器
    .title
    需要限定块作用域

Recommendations

建议

  • Consider using
    loadScript()
    for the external library
  • 考虑对外部库使用
    loadScript()

Ready to Commit?

是否准备好提交?

  • All "Must Fix" issues resolved
  • Linting passes:
    npm run lint
  • Visual validation complete

**After self-review:** Fix any issues found, then proceed with committing and opening a PR.
  • 所有“必须修复”的问题已解决
  • 代码检查通过:
    npm run lint
  • 视觉验证完成

**自我评审后:** 修复发现的问题,然后继续提交和发起PR。

For PR Review Mode

PR评审模式

Structure the review comment for GitHub:
markdown
undefined
为GitHub结构化评审评论:
markdown
undefined

PR Review Summary

PR评审总结

Overview

概述

[Brief summary of the PR and its purpose]
[PR的简要总结和目的]

Preview URLs Validated

已验证的预览URL

  • Before: [URL]
  • After: [URL]
  • 变更前:[URL]
  • 变更后:[URL]

Visual Preview

视觉预览

Desktop (1200px)

桌面端(1200px)

Desktop Screenshot
Desktop Screenshot

Mobile (375px)

移动端(375px)

Mobile Screenshot
<details> <summary>Additional Screenshots</summary>
Mobile Screenshot
<details> <summary>更多截图</summary>

Tablet (768px)

平板端(768px)

Tablet Screenshot
Tablet Screenshot

Block Detail

块详情

Block Screenshot
</details>
Block Screenshot
</details>

Visual Assessment

视觉评估

  • Layout renders correctly across viewports
  • No visual regressions from main branch
  • Colors and typography consistent
  • Images and icons display properly
  • 布局在各视口下渲染正常
  • 与主分支相比无视觉回归
  • 颜色和排版一致
  • 图片和图标显示正常

Checklist Results

检查清单结果

Must Fix (Blocking)

必须修复(阻塞合并)

  • [Critical issue with file:line reference]
  • [带文件:行号引用的严重问题]

Should Fix (High Priority)

应该修复(高优先级)

  • [Important issue with file:line reference]
  • [带文件:行号引用的重要问题]

Consider (Suggestions)

建议(可选项)

  • [Nice-to-have improvement]
  • [锦上添花的改进]

Detailed Findings

详细发现

[Category: e.g., JavaScript, CSS, Performance]

[类别:如JavaScript、CSS、性能]

File:
path/to/file.js:123
Issue: [Description of the issue] Suggestion: [How to fix it]

---
文件:
path/to/file.js:123
问题: [问题描述] 建议: [修复方案]

---

Step 9: Provide Actionable Fixes (PR Review Mode Only)

步骤9:提供可操作的修复方案(仅PR评审模式)

Skip this step for Self-Review mode - in self-review, you fix issues directly in your working directory.
After identifying issues in a PR review, provide actionable fixes to make it easier for the PR author to address them. The goal is to provide one-click fixes whenever possible.
自我评审模式跳过此步骤 - 自我评审时,你直接在工作目录中修复问题。
在PR评审中发现问题后,提供可操作的修复方案,方便PR作者解决。目标是尽可能提供一键修复方案。

Quick Reference

快速参考

PRIMARY METHOD: GitHub Suggestions (use for ~70-80% of fixable issues)
  • One-click acceptance by PR author
  • Proper git attribution
  • Works for changes < 20 lines
  • Native GitHub UI integration
SECONDARY: Guidance Comments (~20-30% of issues)
  • For subjective or architectural issues
  • When multiple approaches exist
  • "Consider" level suggestions
RARE: Fix Commits (avoid unless necessary)
  • Only when suggestions won't work
  • Multi-file complex refactors
  • Changes requiring extensive testing

首选方法:GitHub建议(约70-80%的可修复问题使用)
  • PR作者可一键接受
  • Git归属正确
  • 适用于少于20行的变更
  • 原生GitHub UI集成
次要方法:指导评论(约20-30%的问题)
  • 针对主观或架构问题
  • 存在多种解决方案时
  • “考虑”级别的建议
罕见方法:修复提交(除非必要否则避免)
  • 仅当建议无法解决时使用
  • 跨多文件的复杂重构
  • 需要大量测试的变更

Decision Tree: When to Use Which Approach

决策树:选择哪种方法

ApproachWhen to UseExamples
GitHub Suggestions (PRIMARY)Any change that can be expressed as a code replacementRemove console.log, fix typos, add comments, refactor selectors, update functions, add error handling
Fix Commits (SECONDARY)Changes that need testing, span many files, or are too large for suggestionsComplex multi-file refactors, security fixes requiring validation, changes >20 lines
Guidance Only (FALLBACK)Architectural changes, subjective improvements, or when multiple approaches exist"Consider using IntersectionObserver", design pattern suggestions, performance optimizations
IMPORTANT: Always prefer GitHub Suggestions when possible - they provide the best user experience with one-click acceptance and proper git attribution.
方法使用场景示例
GitHub建议(首选)任何可通过代码替换实现的变更移除console.log、修复拼写错误、添加注释、重构选择器、更新函数、添加错误处理
修复提交(次要)需要测试、跨多文件或超出建议范围的变更复杂的多文件重构、需要验证的安全修复、超过20行的变更
仅指导(备选)架构决策、存在多种有效方案、主观改进“考虑使用IntersectionObserver”、设计模式建议、性能优化(有取舍)
重要提示: 尽可能优先使用GitHub建议 - 这能提供最佳的用户体验,支持一键修复且Git归属正确。

Approach 1: GitHub Inline Suggestions (PRIMARY APPROACH - Recommended)

方法1:GitHub行内建议(首选方法 - 推荐)

Use GitHub's native suggestion feature for most fixes. This provides the best user experience with one-click acceptance and proper git attribution.
When to use:
  • ✅ ANY change that can be expressed as a line replacement
  • ✅ Single-line to multi-line changes (up to ~20 lines works well)
  • ✅ Clear, actionable fixes with known solutions
  • ✅ Independent changes that can be applied separately
  • ✅ Changes that don't require extensive testing before commit
When NOT to use:
  • ❌ Changes requiring testing/validation before commit
  • ❌ Very large changes (>20 lines become unwieldy in GitHub UI)
  • ❌ Changes spanning many files (better as fix commits)
  • ❌ Subjective/architectural suggestions with multiple valid approaches
Benefits:
  • 🚀 One-click acceptance by PR author
  • ✅ Proper co-author attribution in git history
  • 🎯 Batch multiple suggestions into single commit
  • 📱 Works in GitHub mobile app
  • ⚡ Zero copy/paste errors
  • 🔍 Clear before/after diff in GitHub UI
How to create suggestions:
GitHub suggestions are created using the Pull Request Reviews API with a special markdown syntax in the comment body:
markdown
```suggestion
// The corrected code here
```
Complete workflow with examples:
bash
undefined
对大多数修复使用GitHub的原生建议功能。这提供了一键接受的最佳用户体验,且Git归属正确。
使用场景:
  • ✅ 任何可表示为代码替换的变更
  • ✅ 单行到多行变更(最多20行效果良好)
  • ✅ 明确、可操作的修复方案
  • ✅ 可独立应用的变更
  • ✅ 提交前无需大量测试的变更
不适用场景:
  • ❌ 提交前需要测试/验证的变更
  • ❌ 非常大的变更(超过20行在GitHub UI中难以处理)
  • ❌ 跨多文件的变更(更适合修复提交)
  • ❌ 存在多种有效方案的主观/架构建议
优势:
  • 🚀 PR作者可一键接受
  • ✅ Git历史中正确显示共同作者
  • 🎯 可将多个建议批量提交
  • 📱 支持GitHub移动应用
  • ⚡ 无复制粘贴错误
  • 🔍 GitHub UI中清晰显示变更前后对比
如何创建建议:
GitHub建议通过Pull Request Reviews API创建,在评论正文中使用特殊的markdown语法:
markdown
```suggestion
// 这里是修正后的代码
```
完整工作流示例:
bash
undefined

Step 1: Get PR information

步骤1:获取PR信息

PR_NUMBER=196 OWNER="adobe" REPO="helix-tools-website"
PR_NUMBER=196 OWNER="adobe" REPO="helix-tools-website"

Get the current HEAD commit SHA (required for review API)

获取当前HEAD提交SHA(评审API需要)

COMMIT_SHA=$(gh api repos/$OWNER/$REPO/pulls/$PR_NUMBER --jq '.head.sha')
COMMIT_SHA=$(gh api repos/$OWNER/$REPO/pulls/$PR_NUMBER --jq '.head.sha')

Step 2: Analyze the diff to find line positions

步骤2:分析差异以确定行位置

IMPORTANT: Use 'position' in the diff, NOT 'line' in the original file

重要提示:使用diff中的
position
,而非原文件中的
line

Position is the line number in the unified diff output starting from the first diff hunk

Position是从第一个diff块开始的统一diff输出中的行号

Get the diff to understand positions

获取diff以了解位置

gh pr diff $PR_NUMBER --repo $OWNER/$REPO > /tmp/pr-$PR_NUMBER.diff
gh pr diff $PR_NUMBER --repo $OWNER/$REPO > /tmp/pr-$PR_NUMBER.diff

Step 3: Create review JSON with suggestions

步骤3:创建包含建议的评审JSON

Each comment needs:

每个评论需要:

- path: file path relative to repo root

- path: 相对于仓库根目录的文件路径

- position: line number IN THE DIFF (not in the file!)

- position: diff中的行号(不是文件中的行号!)

- body: description + ```suggestion block

- body: 描述 + ```suggestion块

cat > /tmp/review-suggestions.json <<JSON { "commit_id": "$COMMIT_SHA", "event": "COMMENT", "comments": [ { "path": "tools/page-status/diff.js", "position": 58, "body": "Fix: Add XSS Safety Documentation (BLOCKING)\n\nAdd a comment to document that this HTML injection is safe:\n\n```suggestion\n const previewBodyHtml = previewDom.querySelector('body').innerHTML;\n\n // XSS Safe: previewBodyHtml is sanitized by mdToDocDom from trusted admin API\n const newPageHtml = \`\n```\n\nThis addresses the security concern by making it clear that XSS has been considered." }, { "path": "tools/page-status/diff.js", "position": 6, "body": "Fix: Improve Error Handling Pattern\n\nAdd an \`ok\` flag for more consistent error handling:\n\n```suggestion\n * @returns {Promise<{content: string|null, status: number, ok: boolean}>} Content, status, and success flag\n```" }, { "path": "tools/page-status/diff.js", "position": 12, "body": "Fix: Return consistent result object\n\n```suggestion\n return { content: null, status: res.status, ok: false };\n```" }, { "path": "tools/page-status/diff.js", "position": 16, "body": "Fix: Include ok flag in success case\n\n```suggestion\n return { content, status: res.status, ok: true };\n```" }, { "path": "tools/page-status/diff.css", "position": 41, "body": "Fix: Remove stylelint-disable by refactoring selector\n\nUse \`.diff-new-page\` as intermediate selector to avoid specificity conflict:\n\n```suggestion\n.page-diff .diff-new-page .doc-diff-side-header {\n padding: var(--spacing-s) var(--spacing-m);\n```" } ] } JSON
cat > /tmp/review-suggestions.json <<JSON { "commit_id": "$COMMIT_SHA", "event": "COMMENT", "comments": [ { "path": "tools/page-status/diff.js", "position": 58, "body": "修复:添加XSS安全文档(阻塞合并)\n\n添加注释说明此HTML注入是安全的:\n\n```suggestion\n const previewBodyHtml = previewDom.querySelector('body').innerHTML;\n\n // XSS安全:previewBodyHtml来自受信任的管理员API,已被mdToDocDom净化\n const newPageHtml = \`\n```\n\n通过明确说明已考虑XSS问题,解决安全顾虑。" }, { "path": "tools/page-status/diff.js", "position": 6, "body": "修复:改进错误处理模式\n\n添加\
ok\\
标志以实现更一致的错误处理:\n\n```suggestion\n * @returns {Promise<{content: string|null, status: number, ok: boolean}>} 内容、状态和成功标志\n```" }, { "path": "tools/page-status/diff.js", "position": 12, "body": "修复:返回一致的结果对象\n\n```suggestion\n return { content: null, status: res.status, ok: false };\n```" }, { "path": "tools/page-status/diff.js", "position": 16, "body": "修复:成功案例中包含ok标志\n\n```suggestion\n return { content, status: res.status, ok: true };\n```" }, { "path": "tools/page-status/diff.css", "position": 41, "body": "修复:通过重构选择器移除stylelint-disable\n\n使用\
.diff-new-page\\
作为中间选择器以避免特异性冲突:\n\n```suggestion\n.page-diff .diff-new-page .doc-diff-side-header {\n padding: var(--spacing-s) var(--spacing-m);\n```" } ] } JSON

Step 4: Submit the review with all suggestions at once

步骤4:一次性提交所有建议的评审

gh api
--method POST
-H "Accept: application/vnd.github+json"
repos/$OWNER/$REPO/pulls/$PR_NUMBER/reviews
--input /tmp/review-suggestions.json
gh api
--method POST
-H "Accept: application/vnd.github+json"
repos/$OWNER/$REPO/pulls/$PR_NUMBER/reviews
--input /tmp/review-suggestions.json

Step 5: Add a friendly summary comment

步骤5:添加友好的总结评论

gh pr comment $PR_NUMBER --repo $OWNER/$REPO --body "$(cat <<'EOF'
gh pr comment $PR_NUMBER --repo $OWNER/$REPO --body "$(cat <<'EOF'

✨ One-Click Fix Suggestions Added!

✨ 已添加一键修复建议!

I've added GitHub Suggestions that you can apply with a single click!
我已添加GitHub建议,你可一键应用:

How to Apply

应用方法

  1. Go to the Files changed tab
  2. Find the inline comments with suggestions
  3. Click "Commit suggestion" to apply individually
  4. Or click "Add suggestion to batch" on multiple, then "Commit suggestions" to batch
  1. 进入Files changed标签页
  2. 找到带建议的行内评论
  3. 点击**"Commit suggestion"单独应用,或点击"Add suggestion to batch"批量应用后点击"Commit suggestions"**

What's Included

包含的修复

  • ✅ [BLOCKING] XSS safety documentation
  • ✅ Error handling improvements
  • ✅ CSS selector refactoring (removes linter disables)
After applying, run `npm run lint` to verify all checks pass! EOF )"
echo "✅ Review with suggestions posted successfully!" echo "View at: https://github.com/$OWNER/$REPO/pull/$PR_NUMBER"

**Key points:**
- **Use `position` (diff position) NOT `line` (file line number)** - This is critical!
- The `position` is the line number in the unified diff output, counting from the first `@@` hunk marker
- Multiple suggestions in one review enables batch application
- Each suggestion creates a properly attributed co-authored commit when accepted
- Escape special characters in JSON (quotes, backticks, newlines)
- Always include context in the body before the suggestion block

**How to determine the correct `position` value:**

The `position` is the line number in the unified diff, NOT the line number in the file. Here's how to find it:

1. **Get the diff:**
   ```bash
   gh pr diff <PR-number> > pr.diff
  1. Open the diff and count lines from the top, including:
    • File headers (
      --- a/file
      and
      +++ b/file
      )
    • Hunk headers (
      @@ -old,lines +new,lines @@
      )
    • Context lines (no prefix or space prefix)
    • Removed lines (- prefix)
    • Added lines (+ prefix)
  2. The position is the line number of the ADDED line you want to comment on
Example from actual diff:
diff
--- a/tools/page-status/diff.js
+++ b/tools/page-status/diff.js
  async function fetchContent(url) {
    const res = await fetch(url);
-   if (!res.ok) throw new Error(`Failed to fetch ${url}: ${res.status}`);
-   return res.text();
+   if (!res.ok) {
+     return { content: null, status: res.status };  ← Position 12 (counting from top)
+   }
Best practices for suggestions:
  • Keep suggestions focused and atomic (one fix per suggestion)
  • Always include context - explain WHY the change is needed before the suggestion block
  • Test the suggestion mentally or locally before posting
  • Only suggest changes you're confident are correct
  • Include surrounding lines for context (GitHub shows ~3 lines of context)
  • Use
    position
    in the diff, not
    line
    in the file (critical!)
  • Batch related suggestions in one review for easier application
  • Add a friendly summary comment explaining how to apply
  • Format suggestion body with markdown (bold headers, inline code)
  • Escape special characters properly in JSON (quotes, backticks, backslashes)
  • ✅ [阻塞合并] XSS安全文档
  • ✅ 错误处理改进
  • ✅ CSS选择器重构(移除linter禁用)
应用后运行`npm run lint`验证所有检查通过! EOF )"
echo "✅ 带建议的评审已成功发布!" echo "查看地址:https://github.com/$OWNER/$REPO/pull/$PR_NUMBER"

**关键点:**
- **使用`position`(diff中的行号)而非`line`(文件中的行号)** - 这非常关键!
- `position`是统一diff输出中的行号,从第一个`@@`块标记开始计数
- 一次评审中包含多个建议支持批量应用
- 每个建议被接受时会创建正确归属的共同作者提交
- JSON中要转义特殊字符(引号、反引号、换行符)
- 建议块前始终要包含上下文说明

**如何确定正确的`position`值:**

`position`是统一diff中的行号,而非文件中的行号。以下是查找方法:

1. **获取diff:**
   ```bash
   gh pr diff <PR-number> > pr.diff
  1. 打开diff并从顶部开始计数行,包括:
    • 文件头(
      --- a/file
      +++ b/file
    • 块头(
      @@ -old,lines +new,lines @@
    • 上下文行(无前缀或空格前缀)
    • 删除的行(-前缀)
    • 添加的行(+前缀)
  2. position是你要评论的新增行的行号
实际diff示例:
diff
--- a/tools/page-status/diff.js
+++ b/tools/page-status/diff.js
  async function fetchContent(url) {
    const res = await fetch(url);
-   if (!res.ok) throw new Error(`Failed to fetch ${url}: ${res.status}`);
-   return res.text();
+   if (!res.ok) {
+     return { content: null, status: res.status };  ← Position 12(从顶部开始计数)
+   }
建议的最佳实践:
  • 建议要聚焦且原子化(每个建议修复一个问题)
  • 始终包含上下文 - 建议块前解释为什么需要变更
  • 发布前在本地或在脑中验证建议的正确性
  • 只建议你确信正确的变更
  • 包含上下文行(GitHub会显示约3行上下文)
  • 使用diff中的
    position
    ,而非文件中的
    line
    (关键!)
  • 相关建议批量提交到一个评审中,方便批量应用
  • 建议正文使用markdown格式(加粗标题、行内代码)
  • JSON中正确转义特殊字符(引号、反引号、反斜杠)

Approach 2: Fix Commits (For Complex or Multi-File Fixes)

方法2:修复提交(针对复杂或多文件修复)

For more complex fixes, create commits directly on the PR branch. This is especially useful when:
  • Fixes span multiple files
  • Changes need to be tested together
  • Refactoring is required
  • You want to demonstrate the fix working
Prerequisites:
  • Ensure you have write access to the repository or the PR is from a fork you can access
  • Verify the PR author has enabled maintainer edits (usually default for same-org PRs)
Workflow:
bash
undefined
对于更复杂的修复,直接在PR分支上创建提交。这在以下场景特别有用:
  • 修复跨多文件
  • 变更需要一起测试
  • 需要重构
  • 你想演示修复后的效果
前提条件:
  • 确保你有仓库的写入权限,或PR来自你可访问的分支
  • 确认PR作者已启用维护者编辑权限(同组织PR通常默认启用)
工作流:
bash
undefined

1. Get PR branch information

1. 获取PR分支信息

PR_INFO=$(gh pr view <PR-number> --json headRefName,headRepository,headRepositoryOwner) BRANCH=$(echo $PR_INFO | jq -r '.headRefName') REPO_OWNER=$(echo $PR_INFO | jq -r '.headRepositoryOwner.login')
PR_INFO=$(gh pr view <PR-number> --json headRefName,headRepository,headRepositoryOwner) BRANCH=$(echo $PR_INFO | jq -r '.headRefName') REPO_OWNER=$(echo $PR_INFO | jq -r '.headRepositoryOwner.login')

2. Fetch the PR branch

2. 拉取PR分支

git fetch origin pull/<PR-number>/head:pr-<PR-number>
git fetch origin pull/<PR-number>/head:pr-<PR-number>

3. Check out the PR branch

3. 切换到PR分支

git checkout pr-<PR-number>
git checkout pr-<PR-number>

4. Make fixes based on review findings

4. 根据评审发现进行修复

Example: Fix CSS linter issues by refactoring selectors

示例:通过重构选择器修复CSS linter问题

5. Test your fixes

5. 测试你的修复

npm run lint
npm run lint

Run any relevant tests

运行相关测试

6. Commit with detailed reasoning

6. 提交并附上详细说明

git commit -m "$(cat <<'EOF' fix: refactor CSS selectors to eliminate linter disables
Refactored CSS selectors in diff.css to resolve specificity conflicts without using stylelint-disable comments. Changes:
  • Increased specificity using .diff-new-page parent selector
  • Reordered rules to prevent descending specificity issues
  • Maintains same visual appearance and functionality
Addresses code review feedback: https://github.com/{owner}/{repo}/pull/<PR-number>#issuecomment-XXXXX EOF )"
git commit -m "$(cat <<'EOF' fix: 重构CSS选择器以消除linter禁用
重构diff.css中的CSS选择器,无需使用stylelint-disable注释即可解决特异性冲突。变更:
  • 使用.diff-new-page父选择器提高特异性
  • 重新排序规则以避免降序特异性问题
  • 保持视觉效果和功能不变
对应评审反馈:https://github.com/{owner}/{repo}/pull/<PR-number>#issuecomment-XXXXX EOF )"

7. Push to the PR branch

7. 推送到PR分支

git push origin pr-<PR-number>:$BRANCH
git push origin pr-<PR-number>:$BRANCH

8. Add comment to PR explaining what you fixed

8. 在PR中添加评论说明修复内容

gh pr comment <PR-number> --body "$(cat <<'EOF'
gh pr comment <PR-number> --body "$(cat <<'EOF'

Fixes Applied

已应用修复

I've pushed commits to address some of the review findings:
我已推送提交解决部分评审发现的问题:

Commit 1: Refactor CSS selectors

提交1:重构CSS选择器

  • ✅ Eliminated all
    stylelint-disable
    comments
  • ✅ Resolved specificity conflicts properly
  • ✅ Maintained visual appearance
  • ✅ 移除所有
    stylelint-disable
    注释
  • ✅ 正确解决特异性冲突
  • ✅ 保持视觉效果不变

Commit 2: Standardize error handling

提交2:标准化错误处理

  • ✅ Updated fetchContent to return consistent result objects
  • ✅ Updated all callers to use new pattern
  • ✅ Added JSDoc for clarity
  • ✅ 更新fetchContent以返回一致的结果对象
  • ✅ 更新所有调用者使用新模式
  • ✅ 添加JSDoc说明

Still Need Action From You:

仍需你处理的事项:

  • [BLOCKING] Add XSS safety comment (see suggestion in review)
  • Consider extracting renderDiffPanel helper (optional)
All linting passes now. Please review the commits and address the remaining item. EOF )"

**Commit message format for fixes:**
fix: <short description>
<Detailed explanation of what was fixed and why>
Changes:
  • <specific change 1>
  • <specific change 2>
Addresses review feedback: <link to review comment>
undefined
  • [阻塞合并] 添加XSS安全注释(查看评审中的建议)
  • 考虑提取renderDiffPanel辅助函数(可选)
现在所有linting检查已通过。请评审提交内容并处理剩余事项。 EOF )"

**修复提交的消息格式:**
fix: <简短描述>
<详细说明修复内容和原因>
变更:
  • <具体变更1>
  • <具体变更2>
对应评审反馈:<评审评论链接>
undefined

Approach 3: Hybrid Approach (RECOMMENDED FOR MOST PRs)

方法3:混合方法(大多数PR推荐使用)

For the majority of PRs, use this hybrid strategy:
  1. GitHub suggestions for all fixable issues (primary method)
  2. Guidance/comments for subjective or architectural issues
  3. Fix commits only for very complex multi-file refactors
Typical workflow:
bash
undefined
对于大多数PR,使用以下混合策略:
  1. GitHub建议处理所有可修复问题(主要方法)
  2. 指导/评论处理主观或架构问题
  3. 修复提交仅用于非常复杂的多文件重构
典型工作流:
bash
undefined

1. Post comprehensive review comment with summary (from Step 8)

1. 发布包含总结的详细评审评论(来自步骤8)

gh pr comment <PR-number> --repo {owner}/{repo} --body "<detailed review summary>"
gh pr comment <PR-number> --repo {owner}/{repo} --body "<详细评审总结>"

2. Submit a review with GitHub suggestions for ALL fixable issues

2. 提交包含所有可修复问题的GitHub建议

(Create JSON as shown in Approach 1 with all suggestions)

(如方法1所示创建JSON包含所有建议)

gh api POST repos/{owner}/{repo}/pulls/<PR-number>/reviews
--input /tmp/review-suggestions.json
gh api POST repos/{owner}/{repo}/pulls/<PR-number>/reviews
--input /tmp/review-suggestions.json

3. Add a friendly summary about the suggestions

3. 添加关于建议的友好总结

gh pr comment <PR-number> --repo {owner}/{repo} --body "$(cat <<'EOF'
gh pr comment <PR-number> --repo {owner}/{repo} --body "$(cat <<'EOF'

✨ One-Click Suggestions Added!

✨ 已添加一键建议!

I've added GitHub Suggestions for the fixable issues:
  • ✅ [BLOCKING] Security documentation
  • ✅ Error handling improvements
  • ✅ CSS selector refactoring
Go to Files changed tab and click "Commit suggestion" to apply! EOF )"
我已为可修复问题添加GitHub建议:
  • ✅ [阻塞合并] 安全文档
  • ✅ 错误处理改进
  • ✅ CSS选择器重构
前往Files changed标签页,点击**"Commit suggestion"**应用! EOF )"

4. For subjective/architectural issues, add guidance comments separately

4. 对于主观/架构问题,单独添加指导评论

(Only if needed - most issues should have suggestions)

(仅在需要时 - 大多数问题应使用建议)


**Real-world example distribution:**

For a typical PR with 10 issues:
- **GitHub suggestions**: 7-8 issues (concrete fixes)
- **Guidance comments**: 2-3 issues (architectural, subjective, or "consider" level)
- **Fix commits**: 0-1 (only if critically needed)

**This approach provides:**
- ✅ Maximum ease of use (one-click fixes)
- ✅ Clear distinction between concrete fixes and suggestions
- ✅ Reduced review cycles
- ✅ Better PR author experience

**实际案例分布:**

对于一个包含10个问题的典型PR:
- **GitHub建议**:7-8个问题(具体修复)
- **指导评论**:2-3个问题(架构、主观或“考虑”级别)
- **修复提交**:0-1个(仅在必要时)

**此方法的优势:**
- ✅ 使用最便捷(一键修复)
- ✅ 明确区分具体修复和建议
- ✅ 减少评审周期
- ✅ 提升PR作者体验

Real-World Example

实际案例

PR #196: Support unpublished pages in diff tool
Issues identified in review:
  1. XSS safety documentation needed (BLOCKING)
  2. Four CSS stylelint-disable comments (should fix)
  3. Inconsistent error handling (should fix)
  4. CSS variable fallback inconsistency (optional)
Action taken:
bash
undefined
PR #196:差异工具支持未发布页面
评审中发现的问题:
  1. 需要XSS安全文档(阻塞合并)
  2. 4个CSS stylelint-disable注释(应该修复)
  3. 错误处理不一致(应该修复)
  4. CSS变量回退不一致(可选)
采取的行动:
bash
undefined

Created two reviews with 9 total GitHub Suggestions

创建两个评审,共包含9个GitHub建议

- 4 suggestions for diff.js (XSS comment, error handling)

- 4个针对diff.js的建议(XSS注释、错误处理)

- 5 suggestions for diff.css (selector refactoring)

- 5个针对diff.css的建议(选择器重构)

Posted friendly summary comment explaining one-click application

发布友好的总结评论说明一键应用方法

Result: PR author can fix all issues in ~30 seconds vs 5-10 minutes of manual work

结果:PR作者可在约30秒内修复所有问题,而手动修复需要5-10分钟


**View the actual implementation:**
- JavaScript suggestions: https://github.com/adobe/helix-tools-website/pull/196#pullrequestreview-3747855930
- CSS suggestions: https://github.com/adobe/helix-tools-website/pull/196#pullrequestreview-3747857266
- Summary comment: https://github.com/adobe/helix-tools-website/pull/196#issuecomment-3843945119

**Time saved:**
- Traditional review: Author spends 5-10 minutes copying code, editing files, testing
- With suggestions: Author spends 30 seconds clicking "Commit suggestions"
- **Time savings: 90%+ reduction in fix application time**

**查看实际实现:**
- JavaScript建议:https://github.com/adobe/helix-tools-website/pull/196#pullrequestreview-3747855930
- CSS建议:https://github.com/adobe/helix-tools-website/pull/196#pullrequestreview-3747857266
- 总结评论:https://github.com/adobe/helix-tools-website/pull/196#issuecomment-3843945119

**节省的时间:**
- 传统评审:作者需要5-10分钟复制代码、编辑文件、测试
- 使用建议:作者只需30秒点击“Commit suggestions”
- **时间节省:90%+的修复应用时间**

Guidelines for Choosing Approach

方法选择指南

Use GitHub Suggestions when: (DEFAULT - use this ~70-80% of the time)
  • ✅ You know the exact fix needed
  • ✅ Change is < 20 lines (works well in GitHub UI)
  • ✅ Fix is objective and unambiguous
  • ✅ Can be applied without extensive testing
  • ✅ Independent of other changes
  • Examples: Add comments, remove debug code, fix typos, refactor selectors, update error handling, add JSDoc, fix linting issues
Use Fix Commits when: (RARE - use only when suggestions won't work)
  • ✅ Changes span many files (>5 files)
  • ✅ Complex refactoring requiring testing
  • ✅ Changes are interdependent and must be tested together
  • ✅ Security fixes that need immediate attention and validation
  • ✅ You're already working on the PR branch for other reasons
  • Examples: Large refactors, multi-file renames, complex security patches
Use Guidance Only when: (~20-30% of issues)
  • ✅ Architectural decisions needed
  • ✅ Multiple valid approaches exist
  • ✅ Requires domain knowledge or context from PR author
  • ✅ Subjective improvements ("Consider", "Think about")
  • ✅ Performance optimizations with trade-offs
  • Examples: "Consider using IntersectionObserver", "You might want to extract this to a util", "Have you thought about caching?"
Decision flowchart:
Issue identified
Do I know the exact fix? ──NO──→ Use Guidance
    ↓ YES
Is it < 20 lines? ──NO──→ Use Fix Commit or Guidance
    ↓ YES
Use GitHub Suggestion ✅ (BEST OPTION)
使用GitHub建议的场景:(默认 - 约70-80%的情况)
  • ✅ 你知道确切的修复方案
  • ✅ 变更少于20行(在GitHub UI中效果良好)
  • ✅ 修复客观且明确
  • ✅ 无需大量测试即可应用
  • ✅ 独立于其他变更
  • 示例: 添加注释、移除调试代码、修复拼写错误、重构选择器、更新函数、添加错误处理
使用修复提交的场景:(罕见 - 仅当建议无法解决时)
  • ✅ 变更跨多文件(超过5个文件)
  • ✅ 需要测试的复杂重构
  • ✅ 变更相互依赖,必须一起测试
  • ✅ 需要立即关注和验证的安全修复
  • ✅ 你已在PR分支上处理其他内容
  • 示例: 大型重构、多文件重命名、复杂安全补丁
仅使用指导的场景:(约20-30%的情况)
  • ✅ 需要架构决策
  • ✅ 存在多种有效方案
  • ✅ 需要PR作者提供领域知识或上下文
  • ✅ 主观改进(“考虑”、“可考虑”)
  • ✅ 有取舍的性能优化
  • 示例: “考虑使用IntersectionObserver”、“你可将此提取到工具函数”、“你考虑过缓存吗?”
决策流程图:
发现问题
是否知道确切修复方案? ──否──→ 使用指导
    ↓ 是
变更是否少于20行? ──否──→ 使用修复提交或指导
    ↓ 是
使用GitHub建议 ✅(最佳选择)

Quality Standards for Fixes

修复的质量标准

Before posting suggestions or commits:
  1. Verify correctness: Test locally or mentally verify the fix is correct
  2. Check scope: Ensure your fix doesn't introduce new issues
  3. Maintain style: Match existing code style and patterns
  4. Run linters: Ensure fixes don't break linting
  5. Be respectful: Frame fixes as helpful suggestions, not criticism
  6. Link context: Reference the review comment explaining WHY
Don't:
  • Don't fix issues outside the PR scope
  • Don't change code style unrelated to the issue
  • Don't add features or enhancements
  • Don't push commits without explaining what you fixed
  • Don't fix subjective issues without discussion
发布建议或提交前:
  1. 验证正确性: 本地测试或在脑中验证修复正确
  2. 检查范围: 确保你的修复不会引入新问题
  3. 保持风格: 匹配现有代码风格和模式
  4. 运行检查: 确保修复不会打破linting
  5. 保持尊重: 将修复表述为有用的建议,而非批评
  6. 关联上下文: 引用解释原因的评审评论
禁止事项:
  • 不要修复PR范围外的问题
  • 不要修改与问题无关的代码风格
  • 不要添加功能或增强
  • 不要推送提交却不说明修复内容
  • 不要未经讨论修复主观问题

Troubleshooting GitHub Suggestions

GitHub建议故障排除

Common issues and solutions:
ProblemCauseSolution
"Validation Failed: line could not be resolved"Used
line
instead of
position
Use
position
(diff line number) not
line
(file line number)
Suggestion doesn't appear inlineWrong position valueCount lines in the diff carefully, including headers
Can't apply suggestionMerge conflict or branch updatedAuthor needs to update branch first
Suggestion formatting brokenUnescaped JSON charactersEscape quotes, backticks, newlines in JSON
"Invalid commit_id"Used old commit SHAGet current HEAD SHA before creating review
How to verify your review before posting:
bash
undefined
常见问题及解决方案:
问题原因解决方案
"Validation Failed: line could not be resolved"使用了
line
而非
position
使用
position
(diff中的行号)而非
line
(文件中的行号)
建议未在行内显示position值错误仔细计数diff中的行,包括文件头
无法应用建议存在合并冲突或分支已更新作者需先更新分支
建议格式损坏JSON字符未转义JSON中转义引号、反引号、换行符
"Invalid commit_id"使用了旧的提交SHA创建评审前获取当前HEAD SHA
发布前验证评审:
bash
undefined

1. Validate JSON syntax

1. 验证JSON语法

cat /tmp/review-suggestions.json | jq . > /dev/null && echo "✅ Valid JSON"
cat /tmp/review-suggestions.json | jq . > /dev/null && echo "✅ JSON格式正确"

2. Check position values against diff

2. 检查position值与diff是否匹配

gh pr diff <PR-number> > pr.diff
gh pr diff <PR-number> > pr.diff

Manually verify each position value in your JSON matches an added line

手动验证JSON中的每个position值是否对应新增行

3. Test with one suggestion first

3. 先测试一个建议

Before posting 10 suggestions, test with 1 to ensure positions are correct

发布10个建议前,先测试1个确保position正确

undefined
undefined

Success Criteria

成功标准

A good fix provision should:
  • Use GitHub Suggestions as the primary method (for ~70-80% of fixable issues)
  • Make it easy for the author to address issues (one-click accept)
  • Provide working, tested code (not untested suggestions)
  • Explain the reasoning behind each fix in the comment body
  • Reference the original review feedback from Step 8
  • Be respectful and collaborative in tone
  • Focus only on issues identified in the review
  • Not introduce new issues or regressions
  • Include a friendly summary comment explaining how to apply suggestions
  • Use proper
    position
    values (diff lines, not file lines)
  • Batch related suggestions in one review for efficient application

好的修复方案应满足:
  • 优先使用GitHub建议(约70-80%的可修复问题)
  • 让作者轻松解决问题(一键接受)
  • 提供可运行、已测试的代码(而非未经测试的建议)
  • 评论正文中解释每个修复的理由
  • 引用步骤8中的原始评审反馈
  • 语气尊重且协作
  • 仅聚焦评审中发现的问题
  • 不引入新问题或回归
  • 包含友好总结评论说明如何应用建议
  • 使用正确的
    position
    值(diff行号,而非文件行号)
  • 相关建议批量提交到一个评审中以提高应用效率

Quick Start Template

快速开始模板

Copy this template to quickly create a review with GitHub Suggestions:
bash
#!/bin/bash
复制此模板快速创建带GitHub建议的评审:
bash
#!/bin/bash

Quick script to create GitHub Suggestions for PR review

用于PR评审的GitHub建议快速创建脚本

PR_NUMBER=YOUR_PR_NUMBER OWNER="adobe" REPO="helix-tools-website"
PR_NUMBER=YOUR_PR_NUMBER OWNER="adobe" REPO="helix-tools-website"

Get commit SHA

获取提交SHA

COMMIT_SHA=$(gh api repos/$OWNER/$REPO/pulls/$PR_NUMBER --jq '.head.sha') echo "✅ PR Head SHA: $COMMIT_SHA"
COMMIT_SHA=$(gh api repos/$OWNER/$REPO/pulls/$PR_NUMBER --jq '.head.sha') echo "✅ PR HEAD SHA: $COMMIT_SHA"

Create review JSON

创建评审JSON

cat > /tmp/review-$PR_NUMBER.json <<JSON { "commit_id": "$COMMIT_SHA", "event": "COMMENT", "comments": [ { "path": "path/to/file.js", "position": DIFF_LINE_NUMBER, "body": "Fix: Issue Title\n\nExplanation of the issue.\n\n```suggestion\nYour fixed code here\n```\n\nReasoning for the fix." } ] } JSON
cat > /tmp/review-$PR_NUMBER.json <<JSON { "commit_id": "$COMMIT_SHA", "event": "COMMENT", "comments": [ { "path": "path/to/file.js", "position": DIFF_LINE_NUMBER, "body": "Fix: 问题标题\n\n问题说明。\n\n```suggestion\n你的修复代码\n```\n\n修复理由。" } ] } JSON

Submit review

提交评审

gh api POST repos/$OWNER/$REPO/pulls/$PR_NUMBER/reviews
--input /tmp/review-$PR_NUMBER.json
gh api POST repos/$OWNER/$REPO/pulls/$PR_NUMBER/reviews
--input /tmp/review-$PR_NUMBER.json

Add summary comment

添加总结评论

gh pr comment $PR_NUMBER --repo $OWNER/$REPO --body "✨ GitHub Suggestions added! Go to Files changed tab and click Commit suggestion to apply."
echo "✅ Review posted! View at: https://github.com/$OWNER/$REPO/pull/$PR_NUMBER"

**To use:**
1. Set `PR_NUMBER`, `OWNER`, `REPO`
2. Replace the comments array with your actual suggestions
3. Run the script

---
gh pr comment $PR_NUMBER --repo $OWNER/$REPO --body "✨ GitHub建议已添加!前往Files changed标签页,点击Commit suggestion应用。"
echo "✅ 评审已发布!查看地址:https://github.com/$OWNER/$REPO/pull/$PR_NUMBER"

**使用方法:**
1. 设置`PR_NUMBER`、`OWNER`、`REPO`
2. 用实际建议替换comments数组
3. 运行脚本

---

Review Priority Levels

评审优先级

Must Fix (Blocking)

必须修复(阻塞合并)

Issues that MUST be resolved before merge:
  • Missing preview URLs
  • Linting failures
  • Security vulnerabilities
  • Breaking existing functionality
  • Performance regressions (Lighthouse score drop)
  • Accessibility violations
  • Modifications to
    aem.js
合并前必须解决的问题:
  • 缺少预览URL
  • Linting失败
  • 安全漏洞
  • 破坏现有功能
  • 性能回归(Lighthouse评分下降)
  • 可访问性违规
  • 修改
    aem.js

Should Fix (High Priority)

应该修复(高优先级)

Issues that SHOULD be resolved:
  • !important
    usage without justification
  • Unscoped CSS selectors
  • Hardcoded values that should be configurable
  • Missing error handling
  • Console statements left in code
  • CSS in JavaScript
应该解决的问题:
  • 无理由使用
    !important
  • 未限定作用域的CSS选择器
  • 硬编码可配置的值
  • 缺少错误处理
  • 代码中遗留控制台语句
  • JavaScript中写CSS

Consider (Suggestions)

建议(可选项)

Improvements to consider:
  • Code organization
  • Naming conventions
  • Documentation
  • Additional test coverage
  • Modern API usage opportunities

可考虑的改进:
  • 代码组织
  • 命名规范
  • 文档
  • 额外测试覆盖
  • 使用现代API的机会

Common Review Patterns

常见评审模式

Based on actual PR reviews, watch for these patterns:
基于实际PR评审,注意以下模式:

CSS Issues

CSS问题

  • "No CSS in JS, please" - Inline styles should use CSS classes
  • "Use proper CSS" - Avoid style manipulation in JavaScript
  • "Do we need the
    !important
    ?"
    - Strong preference against
    !important
  • "Solvable with more CSS specificity" - Increase specificity instead of
    !important
  • "请不要在JS中写CSS" - 内联样式应使用CSS类
  • "使用标准CSS" - 避免在JavaScript中操作样式
  • "我们需要
    !important
    吗?"
    - 强烈反对使用
    !important
  • "可通过提高CSS特异性解决" - 提高特异性而非使用
    !important

JavaScript Issues

JavaScript问题

  • "Why is it hardcoded here?" - Configuration should be externalized
  • "No global eslint-disable directives" - Specific, justified disables only
  • "Clean up console messages" - Remove debug logging
  • "Use proper feature (e.g., decorateIcons, loadScript)" - Leverage existing utilities
  • "为什么在这里硬编码?" - 配置应外部化
  • "不要全局禁用ESLint" - 仅允许特定、有理由的禁用
  • "清理控制台消息" - 移除调试日志
  • "使用适当的特性(如decorateIcons、loadScript)" - 利用现有工具函数

Architecture Issues

架构问题

  • "Use existing patterns" - Check if similar functionality exists
  • "Consider IntersectionObserver" - For lazy loading
  • "Extract and align design tokens" - Use CSS custom properties
  • "使用现有模式" - 检查是否存在类似功能
  • "考虑使用IntersectionObserver" - 用于懒加载
  • "提取并对齐设计令牌" - 使用CSS自定义属性

Content Issues

内容问题

  • "Check the type in content config" - Validate against expected schema
  • "Is this feature needed?" - Question value vs complexity

  • "检查内容配置中的类型" - 验证是否符合预期 schema
  • "这个功能是必须的吗?" - 权衡价值与复杂度

Review Response Templates

评审回复模板

Approval

批准

markdown
undefined
markdown
undefined

Approved

已批准

Preview URLs verified and changes look good.
预览URL已验证,变更符合要求。

Visual Preview

视觉预览

Desktop Screenshot
<details> <summary>Mobile View</summary>
Mobile Screenshot
</details>
Verified:
  • Code quality and linting
  • Performance (Lighthouse scores)
  • Visual appearance (screenshots captured)
  • Responsive behavior
  • Accessibility basics
[Any additional notes]
undefined
Desktop Screenshot
<details> <summary>移动端视图</summary>
Mobile Screenshot
</details>
已验证:
  • 代码质量和linting
  • 性能(Lighthouse评分)
  • 视觉效果(已截图)
  • 响应式行为
  • 基础可访问性
[其他说明]
undefined

Request Changes

请求变更

markdown
undefined
markdown
undefined

Changes Requested

请求变更

Blocking Issues

阻塞问题

[List with file:line references]
[带文件:行号引用的列表]

Suggestions

建议

[List of recommendations]
Please address the blocking issues before merge.
undefined
[建议列表]
请解决阻塞问题后再合并。
undefined

Comment

评论

markdown
undefined
markdown
undefined

Review Notes

评审说明

[Non-blocking observations and questions]

---
[非阻塞的观察和问题]

---

Integration with GitHub Workflow

与GitHub工作流集成

When triggered via GitHub Actions, the skill should:
  1. Receive: PR number, repository info, event context
  2. Execute: Full review workflow above
  3. Output:
    • Review comment on the PR
    • Appropriate review status (approve/request-changes/comment)
    • Summary posted as PR comment
GitHub Actions integration points:
  • pull_request
    event triggers
  • gh pr review
    for posting reviews
  • gh pr comment
    for detailed feedback

通过GitHub Actions触发时,该技能应:
  1. 接收: PR编号、仓库信息、事件上下文
  2. 执行: 上述完整评审工作流
  3. 输出:
    • PR上的评审评论
    • 适当的评审状态(批准/请求变更/评论)
    • 作为PR评论发布的总结
GitHub Actions集成点:
  • pull_request
    事件触发
  • gh pr review
    用于发布评审
  • gh pr comment
    用于详细反馈

Resources

资源

EDS-Specific Resources

EDS特定资源

GitHub Code Review Resources

GitHub代码评审资源

Success Criteria

成功标准

For Self-Review Mode

自我评审模式

A complete self-review should:
  • Review all modified/new files
  • Check code against all quality criteria
  • Run linting and fix issues
  • Capture visual screenshots of test content
  • Verify responsive behavior across viewports
  • Identify issues to fix before committing
  • Confirm code is ready for commit and PR
完整的自我评审应:
  • 评审所有已修改/新增的文件
  • 根据所有质量标准检查代码
  • 运行linting并修复问题
  • 捕获测试内容的视觉截图
  • 验证跨视口的响应式行为
  • 识别提交前需要修复的问题
  • 确认代码已准备好提交和发起PR

For PR Review Mode

PR评审模式

A complete PR review should:
  • Validate all PR structure requirements (preview URLs, description)
  • Check code against all quality criteria
  • Verify performance requirements
  • Capture and include visual screenshots
  • Assess visual appearance for regressions
  • Assess content/authoring impact
  • Identify security concerns
  • Provide actionable feedback with specific references
  • Include screenshots in PR review comment
  • Provide GitHub Suggestions for all fixable issues (primary method - ~70-80% of issues)
  • Submit suggestions as a single review for batch application
  • Include a friendly summary comment explaining how to apply suggestions
  • Explain reasoning for each fix in the suggestion comment body
  • Use guidance comments only for subjective/architectural issues
  • Use fix commits only when suggestions won't work (rare)
  • Use appropriate review status (approve/request-changes/comment)

完整的PR评审应:
  • 验证所有PR结构要求(预览URL、描述)
  • 根据所有质量标准检查代码
  • 验证性能要求
  • 捕获并包含视觉截图
  • 评估视觉效果是否存在回归
  • 评估对内容/创作的影响
  • 识别安全顾虑
  • 提供带具体引用的可操作反馈
  • 在PR评审评论中包含截图
  • 为所有可修复问题提供GitHub建议(主要方法 - 约70-80%的问题)
  • 将建议作为单个评审提交以支持批量应用
  • 包含友好的总结评论说明如何应用建议
  • 在建议评论正文中解释每个修复的理由
  • 仅对主观/架构问题使用指导评论
  • 仅在建议无法解决时使用修复提交(罕见)
  • 使用适当的评审状态(批准/请求变更/评论)

Integration with Content-Driven Development

与内容驱动开发集成

This skill integrates with the content-driven-development workflow:
CDD Workflow:
Step 1: Start dev server
Step 2: Analyze & plan
Step 3: Design content model
Step 4: Identify/create test content
Step 5: Implement (building-blocks skill)
    └── testing-blocks skill (browser testing)
        └── **code-review skill (self-review)** ← Invoke here
Step 6: Lint & test
Step 7: Final validation
Step 8: Ship it (commit & PR)
Recommended invocation point: After implementation and testing-blocks skill complete, before final linting and committing.
What this catches before PR:
  • Code quality issues
  • EDS pattern violations
  • Security concerns
  • Performance problems
  • Visual regressions
Benefits of self-review:
  • Catch issues early (cheaper to fix)
  • Cleaner PRs with fewer review cycles
  • Learn from immediate feedback
  • Consistent code quality
该技能与内容驱动开发工作流集成:
CDD工作流:
步骤1:启动开发服务器
步骤2:分析与规划
步骤3:设计内容模型
步骤4:识别/创建测试内容
步骤5:实现(building-blocks技能)
    └── testing-blocks技能(浏览器测试)
        └── **code-review技能(自我评审)** ← 在此处调用
步骤6:Lint与测试
步骤7:最终验证
步骤8:交付(提交与PR)
推荐调用时机: 实现和testing-blocks技能完成后,最终linting和提交前。
PR前可捕获的问题:
  • 代码质量问题
  • EDS模式违规
  • 安全顾虑
  • 性能问题
  • 视觉回归
自我评审的优势:
  • 早期发现问题(修复成本更低)
  • PR更简洁,评审周期更少
  • 从即时反馈中学习
  • 代码质量一致