a bio link that looks like you.

Create a polished, custom link-in-bio page for me that will be published with HTMLShare.

Do not start building immediately. First, ask me a short set of questions so you have the information and creative direction you need.

DISCOVERY

Ask me about:

- Whether I already have a design, mockup, or concept from another tool that you should recreate or build from.
- Whether I have screenshots, websites, or other visual references that show styles I like.
- Who I am and how I want to be described.
- Who is likely to visit this page and what I want those visitors to do.
- The links I want to include and their priority.
- Whether there is anything I especially want visitors to notice, visit, buy, watch, read, or sign up for.
- How people should contact me, if applicable.
- Any photos, logos, icons, illustrations, or other assets I have available.
- Any additional visual preferences such as colors, typography, mood, personality, or things I specifically want to avoid.
- Where I plan to share this link, such as Instagram, TikTok, X, YouTube, LinkedIn, or multiple platforms, so tracking can be configured appropriately.

Keep the interview concise and conversational.

Ask only questions that will materially affect the finished page. If one of my answers makes another question unnecessary, skip it. If you need clarification about something important, ask rather than making an assumption.

Do not make me fill out a template or replace placeholder values.

If I provide an existing design or mockup, treat it as the primary visual direction unless I tell you otherwise.

If I provide screenshots, websites, or other references as inspiration, determine what qualities I like about them and use those qualities to create an original design rather than blindly copying them.

If I provide no visual direction, make appropriate design decisions based on what you learn about me, my audience, and my content.

DESIGN

Do not start from a predetermined link-in-bio template.

There is no required layout, set of blocks, button style, featured card, or visual structure.

Design the page specifically around my content and goals.

It does not need to look like a traditional stack of link buttons. Choose the hierarchy, typography, layout, imagery, components, and interactions that make the most sense.

Give more visual importance to the things I most want visitors to do instead of treating every link equally.

Design mobile-first. Assume most visitors will arrive from a social profile on their phone, while still making the page look polished on larger screens.

Make it:

- responsive
- accessible
- fast
- visually polished
- easy to scan
- easy to use with a thumb
- appropriate for the personality or brand I describe

Use semantic HTML, sufficient color contrast, visible keyboard focus states, appropriate alt text, large touch targets, and respect reduced-motion preferences.

Avoid unnecessary frameworks, dependencies, scripts, and heavy assets.

PAGE DETAILS

Treat this as a real public webpage, not a visual mockup.

Include the details expected from a polished production page, including where appropriate:

- descriptive page title
- meta description
- canonical URL
- Open Graph title
- Open Graph description
- Open Graph image
- Open Graph URL
- Open Graph type
- appropriate Twitter/X card metadata
- favicon
- relevant icon metadata
- theme color
- appropriate structured data when it genuinely applies

If you have the ability to create a custom favicon or social sharing / Open Graph image that fits the design, do so.

If an asset is needed that you cannot create, tell me what is needed rather than silently omitting it or substituting something inappropriate.

Do not invent identity details, URLs, claims, follower counts, testimonials, projects, credentials, images, or other facts I have not provided.

LINKS & TRACKING

Make sure every link works and goes to the intended destination.

Use clean destination URLs.

Based on where I tell you the page will be shared, determine whether UTM tracking would be useful.

If tracking would be useful, explain the proposed tracking convention briefly and confirm it with me before adding it.

Use meaningful and consistent UTM parameters rather than arbitrary values.

If the same HTMLShare page will be shared across several platforms, do not incorrectly attribute all traffic to a single platform. Recommend an appropriate approach based on how I intend to distribute the page.

Do not add tracking parameters where they are unnecessary or where they could interfere with the destination.

Use appropriate attributes for external links.

Before delivery, check for broken links, placeholder URLs, and malformed tracking parameters.

QUALITY CHECK

Before considering the page finished:

- Review it at common mobile and desktop sizes.
- Check that the visual hierarchy reflects my priorities.
- Check accessibility basics.
- Check metadata and social sharing tags.
- Check favicon and icon setup.
- Check every link.
- Check any UTM parameters.
- Check for placeholder or invented content.
- Check that images have appropriate dimensions and alt text.
- Check that the page does not require a build step or server.
- Check that there are no unnecessary dependencies.
- Remove unused or unnecessary code.
- Make sure the final result feels finished enough to use as my real public link-in-bio page.

DELIVERY

Produce the page as one self-contained HTML file wherever practical, with its CSS and JavaScript included.

Do not require a framework, build step, database, or server.

If something cannot reasonably be embedded in the HTML file, keep additional assets to a minimum and clearly identify them.

After publishing, use the final HTMLShare URL for canonical and Open Graph URL metadata wherever appropriate. If necessary and supported, update the published artifact after the final URL is known so this metadata is correct.

The finished result should feel like a custom personal website that happens to serve the purpose of a link-in-bio page — not a generic link-in-bio template.

PUBLISHING

Publish the finished page to HTMLShare and give me the link.

Use exactly one of the two paths below, preferring the first. Make the call
directly. Do not route it through a code sandbox, container, or computer-use
session — that is where the request gets blocked, and it is never necessary.

1. An HTMLShare integration or connector, if you have one configured.
   The page is permanent and owned by my account. Report the url and the
   siteId. There is no claimUrl or manageToken on this path — do not go
   looking for one, and do not switch paths in order to produce one.

2. Otherwise, publish anonymously over REST. No account, key, or signup is
   needed:

    POST https://api.htmlshare.net/v1/publish
    content-type: application/json

    {"html": "<!doctype html> ... "}

   The reference is https://htmlshare.net/docs and, for the full schema,
   https://api.htmlshare.net/openapi.json

   Report these from the response, in your reply and never inside the page:
     url          the public page
     claimUrl     a private link that is mine alone. opening it is how I keep
                  the page past its 24-hour expiry, or set an email reminder
                  before it goes. it carries the manage token, so it must
                  never appear in the published HTML or anywhere a visitor
                  could see it.
     manageToken  the only thing that can edit or delete this page later. it is
                  returned once and never again, so tell me what it is.

Tell me which of the two you used. If the path you reach for first is
unavailable in your environment, say so and tell me what you are switching to
before you publish — a permanent page on my account and a 24-hour anonymous
page are different things, and which one I get is my decision, not a detail.

If I ask for a change afterwards, update the existing page instead of
publishing again, so the URL I have already shared keeps working — through the
same integration on path 1, or with the manage token as an X-Manage-Token
header on path 2.