react-native-mobile-hardening
- Repo stars 0
- Author updated Live
- Author repo skills-registry
- Domain
- Engineering
- Compatible agents
-
- Claude Code
- Cursor
- Cline
- Codex
- Windsurf
- Gemini CLI
- +20
- Trust score
- 88 / 100 · community maintained
- Author / version / license
- @tomevault-io · no license declared
- Token usage
- Lean
- Setup complexity
- Guided setup
- External API key
- Not required
- Operating systems
- Unspecified (assume cross-platform)
- Runtime requirements
- No special requirements
- Permissions
-
- Read-only
- Write / modify
- Shell exec
- Network behavior
- Local-only
- Install commands
- 26 variants
Profile is derived at build time from SKILL.md and install vectors. Subject to drift from author intent.
Heads up: 未限定 allowed-tools,默认拥有全部工具权限。
---
name: react-native-mobile-hardening
description: React Native mobile testing, performance, and release hardening for this repo. Use when validati…
category: engineering
runtime: no special runtime
---
# react-native-mobile-hardening output preview
## PART A: Task fit
- Use case: React Native mobile testing, performance, and release hardening for this repo. Use when validating Expo or React Native changes across mobile, iOS, Android, safe area, navigation, gestures, deep links, offline sync, camera, QR, testing, release, preview builds, startup performance, or no-stale-flash regressions. Use when this capability is needed..
- Inputs: target material, constraints, expected output, and acceptance criteria.
- Evidence boundary: follow “When to Use / Focus Areas / Procedure” and do not present inference as author intent.
## PART B: Execution result
- **01** The card summarizes the use case; runtime output centers on “React Native mobile testing, performance, and release hardening for this repo. Use when validating Expo or React Native changes across mobile, iOS, Android, safe area, navigation, gestures, deep links, offline sync, camera, QR, testing, release, preview builds, startup performance, or no-stale-flash regressions. Use when this capability is needed.”.
- **02** When the source has headings, the agent prioritizes “When to Use / Focus Areas / Procedure” so the result follows the author’s structure.
- **03** Typical output includes task judgment, concrete steps, required commands or file edits, validation, and follow-up options.
- **04** Risk context follows the fingerprint: read files, write/modify files, run shell commands; mostly runs locally; usually needs no extra API key.
## Running Rules
- read files, write/modify files, run shell commands; mostly runs locally; usually needs no extra API key.
- Validate with a small sample before expanding scope.
- Return the result, validation criteria, and next iteration options. The source does not require a stable slash command. After installation, invoke the skill by name and describe the task.
Name target files or source material, expected output, forbidden changes, and whether network or shell access is allowed. Permission fingerprint: read files, write/modify files, run shell commands.
Start with a small task and check whether the result follows “When to Use / Focus Areas / Procedure”. Inspect diffs, logs, previews, or tests before expanding scope.
Confirm the final output includes a concrete result, evidence, and next action. If it stays generic, tighten inputs, boundaries, and acceptance criteria.
---
name: react-native-mobile-hardening
description: React Native mobile testing, performance, and release hardening for this repo. Use when validati…
category: engineering
source: tomevault-io/skills-registry
---
# react-native-mobile-hardening
## When to use
- React Native mobile testing, performance, and release hardening for this repo. Use when validating Expo or React Nativ…
- Use it when the task has clear inputs, repeatable steps, and validation criteria.
## What to provide
- Target material, scope, expected result, and forbidden changes.
- Whether network, commands, file writes, or external services are allowed.
## Execution rules
- Organize steps around “When to Use / Focus Areas / Procedure” and keep inference separate from source facts.
- read files, write/modify files, run shell commands; mostly runs locally; usually needs no extra API key.
- Validate with a small sample before expanding the task.
## Output requirements
- Return the deliverable, key evidence, validation method, and next action.
- Mark missing information as unknown; do not invent commands, platforms, or dependencies. The author source anchors workflow facts; repository files anchor sources and commands; Fluxly only adds fit, limitations, and quality judgment.
skill "react-native-mobile-hardening" {
input -> user goal + target files + boundaries + acceptance criteria
context -> When to Use / Focus Areas / Procedure
rules -> SKILL.md triggers / order / output contract
runtime -> no special runtime | read files, write/modify files, run shell commands | mostly runs locally
guardrails -> usually needs no extra API key + small-sample validation + diff/log review
output -> copyable result + checklist + next iteration
} React Native Mobile Hardening
Use this skill when the goal is to test, harden, and de-risk Kanban Lite mobile changes before they surprise users in the field. Small bugs become big bugs once a worker is offline, gloved up, and standing in the rain.
When to Use
Use when the task mentions any of these ideas:
- React Native testing or Expo validation
- mobile regression checks for iOS or Android
- safe area, navigation, gesture, keyboard, or bottom-dock issues
- deep links, QR flows, restore gate, or wrong-workspace/wrong-user recovery
- offline sync, pending resend, conflict review, or stale-cache bugs
- camera, attachment capture, upload states, or QR scanning
- performance, startup time, jank, list scrolling, or render churn
- release hardening, preview builds, EAS profiles, or app identity checks
Focus Areas
Always test these risk areas first:
Protected-content safety
- no stale task flash during restore, reauth, workspace switch, deep links, or QR entry
- cache purge behavior when workspace, subject, or session no longer match
Offline truthfulness
- explicit resend for comments, forms, checklist intents, and attachment drafts
- no silent replay of unsafe server mutations
- clear
Pending,Needs connection, and conflict states
Field-worker ergonomics
- safe area clearance
- large touch targets
- one obvious primary action in the thumb zone
- outdoor-readable contrast and short recovery copy
Cross-platform correctness
- iOS and Android navigation behavior
- deep links and scheme handling
- keyboard overlap, gesture interactions, and back behavior
Procedure
Run the repo-supported validation set first.
pnpm --filter @kanban-lite/mobile run lintpnpm --filter @kanban-lite/mobile run doctorpnpm --filter @kanban-lite/mobile run start -- --offline --clear --port 8088cd packages/mobile && APP_VARIANT=development pnpm exec expo config --jsoncd packages/mobile && APP_VARIANT=preview pnpm exec expo config --json
Walk the highest-risk product flows.
- cold start and restore gate
My WorkandDue- task detail
- deep-link open
- QR open
- account/logout/recovery
Exercise every mutation state, not just the happy path.
- comments: create, edit, delete, pending, resend
- attachments: take photo, scan document, choose file, discard draft, remove synced attachment
- forms: edit, save draft, submit, validation error
- checklist: show, add, edit, delete, check, uncheck, conflict review
- named actions: allowed online, denied, and offline-disabled
Check capability and visibility behavior.
- hidden task means no task UI, not a disabled shell
- denied mutation capability means hidden control, not a teasing disabled button
- allowed-but-offline means either explicit local draft or a clear disabled state
Profile the mobile experience for friction.
- look for unnecessary re-renders, long list jank, layout jumps, and oversized media work
- verify the sticky action dock does not fight the keyboard or safe area
- check that loading and sync states are calm instead of noisy or duplicated
- prefer simple, stable interactions before adding fancy transitions
Re-check release and app identity assumptions.
app.config.tsandeas.jsonmust agree on variant handling- preview and development identifiers should remain coexistence-safe
- release changes should not assume production readiness beyond the current staged contract
Document any failure by class, not just by symptom.
- safety issue: stale flash, wrong-workspace content, auth leakage
- offline issue: pending state lies, silent replay, missing resend review
- platform issue: iOS only, Android only, keyboard/gesture/back behavior
- performance issue: slow startup, scroll jank, heavy image flow, repeated renders
Hardening Checklist
Use this quick pass before calling a change done:
- restore gate never shows protected content too early
- deep links and QR routes validate workspace and session before task detail mounts
- safe area and bottom action dock work on iOS and Android
- offline sync states are explicit and truthful
- camera and attachment flows preserve durable local drafts when needed
- checklist, forms, comments, and actions respect capability gates
- preview/development config still resolves cleanly from Expo config
Avoid
Avoid these release-footguns:
- treating lint success as sufficient mobile validation
- testing only online happy paths
- assuming browser auth behavior maps directly to Expo
- hiding a denial or mismatch bug behind cached content
- queuing destructive offline actions without explicit user review
- changing release profiles without re-checking variant-specific identifiers
Done When
The mobile change is hardened when:
- correctness, offline behavior, and protected-content safety were all exercised
- iOS and Android interaction details were checked intentionally
- performance regressions were considered, not merely hoped away
- Expo validation and variant config still align with the repo contract
- release confidence comes from verified flows, not vibes
Source: borgius/kanban-lite — distributed by TomeVault.
Decide Fit First
Design Intent
How To Use It
Boundaries And Review