AOSP Feature Export Skill

AOSP Feature Export Skill

Exports a FOSD-style Vendor Feature Meta-slice Package for a concrete vendor/third-party feature added on top of AOSP. The export starts from a problem-space feature specification, mines solution-space evidence in AOSP, and writes a traceable package that can be read by humans and consumed by aosp-feature-import through the explicit import contract below.

Key distinction: the feature being exported is NOT an AOSP built-in feature. It is a vendor customization: code, configuration, resources, policies, build hooks, or runtime behavior added or modified by a third-party vendor on top of AOSP. SourcePilot MCP searches through the mcp__plugin_zaku_sourcepilot__* tools find the original AOSP context that the vendor customization interacts with.

Core model: export one feature-first slice, not a directory report. Model the slice as feature -> evidence -> dependencies -> interactions, with explicit traceability from problem space to solution space.

Problem Space                         Solution Space
┌────────────────────┐                ┌────────────────────────────┐
│ Feature Spec       │                │ Code / config / interfaces │
│ capability, scope  │──trace edges──>│ build / runtime evidence   │
│ SKU, switches      │                │ dependencies/interactions  │
└────────────────────┘                └────────────────────────────┘
          │                                         │
          └──────────── Meta-slice Package ─────────┘
                         6 layers

Usage

/zaku:aosp-feature-export "Public DNS"
/zaku:aosp-feature-export "fingerprint unlock"
/zaku:aosp-feature-export "AIUD customization in Settings"

The only user input is the concrete vendor feature description. If additional vendor modification context or previous export context is needed, discover it from the conversation or ask during the protocol rather than exposing extra flags.

Vendor Feature Meta-slice Package Contract

This is the single shared contract between aosp-feature-export and aosp-feature-import: export writes it, and import validates and consumes it. The canonical output is a Vendor Feature Meta-slice Package with stable metadata, feature intent, traceability, six required layers, completeness status, and verification hooks.

Contract item	Required export section / field	Why it exists
Package identity	Metadata with Package schema: vendor-feature-meta-slice/v1 and Generated by: zaku:aosp-feature-export	Lets import reject legacy reports and select the new parser.
Source project	Overview → AOSP project	Lets import compare source and target projects and block same-project imports.
Feature intent	Feature Spec → capability, scope boundary, non-goals, preconditions, activation, visible effect	Preserves problem-space behavior while mapping into the target tree.
Traceability	Traceability Matrix rows from Feature Spec items to solution-space elements and edge types	Explains why a target mapping preserves the original feature intent.
Feature Semantics	Layer 1: Feature Semantics	Defines what capability is delivered, for whom, and under which device/SKU/switch conditions.
Variation Points	Layer 2: Variation Points rows linked to implementation elements	Describes what vendor behavior must be added, overridden, hooked, gated, overlaid, or built in the target.
Implementation Elements	Layer 3: Implementation Elements rows with stable element IDs, layer/area, file or symbol, role, evidence, confidence	Provides import mapping tasks and priority groups.
Dependencies	Layer 4: Dependencies rows linking element IDs to code/config/interface/runtime/build dependencies	Preserves required source relationships and derives target dependency order.
Interactions	Layer 5: Interactions rows with require/exclude/refine/interact/override/conflict relations	Detects composition risks and marks low-confidence or interaction-sensitive mappings for manual verification.
Evidence	Layer 6: Evidence rows with evidence IDs, type, source, supported layer/element IDs, and notes	Carries source proof into target mapping, risk, confidence, and manual verification output.
Completeness status	Completeness Check with every layer marked complete/unknown/unsupported	Distinguishes proven mappings from best-effort or blocked mappings.
Verification hooks	Verification Method entries and evidence IDs	Generates import manual verification points and automated verification candidates.

Every output MUST include every contract item. If a layer or field cannot be proven, write the section anyway, mark its contents as unknown or unsupported, and explain the missing evidence. Do not silently omit a contract item; aosp-feature-import rejects packages that do not satisfy this contract.

Edge Taxonomy

Investigations must look for feature edges, not only paths:

• static_reference: calls, imports, inheritance, registration, listeners, callbacks
• config_dependency: settings keys, resources, overlays, XML, build variables, product variables
• ipc_interface: Binder, AIDL, HIDL, system service, JNI/native boundary
• runtime_state: system property, sysfs, procfs, database/state file, service state
• event_lifecycle: boot, init, broadcast, lifecycle callback, observer, async handler, job/alarm
• policy_permission: SELinux, permission checks, app-ops, signature/system API, UID/package policy
• build_packaging: Soong/Make module, product package, init rc inclusion, firmware/HAL packaging
• verification: tests, logs, traces, commands, settings UI behavior, observable runtime state
• feature_interaction: require, exclude, refine, override, conflict, or composition with another feature

