reviewing-changes

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Reviewing Changes - Android Additions

审查变更 - Android 新增内容

This skill provides Android-specific workflow additions that complement the base

bitwarden-code-reviewer

agent standards.

该Skill提供了特定于Android的工作流补充内容，以完善基础的

bitwarden-code-reviewer

Agent标准。

Instructions

说明

IMPORTANT: Use structured thinking throughout your review process. Plan your analysis in

<thinking>

tags before providing final feedback.

重要提示：在整个审查过程中使用结构化思维。在提供最终反馈前，将你的分析过程写在

<thinking>

标签中。

Step 1: Retrieve Additional Details

步骤1：获取额外细节

<thinking> Determine if more context is available for the changes: 1. Are there JIRA tickets or GitHub Issues mentioned in the PR title or body? 2. Are there other GitHub pull requests mentioned in the PR title or body? </thinking>

Retrieve any additional information linked to the pull request using available tools (JIRA MCP, GitHub API).

If pull request title and message do not provide enough context, request additional details from the reviewer:

Link a JIRA ticket
Associate a GitHub issue
Link to another pull request
Add more detail to the PR title or body

<thinking> 判断是否有更多关于变更的上下文信息： 1. PR标题或正文中是否提到了JIRA工单或GitHub Issues？ 2. PR标题或正文中是否提到了其他GitHub拉取请求？ </thinking>

使用可用工具（JIRA MCP、GitHub API）获取与拉取请求相关的任何额外信息。

如果拉取请求的标题和描述提供的上下文不足，请向提交者请求更多细节：

关联JIRA工单
关联GitHub Issue
链接到其他拉取请求
为PR标题或正文添加更多细节

Step 2: Detect Change Type with Android Refinements

步骤2：结合Android专属规则检测变更类型

<thinking> Analyze the changeset systematically: 1. What files were modified? (code vs config vs docs) 2. What is the PR/commit title indicating? 3. Is there new functionality or just modifications? 4. What's the risk level of these changes? </thinking>

Use the base change type detection from the agent, with Android-specific refinements:

Android-specific patterns:

Feature Addition: New
```
ViewModel
```
, new
```
Repository
```
, new
```
@Composable
```
functions, new
```
*Screen.kt
```
files
UI Refinement: Changes only in
```
*Screen.kt
```
,
```
*Composable.kt
```
,
```
ui/
```
package files

Infrastructure: Changes to

.github/workflows/

gradle/

build.gradle.kts

libs.versions.toml

Dependency Update: Changes only to
```
libs.versions.toml
```
or
```
build.gradle.kts
```
with version bumps

<thinking> 系统分析变更集： 1. 修改了哪些文件？（代码、配置还是文档） 2. PR/提交标题表明了什么？ 3. 是新增功能还是仅做了修改？ 4. 这些变更的风险等级如何？ </thinking>

使用Agent的基础变更类型检测功能，并结合Android专属规则：

Android专属模式：

功能新增：新增
```
ViewModel
```
、新增
```
Repository
```
、新增
```
@Composable
```
函数、新增
```
*Screen.kt
```
文件
UI优化：仅修改
```
*Screen.kt
```
、
```
*Composable.kt
```
、
```
ui/
```
包下的文件

基础设施变更：修改

.github/workflows/

、

gradle/

、

build.gradle.kts

、

libs.versions.toml

依赖更新：仅修改
```
libs.versions.toml
```
或
```
build.gradle.kts
```
中的版本号

Step 3: Load Appropriate Checklist

步骤3：加载对应的检查清单

Based on detected type, read the relevant checklist file:

Dependency Update →
```
checklists/dependency-update.md
```
(expedited review)
Bug Fix →
```
checklists/bug-fix.md
```
(focused review)
Feature Addition →
```
checklists/feature-addition.md
```
(comprehensive review)
UI Refinement →
```
checklists/ui-refinement.md
```
(design-focused review)
Refactoring →
```
checklists/refactoring.md
```
(pattern-focused review)
Infrastructure →
```
checklists/infrastructure.md
```
(tooling-focused review)

The checklist provides:

