agentleFS
OpenAIKnown publisheropenai/community-plugins/plugins/react-native-to-swiftui/skills/audit-ios-readiness/SKILL.md

audit-ios-readiness

Skill18 starsChanged 2 months agoApache-2.0View on GitHub

Run a read-only App Store-readiness preflight for a declared iOS target without claiming approval or submitting anything.

The file

We split this skill into the rules it gives an agent

6 rules. About 0 are common, 4 are distinctive, and 2 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈4

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 2

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Do not edit metadata, entitlements, privacy manifests, assets, source, signing, provisioning, or App Store Connect records.

    line 16
  2. Distinctive:

    Do not archive, upload, submit, notarize, create credentials, install tools, download runtimes, or accept Apple licenses.

    line 17
  3. Distinctive:

    Do not request or expose certificates, profiles, tokens, customer data, private URLs, or production credentials.

    line 18
  4. Distinctive:

    Never state or imply guaranteed App Store approval.

    line 20
  5. Very specific:

    When available, use the bundled scripts/native-port.mjs audit guardrail for the bounded static pass.

    line 36
  6. Very specific:

    Use preflight ready only when there are no local failures or blocked required gates.

    line 49

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Audit iOS Readiness

Perform a bounded, read-only preflight for one declared iOS target after a port. This is an evidence-backed readiness report, not App Store approval.

Required scope

Require the explicit target directory/module, bundle target or scheme when present, approved parity contract, backend/data-collection contract, and licensing/provenance record. Stop if the target, backend contract, licensing, or release expectations are ambiguous.

Safety contract

  • Do not edit metadata, entitlements, privacy manifests, assets, source, signing, provisioning, or App Store Connect records.
  • Do not archive, upload, submit, notarize, create credentials, install tools, download runtimes, or accept Apple licenses.
  • Do not request or expose certificates, profiles, tokens, customer data, private URLs, or production credentials.
  • Inspect only the declared target and approved supporting files. Keep any optional logs under an explicitly approved disposable directory.
  • Never state or imply guaranteed App Store approval.

Preflight checks

Review what can be established locally:

  • bundle identifier, version/build values, deployment target, supported devices, orientations, and required capabilities;
  • Info.plist usage descriptions, privacy manifest declarations, tracking/data-collection claims, and backend/data-flow consistency;
  • entitlements, background modes, networking/ATS choices, permissions, deep links, notifications, and account/deletion behavior when relevant;
  • app icon, launch treatment, asset provenance, fonts, third-party SDK inventory, dependency licenses, and attribution;
  • accessibility evidence for labels, traits, focus order, Dynamic Type, contrast, reduced motion, and assistive-technology reachability;
  • release configuration, debug flags, logging, test hooks, crash paths, localization, and user-facing error/empty/offline states;
  • available deterministic checks and any existing build, Simulator, or XCUITest evidence.

Consult current Apple documentation when a rule may have changed, and label an inference as such. Local checks cannot replace archive validation, App Store Connect metadata, TestFlight, legal review, or human App Review.

When available, use the bundled scripts/native-port.mjs audit guardrail for the bounded static pass. Treat its preflightOnly: true and guaranteedApproval: false fields as invariants, not as a substitute for the human release review below.

Report format

Return:

  1. scope and evidence inspected;
  2. a table of PASS, WARN, FAIL, BLOCKED, or NEEDS HUMAN findings with evidence and the smallest next action;
  3. privacy, permissions, accessibility, licensing, and backend-contract summaries;
  4. platform gates already evidenced versus unavailable;
  5. a release-owner checklist for human decisions;
  6. an explicit conclusion: preflight ready, preflight blocked, or not ready.

Use preflight ready only when there are no local failures or blocked required gates; still say that it is not guaranteed App Store approval.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.