agentleFS
krutikJainkrutikJain/android-agent-skills/.github/skills/android-navigation-deeplinks/SKILL.md

android-navigation-deeplinks

Skill14 starsChanged 8 months agoMITView on GitHub

Handle navigation graphs, back stack behavior, app links, intents, and destination ownership for Android apps.

The file

We split this skill into the rules it gives an agent

5 rules. About 0 are common, 5 are distinctive, and 0 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈5

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Use this skill when the request is about: android navigation graph, deep link into android app, back stack issue in compose nav.

    line 17
  2. Distinctive:

    Treat loading, empty, error, offline, and permission-denied states as first-class UI states.

    line 31
  3. Distinctive:

    Do not hide navigation or permission side effects inside reusable UI components.

    line 32
  4. Distinctive:

    Prefer lifecycle-aware APIs over manual callback chains.

    line 33
  5. Distinctive:

    Keep deep links, intents, and permission prompts testable and observable.

    line 34

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Android Navigation Deep Links

When To Use

  • Use this skill when the request is about: android navigation graph, deep link into android app, back stack issue in compose nav.
  • Primary outcome: Handle navigation graphs, back stack behavior, app links, intents, and destination ownership for Android apps.
  • Handoff skills when the scope expands:
  • android-permissions-activity-results
  • android-testing-ui

Workflow

  1. Confirm the user-visible journey, target device behavior, and failure states that matter.
  2. Identify the owning screens, activities, destinations, and state holders for the flow.
  3. Implement the flow with explicit loading, success, empty, and error handling.
  4. Validate accessibility, configuration changes, and back-stack behavior in the showcase apps.
  5. Escalate data, architecture, or release concerns to the specialized skills called out in the handoff notes.

Guardrails

  • Treat loading, empty, error, offline, and permission-denied states as first-class UI states.
  • Do not hide navigation or permission side effects inside reusable UI components.
  • Prefer lifecycle-aware APIs over manual callback chains.
  • Keep deep links, intents, and permission prompts testable and observable.

Anti-Patterns

  • Assuming the happy path is enough for product flows.
  • Hard-coding request codes or route strings in multiple places.
  • Triggering navigation directly from repositories or network layers.
  • Shipping flows without recovery UI for denied permissions or broken state.

Remediation Examples

Centralize route ownership

sealed interface OrbitRoute {
    data object Board : OrbitRoute
    data class Task(val taskId: String) : OrbitRoute
}

Preserve expected back-stack behavior

navController.navigate(OrbitRoute.Task(taskId)) {
    launchSingleTop = true
    restoreState = true
}

Parse deep-link arguments in one place

val taskId = intent?.data?.getQueryParameter("taskId")
require(!taskId.isNullOrBlank()) { "Missing taskId deep-link argument" }

Examples

Happy path

  • Scenario: Route the Compose showcase into a task details destination from a deep link.
  • Command: cd examples/orbittasks-compose && ./gradlew :app:testDebugUnitTest

Edge case

  • Scenario: Preserve expected Up and Back behavior when the XML activity is cold-started from a link.
  • Command: cd examples/orbittasks-xml && ./gradlew :app:testDebugUnitTest

Failure recovery

  • Scenario: Prevent confusion with permission, state, and release prompts.
  • Command: python3 scripts/eval_triggers.py --skill android-navigation-deeplinks

Done Checklist

  • The implementation path is explicit, minimal, and tied to the right Android surface.
  • Relevant example commands and benchmark prompts have been exercised or updated.
  • Handoffs to adjacent skills are documented when the request crosses boundaries.
  • Official references cover the chosen pattern and the main migration or troubleshooting path.

Official References

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.