osx-review
starsforks
How to install osx-review?
boltzmannentropy/osxskills/osx-review
$npx -y skills add BoltzmannEntropy/OSXSkills --skill osx-reviewUse when preparing mobile/desktop apps for App Store submission, before final release, or when user mentions App Store, production readiness, shipping, or needs comprehensive quality review for distribution
SKILL.md
| 1 | # App Store Readiness Code Review |
| 2 | |
| 3 | ## Overview |
| 4 | |
| 5 | Systematic code review process for applications targeting Apple App Store, Google Play, or desktop distribution. Identifies crash risks, security vulnerabilities, resource leaks, and compliance issues that cause rejection or poor user experience. |
| 6 | |
| 7 | This skill now includes a mandatory cross-repo consistency pass for macOS app websites + README licensing language before release. |
| 8 | This skill also enforces MimikaCODE production UX baselines (system logs, queue/history/models/settings/file-path surfaces) for both existing projects and newly created projects. |
| 9 | |
| 10 | ## Repository Layout (Mandatory in This Workspace) |
| 11 | |
| 12 | All macOS app projects must follow this structure under `artifacts/code`: |
| 13 | |
| 14 | - `artifacts/code/<AppName>PRJ/<AppName>CODE` - source code repository |
| 15 | - `artifacts/code/<AppName>PRJ/<AppName>WEB` - static website repository (moved from `artifacts/all-web`) |
| 16 | |
| 17 | For licensing and legal checks, always use these surfaces: |
| 18 | |
| 19 | - **README surface:** `<AppName>CODE/README.md` |
| 20 | - **Flutter app surface:** `<AppName>CODE/flutter_app/` (legal screens + bundled app resources) |
| 21 | - **Website surface:** `<AppName>WEB/` (`index.html`, `license.html`, `privacy.html`, `terms.html`, `privacy-consent.js`) |
| 22 | |
| 23 | Do not create or update app sites in `artifacts/all-web` for these macOS apps. |
| 24 | |
| 25 | ## When to Use |
| 26 | |
| 27 | - Before App Store/Play Store submission |
| 28 | - Before any production release |
| 29 | - When user says "ship", "release", "production ready", "App Store" |
| 30 | - After major feature completion |
| 31 | - When reviewing cross-platform apps (Flutter, React Native, etc.) |
| 32 | |
| 33 | ## iOS/iPad Baseline (Current) |
| 34 | |
| 35 | For iOS/iPad submissions, enforce these before final sign-off: |
| 36 | |
| 37 | - [ ] Run `bash ./skills/osx-ios/scripts/check_ios_dist.sh --app-root <APP_ROOT>` and resolve all `FAIL` findings |
| 38 | - [ ] Archive/upload baseline matches current App Store Connect tooling requirements |
| 39 | - [ ] TestFlight constraints checked (tester caps, build age, beta review flow) |
| 40 | - [ ] Screenshot coverage satisfies current iPhone + iPad minimum requirements |
| 41 | - [ ] Privacy manifest and required-reason API declarations validated |
| 42 | |
| 43 | ## Review Categories |
| 44 | |
| 45 | Review ALL categories systematically. Do not skip any. |
| 46 | |
| 47 | ```dot |
| 48 | digraph review_flow { |
| 49 | rankdir=TB; |
| 50 | node [shape=box]; |
| 51 | |
| 52 | "Start Review" -> "1. Crash Prevention"; |
| 53 | "1. Crash Prevention" -> "2. Resource Management"; |
| 54 | "2. Resource Management" -> "3. Network & API"; |
| 55 | "3. Network & API" -> "4. Security"; |
| 56 | "4. Security" -> "5. Data Persistence"; |
| 57 | "5. Data Persistence" -> "6. Platform Compliance"; |
| 58 | "6. Platform Compliance" -> "7. Error Handling"; |
| 59 | "7. Error Handling" -> "8. MCP Integration (macOS)"; |
| 60 | "8. MCP Integration (macOS)" -> "9. Performance"; |
| 61 | "9. Performance" -> "10. Product Information"; |
| 62 | "10. Product Information" -> "Generate Report"; |
| 63 | } |
| 64 | ``` |
| 65 | |
| 66 | ## Severity Classification |
| 67 | |
| 68 | | Severity | Definition | Action | |
| 69 | |----------|------------|--------| |
| 70 | | **Critical** | Will cause crashes, data loss, or rejection | Must fix before submission | |
| 71 | | **High** | Likely to cause issues under normal use | Should fix before submission | |
| 72 | | **Medium** | Edge cases, degraded experience | Fix in next release | |
| 73 | | **Low** | Code quality, best practices | Nice to have | |
| 74 | |
| 75 | ## 1. Crash Prevention Checklist |
| 76 | |
| 77 | ### Flutter/Dart |
| 78 | - [ ] All async callbacks check `mounted` before `setState()` |
| 79 | - [ ] `StreamSubscription` cancelled in `dispose()` |
| 80 | - [ ] `Timer` cancelled in `dispose()` |
| 81 | - [ ] `AnimationController` disposed |
| 82 | - [ ] `TextEditingController` disposed |
| 83 | - [ ] `ScrollController` disposed |
| 84 | - [ ] `FocusNode` disposed |
| 85 | - [ ] Null safety: no force unwraps (`!`) without guaranteed non-null |
| 86 | - [ ] List/Map access with bounds checking or `.elementAtOrNull()` |
| 87 | |
| 88 | ### Flutter UI Patterns (Reference: flutter-python-fullstack) |
| 89 | - [ ] **Theme**: Uses `ColorScheme.fromSeed()` with Material 3 |
| 90 | - [ ] **Dark mode**: Supports `ThemeMode.system` (respects OS preference) |
| 91 | - [ ] **Backend check**: Health check on startup with loading/disconnected states |
| 92 | - [ ] **Bundled backend autostart**: If backend is down and app is bundled, UI attempts backend startup automatically (no manual CLI prerequisite for end users) |
| 93 | - [ ] **Startup status UX**: UI shows backend startup progress/status (for example: starting/waiting/failed) |
| 94 | - [ ] **Exit shutdown hook**: App intercepts desktop window-close/exit requests and runs graceful backend shutdown before process exit |
| 95 | - [ ] **Shutdown UX**: During close, app shows a blocking "Stopping server/backend..." progress dialog until shutdown finishes or timeout path is handled |
| 96 | - [ ] **Production messaging**: Disconnected-state copy does not instruct end users to run terminal commands |
| 97 | - [ ] **Stats polling**: Uses `Future.doWhile()` with `mounted` guard |
| 98 | - [ ] **Status chips**: Color-coded |
People who liked this also viewed
6 picksType
- requesting-code-reviewUse when completing tasks, implementing major features, or before merging to verify work meets requirementsSkillsJul 2026
- code-reviewSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026
- receiving-code-reviewUse when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performativeSkillsJul 2026
- baoyu-format-markdownFormats plain text or markdown files with frontmatter, titles, summaries, headings, bold, lists, and code blocks. Use when user asks to "format markdown", "beautify article", "add formatting", or imprSkillsJul 2026
- code-review-excellenceMaster effective code review practices to provide constructive feedback, catch bugs early, and foster knowledge sharing while maintaining team morale. Use when reviewing pull requests, establishing reSkillsJul 2026
- code-review-and-qualityConducts multi-axis code review. Use before merging any change. Use when reviewing code written by yourself, another agent, or a human. Use when you need to assess code quality across multiple dimensiSkillsJul 2026
