Menu
Check if uncommitted changes are important/risky/breaking to require a review before merge/production release.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Safely clear a dirty Inline repo worktree by inspecting uncommitted changes, classifying them as safe to commit, review-needed, blocked, or discard candidates, running focused validation, making scoped commits, and asking before destructive cleanup. Use when the user asks to clear the worktree, clean up WIP, commit what is safe, decide what needs Mo review, or update the repository-specific rules for what can be committed versus blocked.
Use when writing, reviewing, or modernizing Swift code that touches Observation, SwiftUI model data, UIKit/AppKit automatic observation tracking, SwiftUI interoperability with UIKit/AppKit, or Apple APIs gated by iOS/macOS versions. Read this before adopting @Observable, migrating ObservableObject code, using new UIKit/AppKit lifecycle tracking, adding SwiftUI to existing UIKit/AppKit apps, or checking whether an iOS 18/macOS 15 or iOS 26/macOS 26 API is safe for the current deployment target.
Review local app/code changes after implementation and produce a concise technical handoff. Use when the user asks for a review, risk assessment, tradeoff check, "what should I review", "give me snippets", or a high-level impact summary after changes that affect multiple app areas, UX, behavior, complexity, tech debt, or bug risk.
Modernize existing Swift test suites by migrating XCTest to Swift Testing or improving current Swift Testing structure. Use when asked to modernize, update, migrate, supercharge, or convert tests. Do not use for writing new tests from scratch, XCTest-only questions, test result review, test running, coverage updates for new functionality, debugging failures without a migration request, or XCUI UI automation tests.
Safely sync local commits with remote by rebasing onto origin/main and then push, following a GitHub Desktop-style flow. Use when asked to push/sync a branch, reconcile local and remote state, resolve rebase conflicts, run targeted tests or typechecks, and push only if checks pass.
Explain and use the Inline CLI (`inline`) for authentication, chats, users, spaces, messages, search, bots, typing, notifications, tasks, schema, attachments, downloads, JSON output, and configuration. Use when asked how to use the Inline CLI or its commands, flags, outputs, or workflows.
| name | mo-needs-to-review? |
| description | Check if uncommitted changes are important/risky/breaking to require a review before merge/production release. |
| metadata | {"short-description":"Does this code need a review from Mo?"} |
Check if the changes in the current work tree require a second manual review and confirmation from a senior engineer (Mo) who has deep insight into the system or not.
If changes match any of the items below, they need a second check:
any?Dockerfiles we have across the project so our build will fail when deploying?Run applicable items from the static check list we have to confirm static behavior.