haorantang97 Write the repository introduction
Read the repository presentation standard. Inspect actual entrypoints, human documentation, installation paths, licenses and tests before describing capabilities. Infer the repository name, audience and value from available evidence; ask only when an unresolved choice changes the result.
Make the first screen coherent: repository hero, language switcher, truthful badges, concise navigation when useful, and a concrete statement of what the reader can do. A collection's name must remain distinct from each child skill. Use the visual-assets module to replace unfinished artwork before delivery.
Choose structure by purpose. A single tool can lead directly into setup and an example. A collection should help readers choose from public tools before showing installation. A system needs a truthful component/flow map and explicit setup dependencies. Do not force an installation command within a fixed number of lines or make every repository use the same section order.
For a collection, map user tasks to named entrypoints and tangible outputs. Count genuine public tools, not nested SKILL.md files. Use a diagram when relationships benefit from explanation; independent tools should not appear to be a mandatory pipeline. Root documentation introduces and routes; component documentation holds detailed operating instructions.
Give a concrete usage example, meaningful limitations and validation scope. Include the most useful selection/setup FAQs for a substantial page. Links to contribution guidance and actual licenses should resolve. Preserve component-license exceptions and attribution.
Only document installation methods supported by current files and host guidance. Explain complete-folder installation when references/scripts/assets are needed. Do not claim that copying a file activates a hook, sets a model, installs external services or verifies host behavior.
Keep existing language choices. For bilingual repositories, produce complete equivalent editions, synchronize commands and facts, and adapt anchors and diagram labels to each language. A short summary is not a full translation. Fix obsolete names and stale migration/status claims while renovating.
Before delivery, check links and anchors, reconcile the catalogue with the current package tree, inspect rendered assets and the assembled page, and apply the presentation acceptance checks. Keep draft, pushed branch, merged default branch and verified live page as distinct states.