Protocol

Step 1: Health Check

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:

• If configured: display AOSP Project: <project_name> prominently.
• If not configured: display AOSP project is not configured — searches will not be limited to a project. Run /zaku:aosp-project to configure a project.

The aosp-investigator subagent reads this config and passes project to search calls automatically unless a prompt explicitly overrides the project.

On failure, abort with: AOSP MCP server unreachable. Check SOURCEPILOT_URL and SOURCEPILOT_KEY environment variables.

Step 2: Build the Feature Spec

Extract a problem-space feature specification from the description and conversation before searching source code.

Capture:

{
  "feature_name": "<concrete vendor feature name>",
  "capability": "<one-sentence capability or behavior>",
  "scope_boundary": "<what is inside this slice>",
  "non_goals": ["<explicitly excluded behavior>"],
  "preconditions": ["<device/SKU/API/config/runtime assumptions>"],
  "activation": ["<switches, properties, overlays, settings, build flags>"],
  "visible_effect": "<user/system/API-visible result>",
  "known_vendor_context": ["<paths, classes, methods, keys, resources, logs, diffs>"],
  "initial_evidence": ["<evidence already present in the prompt or conversation>"],
  "uncertainties": ["<unknowns that investigators must resolve>"]
}

If no concrete vendor modification context is available, continue in description-only mode but keep that uncertainty in the Evidence layer.

Step 2b: Scope Granularity Check

Before spawning investigators, decide whether the requested feature is concrete enough to export as one meta-slice package.

Single-purpose test: the feature should be describable in one sentence with one purpose. If the sentence contains independent purposes, split them into separate feature candidates.

Split when any are true:

• The feature contains more than two independent logical steps such as fetch, process, store, output, or notify.
• A part can be expressed as a reusable AOSP feature element composed from primitives such as Intent, System Service, HAL interface, Content Provider, JobScheduler, overlay, property, or init service.
• Different parts may change for different reasons: AOSP API change, business rule change, UI change, device/HAL change, policy change, or build/product change.
• The description names a broad module or domain rather than a concrete user-visible behavior, API behavior, device behavior, or vendor hook.
• The expected meta-slice would require unrelated Feature Semantics or unrelated Variation Points.

If the input is too broad: run bounded coarse feature discovery. This branch produces split candidates only and stops before the full export.

1. Run coarse exploration with a 2-round adaptive budget:
   • Round 1: spawn 2 zaku:aosp-investigator agents in parallel.
   • Round 2: only if Round 1 finds fewer than 2 actionable feature candidates, evidence is weak, or the results cannot be bounded into 2-6 single-purpose candidates. Spawn 1-2 additional agents focused on candidate boundaries and evidence gaps.
   • Total cap: at most 4 coarse-exploration agents. Failed agents are not retried.
2. Ask investigators for candidate feature elements, not full implementation reports.
3. Synthesize 2-6 candidates with: candidate name, one-sentence capability, feature boundary, likely layers touched, evidence discovered, search anchors, confidence, and known gaps.
4. Save .granada/aosp-exports/<slug>-split.md and stop without writing the full export package.

Step 3: Build the Evidence Plan

Convert the Feature Spec into an investigation plan before dispatching agents.

Create an Evidence Matrix:

Layer	Required questions	Candidate edges	Evidence found	Status
Feature Semantics	What behavior is delivered and when?	activation, runtime_state, verification	pending	pending
Variation Points	What differs from AOSP?	static_reference, config_dependency, build_packaging	pending	pending
Implementation Elements	What code/config/policy implements it?	all relevant edge types	pending	pending
Dependencies	What must exist for it to work?	ipc_interface, config_dependency, policy_permission, build_packaging	pending	pending
Interactions	What other features or layers can affect it?	feature_interaction, policy_permission, runtime_state	pending	pending
Evidence	What proves each claim?	verification, snippets, logs, traces, tests	pending	pending

The orchestrator should group investigator missions by missing layers and edge types. Do not use keyword groups or second-level directory prefixes as the primary convergence model.

Step 4: Feature-Slice Investigation

Phase 1 — Architecture Skeleton Discovery

Spawn 3 zaku:aosp-investigator subagents in parallel. Each investigator searches independently but receives the same feature-first frame.

