Originality check

Skill rshankras/claude-code-apple-skills/skills/app-store/originality-check

Claude Code skills for Apple platform development (iOS, macOS, iPadOS) — product validation, code generation, App Store optimization, and more

Install

npx -y skills add rshankras/claude-code-apple-skills --skill originality-check

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

What its author says it does

Copied from the file, not written here

Guideline-4.3 anti-spam / originality gate — score whether an app (and each portfolio addition) is meaningfully distinct in function, content, and metadata before you invest or submit. Use at validation/new-app time and again before submission. Protects the whole developer account from 4.3 (spam/duplicate) rejections. NOT rejection-handler (that works an existing rejection) and NOT competitive-analysis (that positions in the market).

SKILL.md

4.1 KB, as published. Nobody here has run it

Originality Check

Decide, with evidence, whether an app is distinct enough to exist — before you build it or submit it.

At portfolio scale, shipping many similar small apps risks Guideline 4.3 (spam / duplicate) — this is the go/no-go distinctness gate that keeps that from happening.

Where it fits (read the seams)

Not rejection-handler. That works a rejection you already have. This is upstream — it prevents the 4.3 by catching sameness before you ship.
Not competitive-analysis / market-research. Those size demand and position you in the market. This judges distinctness (function + content + metadata) vs your own portfolio and vs near-identical competitors — a spam risk, not a demand question.
Two moments to run it: at validate / new-app (don't build a dup) and before submit (don't trip 4.3). Also periodically across the portfolio (internal cannibalization / template-sameness).

Prerequisites

The app idea or a shipped app to evaluate (name, one-line function, target metadata).
Optional: .planning/VALIDATION.md (competitor + market data). If missing/stale, gather fresh via WebSearch or the product/competitive-analysis skill.
Optional ASC access to read the developer's existing portfolio (list_apps / get_metadata).

Flow

Internal check (your own portfolio). list_apps → for each shipped app read its positioning (get_metadata). Does the candidate overlap one you already ship in function, code template, or metadata? Two apps that differ only in theme/reskin = 4.3 risk.
External check (the market). Read VALIDATION.md if present; otherwise WebSearch for close look-alikes. Judge: is the core function a thin reskin of an existing app, or a genuine wedge?

Distinctness scorecard. Score each dimension meaningful difference vs cosmetic, and flag any that is only skin-deep:

Dimension	Distinct if…
Function	it does something materially different, not a template swap
Content / data	unique data or content, not a generic wrapper
Metadata	name / keywords / screenshots not near-identical to siblings or competitors
UX / value	a real reason a user picks this one

Verdict + remedy.
- Distinct → proceed.
- Borderline → give concrete ways to differentiate (merge sibling apps into one configurable app, add the unique wedge, or drop it); if approved, name the specific wedge that MUST be built to clear 4.3.
- Duplicate → recommend not shipping; consolidate any existing thin apps into one strong app instead.
Record. Write the verdict + reasoning to .planning/ (VALIDATION or STATE). For a borderline-approved app, record the wedge as a build requirement so plan/build deliver it.

Done

A written verdict (distinct / borderline+wedge / duplicate) with per-dimension reasoning, and — if borderline — the specific differentiation that must ship before submission.

Caveats

Cosmetic theming ≠ differentiation — Apple judges function + metadata similarity, not intent.
Protect the account. When in doubt between "borderline ship" and "consolidate," prefer one strong app over several thin ones.
Guideline numbers/text drift — confirm current 4.3 wording at the App Review Guidelines (captured 2026-07).