Repository presentation standard
Use for a new public repository, a landing-page renovation, or a publishing-readiness review. Apply the user's chosen reference and existing brand. This is the user's default quality standard; a narrow README fix or local skill edit does not trigger a full redesign or publication.
Establish the reference and the product
Inspect the target's current default branch, README editions, rendered assets, manifests, directory entries, installation paths and validation evidence. For a supplied reference, inspect its actual page and assets; when asked about past work, check the relevant task history and commits. Separate documented historical requirements from your present design interpretation. Record stable source links and commit identifiers, not private conversation transcripts or local paths, in public documentation.
Define what the repository is, who it serves, its public name and the genuine top-level tools. A collection's hero represents the collection. A child skill, internal module, former repository name or template name must not replace that identity. Count public entrypoints from the current package structure; never count every nested SKILL.md as a separate product.
Build a complete introduction
The first screen should identify the repository, state a concrete benefit, and make the next useful action easy to find. Use a coordinated hero, readable language switcher, a small truthful badge row and compact navigation when page length warrants it.
Let repository type determine the sequence:
- Single tool: purpose, a usable starting point, a concrete example, capabilities and limits.
- Collection: purpose, a task-to-tool selection table, starting point, examples and per-tool status. Explain independent tools without inventing a mandatory pipeline.
- System with components: purpose, an actual architecture/flow diagram, core system, component roles, setup dependencies, examples and per-component status.
Use real inputs and outputs in descriptions. Give readers a reason to choose each tool. Put detailed operational instructions in the component's authoritative documentation; the root page should introduce and route. Include a worked example, meaningful limitations, FAQs that resolve likely selection or setup questions, contribution guidance and the actual license when appropriate to the scope.
Positioning can explain a real tradeoff. Do not invent competitors' deficiencies, performance gains, community adoption or platform support to make the page persuasive.
Make the visuals specific
Create a recognizable motif derived from the product's work. Choose typography, palette, spacing and a sensible hierarchy. The Personal-Ontology benchmark uses layered blocks and linked nodes. When the user asks for the same style, preserve the reference composition principles, palette, typography and spacing while creating a distinct mark and adapting the repository name and claims. Do not replace that request with an independently invented identity. Without an explicit same-style request, choose a motif appropriate to the product; no icon or palette is universal.
Use light and dark variants, a responsive viewBox for SVG, accessible labels, and a working image fallback. Use native SVG for text and simple vector graphics. Use an appropriate image skill/tool for raster illustration. Choose dimensions to fit the composition; 700 × 175 is not an invariant. A white rectangle with a renamed title is not the default level of finish.
Save the resolved direction in assets/STYLE.md: reference, repository identity, motif, palette, typography, asset dimensions and language treatment. A supplied reference or existing recorded preference already answers the style question. Ask only when missing information materially affects the result.
When social sharing is part of the renovation, prepare a dedicated 1280 × 640 PNG with the same identity. A social card is its own composition, not a stretched hero. Report generating the asset and configuring GitHub's social preview as separate actions; verify the actual setting before claiming it is active.
Keep claims and editions aligned
Preserve the chosen primary language and existing README filenames unless a change is requested. A supported second language should contain the complete equivalent page, including navigation and translated diagram labels. Keep commands, paths, counts, version claims, links and validation scope synchronized in the same change.
Show only badges supported by actual metadata or workflows. Label a component-specific CI badge as such; omit a release badge when there is no release. Link badges to real destinations. Do not decorate a collection as an awesome-list or add unrelated topics to imply popularity.
Separate format checks, script tests, installation, host activation and observed end-to-end behavior. Preserve third-party and component licenses. Recheck archived repositories, stale migration messages and old product names when renovating.
Acceptance checks
Before claiming the page is ready:
- Read visible text inside SVGs or raster images; compare hero, alt text, social card, root title, About description and package identity. Search for obsolete names and templates without removing legitimate child-skill references.
- Render both hero themes, inspect wide and narrow layouts, and inspect the assembled README. Check clipping, overlap, contrast, wrapping and diagram readability. File existence or valid XML alone does not establish visual quality.
- Check local links, language-switch targets, in-page anchors, asset paths and top-level catalogue completeness. Check both language editions against the same facts and commands.
- Run relevant existing checks. Do not manufacture test counts or write tests that merely assert marketing phrases. Capture concrete defects and fix them.
- Review the diff and live remote state. Publish only within the user's authorization and repository workflow. After publication, verify the actual default-branch content and image rendering; a branch push or draft PR is not a live-homepage update.
If visual inspection or a remote setting is unavailable, identify that exact missing check. Never mark the whole renovation complete on a placeholder scan alone.
Provenance of this default
The user requested on 2026-09-05 that future repository work match Personal-Ontology's level of finish. The benchmark is documented in 412c47749e (positioning, overview, component descriptions, worked example and status) and 6463052751 (mature-repository comparison, light/dark identity, navigation, badges, full English edition, FAQ and social asset). The latter commit names mem0, Basic Memory and SiYuan as comparisons. It does not establish their current product claims.
The demonstrated LabKit failure was a collection hero still saying SKILL SKILL after the public repository became a multi-tool collection. The repair is identity and rendered-page verification, not a global ban on mentioning the child skill.
A subsequent user correction rejected a newly invented LabKit toolbox hero and asked for the same style as Personal-Ontology. A named visual reference can specify both quality and appearance; establish this distinction from the actual wording and preserve the requested fidelity.
The user subsequently rejected the identical Personal-Ontology icon and approved an original titanium L / violet-glass K hero. Preserve the reference's visual qualities without copying its logo or signature silhouette. Follow the latest approved design; earlier preferences are not permanent constraints. An intentionally dark photographic hero may use one asset in both page themes when inspected and explicitly approved; do not force an artificial light variant.