Agent(
  subagent_type="zaku:aosp-investigator",
  model="sonnet",
  prompt="Investigate AOSP for a VENDOR feature meta-slice.

This is a third-party/vendor customization, NOT an AOSP built-in feature.

Feature Spec:
<feature_spec_json>

Edge Taxonomy to consider:
<edge_taxonomy>

Evidence Matrix gaps:
<all layers initially pending>

Your mission: find the architecture skeleton for this feature slice before deep file tracing.
- Identify likely entry points, primary responsibility components, external interfaces, policy constraints, resources, build hooks, and runtime activation paths.
- Trace problem-space feature intent to solution-space AOSP context.
- Look for static references, config dependencies, IPC interfaces, runtime state, lifecycle events, policy/permission gates, build packaging, verification hooks, and feature interactions.
- For every finding, state which of the six layers it supports and which edge type it represents.
- Include file path, symbol/interface/config key, evidence snippet or search result, confidence, and remaining gaps.

Report findings as feature elements and edges, not as a broad module survey."
)

Phase 2 — Coverage-Driven Expansion

Run up to 5 expansion rounds, with a maximum of 15 successful agent spawns across Phase 1 and Phase 2.

Each round:

1. Identify incomplete layers, weak evidence, unverified dependencies, and unresolved interactions from the Evidence Matrix.
2. Spawn 2-3 investigators focused on those gaps. Use 3 only when at least two layers remain weak or interaction/dependency evidence is contradictory.
3. Pass accumulated feature elements, edges, evidence, and rejected paths so agents avoid repeating known work.
4. Stop when either:
   • all six layers are filled with high/medium confidence evidence, or
   • remaining gaps are explicitly classified as unknown or unsupported, and one full expansion round produced no new layer coverage, edge type, or verification evidence.

Progress reporting after each round:

Round N: layer coverage {semantic:x, variation:y, implementation:z, dependency:a, interaction:b, evidence:c}; new elements: <n>; new edges: <n>; unresolved gaps: <n>

Partial failure handling:

• Failed agents do not count toward the successful spawn cap.
• If more than 50% of agents fail in a round, stop expansion and synthesize a partial package with explicit evidence gaps.
• Do not retry failed agents unless their missing layer is mandatory and no other evidence exists.

Step 5: Synthesis

Merge investigator reports into a Vendor Feature Meta-slice Package.

1. Deduplicate by feature element ID, file path, symbol/config key, and edge.
2. Preserve richer evidence when findings overlap.
3. Build the six required layers and mark every claim with evidence and confidence.
4. Build a traceability matrix from Feature Spec fields to solution-space elements and evidence.
5. Build an edge table using the Edge Taxonomy.
6. Model feature interactions explicitly, including require/exclude/refine/interact/override/conflict relationships.
7. Run the six-layer completeness check. Missing layers must be unknown or unsupported with a reason.
8. Generate the canonical English output using the template below.

Step 5b: Existing Export Context

If .granada/aosp-exports/<slug>.md already exists for the confirmed feature, load it as prior context automatically.

1. Compute slug from description using Step 6 rules.
2. Check if .granada/aosp-exports/<slug>.md exists.
3. If it exists, extract previously documented feature elements, edges, evidence, confidence, and last_verified.
4. If last_verified is older than 30 days, warn that the export will be regenerated from current evidence.
5. Use existing findings only as comparison/deduplication context. Current evidence wins.

Step 6: Save

1. Generate slug from description: lowercase, replace spaces/special chars with hyphens, max 50 chars.
2. Create .granada/aosp-exports/ if it does not exist.
3. Write the English canonical output to .granada/aosp-exports/<slug>.md.
4. Confirm: Feature meta-slice package saved to .granada/aosp-exports/<slug>.md.

Error Recovery

On unrecoverable error:

• If evidence has been collected, write partial results to .granada/aosp-exports/<slug>-partial.md.
• The partial result must still include all six layer headings and mark unknown/unsupported layers explicitly.
• Report the error to the user.

Skill is idempotent: re-running with the same inputs overwrites the output file.

Output Template

# Vendor Feature Meta-slice Package: {feature_name}

## Overview
- **Feature:** {feature_spec.capability}
- **Original input:** {original_description}
- **Type:** Vendor/third-party customization
- **AOSP project:** {project_name or "not configured"}
- **Export date:** {date}
- **Last verified:** {last_verified date}
- **Source mode:** {vendor-context / description-only / partial evidence}
- **Investigation rounds:** {n}
- **Completeness:** {complete / partial with unknowns / partial with unsupported layers}

## Feature Spec
- **Capability:** {one-sentence capability}
- **Scope boundary:** {inside scope}
- **Non-goals:** {excluded behavior}
- **Preconditions:** {device/SKU/API/config/runtime assumptions}
- **Activation:** {switches/properties/overlays/settings/build flags}
- **Visible effect:** {user/system/API-visible result}
- **Known vendor context:** {paths/classes/methods/config keys or "none"}

