android-platform-patterns

Guide contributors to reuse existing AniTrend Android platform helper APIs.

51|6|Updated Mar 10, 2019
One-click install
npx skills add https://github.com/AniTrend/anitrend-v2 --skill android-platform-patterns
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: android-platform-patterns
Source: https://github.com/AniTrend/anitrend-v2/tree/main/.agents/skills/android-platform-patterns
Command: npx skills add https://github.com/AniTrend/anitrend-v2 --skill android-platform-patterns

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

It prevents duplicated or inconsistent Android helper logic by guiding contributors to reuse existing platform-layer APIs across the AniTrend app.

Core Features & Use Cases

  • Platform-first helper reuse: Directs you to inspect :android:core, :android:navigation, :android:deeplink, and :app:core before creating new utilities.
  • Clear ownership boundaries: Defines what belongs in platform :android:* modules versus feature-specific modules to avoid tangled abstractions.
  • Decision rules for common touchpoints: Helps you choose the right existing controllers, notification flows, theme/config wiring, router usage, and context/fragment utilities.
  • Real code anchors: Provides canonical files and paths to copy and adapt when a concrete implementation is needed.

Quick Start

Before adding any new Android helper, open the relevant platform module list and confirm whether an existing implementation already covers your configuration, theme, navigation, deeplink, notification, router, or context/fragment use case.

Frequently Asked Questions about android-platform-patterns

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

FAQPage Schema
How do I reuse Android platform helpers instead of duplicating code in feature modules?

To reuse Android platform helpers, inspect existing APIs in core platform modules like :android:core and :android:navigation before implementing new utilities, following defined ownership boundaries to prevent duplicated logic.

What is the correct ownership boundary for Android deep link and navigation utilities?

Deep link utilities belong in the :android:deeplink module, while navigation helpers reside in :android:navigation. Feature modules should consume these platform APIs rather than creating parallel implementations.

When do I need to extend existing Android-side helpers for theme or configuration wiring?

Extend existing Android-side helpers when configuration or theme wiring is required, checking :android:core and :app:core first for existing controllers to avoid tangled abstractions and inconsistent behavior.

Can I implement custom notification permission flows in my Android feature module?

You should not implement custom notification permission flows in feature modules. Check the platform layer for existing notification flow APIs and reuse those controllers to maintain consistent behavior across the app.

What's the best way to handle router contracts and context utilities in Android Kotlin modules?

The best way to handle router contracts and context utilities is to use canonical file anchors provided by the platform modules, adapting existing implementations instead of writing new fragment utilities from scratch.