Skip to main content

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で見る