Skill flagged — suspicious patterns detected

ClawHub Security flagged this skill as suspicious. Review the scan results before using.

Audit App Store Readiness

v1.0.0

Audit an iOS app repo (Swift/Xcode or React Native/Expo) for App Store compliance and release readiness; output a pass/warn/fail report and publish checklist.

0· 1.9k·2 current·2 all-time
byTristan Manchester@tristanmanchester
Security Scan
VirusTotalVirusTotal
Suspicious
View report →
OpenClawOpenClaw
Benign
high confidence
Purpose & Capability
Name/description (iOS/App Store readiness) align with the included files and runtime requirements. The skill only requires git and contains a Node script and supporting reference docs that perform static repo inspection, plist parsing, and optional Xcode build checks—all appropriate for an audit tool.
Instruction Scope
SKILL.md instructs the agent to run the bundled audit.mjs script and to prefer read-only checks. It explicitly marks mutating operations (dependency installs, expo prebuild, signing, xcodebuild archive) as MUTATING and states they should only run with explicit user consent. The instructions reference only repo files and local developer tools; they do not direct data to any external network endpoint.
Install Mechanism
No install spec is provided (instruction + bundled script only). That is low-risk: nothing is downloaded or extracted at install time and the only runtime dependency is Node (for running the script) and git which are reasonable for this task.
Credentials
The skill requests no environment variables, no credentials, and no config paths. It does use local tools if present (plutil, python, xcodebuild) for higher-confidence parsing/build checks, which is proportional to its stated purpose.
Persistence & Privilege
always is false and the skill does not request persistent privileges or modify other skills. It does describe a 'fix mode' that proposes and applies patches (via an agent action like apply_patch) — this is normal for a repo-editing helper but should only be used when the user explicitly requests changes.
Assessment
This skill is coherent and appears to do what it says: static auditing of iOS/React Native/Expo repos with optional build checks. A few practical points before you run it: (1) By default it is read-only, but it can run mutating commands (npm/pod installs, xcodebuild archive, expo prebuild) and apply patches if you ask—review any proposed patches before applying. (2) Build-accuracy checks require macOS/Xcode; on non-mac machines the tool will fall back to static checks and mark build status as WARN. (3) The script reads repository files (including any committed secrets); do not run it on repos containing sensitive credentials you don't want inspected. (4) The tool executes local binaries (git, plutil, python, xcodebuild) — their presence affects behavior. (5) SKILL.md does not include any network endpoints; however, if you run the audit inside an agent with external network access, the generated report could be transmitted by the agent itself — ensure your agent's policies around data transmission are acceptable. If you want higher assurance, inspect the proposed patches and run the script in a sandbox or CI environment first.

Like a lobster shell, security has layers — review code before you run it.

Runtime requirements

🧾 Clawdis
Binsgit
latestvk979s48bm6xme67re463t5vh0h80ew5n
1.9kdownloads
0stars
1versions
Updated 1h ago
v1.0.0
MIT-0

App Store Readiness Audit

This skill reviews an app repository and produces a release readiness report for iOS App Store / TestFlight submission.

It supports:

  • Native iOS (Swift/Obj‑C, Xcode project/workspace)
  • React Native (bare)
  • Expo (managed or prebuild)

Quick start (recommended)

Run the read‑only audit script from the repo root:

{ "tool": "exec", "command": "node {baseDir}/scripts/audit.mjs --repo . --format md" }

If you want JSON output as well:

{ "tool": "exec", "command": "node {baseDir}/scripts/audit.mjs --repo . --format md --json audit.json" }

If the repo is a monorepo, point at the app directory:

{ "tool": "exec", "command": "node {baseDir}/scripts/audit.mjs --repo apps/mobile --format md" }

Output contract

Always return:

  • Overall verdict: PASS / WARN / FAIL
  • Detected project flavour and key identifiers (bundle id, version, build)
  • A list of checks with evidence and remediation steps
  • A Publish checklist the developer can tick off

Use: references/report-template.md

