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).
Scanned 9/6/2026
Install to Claude Code
npx -y skills add rshankras/claude-code-apple-skills --skill originality-check --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Originality Check?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/rshankras-originality-check)More formats (shields.io, HTML) on the badges page.
---
name: originality-check
description: 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).
allowed-tools: [Read, Write, WebSearch, Glob, Grep, AskUserQuestion, mcp__asc-metadata__list_apps, mcp__asc-metadata__get_metadata]
last_verified: 2026-07-16
review_by: 2027-06-22
---
# 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
1. **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.
2. **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?
3. **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 |
4. **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.
5. **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](https://developer.apple.com/app-store/review/guidelines/) (captured 2026-07).
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!