agentsclimarketplace
Sign in

Mobile performance

Skill ahtishamshahzad/agent_dev_flow/.ai/skills/mobile/mobile-performance

Use to plan and diagnose mobile performance — list rendering, re-renders, image/memory usage, startup, and jank — measured on a representative build. Prefer measured, safe fixes over rewrites. The mobile arm of performance-review.From its SKILL.md

Install
npx -y skills add ahtishamshahzad/agent_dev_flow --skill mobile-performance

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

  • 24 days oldThe repository was created 24 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.

SKILL.md

3.4 KB, 692 tokens by cl100k_base, as published. Nobody here has run it

Mobile Performance

Purpose

Plan and diagnose mobile performance: locate the real bottleneck (lists, re-renders, images/memory, startup, jank) via measurement and plan safe, behavior-preserving fixes on a representative build.

When to Use

  • When a screen/list is janky, slow to start, or memory-heavy.
  • Before a performance-motivated refactor.
  • Not as blanket optimization without a measured bottleneck.

Inputs

  • The slow scenario (screen, action, platform, build).
  • Profiling data or a plan to obtain it.

Discovery Questions

  • What is slow, under what action/scale, on which platform?
  • Debug or release/production-like build?
  • Is there a measurement, or must one be taken?
  • Low-end device behavior?

Responsibilities

  • Locate the bottleneck: list rendering (FlatList config, keys, memoized rows), re-renders, image/memory pressure, startup, or animation jank.
  • Plan safe, targeted fixes preserving behavior.
  • Validate on a representative build; capture before/after.
  • Escalate structural fixes to ../../refactor-planning.

Required Workflow

  1. Reproduce + measure on a representative build.
  2. Trace the bottleneck to specific code.
  3. Plan minimal behavior-preserving fixes.
  4. Re-measure; capture before/after.
  5. Record findings + residual risks.

Decision Rules

  • No optimization without a measured bottleneck.
  • Prefer small measurable wins over rewrites.
  • Judge from release-like conditions, not debug.
  • Don't add heavy libraries (e.g. list libs) without measured justification.

Rules

  • Preserve behavior; performance work is not a feature change.
  • Measure before/after; quote numbers.
  • Flag unrun measurements 'unverified until run'.

Anti-Patterns

  • Premature memoization / blind micro-optimization.
  • Judging performance from a debug build.
  • Rewriting instead of fixing the measured hotspot.
  • Adding a list/image library without data.

Validation Checklist

  • Scenario reproduced + measured (representative build).
  • Bottleneck traced to code.
  • Fixes minimal + behavior-preserving.
  • Re-measured; before/after captured.
  • Residual risks noted.

Definition of Done

A recorded mobile-performance report: measured bottleneck, safe fix plan (or applied fixes), before/after numbers from a representative build, and residual risks — aligned with ../../performance-review.

Related Skills

../../performance-review, ../../refactor-planning, mobile-state-management, mobile-vector-icons, mobile-camera-media, mobile-unit-testing

Related Knowledge

../../../knowledge/ (hot paths).

Related References

../../../references/mobile/screens/, ../../../references/mobile/state/ when populated.

Context Loading Guidance

  • Requires: the slow scenario, measurement (or plan), the hot-path code.
  • Does not require: unrelated screens, the full mobile skill set, unrelated references.
  • May load: ../../refactor-planning if the fix is structural.
  • Stop when: before/after is recorded (or measurement flagged unrun).

Token Efficiency Guidance

Read only the measured hot path; quote decisive metrics rather than full profiler dumps.

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.

Gives 0 of the 12 instructions most performance cost skills give in 692 tokens

Counted across 803 of the 1,058 authors here whose files we hold, read 2026-08-07

  • Keep skill files under 500 lines or tokensin 82 of 803, across 16 files
  • Use imperative form in instructionsin 80 of 803, across 9 files
  • Draft assertions while test runs are in progressin 75 of 803, across 9 files
  • Create two to three realistic test promptsin 74 of 803, across 9 files
  • Write skill descriptions to be pushyin 72 of 803, across 7 files
  • Save test cases to evals JSONin 72 of 803, across 6 files
  • Ask questions about edge cases and input formatsin 72 of 803, across 7 files
  • Save timing data immediately when runs completein 70 of 803, across 5 files
  • Include all trigger conditions in the skill descriptionin 69 of 803, across 3 files
  • Launch all test runs in a single turn or simultaneouslyin 69 of 803, across 3 files
  • Capture intent before writing a skillin 67 of 803, across 1 file
  • Import directly instead of barrel filesin 52 of 803, across 15 files

Said here and by no other author read

  • measure on a representative build
  • trace bottleneck to specific code
  • plan minimal behavior-preserving fixes
  • quote decisive metrics
  • record findings and residual risks
  • escalate structural fixes

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.

Keep looking

Skills are one crate of 326,851. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.