Claude Skills by mirzaaghazadeh

Build layouts that adapt to the iPhone Duo fold using reserved regions, division and occlusion regions, displacement patterns, and the split and overlay ArrangementView containers. Use when content or controls land in the fold, when building a split-like or overlay layout, or when custom manually-positioned UI must avoid the hinge or the under-display camera.

Build camera capture for iPhone Duo's two front cameras — the virtual front camera, the inner under-display and outer ultra-wide devices, AVCaptureDeviceDirectionCoordinator, preview mirroring and video gravity, and dual-display capture. Use when an app captures photo or video and must handle the device opening, closing or flipping.

Review or design an iOS interface for iPhone Duo's poses — closed, open, book-folded, tabletop and tent — covering side-mounted controls, asymmetric layouts, fold avoidance, sheets, and how to use the inner display well. Use for design critique, mockup review, or deciding what a screen should look like on a foldable iPhone rather than how to code it.

Adapt a Flutter app to iPhone Duo, Apple's first foldable iPhone — what MediaQuery gives you today, why displayFeatures does not work here, and how to bridge the iOS 27.1 reserved-region, hinge and arrangement APIs through platform channels. Use when a Flutter or Dart app needs foldable iPhone support.

Adapt a game to iPhone Duo — filling the screen across every device pose, orientation locking, aspect ratio versus letterboxing, keeping touch controls out of the fold, and consistent text and control sizing while resizing. Use when the project is a game or uses a game engine such as Unity, Unreal, Godot, SpriteKit or Metal.

Use the iPhone Duo hinge angle for interactions and effects, support Split View multitasking and multiple app scenes, and pair UI across both displays with scene accessories including CameraCaptureAccessory. Use when building fold-driven effects, multi-window support, or dual-display experiences.

Adapt a React Native or Expo app to iPhone Duo, Apple's first foldable iPhone — asymmetric safe area insets, resize handling, and how to expose the iOS 27.1 reserved-region and hinge APIs through a native module. Use when a React Native, Expo or JS-based iOS app needs foldable iPhone support.

Audit and port an iOS app to iPhone Duo, Apple's first foldable iPhone. Use when asked to support, adapt, prepare, test, or review an app for iPhone Duo, foldable iPhone, the inner/outer display, device poses, or the fold. Entry point that routes to the layout, bars, hinge/scenes, camera, and design skills.

Adapt toolbars, navigation bars and tab bars for the vertical axis on iPhone Duo — item ordering, symbol vs text representations, AxisBehavior, overflow menus, visibility priority, and when to opt out. Use when toolbar items look wrong, overflow too early, or need to move to the side on the outer display.

Design and build two-pane experiences for iPhone Duo — the real pixel and point dimensions of each display and each half, the exact hinge callback types (onHingeChange / UIHingeInteraction), hinge-driven effects, pose-to-pattern mapping (companion pane, dual view, list-detail, tabletop controls), two-pane paywalls and fold-aware onboarding. Use when sizing a layout or asset for iPhone Duo, wiring a hinge callback, choosing what goes in each pane, or designing onboarding and purchase flows tha...

Adapt a Capacitor or Ionic app to iPhone Duo, Apple's first foldable iPhone — why the standard Device Posture and Viewport Segments CSS does not reach a web view, what CSS gives you today, and how to get fold state, hinge angle and bar placement from the native side. Use when a Capacitor, Ionic, Angular, React or Vue app needs foldable iPhone support.

Take a run from "nothing was assigned to me" to a pushed, tested change without asking anyone. Use on a check-in that found no new messages, on an escalation from one, or any time you are choosing your own work.

Decide when something is genuinely the owner's call, and then ask it well with ask_user — one-line title, a recommendation, real options, and a default so nothing stalls overnight. Use before escalating anything to the owner, and when writing an approval request or a report.

Get a designed screen onto the glass without the classic desktop-app faults — a panel that will not fill its window, a popover clipped by its parent, a list that re-renders forever, text in the wrong direction. Use when writing or changing any UI code, and before saying a screen is done.

Get from a symptom to a fix without guessing — reproduce it, narrow it, prove the cause, then fix it and leave a regression test. Use when something is failing, flaky, or behaving differently than expected.

