personalize-site

name

personalize-site

description

Use this skill to turn a generated static personal website, blog, portfolio, digital garden, or style recreation into the user's own site by replacing placeholder identity, profile copy, links, projects, featured items, contact details, metadata, and demo page content. Use it after make-personal-site or copy-website-style, or when a user provides an existing static site folder and personal materials such as a bio, resume, README, GitHub profile, old homepage, Markdown notes, or social links.

Personalize Site

Goal

Personalize an already-generated static site so it feels like the user's own website rather than a template, demo, or copied reference.

This skill edits content and metadata. It does not choose a theme, redesign the layout, recreate a reference website, migrate a large article archive, publish the site, or convert the project to another framework.

Contract

Inputs:

• Existing generated static site folder, EDITING.md, page map, or handoff notes.
• User-provided identity/content: bio, resume, GitHub README, old homepage, social links, projects, avatar/logo, contact details, or specific replacements.
• Existing data files, JavaScript data blocks, metadata, and placeholder/source-site content to replace.

Outputs:

• Personalized visible content, metadata, links, images, and source-level identity fields.
• Removed or replaced template/demo/source-site residue.
• Updated EDITING.md describing filled fields, remaining placeholders, and content locations.

Boundaries:

• Do not choose a new theme, redesign the layout, recreate a new reference site, import a large writing archive, publish, or convert frameworks.
• Do not invent specific personal facts, employers, schools, awards, dates, locations, or metrics.
• Do not paste private user data back in the final report unnecessarily.

Success gate:

• User-provided identity/content appears in the right browser-visible locations.
• Important placeholders and source-site identity are gone or intentionally documented.
• Changed internal links/assets remain page-relative and valid.
• review-static-site can pass or only report accepted limitations.

If gate fails:

• Re-inventory HTML, metadata, data files, and JavaScript-rendered content.
• Replace missed placeholder/source strings.
• Use edit-site-part for small layout fit problems caused by new content.
• Use review-static-site again after fixes.

1. Inputs

Use any available materials:

• Static site folder, usually site/, dist/, out/, or public/.
• EDITING.md, page map, or handoff notes from another skill.
• User-provided bio, resume, CV, GitHub README, old homepage, social links, project list, avatar, logo, or contact details.
• Existing data files such as profile.json, posts.json, projects.json, or data blocks in assets/script.js.
• Specific replacement instructions from the user.

If important information is missing, use clear placeholders rather than inventing detailed personal facts.

2. Content Inventory

Before editing, identify where personal or placeholder content lives.

Check:

• HTML files and subpages.
• <title>, meta description, Open Graph/Twitter metadata, favicon/logo references, and visible headings.
• Header, navigation, hero, profile/about sections, contact blocks, footer, sidebars, cards, and overlays.
• Repeated content in JSON files, JavaScript data blocks, or repeated HTML lists.
• Article/detail demo pages, project pages, notes pages, link pages, and special pages.
• EDITING.md instructions and any documented content locations.

Look for common placeholder or demo text such as your name, [e-mail], example.com, lorem ipsum, sample post, sample project, TODO, replace me, and similar strings.

3. Personal Identity Replacement

Replace visible and source-level identity fields consistently.

Typical fields:

• Site title, author name, display name, role, tagline, short bio, location, availability/status, and interests.
• Email, social links, GitHub, X/Twitter, LinkedIn, Bluesky, RSS, newsletter, resume/CV, and other user-provided links.
• Avatar, logo, favicon, alt text, image captions, and profile labels.
• Homepage hero copy, about-page copy, contact copy, footer text, and metadata descriptions.

Do not invent specific employers, schools, awards, publications, metrics, locations, or years. If the user has not provided something, keep it neutral and easy to replace.

When replacing links or assets, preserve static path compatibility:

• Keep site-local links and assets page-relative, not root-absolute.
• From root pages, use paths like assets/avatar.png, about.html, and posts/example.html.
• From nested pages, use the correct depth such as ../assets/avatar.png and ../index.html.
• Do not introduce /assets/..., /posts/..., /images/..., /data/..., or / for internal links unless the site is intentionally server-root-only and the user accepts that direct file opening may break.
• External links such as GitHub, LinkedIn, email, and personal domains may remain absolute URLs.

4. Source-Site And Template Cleanup

When personalizing a style recreation, remove original-site identity and source-specific content by default.

Replace or remove:

• Original author names, handles, domains, emails, social links, analytics IDs, friend links, private URLs, licensing text, site statistics, and community links.
• Original article catalog, article body text, project names, personal testimonials, and personal claims.
• Downloaded avatars, covers, screenshots, logos, or other assets from the original site unless the user owns them or has permission.

Keep the visual structure and interaction pattern, but make the content clearly belong to the user or remain neutral placeholder content.

5. Content Adaptation

Adapt the user's material to the site's existing style and layout instead of pasting long raw text everywhere.

Use the site's concept to shape the copy:

• Minimal site: concise, calm, direct.
• Terminal/archive style: profile, log, status, directory, or config-like wording.
• Bento style: short modular snippets.
• Research homepage: formal, precise, project/publication oriented.
• Blog or digital garden: writing topics, recent notes, tags, and reading paths.
• Portfolio: selected work, role, outcome, stack, and links.

Keep text lengths suitable for the existing containers. If a user-provided paragraph is too long for a card, summarize it and place the fuller version on the about page.

Prefer editing centralized data sources when they exist. If content is repeated across files, update all visible and metadata copies consistently.

6. Validation

Use an actually available interactive browser tool as the first-choice way to inspect the local preview and confirm the personalized content is actually visible in the right places. "Available" means it is exposed in the current turn's callable tool list. In Codex this may be the Browser/in-app browser plugin when routed into the turn; in other agents it may be an equivalent visible browser, browser-use tool, or devtools-backed browser.

If no interactive browser tool is callable, do not pretend the browser placement check happened. Ask the user to enable or invoke the browser tool if visual placement matters; for Codex, that may mean sending a request that explicitly mentions @browser. If the user does not re-route or the client has no such tool, fall back to Playwright, screenshots, static audits, or source checks and state the limitation.

Do not default to Playwright or screenshots-only validation when an interactive browser tool is actually callable. Use Playwright only as a fallback when no interactive browser tool is callable, when the user explicitly asks for it, or when repeatable scripted regression is specifically needed.

Check the pages that should display the user's information, such as home, about/profile, contact, projects, links, and representative article/detail pages. Confirm that user-provided name, tagline, bio, avatar/logo, contact details, social links, project names, and featured items appear where expected.

Also confirm that important placeholder content or source-site identity is not still visible in the browser. This is a content placement check, not a full visual redesign pass.

If personalization changed avatars, favicons, social icons, project links, post links, or data-driven cards, confirm the changed paths work from the affected page depth and that no accidental root-absolute site-local paths were introduced.

Call or suggest using review-static-site at the end.

Editing Guide

Update EDITING.md when it exists, or create it if the site is meant to be reusable.

Record:

• Which personal fields were filled.
• Which content remains placeholder-only.
• Where profile, links, projects, featured items, posts, images, and theme text now live.
• Any user-provided assets copied into the site and where they are referenced.
• Any source-site content intentionally removed or replaced.

Keep the guide for future agents and users, not as marketing copy inside the website.

Output

When finished, report briefly:

• What personal information and pages were updated.
• Which files changed.
• Which placeholders or source-specific residues remain, if any.
• Whether review-static-site was run or should be run next.

Do not paste the user's private personal data back unnecessarily.