Help us improve
Share bugs, ideas, or general feedback.
From zaku
Export documentation for vendor-modified or vendor-added AOSP features by summarizing implementation methods from related context code
npx claudepluginhub innerjoint/granada --plugin zakuHow this skill is triggered — by the user, by Claude, or both
Slash command
/zaku:aosp-feature-export "<vendor feature description>""<vendor feature description>"opusThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Documents vendor/third-party features added on top of AOSP. Takes a concrete vendor feature description as input, extracts any available vendor modification context from the description or conversation, then uses the `mcp__plugin_zaku_sourcepilot__*` tools to search the AOSP codebase for the original code being modified or extended. Outputs an English canonical markdown document focused on the ...
Provides behavioral guidelines to reduce common LLM coding mistakes, focusing on simplicity, surgical changes, assumption surfacing, and verifiable success criteria.
Searches, retrieves, and installs Agent Skills from prompts.chat registry using MCP tools like search_skills and get_skill. Activates for finding skills, browsing catalogs, or extending Claude.
Structures git workflow practices for committing, branching, resolving conflicts, and organizing work across parallel streams. Use when making any code change.
Share bugs, ideas, or general feedback.
Documents vendor/third-party features added on top of AOSP. Takes a concrete vendor feature description as input, extracts any available vendor modification context from the description or conversation, then uses the mcp__plugin_zaku_sourcepilot__* tools to search the AOSP codebase for the original code being modified or extended. Outputs an English canonical markdown document focused on the problem or requirement the feature addresses, vendor solution, implementation method, related context code, and verification approach, archived to .granada/aosp-exports/.
Key distinction: The feature being documented is NOT an AOSP built-in feature. It is a vendor customization — code added or modified by the third-party vendor on top of AOSP. The AOSP search phase finds the original context that the vendor code interacts with.
Scope principle: One export should describe one concrete vendor feature slice, such as AIUD 在 Settings 中的定制功能, not a broad module-level topic like Settings 定制 or Connectivity 定制. If the input is too broad, first run bounded coarse exploration, save the split-candidate result to .granada/aosp-exports/<slug>-split.md, list concrete sub-feature candidates with evidence, stop without exporting a full report, and tell the user to run the skill again with one selected sub-feature.
/zaku:aosp-feature-export "公共DNS"
/zaku:aosp-feature-export "fingerprint unlock"
/zaku:aosp-feature-export "AIUD 在 Settings 中的定制功能"
The only user input is the concrete vendor feature description. If additional vendor modification context or previous export context is needed, the skill should discover it from the conversation or ask for it during the protocol rather than exposing it as command-line flags.
Call mcp__plugin_zaku_sourcepilot__list_projects() to verify the MCP server is reachable and upstream is responding.
After health check passes, read .granada/aosp-config.json to display the active AOSP project:
**🔍 AOSP Project: <project_name>** prominently**⚠ 未配置 AOSP 项目** — 搜索将不限定项目范围。运行 /zaku:aosp-project 设置项目。(The aosp-investigator subagent reads this config and passes project to search calls automatically — no need to inject it into spawn prompts.)
On failure, abort with: AOSP MCP server unreachable. Check SOURCEPILOT_URL and SOURCEPILOT_KEY environment variables.
Extract any available vendor modification context from the feature description and conversation history. Do not require a specific hosting provider or source-control system.
When available, capture:
If no modification context is available, continue in description-only mode and rely on AOSP source search to identify likely original context.
Before spawning investigators, decide whether the requested feature is concrete enough to export as one report.
Single-purpose test (primary): The feature should be describable in one sentence with one purpose. If the sentence contains two independent purposes (for example, query and display user location), split it into query location and display location.
Split when any of these are true:
Settings customization, Connectivity customization, Audio routing) rather than a concrete user-visible behavior, API behavior, or vendor hook.If the input is too broad: run bounded coarse exploration. This branch runs after the Step 2c granularity decision and before Step 3 Phase 1 discovery. It is not a full export, must not write .granada/aosp-exports/<slug>.md, must write the split-candidate result to .granada/aosp-exports/<slug>-split.md, and must not continue into Step 3 after listing candidates.
Run coarse exploration with a 2 rounds adaptive budget:
zaku:aosp-investigator agents in parallel.zaku:aosp-investigator agents focused on candidate boundaries and evidence gaps, not full implementation tracing.Use a breadth-first investigator prompt:
Agent(
subagent_type="zaku:aosp-investigator",
prompt="Coarsely explore AOSP for a BROAD vendor customization description: '<description>'.
This is a third-party/vendor customization, NOT an AOSP built-in feature, and NOT yet a confirmed single feature slice.
Vendor modification context (if available):
<known changed file paths, class names, method names, settings/config keys, and behavior summaries from Step 2>
Previously discovered prefixes, anchors, and candidate areas to avoid in this round (Round 2 only):
<prefixes, anchors, and candidate areas already covered>
Your mission: discover likely concrete sub-feature slices that could each be exported separately later.
- Prefer breadth over depth: identify candidate behavior boundaries, entry points, key AOSP paths, class/interface/settings anchors, resources, and evidence snippets
- Do not produce a full implementation report or trace the complete dependency chain
- Avoid re-searching already discovered prefixes, anchors, or candidate areas in Round 2
- Report candidate sub-features with evidence, uncertainty, and known gaps
For each candidate, include: candidate name, one-sentence description, why it is independently exportable, evidence discovered, likely search anchors, confidence/evidence strength, and known gaps."
)
Synthesize 2-6 candidate sub-features. For each candidate, present:
/zaku:aosp-feature-export "..."Save the split-candidate result:
.granada/aosp-exports/ if it does not exist.granada/aosp-exports/<slug>-split.mdSplit candidate result only — not a complete vendor feature exportIf evidence is insufficient, output conservative low-confidence candidates with explicit evidence gaps rather than presenting them as confirmed.
Stop without exporting a full feature report, without writing .granada/aosp-exports/<slug>.md, and without continuing to Step 3. Confirm the split result path and tell the user to run /zaku:aosp-feature-export again with one selected candidate.
Spawn 3 aosp-investigator subagents in parallel. Each investigator is given the full confirmed sub-feature context and independently decides what/how to search. The orchestrator does NOT pre-generate search queries — investigators handle search strategy themselves:
Agent(
subagent_type="zaku:aosp-investigator",
prompt="Investigate AOSP for the original code related to a VENDOR feature: '<description>'.
This is a third-party/vendor customization, NOT an AOSP built-in feature. The vendor has modified or extended AOSP code to implement this feature.
Vendor modification context (if available):
<known changed file paths, class names, method names, settings/config keys, and behavior summaries from Step 2>
Your mission: Search AOSP to find the ORIGINAL context code that explains how this confirmed vendor sub-feature is implemented.
- Search for the original AOSP classes/interfaces that the vendor code modifies, extends, or calls
- Follow the implementation path from user-facing entry/API hook to framework/service/native/HAL dependencies when relevant
- Identify the concrete problem being solved, the vendor method, the affected code path, and the observable effect
- For each finding, document: file path, code snippet, implementation role, and how it supports the vendor solution
Report ALL discovered AOSP file paths grouped by implementation concern. Include only architecture observations that explain the vendor implementation method."
)
Collect all investigator reports. Extract unique second-level directory prefixes (first two path segments from AOSP root, e.g., frameworks/base, hardware/interfaces, packages/modules/Connectivity). Store in discovered_prefixes set.
Run the full deep investigation loop by default.
Loop up to 5 rounds (max 15 total successful agent spawns across all rounds including Phase 1).
Each round, spawn N aosp-investigator subagents where N is determined by discovery rate:
Pass them the accumulated findings so far and let them independently decide how to expand the search — the orchestrator provides context, not queries:
Agent(
subagent_type="zaku:aosp-investigator",
prompt="Continue investigating AOSP for the original code related to a VENDOR feature: '<description>'.
This is a third-party/vendor customization. The vendor has modified or extended AOSP code.
Previously discovered AOSP paths (DO NOT re-search these):
<list of discovered_prefixes>
Specific files already documented (avoid redundant searches):
<list of up to 50 most-referenced file paths from prior rounds, selected for prefix diversity — spread across the most distinct prefixes to maximize coverage signal>
Key interfaces and classes found so far:
<extracted interface names, class names, AIDL/HIDL definitions from prior rounds>
Your mission: Find AOSP code OUTSIDE the already-discovered areas that clarifies the confirmed sub-feature's implementation method.
- Search for callers/implementors of the interfaces found so far
- Look for adjacent code that explains why the vendor method works: entry points, state flow, config gates, permissions, persistence, service calls, native/HAL boundaries, or tests
- Avoid broad subsystem surveys unless they directly explain the sub-feature's problem-solution path
- Explore upstream/downstream AOSP dependencies not yet covered
Report only NEW findings (paths not in the already-discovered list). Group by implementation concern with observations about how each finding explains the vendor method."
)
After each round:
discovered_prefixes, stop iteratingRound N (M agents): +X new prefixes (total: Y unique prefixes, Z files discovered)The orchestrator's only heavy-lifting phase — merge investigator reports into a problem-solution implementation document:
If .granada/aosp-exports/<slug>.md already exists for the confirmed sub-feature, load it as prior context automatically.
Compute slug from description (same logic as Step 6)
Check if .granada/aosp-exports/<slug>.md exists
last_verified timestamp from the metadata section
c. all previously documented file pathsStaleness check:
last_verified from the existing document's metadata sectionlast_verified is older than 30 days: emit warning to user: "⚠ Last verification is older than 30 days ({date}). A full export will be regenerated from current code."Merge strategy:
last_verified timestamp to current date.granada/aosp-exports/ directory if it doesn't exist.granada/aosp-exports/<slug>.mdFeature export saved to .granada/aosp-exports/<slug>.md.On any unrecoverable error:
.granada/aosp-exports/<slug>-partial.mdSkill is idempotent — re-running with the same inputs overwrites the output file.
# Vendor Feature Element Export: {feature_name}
## Overview
- **Feature:** {confirmed_sub_feature_description}
- **Original input:** {original_description, if scope was split; otherwise same as Feature}
- **Type:** Vendor/third-party customization
- **Scope granularity:** {single purpose / split from broad scope / user-confirmed sub-feature}
- **AOSP project:** {project_name from .granada/aosp-config.json, or "not configured"}
- **Export date:** {date}
- **Vendor modification context:** {known paths/classes/methods/config keys or "description-only"}
- **Extracted keywords:** {keyword_list}
- **Search rounds:** {n}/5
- **Discovered AOSP project count:** {count}
- **Convergence:** {converged at round X / reached max rounds}
## Vendor Problem and Solution
- **Problem to solve:** {specific user behavior, API behavior, device behavior, or integration gap addressed by the vendor change}
- **Vendor method:** {what logic the vendor added or modified}
- **Why it works:** {how the original AOSP mechanism allows this approach to take effect}
- **Final effect:** {user-visible, system-observable, or interface-verifiable result}
## Vendor Modification Summary
{Summarize the known vendor modification context. Explain which paths, classes, methods, settings, resources, or behaviors are known to be changed. If no concrete modification context is available, state that the export is based on the feature description only.}
## Implementation Method
### 1. {implementation step name}
- **Purpose:** {what sub-problem this step solves}
- **Vendor change:** `{vendor/file/path}` {how the class/method/constant/configuration was changed}
- **AOSP context:** `{aosp/file/path}` {original mechanism, call relationship, or state flow}
- **Implementation rationale:** {why this change makes the feature work}
- **Key code:**
{relevant code excerpt}
### 2. {implementation step name}
- **Purpose:** {what sub-problem this step solves}
- **Vendor change:** `{vendor/file/path}` {how the class/method/constant/configuration was changed}
- **AOSP context:** `{aosp/file/path}` {original mechanism, call relationship, or state flow}
- **Implementation rationale:** {why this change makes the feature work}
- **Key code:**
{relevant code excerpt}
## Key Context Code
| Concern | File | Type | Role in the implementation method |
|---------|------|------|-----------------------------------|
| {UI entry/API entry/service flow/config persistence/permission/Native/HAL/test} | `{file_path}` | {Java/Kotlin/C++/AIDL/HIDL/XML/SELinux/Test} | {how this code explains the vendor approach} |
| ... | ... | ... | ... |
## Key Interfaces and Data Flow
{Keep this section only when interfaces or cross-layer data flow are necessary to explain the implementation method. Explain how AIDL/HIDL/Java API/Native/JNI/Intent/Content Provider/System Service/HAL participate in the feature.}
```text
{entry point} -> {vendor modified code} -> {AOSP context code} -> {state/config/service/native/HAL dependency} -> {observable effect}
{Only describe architecture relationships required to understand the implementation method. Avoid expanding this into a full AOSP module overview.}
| Round | Query/focus | New prefixes | Total prefixes | Total files |
|---|---|---|---|---|
| 1 (discovery) | {keyword groups or implementation concerns} | {n} | {n} | {n} |
| 2 | {new implementation concerns} | {n} | {n} | {n} |
| ... | ... | ... | ... | ... |
| {final} | {queries} | {n} | {n} | {n} |
Stop reason: {converged (< 3 new prefixes) / reached max rounds / partial failure}
## Keyword Triggers
- `"aosp export"`, `"aosp feature export"`, `"功能元导出"`, `"feature export"`
## Configuration
- Output directory: `.granada/aosp-exports/` (fixed)
- Full export path: `.granada/aosp-exports/<slug>.md`
- Broad-scope split result path: `.granada/aosp-exports/<slug>-split.md`
- Max iteration rounds: 5
- Max total agent spawns: 15
- Convergence threshold: < 3 new second-level prefixes per round
## Known Limitations
- **Description-only mode:** If no concrete vendor modification context is available, the export may describe the most likely AOSP implementation context rather than confirmed vendor touch points.
- **Broad-scope split output:** Split results are saved as candidate lists only; they are not complete vendor feature exports and must be rerun with one selected candidate for full documentation.
- **Existing export interaction:** Previously exported findings are used for comparison and deduplication when an export with the same slug already exists.