Safety rules (don’t break the repo)

Default to read‑only commands. Do not run commands that modify the workspace unless:

  • the user explicitly asks, or
  • the fix is trivial and clearly desired (then explain what will change first)

Examples of mutating commands:

  • dependency installs (npm i, yarn, pnpm i, pod install)
  • config generation (expo prebuild)
  • signing automation (fastlane match)
  • archiving (xcodebuild archive, eas build) — creates artefacts and may require signing

If you must run a mutating command, label it clearly as MUTATING before running.

Main workflow

1) Identify the repo and project flavour

Prefer scripted detection (audit.mjs). If doing manually:

  • Expo likely: package.json contains expo and app.json / app.config.* exists
  • React Native (bare): package.json contains react-native and ios/ exists
  • Native iOS: *.xcodeproj or *.xcworkspace exists

If multiple apps exist, pick the one matching the user’s intent; otherwise pick the directory with:

  • a single ios/<AppName>/Info.plist, and
  • exactly one .xcodeproj or .xcworkspace near the root.

2) Run static compliance checks (works everywhere)

Run these checks even without Xcode:

  • Repo hygiene: clean git status; obvious secrets not committed
  • iOS identifiers: bundle id, version, build number
  • App icons: includes an App Store (1024×1024) icon
  • Launch screen present
  • Privacy & permissions:
    • Privacy manifest present (PrivacyInfo.xcprivacy) or explicitly accounted for
    • Permission usage strings present when relevant (camera, location, tracking, etc.)
    • Avoid broad ATS exemptions (NSAllowsArbitraryLoads)
  • Third‑party SDK hygiene: licences, privacy manifests, tracking disclosures
  • Store listing basics: privacy policy URL exists somewhere in repo/docs; support/contact info

The script outputs PASS/WARN/FAIL for these.

3) Run build‑accuracy checks (macOS + Xcode, optional but high confidence)

Only if you have Xcode available (local macOS gateway or a paired macOS node).

Recommended sequence (creates build artefacts):

  1. Show Xcode + SDK versions: { "tool": "exec", "command": "xcodebuild -version" }

  2. List schemes (project/workspace as detected): { "tool": "exec", "command": "xcodebuild -list -json -workspace <path>.xcworkspace" } or { "tool": "exec", "command": "xcodebuild -list -json -project <path>.xcodeproj" }

  3. Release build for simulator (fast, avoids signing): { "tool": "exec", "command": "xcodebuild -workspace <...> -scheme <...> -configuration Release -sdk iphonesimulator -destination 'platform=iOS Simulator,name=iPhone 15' build" }

  4. If you need a distribution artefact (MUTATING / signing):

  • Prefer Fastlane if already configured
  • Otherwise xcodebuild archive + xcodebuild -exportArchive

If build checks aren’t possible, the report must explicitly say so and keep the verdict at WARN (unless there are definite FAIL items).

4) Produce the final readiness report

  • Use references/report-template.md
  • Include a “Go / No‑Go” recommendation:
    • FAIL → must fix before submitting
    • WARN → submission may work, but risk areas remain
    • PASS → ready to submit; remaining items are administrative

Manual checks the agent cannot fully verify

Always include these as a final checklist section (even if automated checks pass):

  • App Store Connect metadata: screenshots, description, keywords, age rating, pricing, categories
  • Privacy Nutrition Labels match actual behaviour
  • Export compliance (encryption) answers are correct
  • Content/IP rights: licences, third‑party assets, trademarks
  • Account / regional requirements (e.g. EU trader status if applicable)
  • In‑app purchases / subscriptions configured if used

See: references/manual-checklist.md

When the user asks “make it compliant”

Switch to fix mode:

  1. Identify failing items that can be fixed safely in‑repo (Info.plist strings, PrivacyInfo.xcprivacy template, ATS exceptions tightening, etc.)
  2. Propose minimal patches and apply with apply_patch
  3. Re‑run audit.mjs and update the report

Quick search

Comments

Loading comments...