minors-readiness

A sentence saying "for users 18+" and a checkbox do not create an adult-only product. This skill compares the stated audience with the evident audience and with what the product actually does with age.

Activate when

• The product could appeal to children (games, education, toys, social, creator tools, family apps, characters/cartoon style, school context).
• A date-of-birth, age, grade, or parent field exists; terms or copy state an age rule; accounts or content are public between users.
• Not for a clearly adult B2B tool with no child signals: record the evidence and stop.

Working alone

This skill is self-contained. Its companions (declared in its metadata) are skills whose method it may need to do its own promised work. Use of a companion can be conditional: declaring one does not mean running it. When a companion's lane applies, use the skill if it is installed; if not, follow its short entry in references/companion-methods.md and say in your report which lanes ran inline at reduced depth. Never skip an applicable lane silently. Skills mentioned here only for escalation, referral, documentation, or optional deeper follow-up are not dependencies: report the hand-off and finish honestly.

Companions: analytics-privacy, third-party-privacy, design-system-reconnaissance.

Inspect

1. Stated audience: terms, privacy notice, footers, app store text, marketing ("for kids", "ages 6-12", "18+ only").
2. Evident audience signals: content and imagery style, gamification aimed at children, school/parent language, product category, influencers/characters, community features, sample data.
3. Age collection and use: DOB/age fields (required? validated? stored?); what happens on a "too young" answer (blocked? data kept? can the user simply retry with another date?); whether age drives behavior (feature limits, ads, content), whether the field is stored longer than needed.
4. Contradictions: an "18+" statement with a birth-year dropdown starting at 2015; a children's product with no age handling; analytics/advertising/replay running on pages plausibly used by minors; open chat, public profiles, or user-content sharing with unknown-age users; account creation allowing anonymous minors to share personal data.
5. Parental handling where the product is child-directed or collects from children: is there any parent/guardian flow? Does it exist in code or only in copy?
6. Third parties on child-plausible pages: advertising pixels, embedded social, replay (analytics-privacy, third-party-privacy).

Evidence that counts

Label each claim OBSERVED, SOURCE-INDICATED, DECLARED, INFERRED, UNKNOWN, or REVIEW REQUIRED. UNKNOWN is never a pass and never a failure.

• Stated audience is DECLARED. Evident audience is INFERRED (list the signals). A gap between them is a finding, not a verdict about the law.
• Whether the product is "directed to children" in a legal sense is REVIEW REQUIRED. Do not conclude it yourself.
• An age field that is collected but unenforced is SOURCE-INDICATED; prove the bypass by trying it on a test flow.
• Legal specifics: never from memory. When a rule, deadline, threshold, or required wording matters, read the current text or guidance at an official source while you run (start from references/official-sources.md), cite the source and access date, and treat applicability to this business as REVIEW REQUIRED. If you cannot look it up, the answer is UNKNOWN.

May change

Design first. Before creating or changing anything visible, inspect the project's existing design system (design-system-reconnaissance) and build from its tokens and components, by the component ladder: reuse, compose, extend, and only then create a matching component. Never impose a ReadyVibe look on the user's site.

• Make an existing age check actually enforce (server-side validation, not only UI; no auto-retry loophole) when the owner has stated the rule.
• Stop collecting age/DOB that nothing uses; remove age data from analytics.
• Align copy with the owner's actual audience statement.
• Never invent an age threshold, add a "Are you 18?" click-through as if it were verification, or add parental-consent flows you cannot back with real process.

Must not claim

"COPPA/GDPR-K compliant", "child-safe", "age-verified", "suitable for children", or that an age gate is verification. Do not state age thresholds by jurisdiction from memory.

Verify

Exercise the age flow: under-age answer, edge-age answer, retry with a different date, back button. Confirm server-side enforcement and that under-age data is not silently retained. Re-check that trackers do not run on child-plausible pages if the owner decides they should not.

Escalate

Any child-directed or mixed-audience signal: REVIEW REQUIRED, and regulated-domain-triggers. Collection of data from minors, public social features, advertising to minors, or sensitive categories: recommend legal review before launch, and stop ordinary work on that surface until the owner decides the audience.

No change is valid when

The evident audience is clearly adult/professional, no age or child signals exist, and copy is consistent. Say so with the signals you checked, and the recheck trigger (a game mode, a school offering).