from-idea-to-personal-site

name	from-idea-to-personal-site
description	Run the complete idea-to-personal-website or blog workflow. Use when the user wants a one-click or end-to-end pipeline from a vague idea, reference URL, template, personal materials, style direction, or writing drafts to concrete style references, a validated static personal site, and optionally a live deployment on GitHub Pages, Cloudflare Pages, Netlify, or Vercel.

From Idea To Personal Site

Goal

Take a personal website or blog request from initial idea to a validated local static site, and optionally to a live published URL.

This is the user-facing end-to-end pipeline. It should choose and chain the existing specialist skills, enforce gates after each stage, repair failures by routing to the smallest responsible skill, and stop only when the requested outcome is actually reached or blocked by a missing user/account action.

Contract

Inputs:

• User idea, reference URL, template, screenshot, target style, personal identity materials, site folder, content drafts, and optional publishing target.
• Optional output folder, deployment platform, repository/account state, and custom domain.

Outputs:

• A completed local static site or updated existing site.
• Optional live deployment or exact platform steps/configuration when deployment needs user account action.
• A concise handoff with route used, site folder, preview or live URL, validation performed, files changed, and remaining user-editable content.

Boundaries:

• Do not implement child-skill details directly when a specialist skill applies.
• Do not publish, push, create repositories/projects, bind domains, or change DNS unless the user explicitly asked for that remote action.
• Do not skip validation after generation, recreation, personalization, post import, broad edits, or before deployment.
• Do not invent detailed personal facts when user materials are missing; use editable placeholders and document them.

Success gate:

• The site reaches the user's requested endpoint: validated local site, publish-ready package, or verified live URL.
• All relevant stage gates pass, or unresolved risks are explicit and accepted by the user.

If gate fails:

• Route the failure to the smallest responsible skill.
• Re-run the affected validation.
• Ask the user only when missing content, missing credentials, account permissions, unavailable assets, or external platform actions prevent progress.

Child Skills

Use the installed skills as building blocks:

• search-blog-theme for unclear direction, style discovery, or reference selection.
• find-style-references for grounding a chosen direction in real websites, templates, screenshots, and a build-ready design brief.
• make-personal-site for original zero-dependency static site generation.
• copy-website-style for recreating a specific website, template, screenshot, or visual system.
• personalize-site for replacing placeholders, copied identity, metadata, links, and profile content.
• add-blog-posts for importing Markdown, Obsidian notes, Word drafts, old posts, assets, math, links, and rich article content.
• edit-site-part for focused repair or small local adjustments found during the loop.
• review-static-site for deterministic and browser validation.
• publish-static-site for publishing preparation or deployment.
• build-personal-site only when a lower-level route decision is needed.

Do not load every child skill upfront. Load the next child skill only when the pipeline reaches that stage.

Default Pipeline

Use this closed loop for broad "from idea to site" or "one-click personal blog" requests:

1. Clarify endpoint. Input: user request and available materials. Output: route plan and expected endpoint: local site, publish-ready site, or live deployment. Gate: the site type, available inputs, and stopping point are clear enough to act.

2. Choose direction. Input: idea, taste, examples, audience, or reference material. Output: specific visual/site direction. Gate: direction is concrete enough to build. If unclear: use search-blog-theme.

3. Ground the style in references. Input: chosen direction, theme words, or user examples. Output: concrete reference set and build-ready design brief. Gate: the brief is grounded in multiple search angles and at least 3 inspected strong references when possible, and is specific enough to build. Use find-style-references before original builds unless the user supplied a specific reference website for close recreation.

4. Create or recreate the site. Input: direction or reference URL/screenshot/template. Output: static site folder with representative pages and EDITING.md. Gate: required page types exist and navigation points to real pages. Use make-personal-site for original sites. Use copy-website-style for specific references.

5. Personalize content. Input: generated site plus user identity, bio, links, projects, avatar, resume, or supplied profile material. Output: site content and metadata reflect the user, with copied-source identity removed. Gate: user-provided information appears in intended areas and source/demo residue is gone. Use personalize-site when identity or placeholder replacement is needed.

6. Add writing. Input: generated or existing site plus article drafts, notes, Markdown, Word files, image folders, math, citations, and links. Output: article/detail pages, updated indexes, copied assets, and article-specific notes. Gate: posts render with working links, assets, math, code, and responsive layout. Use add-blog-posts when writing content is provided.

7. Validate. Input: static site root, expected page scope, forbidden source strings, and optional reference URL. Output: pass/fail report or fixes. Gate: review-static-site has no blockers for paths, encoding, privacy residue, page types, browser rendering, console/network errors, or mobile usability. If gate fails: fix with the smallest child skill, then run the affected validation again.

8. Publish or prepare. Input: validated static root plus desired platform or account constraints. Output: deployment settings/config, manual steps, or live URL. Gate: deployment root is correct and the live or prepared site uses the right folder. Use publish-static-site only when the user asked to publish, deploy, or prepare publishing.

9. Handoff. Input: completed site and validation/deployment results. Output: concise final summary with where the site is, how to preview or open it, what was validated, and what the user can edit next.

Routing Shortcuts

• Vague idea only: search-blog-theme -> find-style-references -> make-personal-site -> review-static-site.
• Chosen direction: find-style-references -> make-personal-site -> personalize-site if needed -> review-static-site.
• Reference website/template/screenshot: copy-website-style -> personalize-site -> review-static-site.
• Existing site plus identity materials: personalize-site -> review-static-site.
• Existing site plus articles: add-blog-posts -> review-static-site.
• Existing site plus one precise change: edit-site-part -> affected browser validation, and review-static-site if shared structure changed.
• Publish request: review-static-site -> publish-static-site.
• Full idea-to-publish request: choose direction -> find references -> create/recreate -> personalize -> add posts if provided -> review-static-site -> publish-static-site.

One-Click Defaults

When the user asks for a complete site but leaves choices open:

• Default to plain static HTML/CSS/JS for this version.
• Default output folder to the user's requested folder, otherwise a clear local site/ folder in the workspace.
• Default to a useful first screen, not a marketing landing page.
• Default to editable placeholders for missing personal facts.
• Default to researching real style references before building from taste words.
• Default to page-relative paths for direct-open, local HTTP, and subpath deployment compatibility.
• Default to local validation and preview before any publishing step.
• Default to Cloudflare Pages or GitHub Pages guidance for plain static publishing if the user asks where to publish but has no preference.

Gate Loop

After each stage:

1. Check the stage gate.
2. If it passes, continue.
3. If it fails, route to the smallest child skill that can fix it.
4. Re-run only the relevant validation.
5. Continue until the endpoint is reached or an external blocker remains.

Common blocker handling:

• Missing personal information: keep neutral placeholders and document them, unless the user wants to pause.
• Missing article assets: preserve the article, mark missing assets in EDITING.md, and report them.
• Missing platform login or permissions: prepare exact publishing steps instead of pretending deployment happened.
• Privacy or path blockers: fix before publishing.

Final Report

Keep the final response short:

• Route used.
• Site folder.
• Preview URL, local file, or live URL.
• Major pages/content created or updated.
• Validation performed.
• Publishing status and any required user action.

Do not paste long audit logs unless the user asks.