Skip to main content

write-ui-module-readme

Write concise module README files for `packages/ui/src/lib/*` primitives. Use when drafting or revising README docs for UI package modules like popover, press, or other first-party UI helpers, especially when the main goal is agent-friendly usage guidance and a short explanation of each exported value.

معلومات المصدر

المستودع
remix-run/remix
آخر نشاط في المصدر
٢٧ أبريل ٢٠٢٦ في ٢٠:٣٨
لغة SKILL.md المكتشفة
الإنجليزية
النجوم
٣٣٬٤٠٨
التفرعات
٢٬٧٨٧

خيارات التثبيت

يُحدَّد Prompt الذي يراجع المصدر أولًا بشكل افتراضي. يمكنك التبديل إلى أمر مباشر أو تنزيل نسخة محلية.

مراجعة ملفات المصدر

اقرأ SKILL.md وأي ملفات مرافقة يعرضها SkillsMP قبل أن تقرر التثبيت.

عرض SKILL.md

SKILL.md
تعليمات المصدر · معاينة للقراءة فقط
name
write-ui-module-readme
description
Write concise module README files for `packages/ui/src/lib/*` primitives. Use when drafting or revising README docs for UI package modules like popover, press, or other first-party UI helpers, especially when the main goal is agent-friendly usage guidance and a short explanation of each exported value.
# Write UI Module Readme ## Overview Write module README files for `packages/ui/src/lib/*` as practical usage guides for agents and developers. Optimize for fast, correct adoption: - show the canonical usage first - explain each exported `module.*` value briefly - document the important behavior guarantees - avoid implementation-history dumps and internal type walkthroughs These are module docs for UI primitives, not package-level READMEs. ## Workflow 1. Read the module source first. - Identify the actual public exports and their roles. - Confirm the behavior from code, not memory. 2. Read nearby tests and demos. - Pull behavior notes from tests. - Reuse the most realistic example shape from a demo when available. 3. Document the module as it exists today. - Do not describe planned APIs. - Do not document internal coordinators, private state, or workaround history unless they are part of the public contract. 4. Keep the README short and scannable. - Prefer short paragraphs and flat bullets. - Use one strong canonical example instead of multiple weak snippets. ## Recommended Structure Use this structure unless the module needs something more specific: 1. `# ModuleName` 2. One or two sentences: what it is, what it is for, and what it is not for 3. `## Usage` 4. `## \`module.\*\`` or equivalent export reference 5. `## Behavior Notes` 6. `## When To Use Something Else` when the primitive sits below higher-level widgets ## Usage Section Lead with a copy-pasteable example that shows the real shape of usage. - Prefer production-shaped UI over toy snippets. - Use the actual exported API names. - Show the minimum surrounding structure needed to use the primitive correctly. - If the module composes with other first-party UI helpers, show that composition. For popup-style primitives, the example should usually show: - trigger - surface/root - one or two meaningful controls inside - dismissal or completion path ## Export Reference After the example, explain the role of each important exported value in a few lines each. For example: - `module.context`: what shared coordination it provides - `module.button(...)`: what it registers or activates - `module.surface()`: what it turns the host into - `module.dismiss()`: how it closes or finalizes - `module.change`: what event it emits and the useful event fields Keep this section focused on: - what it does - where to apply it - key arguments or options - observable behavior Do not turn this into a full API dump. ## Behavior Notes Document the behaviors that matter when composing with the primitive: - focus movement - dismissal rules - anchoring rules - keyboard behavior - multi-trigger behavior - any important guarantees tested in the module suite This section should save a reader from opening the implementation just to answer “what happens when...?” ## Scope Rules - Treat the primary audience as an agent or developer trying to use the primitive correctly. - Prefer usage guidance over architecture explanation. - Name public events and useful event fields, but avoid deep event-class internals unless necessary. - Do not document private classes, internal coordinators, or helper mixins unless the README is specifically for that helper. - Do not pad the README with generic accessibility or popover theory the agent already knows. ## Good Patterns - “Use `popover` directly for custom floating panels like filters or view options.” - “Wrap triggers and the surface in `popover.context`.” - “The opener that started the current session controls anchoring and focus return.” - “Do not use this as the final consumer-facing primitive for menus or comboboxes.” ## Checklist - Did you read the module source first? - Did you confirm behavior from tests or demos? - Does the README start with a realistic usage example? - Does it explain each important exported value briefly? - Does it include behavior notes that matter in practice? - Does it avoid internal implementation detail and historical debugging context? - Would an agent know how to use the primitive correctly without opening the source?
عرض على GitHub