<oem-or-soc>-<subsystem>-expert

Extend subsystem routing to vendor-specific Android paths within OEM device trees.

40|7|Updated Mar 14, 2026

Search Tags:#android #vendor #skill-template #bsp #path-routing #oem-specific #subsystem-guidance

Ready to run

npx skills add https://github.com/jonaschen/Android-Software --skill oem-or-soc-subsystem-expert

💬 Prompt for ChatGPT / Claude Chat▼

Please help me install this Agent Skill.
Skill: <oem-or-soc>-<subsystem>-expert
Source: https://github.com/jonaschen/Android-Software/tree/main/skills/L3-TEMPLATE
Command: npx skills add https://github.com/jonaschen/Android-Software --skill oem-or-soc-subsystem-expert

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This template skill captures vendor-specific path scope expansion when generic L2 guidance cannot resolve OEM/SoC deviations, preventing agents from hallucinating nonexistent files and forcing them to respect vendor boundaries.

Core Features & Use Cases

Path Scope Documentation: Lists vendor/<oem>/ and device/<oem>/ areas plus parent L2 overrides so the agent knows exactly where OEM code lives.
Escalation Intelligence: Defines when to hand back to the parent L2 skill or reroute to a different OEM target, ensuring consistent subsystem ownership.
Governance and Safety: Enumerates forbidden actions and vendor-specific tool calls to keep advice compliant with BSP constraints and Treble/VNDK boundaries.

Quick Start

Request OEM-specific routing by naming your vendor path and desired subsystem so the skill extends the parent L2 context.

Frequently Asked Questions about <oem-or-soc>-<subsystem>-expert

High-intent search queries and answers about installing and using this skill.

FAQPage Schema

How do I handle OEM-specific Android subsystem routing when generic L2 guidance fails?▼

OEM-specific Android subsystem routing extends generic L2 guidance by targeting vendor paths like vendor/<oem>/ and device/<oem>/ to resolve SoC-specific boot, HAL, and BSP issues. It defines forbidden actions and path scope tables to maintain BSP compliance.

What are the forbidden actions when modifying vendor-specific Android BSP paths?▼

Forbidden actions in vendor-specific Android BSP paths prevent hallucinating nonexistent files and enforce vendor boundaries. The skill enumerates restricted tool calls and actions to keep troubleshooting aligned with parent L2 constraints and Treble/VNDK boundaries.

When do I need to escalate Android SoC-specific boot or HAL issues to the parent L2 skill?▼

You escalate Android SoC-specific boot or HAL issues to the parent L2 skill when troubleshooting exceeds OEM-specific path scopes. The skill defines escalation intelligence rules to reroute targets and ensure consistent subsystem ownership across vendor trees.

Can I use this skill to resolve Treble and VNDK boundary issues in device/<oem>/ trees?▼

Yes, this skill resolves Treble and VNDK boundary issues in device/<oem>/ trees by providing governance rules and vendor-specific tool calls. It ensures OEM-specific troubleshooting remains compliant with BSP constraints and parent L2 overrides.

How do I document vendor path scopes for Android subsystem troubleshooting?▼

You document vendor path scopes for Android subsystem troubleshooting by listing vendor/<oem>/ and device/<oem>/ areas alongside parent L2 overrides. This path scope documentation pinpoints exactly where OEM code lives to prevent boundary violations.

Why does generic Android subsystem guidance fail to resolve SoC-specific BSP deviations?▼

Generic Android subsystem guidance fails to resolve SoC-specific BSP deviations because it lacks vendor path scope expansion. Without targeting vendor/<oem>/ and device/<oem>/ areas, agents hallucinate nonexistent files and violate vendor boundaries.