code-review
Guide GitHub Copilot pull-request reviews for the Common Android Auth library using repository-specific correctness, security, compatibility, telemetry, performance, testing, and comment-quality rules.
来源信息
- 仓库
- AzureAD/microsoft-authentication-library-common-for-android
- 最近来源活动
- 2026年10月22日 16:41
- 检测到的 SKILL.md 语言
- 英语
- 星标
- 57
- Forks
- 57
安装方式
默认使用会先检查来源的 Prompt;你也可以切换为直接命令,或下载本地副本。
检查来源文件
决定是否安装前,请先阅读 SKILL.md,以及 SkillsMP 当前展示的配套文件。
文件资源管理器
10 个文件正在显示 SKILL.md
SKILL.md
来源说明 · 只读预览- name
- code-review
- description
- Guide GitHub Copilot pull-request reviews for the Common Android Auth library using repository-specific correctness, security, compatibility, telemetry, performance, testing, and comment-quality rules.
# GitHub Copilot PR review
Use this skill only for pull-request review in `AzureAD/microsoft-authentication-library-common-for-android`.
## Workflow
1. Read the complete diff and enough local context to understand each changed path. Review changed code and directly affected behavior; do not deep-audit untouched legacy code.
2. Classify the change and load the applicable references:
- Always: [comment quality and severity](references/comment-quality-severity.md), [false-positive suppression](references/false-positive-suppression.md), and the [general memory and storage performance screen](references/performance-resources-dependencies.md#general-memory-and-storage-performance-screen). Screen every production-code change, not only edits to known hot paths or cache classes.
- Commands, controllers, OAuth/OIDC, cache, authority, IPC, errors, shared contracts, or downstream consumers: [domain context](references/domain-context.md) and [correctness and API compatibility](references/correctness-api-compatibility.md).
- Authentication, authorization, tokens, claims, logs, telemetry data, feature flags, intents, deserialization, keys, certificates, or cryptography: [security, privacy, and cryptography](references/security-privacy-crypto.md).
- Shared mutable state, executors, threads, coroutines, flows, cancellation, cache updates, or key rotation; changed/added/removed/moved `synchronized` blocks/methods, Kotlin `@Synchronized`, explicit `Lock`/`withLock`/`Mutex`, or modified lock expressions/helpers/receivers/shared-state paths: [concurrency and threading](references/concurrency-threading.md). Follow its [change-driven analysis](references/concurrency-threading.md#lock-identity-and-beforeafter-analysis) even for refactors without new locking tokens. Also follow [runtime call targets](references/concurrency-threading.md#runtime-target-trace) for changed interface/abstract calls, concrete overridable calls in Java and Kotlin (including Java virtual and Kotlin `open` methods), injected implementations, hierarchy/override changes, or callback/listener/lambda invocations/bodies reached while a lock is held, even when that caller is unchanged. Synchronization merely present elsewhere in a file, or an interface call alone, is not a finding.
- Java/Kotlin production logic, validation, nullability, collections, serialization, error modeling, or public/shared APIs: [correctness and API compatibility](references/correctness-api-compatibility.md).
- Memory/collection operations, object ownership/lifetimes, caches, storage, serialization, cryptography, hot paths, build/dependency files, or resource ownership: deepen the [performance, resources, and dependencies](references/performance-resources-dependencies.md) review as the general screen requires. For AcquireTokenSilent (ATS) dependencies, also apply the [ATS examples](references/performance-resources-dependencies.md#acquiretokensilent-ats-regression-checks); those examples do not limit the general rule.
- OpenTelemetry spans, attributes, status, correlation IDs, `SpanName`, or `AttributeName`: [telemetry and observability](references/telemetry-observability.md).
- Tests, bug fixes, public APIs, Javadoc/KDoc, documentation changes, or new source files: [testing and documentation](references/testing-documentation.md).
Load every reference whose trigger applies; one diff can require several.
3. Verify each candidate finding against actual code: trace type hierarchies, data sources, reachability, lifecycle, synchronization, existing tests, and repository conventions. Treat names as hints, not evidence.
4. Report only high-confidence, actionable findings. Each comment must identify the issue, explain its impact, and recommend a concrete fix. Include a patch only when it is safe and compilable.
5. Before submitting, remove duplicates, speculative concerns, style-only comments, unrelated scope expansion, and findings already suppressed by the references.
Prioritize security, correctness, concurrency, compatibility, and meaningful performance regressions. Tailor every comment to the changed code.
在 GitHub 查看