mobile-ai-agents 1.0.23

package/workflows/appforge-workflow.md

@@ -0,0 +1,232 @@
+# Workflow — APPFORGE Idea to Store
+
+**Type:** Idea to production launch  
+**Agents Used:** APPFORGE, AXIOM / SWIFT / DART / BRIDGE, SENTINEL, PERF, LAUNCHPAD, PIPELINE, SCRIBE, Mobile Memory
+**Skills Used:** /grill-mobile, /feature-slice, /perf-audit, /accessibility-audit, /release-prep, /store-listing, /mobile-memory-save
+
+---
+
+## When to Use
+
+Use APPFORGE when a developer has a rough mobile app idea and needs a disciplined path to a small, shippable MVP prepared for Play Store launch.
+
+Supported platforms:
+
+- Android
+- iOS
+- Flutter
+- React Native
+
+---
+
+## Stage Gate Loop
+
+```text
+Idea
+  ↓
+Stage 1: Discovery
+  ↓ approve discovery
+Stage 2: PRD.md
+  ↓ approve PRD
+Stage 3: Design Plan
+  ↓ approve design
+Stage 4: TASKS.md + DEPENDENCIES.md + ROADMAP.md
+  ↓ approve tasks
+Stage 5: Implement one subtask
+  ↓ acceptance criteria pass
+Stage 6: UI Match Review
+  ↓ feature passes
+Stage 7: Full QA
+  ↓ launch readiness accepted
+Stage 8: Play Store Preparation
+```
+
+APPFORGE must not skip a gate. If a gate is not approved, revise the current artifact instead of moving forward.
+
+---
+
+## Stage 1 — App Idea Discovery
+
+Ask:
+
+1. What app idea do you have?
+2. Which platform are you building for?
+3. Are you building solo or with a team?
+4. What is your target launch date?
+5. Do you want AI features, ads, subscription, or one-time purchase?
+6. Do you already have designs or should we create wireframes from scratch?
+7. What design direction should the app use? Examples: clean utility, polished consumer, playful gamified, premium wellness, dense dashboard, enterprise/admin, kids/education, game-like, or custom reference.
+8. Which tech stack do you want to use?
+
+Then produce five refined ideas, the best recommendation, target audience, problem statement, value proposition, monetization, and MVP scope.
+
+---
+
+## Stage 2 — PRD Creation
+
+Create `PRD.md` with:
+
+- Product overview
+- Target audience
+- User personas
+- Core features
+- User flows
+- Functional requirements
+- Non-functional requirements
+- Monetization
+- Analytics events
+- Edge cases
+- Risks
+- MVP vs future features
+
+---
+
+## Stage 3 — Free Design Plan
+
+Use free or low-cost tools:
+
+- Pencil Project
+- Figma free plan
+- Penpot
+- Excalidraw
+- Canva free
+- Hand-drawn wireframes
+
+Create screen list, wireframe descriptions, design system, colors, typography, components, empty/loading/error states, and screenshot plan.
+
+Before generating the design plan, ask or infer design direction:
+
+- Clean utility
+- Polished consumer
+- Playful gamified
+- Premium wellness
+- Dense dashboard
+- Enterprise/admin
+- Kids/education
+- Game-like
+- Custom reference
+
+The design plan must state the chosen direction, target emotion, first-screen goal, visual hierarchy, and why the style fits the audience. For demo-grade work, do not default to plain stock UI unless the user chooses clean utility.
+
+---
+
+## Stage 4 — Task Breakdown
+
+Create:
+
+- `TASKS.md`
+- `DEPENDENCIES.md`
+- `ROADMAP.md`
+
+Each task must include title, goal, dependencies, likely files, acceptance criteria, QA checklist, estimated complexity, and implementation notes.
+
+Add `/prd-verification` as the required post-implementation gate for every task. It must compare the implementation, tests, screenshots, and Mobile MCP evidence against `PRD.md`, `DESIGN.md`, and `TASKS.md` before APPFORGE marks a task complete.
+
+---
+
+## Stage 5 — Implementation Loop
+
+For each subtask:
+
+1. Read `PRD.md`.
+2. Read the design plan.
+3. Read `DEPENDENCIES.md`.
+4. Implement only the current subtask.
+5. Do not modify unrelated files.
+6. Explain changed files.
+7. Confirm acceptance criteria.
+8. Compare output with design.
+9. Run tests if available.
+10. Run `/prd-verification` with PRD/design/tasks, changed files, tests, screenshots, and QA reports.
+11. Mark task complete only when it matches PRD and design.
+
+Use the platform reviewer after implementation:
+
+- Android: AXIOM
+- iOS: SWIFT
+- Flutter: DART
+- React Native: BRIDGE
+
+---
+
+## Stage 6 — UI Match Review
+
+Check:
+
+- Layout
+- Spacing
+- Typography
+- Colors
+- Components
+- Responsiveness
+- Empty states
+- Loading states
+- Error states
+- Accessibility
+
+Output match percentage, differences found, fix recommendations, and priority list.
+
+---
+
+## Stage 7 — Full QA
+
+Test:
+
+- Authentication
+- Main flows
+- Edge cases
+- Offline behavior
+- API errors
+- App restart
+- Rotation
+- Performance
+- Crash risks
+- Memory leaks
+- Accessibility
+- Analytics events
+
+Output:
+
+- `QA_REPORT.md`
+- Bug list
+- Fix priority
+- Launch readiness score
+
+Mobile MCP integration belongs here when device automation is available. Use it for emulator/simulator or real-device screenshots, UI element inspection, taps, text input, app launch, app install, and repeated QA flows.
+
+---
+
+## Stage 8 — Play Store Preparation
+
+Use LAUNCHPAD and `/store-listing` to create:
+
+- `PLAYSTORE_LISTING.md`
+- `SCREENSHOT_PLAN.md`
+- `RELEASE_CHECKLIST.md`
+
+Include app names, short description, full description, keywords, screenshot captions, feature graphic brief, app icon brief, privacy policy checklist, data safety checklist, release notes, and testing instructions.
+
+---
+
+## Outputs
+
+| Stage | Artifact |
+|---|---|
+| Discovery | Refined idea set + recommended MVP |
+| PRD | `PRD.md` |
+| Design | Free design plan + screenshot plan |
+| Tasks | `TASKS.md`, `DEPENDENCIES.md`, `ROADMAP.md` |
+| Implementation | Per-task implementation summaries |
+| UI Review | Match percentage + fix list |
+| QA | `QA_REPORT.md` |
+| Store | `PLAYSTORE_LISTING.md`, `SCREENSHOT_PLAN.md`, `RELEASE_CHECKLIST.md` |
+
+---
+
+## Operating Rules
+
+- Keep MVP small enough to ship.
+- Ask questions when requirements are unclear.
+- Preserve context with `/mobile-memory-save` after every approved stage.
+- Do not implement code until the PRD, design, and task breakdown are approved.
+- Do not mark a task complete until acceptance criteria and design match are verified.

