Deep links

Skill linkrunner-labs/skills/skills/troubleshoot/deep-links

Installable Agent Skills for integrating the Linkrunner SDK and deep linking, for AI coding agents (Claude Code, Cursor, Windsurf, Copilot)

Install

npx -y skills add linkrunner-labs/skills --skill deep-links

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

16 days oldThe repository was created 16 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Diagnose why Linkrunner deep links (iOS Universal Links / Android App Links) open the browser instead of the app, or do not open the app at all. Runs the full verification gauntlet - hosted apple-app-site-association and assetlinks.json, Apple CDN freshness, Android fingerprint + verification state, associated-domains entitlement, manifest intent filters - and reports exactly what is broken and how to fix it. Use when someone says a Linkrunner link opens Safari/Chrome, App Links will not verify, or a universal link is ignored.

SKILL.md

3.8 KB, 785 tokens by cl100k_base, as published. Nobody here has run it

Linkrunner - deep link troubleshooter

The symptom is almost always: an HTTPS link opens the browser instead of the app. That means domain verification is failing somewhere between the hosted file, Apple/Google's cache, the app's native config, and the device. Diagnose in order - do not guess.

0. Gather the facts first

Ask for / detect these before running anything:

The domain the links use (e.g. app.example.com).
Android package name (from applicationId in android/app/build.gradle or the manifest).
iOS appID = TEAM_ID.BUNDLE_ID (Team ID from Apple Developer → Membership; bundle id from Xcode).
Which build is on the device (debug vs release - they are signed with different keystores and have different fingerprints).
Whether the user is testing by typing the URL into Safari - that never opens the app on iOS; it must be tapped from another app (e.g. Notes). Rule this out first.

1. Run the diagnostic

From the app project root:

bash scripts/diagnose-deep-links.sh <domain> <android_package> <ios_team_id.bundle_id>

It checks the hosted files, Apple's CDN, the Google Digital Asset Links API, the local native wiring, and - if a device is connected over adb - the live Android verification state. Read its output, then use the references below to fix whatever it flags.

2. Interpret and fix

What you see	Go to
assetlinks 404, fingerprint mismatch, `1024`/`legacy_failure`, works on debug not release	`references/android.md`
AASA 404/stale, CDN serving old file, link opens Safari	`references/ios.md`
Both platforms	do both

3. The usual root causes (in frequency order)

Android fingerprint mismatch - the SHA-256 in assetlinks.json is not the keystore that signed the build on the device. Debug and release differ; Play App Signing uses the Play Console fingerprint, not your local keystore.
Cached verification - the hosted file is now correct but the device/OS still holds the old result. Android needs an explicit re-verify; iOS needs the Apple CDN to refresh (up to a day) or developer mode.
File not hosted - not saved in dashboard → Project Settings → Domain Verification, so the .well-known/ URL 404s.
Native config missing - no android:autoVerify="true" intent filter for the host, or the Associated Domains capability / applinks: entry absent.
Testing wrong - typing a universal link into Safari (never works).

4. Confirm the fix

Re-run the diagnostic, then test for real:

# Android
adb shell am start -a android.intent.action.VIEW -d "https://<domain>/path" <android_package>
# iOS simulator
xcrun simctl openurl booted "https://<domain>/path"

On iOS, tap a link from Notes (not Safari). Report which checks pass and which dashboard/native step the user still needs to complete.

References

references/android.md - App Links verification: fingerprints, adb pm states, re-verify, force-approve
references/ios.md - Universal Links verification: AASA, Apple CDN, developer mode, swcd logs

Gives 0 of the 12 instructions most quality gates skills give in 785 tokens

Counted across 1,195 of the 2,094 authors here whose files we hold, read 2026-08-06

read the output and check the exit codein 55 of 1195, across 14 files
verify requirements using a line-by-line checklistin 53 of 1195, across 12 files
identify the verification command proving the claimin 53 of 1195, across 12 files
run the full verification commandin 51 of 1195, across 11 files
verify output confirms the claimin 49 of 1195, across 10 files
check version control diff after agent delegationin 45 of 1195, across 5 files
state claim with evidencein 43 of 1195, across 3 files
run the test suitein 32 of 1195, across 24 files
keep state in memory by defaultin 27 of 1195, across 6 files
make prototype runnable with one commandin 26 of 1195, across 5 files
detect the package manager from lockfilesin 24 of 1195, across 5 files
produce a verification reportin 23 of 1195, across 12 files

Said here and by no other author read

gather domain package and build facts first
rule out typing urls into safari
run the deep links diagnostic script
use reference docs to fix flagged issues
fix android fingerprint mismatches
clear cached verification states on devices

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.