native-component-doc

Generates MDX documentation for React Native components in the @skyroc/native-ui library.

792|173|Updated Aug 8, 2024
One-click install
npx skills add https://github.com/Ohh-889/skyroc-admin --skill native-component-doc
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: native-component-doc
Source: https://github.com/Ohh-889/skyroc-admin/tree/main/.agents/skills/native-component-doc
Command: npx skills add https://github.com/Ohh-889/skyroc-admin --skill native-component-doc

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Writing documentation for React Native UI components requires cross-checking source code, TypeScript types, variant definitions, and playground demos, which is tedious and error-prone when done manually. This Skill automates the full workflow of locating component source files, validating implementation consistency, and producing spec-compliant MDX documentation for the native-ui-docs site.

Core Features & Use Cases

  • Automated file location: Maps a component name (e.g., ActionSheet) to its source directory, playground demos, route page, and MDX document path using kebab-case slug conventions.
  • Implementation consistency validation: Cross-verifies props declared in types.ts against actual component destructuring, defaultVariants, classNames slots, and RN-specific behaviors like hitSlop and accessibilityState before writing docs.
  • Spec-compliant MDX generation: Produces documentation with Demo references, PropsTable, UnionType, and TypeTable sections following fumadocs conventions, including sidebar meta.json registration and demo coverage checks.
  • Use Case: Ask the AI to write documentation for the Button component, and it reads the source and demos, creates any missing playground demos with named exports, generates the MDX page, and verifies demo-to-doc coverage with a diff command.

Quick Start

Write the documentation for the ActionSheet component in @skyroc/native-ui following the native-ui-docs conventions.

Frequently Asked Questions about native-component-doc

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I write documentation for a React Native UI component?

Provide the component name such as Button or ActionSheet, and the workflow locates its source in packages/native/ui, reads playground demos, validates props against types.ts and variants files, then generates a spec-compliant MDX page with Demo, PropsTable, and type sections.

How are playground demos referenced in native-ui MDX docs?

Demos are referenced with the format <Demo src="@playground/$slug/$DemoName" /> without a modules directory. Each demo must be a named export matching its filename, and every demo in the index.tsx summary page must appear exactly once in the document.

Does this documentation workflow differ from web-ui component docs?

Yes. Native docs use named exports instead of default exports, omit inline code blocks because Demo renders full source, skip 'use client' directives, and include a right-panel phone preview rendered from the playground route page.

Why must demo components use named exports in the playground?

The demo-preview.tsx loader dynamically imports demo modules and retrieves components by module name via mod[exportName]. Using default exports or mismatched names causes the preview to fail to resolve the component.

What happens when component types and implementation are inconsistent?

The workflow flags it as an implementation issue first and fixes the source or types when possible rather than documenting around the bug. If unfixable, the risk is reported and the undocumented capability is never promised in the docs.

How is type completeness enforced in PropsTable and TypeTable?

Every non-builtin PascalCase type referenced in tables must be defined in the page's type section via TypeTable or UnionType, or registered in type-registry.ts for cross-page links. Short union types are inlined directly instead of creating separate type entries.