package/workflows/ci-setup.md

@@ -0,0 +1,77 @@
+# Workflow — CI Setup
+
+**Type:** DevOps / Automation
+**Agents Used:** PIPELINE
+**Skills Used:** /release-prep
+
+---
+
+## When to Use
+
+Setting up CI/CD for a new project, or fixing a broken pipeline from scratch.
+
+---
+
+## Steps
+
+```
+1. AUDIT (if existing CI)
+   ↓ Paste current CI config to PIPELINE for audit.
+   ↓ Identify: what's missing, what's slow, what's broken.
+
+2. GENERATE — PIPELINE
+   ↓ Provide project context:
+     PLATFORM: Android | iOS | Flutter | React Native
+     CI_TOOL: GitHub Actions | Bitrise | Fastlane
+     DEPLOY_TARGET: Firebase App Distribution | TestFlight | Play Store | App Store
+     BRANCH_STRATEGY: trunk | gitflow
+   ↓ PIPELINE generates complete, copy-paste-ready config files.
+
+3. CONFIGURE SECRETS
+   ↓ Follow the "Secrets to Configure" section from PIPELINE output.
+   ↓ Add keystore/certificates, Firebase token, store credentials to CI secrets.
+
+4. TEST THE PIPELINE
+   ↓ Open a test PR → verify pr-check workflow runs and passes.
+   ↓ Merge to main → verify deploy workflow runs and uploads artifact.
+
+5. ADD REPORTING
+   ↓ Test results uploaded as CI artifacts.
+   ↓ Lint results uploaded as CI artifacts.
+   ↓ Slack/Teams notification on failure (optional).
+
+6. DOCUMENT
+   ↓ Add CI setup notes to README or docs/ci-setup.md.
+   ↓ Document how to add a new deployment target.
+```
+
+---
+
+## Pipeline Architecture Target
+
+```
+On PR:
+  └── Lint + unit tests → fast feedback (< 5 min target)
+
+On merge to main:
+  └── Full build + integration tests + deploy to internal track
+
+On tag (vX.Y.Z):
+  └── Release build → sign → upload to store
+```
+
+---
+
+## Inputs
+
+- Platform and CI tool preference
+- Deployment targets (Firebase / TestFlight / stores)
+- Signing credentials (or intent to set up)
+
+---
+
+## Outputs
+
+- Complete `.github/workflows/` or `Bitrise.yml` or `Fastfile`
+- Secrets configuration checklist
+- Running pipeline on first PR

