write-lynx-component-docs

Writing Lynx component documentation

Goal

Write Lynx component documentation and runnable examples in accordance with repository rules. Do not hide the differences between the web documentation preview and the actual Lynx app environment, and respect the boundary between documentation work and runtime implementation changes.

Getting started

1. Read all of the AGENTS.mdthat apply to the repository root and the working path.
2. When modifying a documentation page, read docs/AGENTS.md.
3. When modifying a runnable example, read docs/examples/lynx/AGENTS.md.
4. When modifying the preview build or manifest, read docs/scripts/lynx-examples/AGENTS.md.
5. Find the React documentation and examples for the same component and use the section structure, scenarios, and behavior shown to users as the reference point.
6. Compare existing Lynx documentation·examples with a nearby Lynx component to decide on the platform conversion approach.

Scope assessment

Before starting work, classify the problem as one of the following three.

• Documentation issue: Only the documentation presentation is wrong, such as descriptions, code exposure, callouts, or tab structure.
• Example·preview issue: The documentation execution environment is wrong, such as example entries, style registration order, bundle URLs, or manifests.
• Component·runtime issue: It reproduces in the actual host app with the same API and usage pattern.

Resolve documentation issues and example issues within docs/ . Do not change distributed components solely because of web preview limitations. For issues that also reproduce in the actual host app, do not add documentation-only exceptions; separate them as component work.

Workflow

1. Check the React documentation·examples for the same component together with the Lynx public API.
2. Investigate the Lynx APIs·syntax·CSS·elements used in the component source, and determine the minimum Engine version and the XElements used based on the official Lynx API documentation and compatibility data.
3. Authoring rulesWrite the compatibility frontmatter, MDX, and example entries according to
4. WebLynx is checked only in the actual documentation development server and docs/out의 LynxComponentExample.
5. If the web and native results differ, classify the cause according to preview and runtime.
6. When possible, check native-only behavior in Lynx Explorer or PlayLynx. If there is no device or session, report it as an environment blocker without a workaround implementation.
7. Verification procedurePerform

and report the environments checked and remaining constraints.

• Core principles
• @seed-design/lynx-reactExamples show the usage pattern recommended in the actual host app as is.
• Use only the public exports of
• When writing or modifying Lynx component documentation, also check the Engine·XElement compatibility frontmatter. For versions, official Lynx API documentation와 Lynx Compatibility Data, and do not guess.
• In ordinary documentation work, do not move WebLynx examples to a standalone HTML, a separate Vite app, or a temporary React page.
• Consider a standalone reproduction environment only when the user has requested diagnosis of the documentation runtime, or when the issue reproduces in the production documentation as well. Before starting, announce that the scope of work is expanding.
• For native behaviors that cannot be represented in the web preview, provide guidance with a short callout.
• In the QR code, put a directly accessible .lynx.bundle HTTP(S) address. lynx:// Use deep links only for the Explorer run button.
• In the status output, false, null, 0values that may not be displayed as-is as JSX, such as JSON.stringifyserialize as
• Register shared styles before components. Do not re-import recipe CSS owned by a component in the example.
• Reflect newly confirmed repeatable rules in the corresponding reference of this skill.