seed-write-lynx-component-docs

Writing Lynx component documentation

Lynx documentation and examples are written based on the React documentation of the same component. For supported features, keep the section order, example titles, scenarios, and user-visible results as identical as possible. Change only the parts that differ because of the Lynx runtime, and note the reason.

Getting started

1. Read the AGENTS.mdthat applies from the repository root to the modification path.
2. Additionally read docs/AGENTS.mdfor documentation, docs/examples/lynx/AGENTS.mdfor examples, and docs/scripts/lynx-examples/AGENTS.mdfor preview builds or manifests.
3. seed-component-mapto find the target's package exports, Registry, React and Lynx documentation, and examples, and read the resulting paths directly.
4. If differences between the React and Lynx public APIs affect the documentation structure, use seed-api-parity. Distinguish intentional differences due to platform constraints from omissions that need to be filled in.

Decide the distribution path first

seed-component-mapDetermine the consumption path for documentation and examples from the Registry and package export results of

Distribution method	Installation, Usage, runnable examples
Registry distribution	Use the Registry installation method and the installed path. docs/examples/lynxand vendored app examples also use the same Registry wrapper.
package-only	@seed-design/lynx-reactdirectly use the actual public exports of. Do not create Registry installation steps that do not exist.
package + Registry	Basic usage and runnable examples use the Registry path. Low-level package APIs are placed as separate examples only when explaining content that users must compose themselves.

Do not infer the distribution method merely from the existence of a Registry file. Check the Registry registration information, the installation method in the current documentation, and the example consumption path together.

Aligning with the React documentation

Before working, create the following mapping table. A short note that can be included in the result is sufficient.

React section/scenario	Lynx handling	Basis
Same feature supported	Keep the title, order, and user-visible results	Corresponding public API/example path
Lynx-style conversion needed	Keep user-visible results and convert only events, elements, and accessibility attributes	Basis for platform difference
Not supported	Do not create a runnable example; explain the difference and alternatives	Basis in runtime or public API

Do not remove or rename scenarios supported by the React documentation without reason. Add installation, execution, and compatibility guidance needed only for Lynx in a position that does not break the common section flow. If there is no corresponding React documentation, use the closest Lynx documentation structure and the target component's actual public API as the basis.

Workflow

1. Collect sections, example titles, scenario files, and user outcomes from the React documentation.
2. Classify each scenario as fully supported, Lynx-style conversion, or unsupported.
3. Investigate the Lynx APIs, CSS, and elements used by the component. find-referFirst look for a local official documentation snapshot with lynx-api-docs, check API and Engine compatibility with lynx-check-css-support.
4. Writing rulesWrite frontmatter, MDX, and example entries according to
5. Check the browser preview in the actual documentation dev server or docs/out의 LynxComponentExample.
6. If the browser and actual Lynx results differ, preview and runtimedivide them into documentation issues, preview issues, and component/runtime issues according to
7. If you newly claim native results or change example behavior, verify directly in an available Lynx host app or examples/lynx-spa. If there is no environment, report the scope that could not be verified and do not add workaround implementations.
8. Verification procedureand report the environments verified and remaining limitations.

Work boundaries

• If only the description or code exposure is wrong, docs/ fix it within
• Fix example entries, style registration order, bundle URLs, and manifest issues in the documentation execution environment.
• Separate API or behavior issues that also reproduce in the actual host app into component work.
• Do not change a distributed component based only on the limitations of the browser preview.
• Do not imitate unsupported features as if they work in documentation examples.

Writing principles

• Runnable examples show the consumption path and usage patterns recommended in the actual host app.
• Registry-distributed components use the Registry. Only package-only components are imported directly from @seed-design/lynx-react.
• When the same functionality is supported, preserve the React documentation's section order, example titles, scenarios, wording, and user outcomes as much as possible.
• Verify official materials for Engine/XElement compatibility with find-refer와 lynx-api-docs. For CSS properties and values, use lynx-check-css-supporttogether. Do not work around this with Context7 or general web searches, and do not guess versions.
• In general documentation work, do not create standalone HTML, a separate Vite app, or temporary React pages.
• Briefly note native behaviors that cannot be represented in the browser preview near the relevant example.
• Put a directly accessible .lynx.bundle HTTP(S) address in the QR code. lynx:// Use deep links only for the Explorer run button.
• false, null, 0Values that may not display JSX as-is, such as JSON.stringify, are serialized with
• Register shared styles before components. Do not re-import Recipe CSS owned by a component in examples.