package/workflows/crash-to-fix.md

@@ -0,0 +1,71 @@
+# Workflow — Crash to Fix
+
+**Type:** Incident response
+**Agents Used:** CRASHER, AXIOM / SWIFT / DART / BRIDGE, PIPELINE
+**Skills Used:** /crash-triage, /android-tdd or /ios-tdd
+
+---
+
+## When to Use
+
+When a crash alert fires in Firebase Crashlytics, Sentry, or Bugsnag.
+
+---
+
+## Steps
+
+```
+1. TRIAGE — /crash-triage
+   ↓ Paste the stacktrace immediately.
+   ↓ Classify: P0 (all users) / P1 (significant %) / P2 (edge case).
+   ↓ P0: wake the on-call engineer. P2: file a ticket for next sprint.
+
+2. INVESTIGATE — CRASHER
+   ↓ Deep dive: root cause, failure path, reproduction conditions.
+   ↓ Determine reproduction rate and affected versions.
+
+3. FIX — AXIOM / SWIFT / DART / BRIDGE (platform-specific)
+   ↓ Implement the concrete fix from CRASHER's recommendation.
+   ↓ Do not refactor surrounding code — fix only what caused the crash.
+
+4. REGRESSION TEST — /android-tdd or /ios-tdd or /flutter-tdd
+   ↓ Write the test that would have caught this crash.
+   ↓ The test must fail on the unfixed code and pass after the fix.
+
+5. DEPLOY — PIPELINE (if P0/P1)
+   ↓ Hot-patch via OTA update (React Native / Flutter) if available.
+   ↓ Otherwise: expedited build → internal test → staged rollout.
+
+6. MONITOR
+   ↓ Watch crash rate for 24 hours post-deploy.
+   ↓ Confirm crash-free rate returns to baseline.
+```
+
+---
+
+## P0 Decision Tree
+
+```
+Crash rate > 1%?
+├── YES → Wake on-call. Deploy hotfix within 2 hours.
+│         If OTA possible (RN/Flutter): deploy in 15 minutes.
+└── NO → Is it on a critical flow (login, payment, checkout)?
+          ├── YES → P1. Fix in current sprint. Staged rollout.
+          └── NO → P2. File ticket. Fix in next sprint.
+```
+
+---
+
+## Inputs
+
+- Full stacktrace from crash monitoring tool
+- Reproduction rate and affected version range
+- Recent code changes (git log since last stable version)
+
+---
+
+## Outputs
+
+- Root cause analysis
+- Code fix with regression test
+- Deployed build or hotfix OTA

package/workflows/feature-ship.md

