appscreenmap
CLAUDE.md2 starsChanged 16 days agoMITView on GitHub
Open-source (MIT) tool that crawls a mobile app on an emulator and maps every screen and transition. The design and roadmap are in docs/PLAN.md; the data contract is in docs/MAP_SCHEMA.md. - A monorepo: apps/ (what people run) + packages/ (building blocks); layout in docs/ARCHITECTURE.md. Two workspaces: uv for Python (pyproject.toml), Bun for TypeScript (package.json: the viewer, packages/design-tokens, and packages/security as @appscreenmap/security-rules). make setup. - Python is a uv workspace (the root pyproject.toml is virtual). Everything imports as appscreenmap.* (a namespace…
In this repository22 other files it gives its agents.
- a11y-auditSkill
- adaptiveSkill
- add-a11y-ruleSkill
- add-exporterSkill
- android-intent-securitySkill
- android-permissions-securitySkill
- crawl-appSkill
- design-systemSkill
- edge-to-edgeSkill
- extend-crawlerSkill
- ios-a11y-rulesSkill
- ios-simulatorSkill
- maintain-crawlerSkill
- play-policy-insightsSkill
- security-auditSkill
- security-rulesSkill
- stack-iosSkill
- stack-rulesSkill
- store-requirementsSkill
- tune-crawlerSkill
- wcag-mobile-rulesSkill
- web-uiSkill
The file
We split this CLAUDE.md into the rules it gives an agent
3 rules. About 0 are common, 1 is distinctive, and 2 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈1
Distinctive · estimate
This author's own choices. Worth a look.
2
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 51
Test against the Playground (known answers), not stock apps.
- Very specific: line 57
Every exploration fix gets a synthetic regression test (packages/crawler/tests/, or packages/core/tests/ for screen identity) before …
- Distinctive: line 72
No git tags or releases until asked.
≈ “Common” is an estimate: at least 1 in 5 of the 26,980 CLAUDE.md 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.
Files
AppScreenMap
Open-source (MIT) tool that crawls a mobile app on an emulator and maps every screen and
transition. The design and roadmap are in docs/PLAN.md; the data contract is in docs/MAP_SCHEMA.md.
Layout
- A monorepo:
apps/(what people run) +packages/(building blocks); layout indocs/ARCHITECTURE.md. Two workspaces: uv for Python (pyproject.toml), Bun for TypeScript (package.json: the viewer,packages/design-tokens, andpackages/securityas@appscreenmap/security-rules).make setup. - Python is a uv workspace (the root
pyproject.tomlis virtual). Everything imports asappscreenmap.*(a namespace package: never addsrc/appscreenmap/__init__.py). A package imports only what itspyproject.tomldepends on (packages/testkit/tests/test_layers.pychecks).packages/core/:appscreenmap.core: map.json model, analyzer, config, runs, notes, media, manual (screens filed by hand), merge, accounts, activity log (appscreenmap logs), timeline; imports nothing elsepackages/drivers/: Android (adb, dumpsys, device facts, apkinfo, logcat) and iOS Simulator; stdlib onlypackages/crawler/: explorer, replay, load timingpackages/a11y/: WCAG checks (checks.py), criteria (wcag.py), HTML/MD reportpackages/security/: all security tooling (scanner modules,rules.jsoncatalogue also read by the viewer,hooks/frida-observe.js,hooks/mitm_observe.py+network.pyforcrawl --network); stdlib only. The mitmproxy addon runs in mitmproxy's own Python: never import appscreenmap or mitmproxy at its top levelpackages/stack/: what an installed app is built with (dumpsys package+ the APKs pulled from the emulator: framework, SDK levels, ABIs, 16 KB alignment, libraries, storage map; on iOS the simulator's.app: Info.plist, Mach-O, frameworks) →audits/stack.json, build kept in<canvas>/build/;libchecker.jsonis a LibChecker-Rules snapshot (make stack-rules-sync)packages/store/: store readiness (target / compile / min SDK vs Play and App Store rules, 365 days ahead;requirements.json)packages/reports/: health report, perf summary ·packages/regression/: verify, visual diff ·packages/exporters/: Maestro, Mermaidpackages/testkit/: dev-only test helpers (appscreenmap.testkit.helpers: synthetic hierarchies,REPO;appscreenmap.testkit.fakedevice: a scriptable fake app/driver)apps/engine/:appscreenmap.engine: the CLI (engine/cli/, one module per command group;screens.py:add-screen/edit-screen;watch.pyandrecord.py: use the app by hand, log/traffic or a Maestro flow) and the MCP server (engine/mcp_server.py), on top of every package- tests live next to their code (
<package>/tests/), on synthetic hierarchies; no device needed
apps/cli/: theappscreenmapbinary (Bun + Ink): terminal home that runs the dashboard (the engine'sserve), hands every other command to the engine;setup,update,paths,clean. macOS first.make cli,make cli-check,make release-local(a release folder to test install.sh/setup/update against; never publish without being asked).apps/viewer/: React viewer, owned by a separate session. Don't edit it from crawler work. It imports the tokens and the security rules as workspace packages, never by relative path.packages/design-tokens/tokens.css: the single source of colour, type, space and motion (Ghost dark × Xcode blue, Geist), for the viewer and the HTML reports. Change it only through thedesign-systemskill.samples/: the end-to-end playground,playground-app/(purpose-built Compose app, v1/v2 APKs + source, every screen = a scenario; a SwiftUI iOS version is planned).samples/demo.shruns every scenario. No real third-party or personal app lives in the repo: real-app testing happens locally, outside it.runs/<project>/<run-id>/: crawl output, git-ignored (generated locally;samples/demo.shmakes sample ones). Run ids are flat and unique;appscreenmap serveresolves/runs/<run-id>/…to the project folder.
Rules
map.jsonis the contract withapps/viewer/. Within schema 1, only add fields; never rename or remove them. Updatedocs/MAP_SCHEMA.mdin the same change.- Test against the Playground (known answers), not stock apps; real apps are tested locally, outside the repo. Use
--clear-datato map the first-run state. When a feature needs a new scenario, add a screen to the Playground (mark deliberate bugsA11Y BUG (WCAG x.y.z)), rebuild withsamples/playground-app/build.sh, and list it insamples/README.md. - The crawl must stay inside the target app (
stay_in_app, lock task pinning). Never ship a change that presses BACK or opens other apps to recover. - Every exploration fix gets a synthetic regression test (
packages/crawler/tests/, orpackages/core/tests/for screen identity) before re-crawling. - One canvas per app, by default. Every crawl or re-run of an app ends in that app's one canvas: crawl, then
appscreenmap merge --into <canvas> <run> --labels "<flow>" --moveadds it as a scenario in place (same id and folder; notes, comments and tree edits kept) and removes the run's own folder, so no extra run is left behind. The app's first run becomes its canvas. Start a separate run or a new canvas only when the developer asks for one. Ask before--clear-data(it logs the emulator out) and before deleting a canvas. - One finalised sign-up flow per app and path (
runs/<project>/maestro/<path>.yaml): fix that file and overwrite it, never copy its steps into a TOML playbook or keep-v2copies. NeverhideKeyboardon Android (it presses Back); a new account email every run. - English by default in every tree. For an app that shows another language, every screen title and every link label
on the canvas is English: crawled screens get English display titles in the canvas's
titles.json(the crawler's ownmap.jsontitle stays), manual screens and links are filed with English titles and--vialabels, and a link labelled with a raw element id gets a readable name. Do this in the same pass as the capture, not when asked. The app's own text (screenshots, hierarchy) stays as the app shows it, and the app's language is never changed. - No git tags or releases until asked.
Commands
uv sync && uv run pytest -q && uv run ruff check && uv run ruff format
make test-fast # about 10 s: skips the `slow` tests (the fake app through the crawler); the full suite above is for before a push
uv run appscreenmap-engine doctor
APP_PASSWORD=playground-demo uv run appscreenmap-engine crawl --apk samples/playground-app/apk/playground-v1.apk \
--config samples/playground-app/appscreenmap.toml --clear-data --max-steps 200
uv run appscreenmap-engine report runs/playground/<run-id> # health: wasted steps, identity issues, nav failures
uv run appscreenmap-engine perf runs/playground/<run-id> # load time per screen, jank, cold startSkills (.claude/skills/)
design-system: the token system (packages/design-tokens/tokens.css), its rules and decisions, and the contrast checkios-simulator: set up, run and debug an iOS Simulator crawl (build for the simulator, simctl + idb, diagnosing a bad crawl)security-audit: runappscreenmap securityon an Android build (manifest, secrets, data at rest, Frida log) and judge the resultstore-requirements: refresh the dated Play / App Store rules inpackages/store/.../requirements.json(each spring, after announcements)stack-rules: keep the app stack scan's rules current (packages/stack: framework fingerprints, storage map, the LibChecker snapshot viamake stack-rules-sync), calibrate from real builds locallystack-ios: build and debug the iOS stack scan on the simulator (Mach-O, bundle markers, KMP / Compose, data container, Frida spike)play-policy-insights,android-permissions-security,android-intent-security,edge-to-edge,adaptive: unchanged copies from github.com/android/skills (Apache-2.0;make skills-sync) for audits and scans;audit-xcode-security-settings,uikit-app-modernization: Apple's, synced from Xcode 27 (make skills-xcode, git-ignored, no license). Audit/scan skills only, no development skills; excluded from ruffsecurity-rules: the security rule catalogue (packages/security/.../rules.json): ids, severities, fixes, official sourcesios-a11y-rules: iOS accessibility (VoiceOver, Dynamic Type, HIG 44 pt) mapped to WCAG, what is detected and the Swift fixweb-ui: viewer UI work inapps/viewer/(owned by the web session); followsdesign-systemcrawl-app: run a crawl and review the resulttune-crawler: turn a bad crawl into a test and a fix (screen identity, wasted taps, routing)extend-crawler: add features (drivers, exports, patterns, config, schema fields, CLI)maintain-crawler: dependency/Android upgrades, compatibility checks, schema migrationswcag-mobile-rules: WCAG 2.2 → Android reference (thresholds, what's new, who checks what)a11y-audit: full WCAG 2.2 audit (automated + 200% font crawl + device tests + manual + triage + report)add-a11y-rule: add or fix an automated a11y check (crawlera11y/checks.py; viewer rules belong to the web session)add-exporter: generate tests for an E2E tool (Maestro, Appium, Espresso, …) and build the pluggable exporter interface
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
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.