Multi-pass review strategy
Type-specific focus areas
What to check and what to skip
Structured thinking guidance

根据检测到的变更类型，读取相关的检查清单文件：

依赖更新 →
```
checklists/dependency-update.md
```
（快速审查）
Bug修复 →
```
checklists/bug-fix.md
```
（聚焦审查）
功能新增 →
```
checklists/feature-addition.md
```
（全面审查）
UI优化 →
```
checklists/ui-refinement.md
```
（设计聚焦审查）
代码重构 →
```
checklists/refactoring.md
```
（模式聚焦审查）
基础设施变更 →
```
checklists/infrastructure.md
```
（工具聚焦审查）

检查清单包含：

多轮审查策略
特定类型的聚焦领域
需要检查和可以跳过的内容
结构化思维指导

Step 4: Execute Review Following Checklist

步骤4：遵循检查清单执行审查

<thinking> Before diving into details: 1. What are the highest-risk areas of this change? 2. Which architectural patterns need verification? 3. What security implications exist? 4. How should I prioritize my findings? 5. What tone is appropriate for this feedback? </thinking>

Follow the checklist's multi-pass strategy, thinking through each pass systematically.

<thinking> 在深入细节之前： 1. 此变更的最高风险区域是什么？ 2. 需要验证哪些架构模式？ 3. 存在哪些安全影响？ 4. 我应该如何对发现的问题进行优先级排序？ 5. 反馈采用何种语气较为合适？ </thinking>

遵循检查清单的多轮审查策略，系统地完成每一轮审查。

Step 5: Consult Android Reference Materials As Needed

步骤5：必要时参考Android参考资料

Load reference files only when needed for specific questions:

Issue prioritization →
```
reference/priority-framework.md
```
(Critical vs Suggested vs Optional)
Phrasing feedback →
```
reference/review-psychology.md
```
(questions vs commands, I-statements)
Architecture questions →
```
reference/architectural-patterns.md
```
(MVVM, Hilt DI, module org, error handling)
Security questions (quick reference) →
```
reference/security-patterns.md
```
(common patterns and anti-patterns)
Security questions (comprehensive) →
```
docs/ARCHITECTURE.md#security
```
(full zero-knowledge architecture)
Testing questions →
```
reference/testing-patterns.md
```
(unit tests, mocking, null safety)
UI questions →
```
reference/ui-patterns.md
```
(Compose patterns, theming)
Style questions →
```
docs/STYLE_AND_BEST_PRACTICES.md
```

仅在针对特定问题需要时加载参考文件：

问题优先级划分 →
```
reference/priority-framework.md
```
（关键、建议、可选）
反馈措辞 →
```
reference/review-psychology.md
```
（提问式 vs 命令式，第一人称表述）
架构问题 →
```
reference/architectural-patterns.md
```
（MVVM、Hilt DI、模块组织、错误处理）
安全问题（快速参考） →
```
reference/security-patterns.md
```
（常见模式与反模式）
安全问题（全面参考） →
```
docs/ARCHITECTURE.md#security
```
（完整的零知识架构）
测试问题 →
```
reference/testing-patterns.md
```
（单元测试、模拟、空安全）
UI问题 →
```
reference/ui-patterns.md
```
（Compose模式、主题）
代码风格问题 →
```
docs/STYLE_AND_BEST_PRACTICES.md
```

Core Principles

核心原则

Appropriate depth: Match review rigor to change complexity and risk
Specific references: Always use
```
file:line_number
```
format for precise location
Actionable feedback: Say what to do and why, not just what's wrong
Efficient reviews: Use multi-pass strategy, skip what's not relevant
Android patterns: Validate MVVM, Hilt DI, Compose conventions, Kotlin idioms

适当的审查深度：根据变更的复杂度和风险匹配审查严格程度
精确的引用：始终使用
```
file:line_number
```
格式指定精确位置
可执行的反馈：说明要做什么以及原因，而不仅仅指出问题
高效的审查：采用多轮策略，跳过无关内容
Android模式验证：验证MVVM、Hilt DI、Compose规范、Kotlin惯用写法