@@ -0,0 +1,61 @@
+# Workflow — Feature Ship
+
+**Type:** End-to-end feature delivery
+**Agents Used:** AXIOM / SWIFT / DART / BRIDGE, SCRIBE
+**Skills Used:** /grill-mobile, /feature-slice, /compose-review or /swiftui-review or /flutter-review, /android-tdd or /ios-tdd or /flutter-tdd
+
+---
+
+## When to Use
+
+Start here for any feature that will take more than one day to build.
+
+---
+
+## Steps
+
+```
+1. ALIGNMENT — /grill-mobile
+   ↓ Ask all 20 questions before writing any code.
+   ↓ Confirm understanding with 3-bullet summary.
+
+2. PLANNING — /feature-slice
+   ↓ Break the feature into independently shippable tickets.
+   ↓ Identify the data layer ticket as the first blocker.
+
+3. IMPLEMENTATION — AXIOM / SWIFT / DART / BRIDGE
+   ↓ Implement data layer first (API model, repository).
+   ↓ Domain layer (use case, business logic).
+   ↓ ViewModel / state management.
+   ↓ UI scaffold → UI with real data → error states.
+
+4. REVIEW — /compose-review or /swiftui-review or /flutter-review or /rn-review
+   ↓ Recomposition / rebuild audit before PR.
+   ↓ Fix any WARNING or CRITICAL issues.
+
+5. TESTS — /android-tdd or /ios-tdd or /flutter-tdd or /rn-tdd
+   ↓ Unit tests for use case and ViewModel.
+   ↓ UI test for the happy path.
+
+6. DESCRIPTION — SCRIBE
+   ↓ Generate PR description from commit log.
+   ↓ Human reviews before submitting.
+
+7. MERGE
+```
+
+---
+
+## Inputs
+
+- Jira / Linear / GitHub ticket describing the feature
+- Figma design link (optional but recommended)
+- Target platform and version context
+
+---
+
+## Outputs
+
+- Working feature behind a feature flag
+- Unit + UI tests
+- PR description ready for review

package/workflows/game-level.md

@@ -0,0 +1,72 @@
+# Workflow — Game Level (Unity / Unreal)
+
+**Type:** Game development
+**Agents Used:** FORGE / UNREAL, PERF
+**Skills Used:** /shader-gen, /game-perf, /unity-tdd or /blueprint-to-cpp
+
+---
+
+## When to Use
+
+Designing, implementing, and optimizing a new game level or major game feature.
+
+---
+
+## Steps
+
+```
+1. ARCHITECTURE — FORGE / UNREAL
+   ↓ Review the level design document against engine capabilities.
+   ↓ Identify: which systems are affected (physics, AI, rendering, audio)?
+   ↓ Flag any design element that will blow the frame budget on target hardware.
+   ↓ Recommend architecture: which logic belongs in C++ vs Blueprint vs ScriptableObject.
+
+2. VISUAL EFFECTS — /shader-gen
+   ↓ Generate HLSL/ShaderLab shaders for any described visual effects.
+   ↓ Request mobile-optimized variants for mobile targets.
+   ↓ Note instruction count and mobile compatibility.
+
+3. FRAME BUDGET — /game-perf
+   ↓ Set the frame budget before implementation starts:
+     - Draw call budget for the level
+     - Polygon budget for hero vs background assets
+     - Texture memory budget
+     - Physics object limit
+   ↓ Allocate budget to level elements: environment, characters, particles, UI.
+
+4. IMPLEMENTATION — FORGE / UNREAL
+   ↓ Implement game systems in C++ where performance requires it.
+   ↓ Blueprint for designer-owned logic and rapid iteration.
+   ↓ /blueprint-to-cpp for any Blueprint logic called in Tick.
+
+5. TESTS — /unity-tdd or /blueprint-to-cpp
+   ↓ EditMode tests for game logic (health, scoring, AI state machine).
+   ↓ PlayMode tests for runtime behavior (collision, triggers, win conditions).
+
+6. VALIDATE — PERF
+   ↓ Profile the level on the lowest target device spec.
+   ↓ Confirm frame rate at the most complex scene point (most particles, enemies, lights).
+   ↓ Memory: no texture streaming hitches, no GC spikes during gameplay.
+
+7. PLAYTEST READY
+   ↓ Level loads in < 5 seconds on target hardware.
+   ↓ Stable 30fps (mobile) or 60fps (PC/console) throughout.
+   ↓ No physics glitches or rendering artifacts.
+```
+
+---
+
+## Inputs
+
+- Level design document (layout, objectives, visual style)
+- Target platform specs (GPU, RAM, target frame rate)
+- Engine version and render pipeline
+
+---
+
+## Outputs
+
+- Level implementation with documented frame budget
+- Custom shaders for visual effects
+- Game logic unit tests
+- Performance validation report