## Traceability Matrix

| Problem-space item | Solution-space element | Edge type | Evidence | Confidence |
|--------------------|------------------------|-----------|----------|------------|
| {feature spec field} | `{path#symbol}` / `{config}` / `{interface}` | {edge type} | {snippet/log/test/search evidence} | high/medium/low |

## Layer 1: Feature Semantics

{What capability the vendor feature delivers, when it applies, and how it is observed.}

## Layer 2: Variation Points

| Variation | AOSP baseline | Vendor change | Mechanism | Evidence | Confidence |
|-----------|---------------|---------------|-----------|----------|------------|
| {add/override/hook/conditional/overlay/property/build} | {baseline behavior} | {vendor behavior} | {how it is applied} | {evidence} | {confidence} |

## Layer 3: Implementation Elements

| Element ID | Layer/area | File or symbol | Role | Evidence | Confidence |
|------------|------------|----------------|------|----------|------------|
| {element_id} | {framework/service/HAL/sepolicy/init/app/build} | `{path#symbol}` | {implementation role} | {evidence} | {confidence} |

## Layer 4: Dependencies

| From | To | Edge type | Required for | Evidence | Confidence |
|------|----|-----------|--------------|----------|------------|
| {element_id} | {element_id/config/interface/runtime state} | {edge type} | {why dependency matters} | {evidence} | {confidence} |

## Layer 5: Interactions

| Feature or layer | Relation | Interaction point | Risk | Evidence | Confidence |
|------------------|----------|-------------------|------|----------|------------|
| {power/permission/overlay/device/version/other feature} | require/exclude/refine/interact/override/conflict | {where interaction occurs} | {composition risk} | {evidence} | {confidence} |

If no interaction can be proven, write `unknown` and explain what evidence was searched.

## Layer 6: Evidence

| Evidence ID | Type | Source | Supports | Notes |
|-------------|------|--------|----------|-------|
| {evidence_id} | source snippet / diff / build graph / runtime log / trace / test / config hit | {path/log/test/trace} | {layer and element IDs} | {notes} |

## Completeness Check

| Layer | Status | Missing evidence or unsupported reason |
|-------|--------|----------------------------------------|
| Feature Semantics | complete/unknown/unsupported | {reason if not complete} |
| Variation Points | complete/unknown/unsupported | {reason if not complete} |
| Implementation Elements | complete/unknown/unsupported | {reason if not complete} |
| Dependencies | complete/unknown/unsupported | {reason if not complete} |
| Interactions | complete/unknown/unsupported | {reason if not complete} |
| Evidence | complete/unknown/unsupported | {reason if not complete} |

## Verification Method

- **Verification entry:** {Settings page, command, API, log, test, trace, runtime state}
- **Expected behavior:** {what should be observed}
- **Key logs/state:** {log tag, property, database row, service state, trace marker}
- **Regression focus:** {adjacent behavior or feature interactions at risk}

## Investigation Log

| Round | Focus | New feature elements | New edges | Layer gaps closed | Remaining gaps |
|-------|-------|----------------------|-----------|-------------------|----------------|
| 1 | architecture skeleton | {n} | {n} | {layers} | {gaps} |
| ... | ... | ... | ... | ... | ... |

**Stop reason:** {six-layer complete / unknowns classified / reached max rounds / partial failure}

## Metadata

- **Package schema:** vendor-feature-meta-slice/v1
- **Generated by:** zaku:aosp-feature-export
- **Historical context:** {whether an existing export was found and used for comparison/deduplication}
- **Scope split:** {not split / split, exported sub-feature: <name>, remaining candidates: <list>}

Keyword Triggers

• "aosp export", "aosp feature export", "feature element export", "feature export", "meta-slice 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
• Partial export path: .granada/aosp-exports/<slug>-partial.md
• Max expansion rounds: 5
• Max successful investigator spawns: 15
• Convergence: six-layer coverage complete, or remaining gaps explicitly classified as unknown/unsupported with no new evidence in a full expansion round

Known Limitations

• Description-only mode: If no concrete vendor modification context is available, the export may identify likely AOSP context rather than confirmed vendor touch points; mark confidence accordingly.
• Runtime evidence availability: logs, traces, and tests may not be present in source search; mark runtime evidence as unknown when unavailable.
• Feature interactions: absence of evidence is not proof of no interaction. If interactions cannot be proven, record the searched edge types and mark the interaction layer unknown.
• Broad-scope split output: split results are candidate lists only and must be rerun with one selected feature for a full meta-slice package.