@kensaurus/skills 0.0.0-stage → 2.1.0

package/commands/gtm-weekly.md

@@ -0,0 +1,17 @@
+---
+description: "Weekly growth review — funnel by source, top drop-off, one experiment, one post, scorecard row"
+argument-hint: "[week or date range]"
+---
+
+# GTM Weekly
+
+Run the **`iterate-gtm-weekly`** skill: pull Visit → Signup → Activated →
+Habit → Paid → Refer by source for this week vs last, fill any launch
+Results table older than 7 days, name the step with the largest absolute
+loss, attribute last week's experiment with a number, choose exactly one
+experiment and one post, append the scorecard row, schedule next week.
+
+Production errors go to `iterate-post-launch`; blind funnel cells go to
+`audit-analytics` first.
+
+The full playbook lives in the **`iterate-gtm-weekly`** skill.

package/commands/gtm.md

@@ -0,0 +1,22 @@
+---
+description: "Take a shipped repo to market: plan → approve → measure → message → activate → be found → launch → weekly loop"
+argument-hint: "[product url or repo path, optional 'phase N' to execute an approved phase]"
+disable-model-invocation: true
+---
+
+# GTM
+
+Run the **`workflow-gtm`** skill. Default to Step 1 (`plan-gtm`) unless an
+approved `plan-gtm.md` already exists — then execute the named phase:
+
+1. **Measure** → `audit-analytics`
+2. **Message** → `enhance-web-conversion` (+ `enhance-readme` when the repo is the product)
+3. **Activate** → `enhance-onboarding`
+4. **Be found** → `enhance-web-seo`, `plan-aeo-readiness`
+5. **Launch** → `docs-launch-kit`
+6. **Loop** → `iterate-post-launch`
+
+Nothing from Step 2 onward runs before its phase is approved. End with the
+GTM scorecard (funnel before/after, skips named, next week's one fix).
+
+The full playbook lives in the **`workflow-gtm`** skill.

package/commands/handoff.md

@@ -0,0 +1,15 @@
+---
+description: "Compact the current conversation into a handoff document for a fresh agent session"
+argument-hint: "[what the next session will focus on]"
+disable-model-invocation: true
+---
+
+# /handoff
+
+Follow the **`handoff`** skill: write a handoff document summarizing the current
+conversation — state, ordered next steps, suggested skills, gotchas — so a fresh
+agent can continue the work. Save to the OS temp directory (not the workspace),
+redact secrets, reference existing artifacts by path instead of copying them,
+and report verification state honestly per `verification-before-completion`.
+
+If arguments were passed, treat them as the next session's focus.

package/commands/housekeep-backlog.md

@@ -0,0 +1,18 @@
+---
+description: "Inventory parked work into one living BACKLOG.md — regenerate and diff, do not implement"
+argument-hint: "[optional path to an existing BACKLOG.md]"
+disable-model-invocation: true
+---
+
+# Housekeep Backlog
+
+Run the **`housekeep-backlog`** skill: scan the repo for unfinished
+plans, deferred phases, TODO/FIXME markers, skipped tests, and open
+audit findings; dedup; write or regenerate `docs/BACKLOG.md` with stable
+`BL-` IDs and a new/done/stale diff.
+
+Inventories only. Execution stays on `complete-everything` /
+`burndown-full`. Decisions stay on `docs-adr`. Flag debt stays on
+`workflow-feature-flag`.
+
+The full playbook lives in the **`housekeep-backlog`** skill.

package/commands/housekeep-files.md

@@ -0,0 +1,22 @@
+---
+description: "Organize a document tree by copy-not-move: hash inventory, dry run, labeled copies, search catalog, verify every source survived"
+argument-hint: "[source folders] [destination root]"
+disable-model-invocation: true
+---
+
+# Housekeep Files
+
+Run the **`housekeep-files`** skill on the folders named in the argument
+(default: ask which Downloads / cloud-drive folders are in scope).
+
+1. Inventory the top two levels and offer the layout options (root per
+   owner, one root with owners inside, PARA-lite); wait for the choice.
+2. Write `plan.tsv` and `count-only.txt`; run `inventory`, then `dry-run`;
+   show the preview counts and any `indexed-in-place:secret` rows.
+3. On approval run `apply`, then `verify`; report the verify exit code and
+   the storage added.
+
+Copies only. Nothing is moved or deleted; retiring the originals is a
+later, human-run step. Repository cleanup stays on `workflow-housekeep`.
+
+The full playbook lives in the **`housekeep-files`** skill.

package/commands/housekeep-gates.md

@@ -0,0 +1,18 @@
+---
+description: "Consolidate accreted CI gates into one aggregator required check — apply phase by phase"
+argument-hint: "[archaeology map or workflow path]"
+disable-model-invocation: true
+---
+
+# Housekeep Gates
+
+Run the **`housekeep-gates`** skill: consume the `audit-gate-logic`
+archaeology map, build one aggregator job that `needs:` every real check
+and fails on failed **or skipped** dependencies, port unique value from
+losers, then **delete** (do not disable) the rest.
+
+**Net enforcement strictly ≥ before.** Branch-protection changes always
+get explicit confirmation. Pipeline cost stays on `audit-cicd`. Installing
+brand-new guard classes stays on `enhance-agent-guardrails`.
+
+The full playbook lives in the **`housekeep-gates`** skill.

package/commands/instant-nav.md

@@ -0,0 +1,11 @@
+---
+description: "Make in-site navigation instant — Speculation Rules, bfcache, View Transitions, 103 Early Hints"
+argument-hint: "[route or next-click path]"
+disable-model-invocation: true
+---
+
+# /instant-nav
+
+Follow the **`enhance-web-instant-nav`** skill. First-load LCP/INP/CLS →
+`audit-performance`. JS weight → `audit-bundle-size`. Pure SPA routing →
+framework prefetch, not this skill.

package/commands/integrity-plan.md

@@ -0,0 +1,19 @@
+---
+description: "Data-integrity & destructive-op audit — plan only, no migrations or tokens until approved"
+argument-hint: "[path or scope]"
+disable-model-invocation: true
+effort: high
+---
+
+# Data Integrity Plan
+
+Run the **`plan-data-integrity`** skill: audit for destructive-operation and
+data-loss risk (unsafe migrations, unguarded deletes, backups in the same
+blast radius as prod). Restore drills and RPO/RTO stay on `/backup-plan`.
+**Audit and plan only — run no migrations and add no tokens until the plan is
+approved.**
+
+Emit findings ranked by severity with locations and a phased safeguard
+checklist. After approval, execute with `db-migrator` and `backend-patterns`.
+
+The full playbook lives in the **`plan-data-integrity`** skill.

package/commands/launch-kit.md

@@ -0,0 +1,16 @@
+---
+description: "Write a versioned launch kit — Show HN, Product Hunt, Reddit, X/LinkedIn, article outline, release notes, calendar, UTMs"
+argument-hint: "[version or release, optional channel list]"
+disable-model-invocation: true
+---
+
+# Launch Kit
+
+Run the **`docs-launch-kit`** skill: build a claims table from the changelog
+and repo, pick one problem-first angle, write native copy per channel, add a
+calendar and UTM links, and save it as `docs/launch/<version>.md`.
+
+Every number and feature in the copy must trace to the claims table. No vote
+solicitation, no fabricated proof, maker disclosed on every channel.
+
+The full playbook lives in the **`docs-launch-kit`** skill.

package/commands/mcp-guide.md

@@ -0,0 +1,40 @@
+---
+description: "Reference for the essential MCP set (Firecrawl, Context7, Supabase) and headed playwright-cli — not the host /mcp manager"
+---
+
+# MCP-Powered Development
+
+> **Named `/mcp-guide` (not `/mcp`).** Claude Code and the Cursor CLI both reserve `/mcp` for managing MCP servers. This file says which connection to use. It does not start or list servers.
+
+The default template (`mcp/mcp.json.template`) is three servers. Prefer a Cursor plugin when that plugin is already connected, and skip the matching stdio server.
+
+## Essential
+
+### Context7 — library docs
+
+Current docs for the version this repo has pinned. Use it before implementing an unfamiliar library API.
+
+### Firecrawl — web research
+
+Authenticated search and page scrape. Keep `FIRECRAWL_NO_SEARCH_FEEDBACK=1` and `FIRECRAWL_NO_ENDPOINT_FEEDBACK=1`. The `research` skill owns the broad-search → deep-scrape → discovery sequence, including the WebSearch / WebFetch fallback when Firecrawl is not connected.
+
+### Supabase — project data
+
+Queries, auth, storage, and migrations for the configured project. Do not invent a project ref.
+
+## Browser
+
+Skills drive a **visible** browser with `playwright-cli` (`npx --yes @playwright/cli@latest`, `--headed` on `open`). Read `protocol-browser-anti-stall` first. The Playwright MCP is not the default and is not what the skills call.
+
+## Not installed by default
+
+Sequential Thinking is not shipped (ADR-0009) and the Playwright MCP exists only in `mcp/mcp-full.json.template`; do not plan on either. Reasoning depth is set by the effort level, not by a scratchpad server or by writing reasoning steps into the transcript.
+
+## Which one
+
+| Job | Use |
+|-----|-----|
+| Unfamiliar library API | Context7 for the pinned version, then Firecrawl if the docs page is not enough |
+| Implementation patterns on the web | Firecrawl, or the host web search if it is not connected |
+| Live database or auth state | Supabase |
+| Click through a UI | playwright-cli, one user action at a time |

package/commands/mobile-plan.md

@@ -0,0 +1,19 @@
+---
+description: "App Store / Play submission-readiness audit — plan only, no manifest edits until approved"
+argument-hint: "[app path or scope]"
+disable-model-invocation: true
+effort: high
+---
+
+# Mobile Readiness Plan
+
+Run the **`plan-mobile-readiness`** skill: audit a Capacitor/React Native app
+for App Store and Play submission readiness (privacy manifest, data-safety,
+permissions, metadata), then produce a readiness plan. **Audit and plan only —
+edit no manifests until the plan is approved.**
+
+Emit findings ranked by severity (submission blockers first) with a phased
+checklist. After approval, execute with `plan-capacitor-hardening` and the
+relevant mobile skills.
+
+The full playbook lives in the **`plan-mobile-readiness`** skill.

package/commands/native-rn-monorepo/README.md

@@ -0,0 +1,78 @@
+# Native RN-monorepo commands (Cursor)
+
+Slash-command bundle for an RN + Web monorepo where the developer
+is on **Linux/Windows (no Mac)** and iOS verification happens on
+**GitHub Actions** macOS runners with TestFlight as the install
+target.
+
+## What's here
+
+| Command | Domain | What it does |
+|---|---|---|
+| `/android-build` | local | Build debug APK locally |
+| `/android-install` | local | Install + launch on device/emulator |
+| `/android-logcat` | local | Tail filtered Android logs |
+| `/ios-ci-trigger` | CI | `gh workflow run …` for iOS |
+| `/ios-ci-status` | CI | Check latest iOS CI run |
+| `/ios-ci-logs` | CI | Diagnose failed iOS CI run |
+| `/rn-verify` | local | Smoke test: TS + lint + Android compile + web typecheck |
+| `/rn-reset` | local | Full local cache reset |
+| `/rn-ship-ios` | combined | Verify → push → trigger iOS CI → watch |
+
+## Install into a project
+
+```bash
+mkdir -p <project>/.cursor/commands
+cp ~/skills/commands/native-rn-monorepo/*.md <project>/.cursor/commands/
+```
+
+(Skip this `README.md` — it's documentation, not a slash command.)
+
+## Customisation required after install
+
+1. Run `gh workflow list` in the project and replace `ios.yml` in
+   `ios-ci-trigger.md`, `ios-ci-status.md`, `ios-ci-logs.md`, and
+   `rn-ship-ios.md` with the actual iOS workflow filename.
+2. If your monorepo uses nested paths (e.g. `apps/mobile/android/`),
+   replace `android` with the correct path in `/android-build`,
+   `/android-install`, `/android-logcat`, and `/rn-verify`.
+3. Verify `gh` is authenticated (`gh auth status`) — every iOS
+   command depends on it.
+4. Confirm the iOS workflow accepts a `workflow_dispatch` trigger
+   with the inputs you reference (most commonly `platform`,
+   `track`, or `clear-cache`).
+
+## The shipping loop
+
+```
+edit
+  ↓
+/rn-verify              (TS + lint + Android Kotlin compile)
+  ↓
+/android-build          (full debug APK + install on emulator)
+  ↓
+test on Android emulator
+  ↓
+/rn-ship-ios            (verify → push → CI → TestFlight)
+  ↓
+TestFlight installs build on iPhone (Apple processing ~5–30 min)
+  ↓
+/ios-ci-logs            (only if anything failed)
+```
+
+## Why these commands?
+
+- **iOS macOS runners cost ~10× Linux runners.** The
+  verify-locally-first gate in `/rn-ship-ios` exists to avoid
+  shipping known-broken code to a 15-minute build.
+- **Apple processing is asynchronous.** The status / logs commands
+  are explicit that workflow `success` ≠ "TestFlight available."
+- **Logcat without a filter is unusable.** `/android-logcat` scopes
+  to the package PID and surfaces only the categories that matter
+  for RN apps (`ReactNative*`, `AndroidRuntime`, `ANR`, `FATAL`).
+
+## Companion rules
+
+The matching `.mdc` rule bundle lives at
+`~/skills/rules/native-rn-monorepo/`. Install both together
+so the agent has both the *what* (rules) and the *how* (commands).

package/commands/native-rn-monorepo/android-build.md

@@ -0,0 +1,26 @@
+---
+description: "Build the Android debug APK locally and confirm BUILD SUCCESSFUL"
+---
+
+# /android-build
+
+Build the Android app in debug mode and verify success.
+
+## Steps
+
+1. From repo root: `cd android && ./gradlew :app:assembleDebug --console=plain`
+2. Parse the output for `BUILD SUCCESSFUL` or `BUILD FAILED`.
+3. If `BUILD FAILED`, identify the first compilation error in the
+   output, propose a fix, and re-run after applying it.
+4. If `BUILD SUCCESSFUL`, report the APK path:
+   `android/app/build/outputs/apk/debug/app-debug.apk`.
+5. If the build is slow (>2 min), check the Gradle daemon status
+   with `./gradlew --status`.
+
+## Don't
+
+- Don't declare success without seeing `BUILD SUCCESSFUL` in stdout.
+- Don't suggest cleaning + rebuilding as a first response to errors
+  — fix the actual error.
+- Don't bump SDK or AGP versions to "fix" build errors unless the
+  user explicitly asks.

package/commands/native-rn-monorepo/android-install.md

@@ -0,0 +1,32 @@
+---
+description: "Install the debug build on a connected device or emulator and launch it"
+effort: low
+---
+
+# /android-install
+
+Install the debug build on a connected device or emulator and
+launch it.
+
+## Steps
+
+1. Confirm a device is connected: `adb devices`.
+   - If output shows no devices, ask the user to start an emulator
+     or plug in a device.
+   - If multiple devices, ask which one (or confirm the first
+     listed).
+2. Read the package name from `android/app/src/main/AndroidManifest.xml`
+   (`package=` attribute) or from `android/app/build.gradle`
+   `applicationId`.
+3. Install: `cd android && ./gradlew :app:installDebug`
+4. If install fails with `INSTALL_FAILED_VERSION_DOWNGRADE` or
+   `INSTALL_FAILED_UPDATE_INCOMPATIBLE`:
+   - Run `adb uninstall <package_name>` then retry installDebug.
+5. Launch: `adb shell monkey -p <package_name> -c android.intent.category.LAUNCHER 1`
+6. Optionally tail logs (use `/android-logcat` separately).
+
+## Don't
+
+- Don't `adb uninstall` without warning — it wipes app data.
+- Don't install on multiple devices simultaneously without
+  confirming.

package/commands/native-rn-monorepo/android-logcat.md

@@ -0,0 +1,37 @@
+---
+description: "Tail logcat scoped to this app's PID and summarize crashes, bridge errors, and ANRs"
+effort: low
+---
+
+# /android-logcat
+
+Tail Android logcat scoped to this app and surface anything
+notable.
+
+## Steps
+
+1. Read package name from
+   `android/app/src/main/AndroidManifest.xml` (`package=`
+   attribute).
+2. Get the running PID: `adb shell pidof -s <package_name>`
+3. If a PID exists:
+   ```
+   adb logcat --pid=<pid>
+   ```
+4. If no PID (app not running), use a tag-based filter:
+   ```
+   adb logcat *:S ReactNative:V ReactNativeJS:V AndroidRuntime:E
+   ```
+5. Capture ~50 lines, then summarize:
+   - Any `FATAL EXCEPTION` or `AndroidRuntime` crashes (with stack
+     trace summary)
+   - Any `ReactNative` bridge errors
+   - Any `ANR` (Application Not Responding) warnings
+   - Any obvious permission denials
+
+## Don't
+
+- Don't dump raw logcat output without summarizing.
+- Don't run `adb logcat` without a filter — it's overwhelming.
+- Don't `adb logcat -c` (clear buffer) unless explicitly asked —
+  it loses context.

package/commands/native-rn-monorepo/ios-ci-logs.md

@@ -0,0 +1,56 @@
+---
+description: "Fetch the latest failed iOS CI run's logs and categorize the failure"
+---
+
+# /ios-ci-logs
+
+Fetch logs from the latest failed iOS CI build and diagnose.
+
+## Steps
+
+1. Find the latest failed run:
+   ```
+   gh run list --workflow=ios.yml --limit=10 --json databaseId,conclusion,displayTitle,headBranch
+   ```
+   Pick the most recent with `"conclusion": "failure"`.
+
+2. Get the failed job(s) and steps:
+   ```
+   gh run view <run-id> --log-failed
+   ```
+
+3. Identify the failure category. Common iOS CI failure modes for
+   RN projects:
+
+   | Symptom in logs | Likely cause |
+   |---|---|
+   | `No matching provisioning profiles found` | Profile expired or bundle ID mismatch |
+   | `Code signing is required for product type 'Application'` | Missing/wrong signing identity in CI |
+   | `error: Sandbox: bash(...) deny(1) file-write-create` | Hermes/RN script needs entitlements or permissions tweak |
+   | `ld: framework not found` | Pod install missed a transitive dep — bump pod cache invalidation |
+   | `RCT-Folly compile error` | Xcode version mismatch with RN version |
+   | `pod install` fails with `CDN: trunk URL couldn't be downloaded` | CocoaPods CDN flake — retry |
+   | `Apple ID authentication failed` (during TestFlight upload) | App-specific password expired or App Store Connect API key rotated |
+   | `ITMS-90xxx` errors | Apple's validation rejected the build — read the message; usually missing usage strings or icon dimensions |
+   | `EX_BAD_ACCESS` during build | Random Xcode flake — re-run before investigating |
+
+4. Report:
+   - The failed step name and the lines around the first real error (not the whole log).
+   - Categorized cause (from the table above or a new diagnosis).
+   - Concrete fix suggestion. For "random flake" categories,
+     suggest re-running before code changes.
+
+5. If the failure looks transient, suggest:
+   ```
+   gh run rerun <run-id> --failed
+   ```
+   This re-runs only the failed jobs without re-doing successful
+   ones.
+
+## Don't
+
+- Don't dump the entire log — summarize.
+- Don't propose code changes for transient/infra failures (cert
+  renewal, CDN flakes, runner issues).
+- Don't suggest bumping Xcode or RN versions to "fix" a build error
+  without verifying that's actually the cause.

package/commands/native-rn-monorepo/ios-ci-status.md

@@ -0,0 +1,52 @@
+---
+description: "Check the latest iOS CI run status and whether the TestFlight upload step ran"
+effort: low
+---
+
+# /ios-ci-status
+
+Check the status of the most recent iOS CI build.
+
+## Steps
+
+1. List recent runs of the iOS workflow:
+   ```
+   gh run list --workflow=ios.yml --limit=5
+   ```
+   (Replace `ios.yml` with the actual filename — confirm with
+   `gh workflow list` once.)
+
+2. Identify the latest run's status. Possible states:
+   - `queued` / `in_progress` → still running
+   - `completed` + conclusion `success` → built and (likely)
+     uploaded to TestFlight
+   - `completed` + conclusion `failure` → failed, recommend
+     `/ios-ci-logs`
+   - `completed` + conclusion `cancelled` → manually cancelled
+
+3. For an in-progress run, optionally watch:
+   ```
+   gh run watch <run-id>
+   ```
+
+4. For a completed successful run, summarize:
+   - Run duration
+   - Commit SHA being built (from
+     `gh run view <run-id> --json headSha,displayTitle`)
+   - Whether TestFlight upload step ran (look for it in the job
+     list: `gh run view <run-id>`)
+   - Suggest checking TestFlight directly for processing status
+     (Apple's processing takes 5–30 min after upload)
+
+5. If multiple recent runs failed, report the trend, not just the
+   latest. Repeated failures on the same step often indicate a
+   systemic issue (cert expired, provisioning profile mismatch,
+   dependency drift).
+
+## Don't
+
+- Don't poll repeatedly in a tight loop — once or twice is enough;
+  use `gh run watch` for live updates.
+- Don't claim success based on workflow status alone if the
+  TestFlight upload step is in a separate job — verify that job
+  specifically.

package/commands/native-rn-monorepo/ios-ci-trigger.md

@@ -0,0 +1,59 @@
+---
+description: "Trigger the iOS GitHub Actions workflow for the pushed branch and report the run URL"
+effort: low
+---
+
+# /ios-ci-trigger
+
+Kick off the iOS build on GitHub Actions. Use after any change that
+could affect iOS (native bridge code, `ios/` files, `Podfile`, RN
+version bumps, or shared JS that's iOS-sensitive).
+
+## Prereq
+
+- `gh` CLI installed and authenticated: `gh auth status` should
+  show your account.
+- The iOS workflow file exists at `.github/workflows/<filename>.yml`.
+  Confirm by listing: `gh workflow list`.
+
+## Steps
+
+1. Confirm clean working tree — uncommitted changes won't reach CI:
+   ```
+   git status
+   ```
+   If dirty, ask the user whether to commit/push first.
+2. Confirm pushed:
+   ```
+   git rev-parse HEAD
+   git ls-remote origin HEAD
+   ```
+   These should match. If not, `git push` first.
+3. Trigger the workflow (replace `ios.yml` with the actual filename
+   from `gh workflow list`):
+   ```
+   gh workflow run ios.yml --ref <branch>
+   ```
+   For workflow with inputs (e.g., a `clear-cache` flag):
+   ```
+   gh workflow run ios.yml --ref <branch> -f clear-cache=true
+   ```
+4. Wait briefly for the run to register (workflow_dispatch can take
+   5–15s):
+   ```
+   sleep 10
+   gh run list --workflow=ios.yml --limit=1
+   ```
+5. Report the run URL: `gh run view <run-id> --web` or just print
+   the URL.
+6. Suggest follow-up: `/ios-ci-status` to check progress,
+   `/ios-ci-logs` if it fails.
+
+## Don't
+
+- Don't trigger on every commit — this burns macOS minutes (10x the
+  cost of Linux runners).
+- Don't trigger from a dirty working tree without committing first
+  — CI builds the pushed HEAD, not your local files.
+- Don't kick off duplicate runs while one is in progress — cancel
+  the old one or wait.

package/commands/native-rn-monorepo/rn-reset.md

@@ -0,0 +1,50 @@
+---
+description: "Full React Native cache reset (Metro, Watchman, node_modules, Gradle) for stale-state symptoms"
+effort: low
+---
+
+# /rn-reset
+
+Full reset of React Native caches when builds misbehave with
+stale-state symptoms.
+
+Linux/Windows version — no iOS local steps. iOS cache resets happen
+on the CI runner.
+
+## When to use
+
+Symptoms that warrant this command:
+
+- "Unable to resolve module" for a module that exists
+- Metro showing stale code after edits
+- Android build fails with `Duplicate class` errors after a
+  dependency change
+- Hermes crashes that don't reproduce on a fresh checkout
+
+Run this only for cache-related symptoms — it is slow and destructive.
+
+## Steps
+
+1. Stop Metro: `pkill -f "react-native start" || true` (Linux) or
+   `taskkill /F /IM node.exe` (Windows, careful — kills all node).
+2. Clear Watchman if installed:
+   `watchman watch-del-all 2>/dev/null || true`
+3. Clear Metro cache: `rm -rf $TMPDIR/metro-* $TMPDIR/haste-map-*`
+   (Linux) or `del /s /q %TEMP%\metro-* %TEMP%\haste-map-*`
+   (Windows).
+4. Reinstall node_modules — match the lockfile present:
+   - `package-lock.json` → `rm -rf node_modules && npm install`
+   - `yarn.lock` → `rm -rf node_modules && yarn install`
+   - `pnpm-lock.yaml` → `rm -rf node_modules && pnpm install`
+5. Android Gradle: `cd android && ./gradlew clean && cd ..`
+6. Restart Metro: `npx react-native start --reset-cache`
+
+For iOS: a CI re-run with caches cleared. Trigger via
+`/ios-ci-trigger` with the `clear-cache` input if your workflow
+supports it.
+
+## Don't
+
+- Don't run this in CI — it's a local-debugging tool.
+- Don't do this without committing or stashing in-flight changes
+  first.