originality-check

Name: originality-check
Author: rshankras

548stars46forks

How to install originality-check?

rshankras/claude-code-apple-skills/originality-check

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

Installs into the current project.

Summary

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 accoun

Files · 1

View on GitHub

SKILL.md

1	# Originality Check
2
3	Decide, with evidence, whether an app is distinct enough to exist — before you build it or submit it.
4
5	> At portfolio scale, shipping many similar small apps risks Guideline 4.3 (spam / duplicate)
6	> — this is the go/no-go distinctness gate that keeps that from happening.
7
8	## Where it fits (read the seams)
9
10	- Not `rejection-handler`. That works a rejection you already have. This is upstream — it
11	prevents the 4.3 by catching sameness before you ship.
12	- Not `competitive-analysis` / `market-research`. Those size demand and position you in the
13	market. This judges distinctness (function + content + metadata) vs your own portfolio and vs
14	near-identical competitors — a spam risk, not a demand question.
15	- Two moments to run it: at `validate` / `new-app` (don't build a dup) and before `submit`
16	(don't trip 4.3). Also periodically across the portfolio (internal cannibalization / template-sameness).
17
18	## Prerequisites
19
20	- The app idea or a shipped app to evaluate (name, one-line function, target metadata).
21	- Optional: `.planning/VALIDATION.md` (competitor + market data). If missing/stale, gather fresh
22	via WebSearch or the `product/competitive-analysis` skill.
23	- Optional ASC access to read the developer's existing portfolio (`list_apps` / `get_metadata`).
24
25	## Flow
26
27	1. Internal check (your own portfolio). `list_apps` → for each shipped app read its positioning
28	(`get_metadata`). Does the candidate overlap one you already ship in function, **code
29	template, or metadata**? Two apps that differ only in theme/reskin = 4.3 risk.
30	2. External check (the market). Read `VALIDATION.md` if present; otherwise `WebSearch` for close
31	look-alikes. Judge: is the core function a thin reskin of an existing app, or a genuine wedge?
32	3. Distinctness scorecard. Score each dimension meaningful difference vs cosmetic, and flag any
33	that is only skin-deep:
34
35	\| Dimension \| Distinct if… \|
36	\|---\|---\|
37	\| Function \| it does something materially different, not a template swap \|
38	\| Content / data \| unique data or content, not a generic wrapper \|
39	\| Metadata \| name / keywords / screenshots not near-identical to siblings or competitors \|
40	\| UX / value \| a real reason a user picks this one \|
41
42	4. Verdict + remedy.
43	- Distinct → proceed.
44	- Borderline → give concrete ways to differentiate (merge sibling apps into one configurable
45	app, add the unique wedge, or drop it); if approved, name the specific wedge that MUST be built
46	to clear 4.3.
47	- Duplicate → recommend not shipping; consolidate any existing thin apps into one strong
48	app instead.
49	5. Record. Write the verdict + reasoning to `.planning/` (VALIDATION or STATE). For a
50	borderline-approved app, record the wedge as a build requirement so `plan`/`build` deliver it.
51
52	## Done
53
54	- A written verdict (distinct / borderline+wedge / duplicate) with per-dimension reasoning, and —
55	if borderline — the specific differentiation that must ship before submission.
56
57	## Caveats
58
59	- Cosmetic theming ≠ differentiation — Apple judges function + metadata similarity, not intent.
60	- Protect the account. When in doubt between "borderline ship" and "consolidate," prefer one
61	strong app over several thin ones.
62	- Guideline numbers/text drift — confirm current 4.3 wording at the
63	[App Review Guidelines](https://developer.apple.com/app-store/review/guidelines/) (captured 2026-07).

People who liked this also viewed

6 picks

Type

originality-check

548stars46forks

View on GitHub

How to install originality-check?

rshankras/claude-code-apple-skills/originality-check

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

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Originality Check
2
3	Decide, with evidence, whether an app is distinct enough to exist — before you build it or submit it.
4
5	> At portfolio scale, shipping many similar small apps risks Guideline 4.3 (spam / duplicate)
6	> — this is the go/no-go distinctness gate that keeps that from happening.
7
8	## Where it fits (read the seams)
9
10	- Not `rejection-handler`. That works a rejection you already have. This is upstream — it
11	prevents the 4.3 by catching sameness before you ship.
12	- Not `competitive-analysis` / `market-research`. Those size demand and position you in the
13	market. This judges distinctness (function + content + metadata) vs your own portfolio and vs
14	near-identical competitors — a spam risk, not a demand question.
15	- Two moments to run it: at `validate` / `new-app` (don't build a dup) and before `submit`
16	(don't trip 4.3). Also periodically across the portfolio (internal cannibalization / template-sameness).
17
18	## Prerequisites
19
20	- The app idea or a shipped app to evaluate (name, one-line function, target metadata).
21	- Optional: `.planning/VALIDATION.md` (competitor + market data). If missing/stale, gather fresh
22	via WebSearch or the `product/competitive-analysis` skill.
23	- Optional ASC access to read the developer's existing portfolio (`list_apps` / `get_metadata`).
24
25	## Flow
26
27	1. Internal check (your own portfolio). `list_apps` → for each shipped app read its positioning
28	(`get_metadata`). Does the candidate overlap one you already ship in function, **code
29	template, or metadata**? Two apps that differ only in theme/reskin = 4.3 risk.
30	2. External check (the market). Read `VALIDATION.md` if present; otherwise `WebSearch` for close
31	look-alikes. Judge: is the core function a thin reskin of an existing app, or a genuine wedge?
32	3. Distinctness scorecard. Score each dimension meaningful difference vs cosmetic, and flag any
33	that is only skin-deep:
34
35	\| Dimension \| Distinct if… \|
36	\|---\|---\|
37	\| Function \| it does something materially different, not a template swap \|
38	\| Content / data \| unique data or content, not a generic wrapper \|
39	\| Metadata \| name / keywords / screenshots not near-identical to siblings or competitors \|
40	\| UX / value \| a real reason a user picks this one \|
41
42	4. Verdict + remedy.
43	- Distinct → proceed.
44	- Borderline → give concrete ways to differentiate (merge sibling apps into one configurable
45	app, add the unique wedge, or drop it); if approved, name the specific wedge that MUST be built
46	to clear 4.3.
47	- Duplicate → recommend not shipping; consolidate any existing thin apps into one strong
48	app instead.
49	5. Record. Write the verdict + reasoning to `.planning/` (VALIDATION or STATE). For a
50	borderline-approved app, record the wedge as a build requirement so `plan`/`build` deliver it.
51
52	## Done
53
54	- A written verdict (distinct / borderline+wedge / duplicate) with per-dimension reasoning, and —
55	if borderline — the specific differentiation that must ship before submission.
56
57	## Caveats
58
59	- Cosmetic theming ≠ differentiation — Apple judges function + metadata similarity, not intent.
60	- Protect the account. When in doubt between "borderline ship" and "consolidate," prefer one
61	strong app over several thin ones.
62	- Guideline numbers/text drift — confirm current 4.3 wording at the
63	[App Review Guidelines](https://developer.apple.com/app-store/review/guidelines/) (captured 2026-07).

People who liked this also viewed

6 picks

Type