diff --git a/plugins/android-reverse-engineering/skills/android-reverse-engineering/SKILL.md b/plugins/android-reverse-engineering/skills/android-reverse-engineering/SKILL.md
index 7e3277b..f804a65 100644
--- a/plugins/android-reverse-engineering/skills/android-reverse-engineering/SKILL.md
+++ b/plugins/android-reverse-engineering/skills/android-reverse-engineering/SKILL.md
@@ -148,7 +148,13 @@ Navigate the decompiled output to understand the app's architecture.
    - Distinguish app code from third-party libraries
    - Look for packages named `api`, `network`, `data`, `repository`, `service`, `retrofit`, `http` — these are where API calls live
 
-3. **Identify the architecture pattern**:
+3. **Read every `BuildConfig.java`** — these are almost never obfuscated and frequently leak the highest-signal constants in the entire APK (base URLs, flavor names, build type, third-party API keys, feature flags):
+   ```bash
+   find <output>/sources -name BuildConfig.java -exec grep -H '=' {} \;
+   ```
+   Each Gradle module emits its own `BuildConfig`, so expect 1–N hits. Read all of them.
+
+4. **Identify the architecture pattern**:
    - MVP: look for `Presenter` classes
    - MVVM: look for `ViewModel` classes and `LiveData`/`StateFlow`
    - Clean Architecture: look for `domain`, `data`, `presentation` packages
@@ -242,15 +248,32 @@ On Windows (PowerShell):
 & "${CLAUDE_PLUGIN_ROOT}/skills/android-reverse-engineering/scripts/find-api-calls.ps1" <output>/sources/ -Auth
 ```
 
-Then, for each discovered endpoint, read the surrounding source code to extract:
-- HTTP method and path
-- Base URL
-- Path parameters, query parameters, request body
-- Headers (especially authentication)
-- Response type
-- Where it's called from (the call chain from Phase 4)
+Document the endpoints in **two tiers** — going deep on every endpoint is
+prohibitively expensive on apps with 100+ paths, and most of them do not
+warrant it. Always produce Tier 1; expand Tier 2 only for the endpoints
+that matter.
 
-**Document each endpoint** using this format:
+#### Tier 1 — flat inventory (always)
+
+A single table covering every discovered endpoint. Aim for one line each;
+if you cannot determine a column, write `?`.
+
+| Host | Method | Path | Auth | Source file |
+|------|--------|------|------|-------------|
+| `api.example.com` | GET | `/v1/users/profile` | Bearer | `com/example/api/UserApi.java` |
+| `api.example.com` | POST | `/v1/auth/login` | none | `com/example/api/AuthApi.java` |
+
+This table answers "what does the backend look like" in one screen and
+takes ~5 minutes to produce from the `--paths` output even on a large app.
+
+#### Tier 2 — per-endpoint detail (only for high-value endpoints)
+
+Reserve the detailed format for the few endpoints that actually need it:
+
+- the entire authentication flow (login, refresh, logout, OTP/SMS, anonymous, registration)
+- payment / checkout / order-creation endpoints
+- anything the user explicitly asked about
+- anything that looked unusual during the scan (custom signing, undocumented headers, etc.)
 
 ```markdown
 ### `METHOD /path`
@@ -265,6 +288,10 @@ Then, for each discovered endpoint, read the surrounding source code to extract:
 - **Called from**: `LoginActivity → LoginViewModel → UserRepository → ApiService`
 ```
 
+As a default, do not produce Tier 2 entries for more than ~10 endpoints
+unless the user explicitly asks for more — Tier 1 plus a Tier 2 deep dive
+on auth + 1-2 key flows is what most consumers of this work actually want.
+
 See `${CLAUDE_PLUGIN_ROOT}/skills/android-reverse-engineering/references/api-extraction-patterns.md` for library-specific search patterns and the full documentation template.
 
 ## Output