code-review
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChineseCode 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 and
git addgit 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: (reviews uncommitted changes in working directory)
/code-review
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: or
/code-review <PR-number>/code-review <PR-URL> - Automated: Via GitHub workflow on event
pull_request
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
undefinedSee 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):**
```bashgit diff --staged
**明确评审范围:**
- 修改了哪些文件?
- 这属于哪种类型的变更?(新增模块、bug修复、功能开发、样式调整、重构)
- 测试内容的URL是什么?(来自CDD工作流)
**PR评审模式(提供PR编号):**
```bashGet 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):
| Element | Requirement | Check |
|---|---|---|
| Preview URLs | Before/After URLs showing the change | Required |
| Description | Clear explanation of what changed and why | Required |
| Scope alignment | Changes match PR title and description | Required |
| Issue reference | Link 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 comments without justification
eslint-disable - No global directives
eslint-disable - ES6+ features used appropriately
- extensions included in imports
.js
Architecture:
- No frameworks in critical rendering path (LCP/TBT impact)
- Third-party libraries loaded via in blocks, not
loadScript()head.html - Consider for heavy libraries
IntersectionObserver - is NOT modified (submit upstream PRs for improvements)
aem.js - 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 - 不得修改(如需改进请提交上游PR)
aem.js - 未经团队共识不得引入构建步骤
代码模式:
- 复用现有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 unless absolutely necessary (with justification)
!important - Property order maintained (don't reorder in functional PRs)
Scoping & Selectors:
- All selectors scoped to block: or
.{block-name} .selectormain .{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(all1200px)min-width - No mixing of and
min-widthqueriesmax-width - 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} .selectormain .{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 (performance impact)
<head>
- 合理使用语义化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 or delayed loading
IntersectionObserver - 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:
- Navigate to the After preview URL
- Take screenshots at different viewport sizes
- Optionally take element-specific screenshots of changed blocks
Option 3: Manual capture with guidance
Instruct the reviewer or PR author to:
- Open the After preview URL
- Use browser DevTools to set viewport sizes
- 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工具:
- 打开变更后的预览URL
- 不同视口尺寸下截图
- 可选:对变更的块进行元素特定截图
选项3:手动捕获(带指导)
指导评审者或PR作者:
- 打开变更后的预览URL
- 使用浏览器开发者工具设置视口尺寸
- 截图并附加到PR
上传截图到GitHub:
bash
undefinedUpload 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)
Mobile (375px)
移动端(375px)
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
undefinedCode Review Summary
代码评审总结
Files Reviewed
已评审文件
- (new)
blocks/my-block/my-block.js - (new)
blocks/my-block/my-block.css
- (新增)
blocks/my-block/my-block.js - (新增)
blocks/my-block/my-block.css
Visual Validation
视觉验证

✅ Layout renders correctly across viewports
✅ No console errors
✅ Responsive behavior verified

✅ 布局在各视口下渲染正常
✅ 无控制台错误
✅ 响应式行为已验证
Issues Found
发现的问题
Must Fix Before Committing
提交前必须修复
- - Remove console.log debug statement
blocks/my-block/my-block.js:45 - - Selector
blocks/my-block/my-block.css:12needs block scoping.title
- - 移除console.log调试语句
blocks/my-block/my-block.js:45 - - 选择器
blocks/my-block/my-block.css:12需要限定块作用域.title
Recommendations
建议
- Consider using for the external library
loadScript()
- 考虑对外部库使用
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
undefinedPR 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)
Mobile (375px)
移动端(375px)
Tablet (768px)
平板端(768px)
Block Detail
块详情
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:
Issue: [Description of the issue]
Suggestion: [How to fix it]
path/to/file.js:123
---文件:
问题: [问题描述]
建议: [修复方案]
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
决策树:选择哪种方法
| Approach | When to Use | Examples |
|---|---|---|
| GitHub Suggestions (PRIMARY) | Any change that can be expressed as a code replacement | Remove 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 suggestions | Complex 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
undefinedStep 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
positionlinePosition 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添加\标志以实现更一致的错误处理:\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使用\作为中间选择器以避免特异性冲突:\n\n```suggestion\n.page-diff .diff-new-page .doc-diff-side-header {\n padding: var(--spacing-s) var(--spacing-m);\n```"
}
]
}
JSON
ok\\.diff-new-page\\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
--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
--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
应用方法
- Go to the Files changed tab
- Find the inline comments with suggestions
- Click "Commit suggestion" to apply individually
- Or click "Add suggestion to batch" on multiple, then "Commit suggestions" to batch
- 进入Files changed标签页
- 找到带建议的行内评论
- 点击**"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-
Open the diff and count lines from the top, including:
- File headers (and
--- a/file)+++ b/file - Hunk headers ()
@@ -old,lines +new,lines @@ - Context lines (no prefix or space prefix)
- Removed lines (- prefix)
- Added lines (+ prefix)
- File headers (
-
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 in the diff, not
positionin the file (critical!)line - 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-
打开diff并从顶部开始计数行,包括:
- 文件头(和
--- a/file)+++ b/file - 块头()
@@ -old,lines +new,lines @@ - 上下文行(无前缀或空格前缀)
- 删除的行(-前缀)
- 添加的行(+前缀)
- 文件头(
-
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
undefined1. 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 comments
stylelint-disable - ✅ 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>
对应评审反馈:<评审评论链接>
undefinedApproach 3: Hybrid Approach (RECOMMENDED FOR MOST PRs)
方法3:混合方法(大多数PR推荐使用)
For the majority of PRs, use this hybrid strategy:
- GitHub suggestions for all fixable issues (primary method)
- Guidance/comments for subjective or architectural issues
- Fix commits only for very complex multi-file refactors
Typical workflow:
bash
undefined对于大多数PR,使用以下混合策略:
- GitHub建议处理所有可修复问题(主要方法)
- 指导/评论处理主观或架构问题
- 修复提交仅用于非常复杂的多文件重构
典型工作流:
bash
undefined1. 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
--input /tmp/review-suggestions.json
gh api POST repos/{owner}/{repo}/pulls/<PR-number>/reviews
--input /tmp/review-suggestions.json
--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:
- XSS safety documentation needed (BLOCKING)
- Four CSS stylelint-disable comments (should fix)
- Inconsistent error handling (should fix)
- CSS variable fallback inconsistency (optional)
Action taken:
bash
undefinedPR #196:差异工具支持未发布页面
评审中发现的问题:
- 需要XSS安全文档(阻塞合并)
- 4个CSS stylelint-disable注释(应该修复)
- 错误处理不一致(应该修复)
- CSS变量回退不一致(可选)
采取的行动:
bash
undefinedCreated 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:
- Verify correctness: Test locally or mentally verify the fix is correct
- Check scope: Ensure your fix doesn't introduce new issues
- Maintain style: Match existing code style and patterns
- Run linters: Ensure fixes don't break linting
- Be respectful: Frame fixes as helpful suggestions, not criticism
- 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
发布建议或提交前:
- 验证正确性: 本地测试或在脑中验证修复正确
- 检查范围: 确保你的修复不会引入新问题
- 保持风格: 匹配现有代码风格和模式
- 运行检查: 确保修复不会打破linting
- 保持尊重: 将修复表述为有用的建议,而非批评
- 关联上下文: 引用解释原因的评审评论
禁止事项:
- 不要修复PR范围外的问题
- 不要修改与问题无关的代码风格
- 不要添加功能或增强
- 不要推送提交却不说明修复内容
- 不要未经讨论修复主观问题
Troubleshooting GitHub Suggestions
GitHub建议故障排除
Common issues and solutions:
| Problem | Cause | Solution |
|---|---|---|
| "Validation Failed: line could not be resolved" | Used | Use |
| Suggestion doesn't appear inline | Wrong position value | Count lines in the diff carefully, including headers |
| Can't apply suggestion | Merge conflict or branch updated | Author needs to update branch first |
| Suggestion formatting broken | Unescaped JSON characters | Escape quotes, backticks, newlines in JSON |
| "Invalid commit_id" | Used old commit SHA | Get current HEAD SHA before creating review |
How to verify your review before posting:
bash
undefined常见问题及解决方案:
| 问题 | 原因 | 解决方案 |
|---|---|---|
| "Validation Failed: line could not be resolved" | 使用了 | 使用 |
| 建议未在行内显示 | position值错误 | 仔细计数diff中的行,包括文件头 |
| 无法应用建议 | 存在合并冲突或分支已更新 | 作者需先更新分支 |
| 建议格式损坏 | JSON字符未转义 | JSON中转义引号、反引号、换行符 |
| "Invalid commit_id" | 使用了旧的提交SHA | 创建评审前获取当前HEAD SHA |
发布前验证评审:
bash
undefined1. 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正确
undefinedundefinedSuccess 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 values (diff lines, not file lines)
position - Batch related suggestions in one review for efficient application
好的修复方案应满足:
- 优先使用GitHub建议(约70-80%的可修复问题)
- 让作者轻松解决问题(一键接受)
- 提供可运行、已测试的代码(而非未经测试的建议)
- 评论正文中解释每个修复的理由
- 引用步骤8中的原始评审反馈
- 语气尊重且协作
- 仅聚焦评审中发现的问题
- 不引入新问题或回归
- 包含友好总结评论说明如何应用建议
- 使用正确的值(diff行号,而非文件行号)
position - 相关建议批量提交到一个评审中以提高应用效率
Quick Start Template
快速开始模板
Copy this template to quickly create a review with GitHub Suggestions:
bash
#!/bin/bash复制此模板快速创建带GitHub建议的评审:
bash
#!/bin/bashQuick 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
--input /tmp/review-$PR_NUMBER.json
gh api POST repos/$OWNER/$REPO/pulls/$PR_NUMBER/reviews
--input /tmp/review-$PR_NUMBER.json
--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:
- usage without justification
!important - 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 ?" - Strong preference against
!important!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
undefinedmarkdown
undefinedApproved
已批准
Preview URLs verified and changes look good.
预览URL已验证,变更符合要求。
Visual Preview
视觉预览
Verified:
- Code quality and linting
- Performance (Lighthouse scores)
- Visual appearance (screenshots captured)
- Responsive behavior
- Accessibility basics
[Any additional notes]
undefined已验证:
- 代码质量和linting
- 性能(Lighthouse评分)
- 视觉效果(已截图)
- 响应式行为
- 基础可访问性
[其他说明]
undefinedRequest Changes
请求变更
markdown
undefinedmarkdown
undefinedChanges Requested
请求变更
Blocking Issues
阻塞问题
[List with file:line references]
[带文件:行号引用的列表]
Suggestions
建议
[List of recommendations]
Please address the blocking issues before merge.
undefined[建议列表]
请解决阻塞问题后再合并。
undefinedComment
评论
markdown
undefinedmarkdown
undefinedReview Notes
评审说明
[Non-blocking observations and questions]
---[非阻塞的观察和问题]
---Integration with GitHub Workflow
与GitHub工作流集成
When triggered via GitHub Actions, the skill should:
- Receive: PR number, repository info, event context
- Execute: Full review workflow above
- Output:
- Review comment on the PR
- Appropriate review status (approve/request-changes/comment)
- Summary posted as PR comment
GitHub Actions integration points:
- event triggers
pull_request - for posting reviews
gh pr review - for detailed feedback
gh pr comment
通过GitHub Actions触发时,该技能应:
- 接收: PR编号、仓库信息、事件上下文
- 执行: 上述完整评审工作流
- 输出:
- PR上的评审评论
- 适当的评审状态(批准/请求变更/评论)
- 作为PR评论发布的总结
GitHub Actions集成点:
- 事件触发
pull_request - 用于发布评审
gh pr review - 用于详细反馈
gh pr comment
Resources
资源
EDS-Specific Resources
EDS特定资源
- EDS Development Guidelines: https://www.aem.live/docs/dev-collab-and-good-practices
- Performance Best Practices: https://www.aem.live/developer/keeping-it-100
- Block Development: https://www.aem.live/developer/block-collection
- David's Model: https://www.aem.live/docs/davidsmodel
GitHub Code Review Resources
GitHub代码评审资源
- GitHub Suggestions Documentation: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/incorporating-feedback-in-your-pull-request
- Pull Request Reviews API: https://docs.github.com/en/rest/pulls/reviews
- Review Comments API: https://docs.github.com/en/rest/pulls/comments
- Creating Review Comments: https://docs.github.com/en/rest/pulls/comments#create-a-review-comment-for-a-pull-request
- GitHub建议文档: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/incorporating-feedback-in-your-pull-request
- 拉取请求评审API: https://docs.github.com/en/rest/pulls/reviews
- 评审评论API: https://docs.github.com/en/rest/pulls/comments
- 创建评审评论: https://docs.github.com/en/rest/pulls/comments#create-a-review-comment-for-a-pull-request
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更简洁,评审周期更少
- 从即时反馈中学习
- 代码质量一致