rshankras/originality-check

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 (captured 2026-07).