modelscope.cn

cook-mobile

Workflow orchestration for mobile projects (React Native, Expo, iOS, Android). Structured phases — Plan, Design, Code, Review, Test — with memory-bank integration for session continuity.

Installation

$ npx skills add https://modelscope.cn

Similar popular skills

Related neighbors and high-traction skills in the same topics — useful to compare before installing.

Also in this package

Other skills from modelscope.cn · top by installs.

npx skills add https://modelscope.cn

Browse all from modelscope.cn

More details

Agent compatibility

Declared targets from SKILL.md / docs. Unmarked agents are not listed — the skill may still install via the CLI.

Claude Code Not declared
Cursor Not declared
Codex Not declared
GitHub Copilot Not declared
Windsurf Not declared
Gemini CLI Not declared
Cline Not declared
OpenCode Not declared

Package contents

Files included with this skill beyond the listing page.

  • skill md SKILL.md 3,713 B

History

  1. First recorded snapshot · 0 installs

SKILL.md

Cook — Mobile Workflow

Structured workflow for mobile projects. Every non-trivial task flows through ordered phases.

Plan → Design → Code → Review → Test

Memory Bank — Required for Every Session

At the start of EVERY session, read all files in memory-bank/:

  1. projectbrief.md — Core requirements and goals
  2. productContext.md — Problem and solution context
  3. techContext.md — Technical setup and dependencies
  4. systemPatterns.md — Architecture and design patterns
  5. activeContext.md — Current work focus and recent changes
  6. progress.md — Completed work and known issues

If memory-bank/ does not exist, create it with the files above based on what you learn from the codebase.

After completing work (end of Test phase or any stopping point), update:

  • activeContext.md — What was done, current state, next steps
  • progress.md — Mark completed items, add new known issues

This ensures continuity across sessions. Never skip this step.


[PLAN] Plan

  1. Read requirements. Ask if ambiguous.
  2. Identify affected screens, navigation, and native modules.
  3. Break into subtasks. Define acceptance criteria for both iOS and Android.
  4. Identify platform-specific behavior needed.

Output: Numbered plan with affected screens and acceptance criteria. Rule: No code in this phase.

[DESIGN] Design

  1. Define screen components and navigation flow.
  2. Plan gestures, animations, and platform-specific UI.
  3. Identify shared vs platform-specific code.

Output: Screen hierarchy, navigation map, and platform-specific decisions. Rule: Match existing component patterns. Follow platform conventions.

[CODE] Code

  1. Build shared components first, then platform-specific code.
  2. Handle offline state, slow networks, and permission prompts.
  3. Use platform-specific patterns where needed (SafeAreaView, StatusBar, etc.).
  4. Test on both platforms during development.

Rules:

  • Match existing component patterns and naming conventions.
  • Handle both iOS and Android edge cases.

[REVIEW] Review

  1. Cross-platform — Works on both iOS and Android? Platform-specific edge cases handled?
  2. Performance — No JS thread blocking? FlatList/FlashList for long lists? Memoization where needed?
  3. UX — Proper keyboard avoidance? Touch targets >=44pt? Loading indicators?
  4. Permissions — Camera, location, notifications handled gracefully with denial fallbacks?
  5. Types — Props typed correctly? No any?

Fix issues immediately. If layout/design is wrong, loop back to Design.

[TEST] Test

  1. Component tests — Test screen components and interactions.
  2. Platform test — Run on iOS simulator and Android emulator.
  3. Run full test suite and type checker.

Rule: Test user behavior across both platforms, not implementation details.


Iteration

If any phase reveals problems:

  • Test failures from a bug → Fix in Code, re-run Review + Test.
  • Review reveals missing requirements → Loop back to Plan.
  • Design flaw found during Code → Loop back to Design.
  • User feedback changes scope → Restart from Plan.

Always note which phase you're returning to and why.

Phase Markers

Prefix progress with the current phase:

[PLAN] Analyzing requirements...
[DESIGN] Defining screen flow...
[CODE] Implementing components...
[REVIEW] Self-reviewing changes...
[TEST] Running on simulators...