Design a screen someone can read at a glance and act on without being taught — hierarchy, density, the states you forgot, and copy that says something. Use before building any screen, panel, sheet or empty state, and when a screen "works" but feels wrong.

Handle a broken default branch or failing CI — establish what broke and when, get the branch green the fastest safe way, then fix it properly. Use the moment you notice main is red or the suite fails for reasons that are not yours.

Learn an unfamiliar codebase before changing it — what it is, how it builds, how it is tested, what the house rules are. Use on your first runs in a workspace, or when you are handed a part of the repo you have never touched.

Propose a new teammate with evidence, and write the soul and rules that make them useful on day one. Use when work is repeatedly blocked on a role nobody holds, or when the owner asks who the team is missing.

Keep credentials out of the repo, the logs and your own messages — how to read a secret you need, what to do when you find one committed, and why you never move one somewhere new. Use whenever a task involves an API key, token, password, certificate or connection string.

Fix a performance problem with evidence rather than instinct — measure first, find where the time actually goes, change one thing, and prove the win. Use when something is slow, when a build or suite is dragging, or before optimising anything.

Turn a goal into tasks a teammate can actually finish — sized to one run, with a definition of done, an owner and an order. Use when you are given something large, when you run the standup, or when the team is busy but nothing is shipping.

Change the shape of code without changing what it does — get a test harness under it first, move in reversible steps, and keep the refactor out of the change that alters behaviour. Use before restructuring, renaming across files, or untangling something to make a feature possible.

Keep what you learned so future runs start ahead — what belongs in remember, what belongs in a skill written with learn_skill, and what belongs nowhere. Use at the end of a run where you worked something out the hard way.

Review a teammate's change so the review is worth the time it costs — read the diff, run it, look for the bug that matters, and leave evidence rather than opinions. Use when reviewing a pull request, a branch or a patch.

Take a security pass over a change — where untrusted input reaches something dangerous, what the authorisation check misses, and what leaks in a log or an error. Use when reviewing code that touches input, auth, files, queries, shell commands or the network.

Answer an open technical question with a time-boxed throwaway experiment instead of arguing or over-building. Use when the team does not know whether an approach will work, which library to pick, or how much a change would cost.

Take one task from "assigned" to a reviewable change — branch, small diff, tests, green checks, honest commit message, pull request. Use whenever you are about to edit code you intend to merge.

Do the work for what it is worth — spend your run on the thing that was asked, not on re-reading the repo, arguing with a teammate or grinding a stuck task. Use when a job looks large, when you have failed twice already, or when you are about to start something open-ended.

Turn a report into something the team can act on — reproduce it, judge how much it matters, and either file it as a well-shaped task or close it. Use when a bug is reported, when an issue lands, or when the owner mentions something is broken.

Upgrade packages without breaking the build or importing something nobody vetted — read the changelog, move in separate steps, and prove it still works. Use when updating a dependency, responding to a security advisory, or adding a new package.

Work the forge from the command line with gh — open and describe a pull request, read review comments, check why CI failed, file and close issues. Use when a task involves a pull request, an issue, or a failing check rather than only local code.

Stay inside the limits the owner set — the workspace fence, the permission rules, approvals that block a tool call, and commands that cannot be undone. Use before running anything destructive, touching a path outside the repo, or reaching a service on the network.

Use git without losing work or rewriting somebody else's history — branches, clean commits, conflicts, and the recovery moves when something has gone wrong. Use before branching, rebasing, resolving a conflict, or any command that discards changes.

Talk to the rest of the team so it moves work forward rather than filling channels — when to post, when to ask a named teammate, how to hand off a task, and how not to end up in a loop of replies. Use before posting in a channel, assigning work, or answering a mention.

Write a standup plan, an end-of-day report or a retrospective that the owner can read in thirty seconds and act on. Use for any scheduled check-in, daily summary, weekly retro or "where are we" request.

Write docs that stay true to the code — README, reference, release notes and comments that answer what a reader actually needs. Use when behaviour changed, when a README no longer matches, or when you are asked to document something.

Write tests that are worth keeping — testing behaviour rather than implementation, covering the case that actually breaks, and failing for a reason someone can read. Use when adding a test, fixing one, or deciding a change needs coverage.