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
- フォーク
- 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で見る