Portfolio Builder
將個人的工作經歷轉化為一頁式作品集。Claude 先在對話中規劃內容，將其鎖定在 BRIEF.md 中，然後提供 Claude Code 提示。Claude Code 在本地端建構，推送至 GitHub，由 Netlify 部署。接著 Claude 會審查程式碼庫和實際網站。
此技能產出之所有內容的寫作規則：輕鬆、直接的語氣，短句，不使用 em-dash（僅使用一般連字號）。
第一階段：詢問前先收集
- 提取已知資訊：記憶、過往對話、現有網站（實際擷取其功能列表和文案）。
- 先草擬一份內容清單。切勿從空白的問卷開始。
第二階段：草擬摘要 v1，然後最多詢問 4 個決策
以實際文案草擬各區塊，然後僅詢問會改變建構的項目：
- 主要目標對象（客戶、招募主管、或兩者，以及以哪個為主）。
- 可見性限制（是否提及現任雇主或採用泛稱；需要保密的事項）。
- 要納入哪些專案。
- 網站位置（先使用 Netlify 子網域即可）。
防護措施：
- 不得編造指標、推薦或客戶。
- 不得提出使用者未做出的聲明（例如，在他們並未實際從事 AI 工作的正職中宣稱做過 AI 相關工作）。
- 團隊成就歸功於團隊。
- 若雇主保持匿名，則也應刪除任何可能識別其身分的細節（例如國家列表、確切職稱加上產業）。改寫為「五大市場」，而非列出清單。
- 注意區域用詞（例如，當一個國家橫跨多洲時使用「亞洲市場」）以及主角文案中的模糊代名詞。
專案納入規則：當專案已上線且展示了目標對象願意付費的技能時，才應納入。過多的副業會給人「沒時間理你」的印象。已停滯或過去的工作應放在一個較小的「來自實驗室」行列中，並誠實標示。尚未命名或未啟動的專案則應等待。
工具：僅列出親自使用過的工具。僅熟悉的工具應以一行註腳表示（「亦熟悉 X 和 Y」）。
第三階段：填補缺口
詢問：顯示名稱、大頭照、每個專案一張螢幕截圖、線上網址、GitHub 網址、聯絡信箱、社群媒體。改寫任何提供的網站文案，使其符合作品集風格（說明它是什麼、為誰而做、他們建構了什麼）。 每個卡片連結必須指向實際描述該項目的頁面。若頁面尚未準備好，則不提供連結，並加上標籤（例如「即將上線」）。 將任何尚未準備好的項目（如預約連結、「與我合作」、推薦）推遲至「稍後」清單，而不是阻擋 v1 版本的推出。
第四階段：鎖定 BRIEF.md
撰寫 BRIEF.md，包含以下依序排列的章節：
- 目標（10 秒測試：他們建構了什麼、證明、如何聯繫他們）
- 目標對象
- 文案規則（語氣、不使用 em-dash、可見性與準確性防護措施、使用既有的文案）
- 技術（純 HTML/CSS/原生的 JavaScript，無建構步驟；index.html, styles.css, main.js, /assets；GitHub + Netlify；Lighthouse 95 以上；行動優先）
- 設計方向（預設類似 Apple：Inter 或系統字型、大量留白、最大寬度約 1080px、文字區塊約 680px、緊湊的大標題、中性色調、20-24px 的卡片圓角、極細邊框、一種重點色並謹慎使用、支援明暗模式切換、配合減少動畫設定微調的淡入效果、螢幕截圖置於極簡的瀏覽器框架卡片中、帶模糊效果的黏性導覽列）
- 版面規則（從一開始就融入）：
- 導覽列和每個區塊共用同一個容器，因此所有左邊緣對齊。
- 使用一個區塊間距代幣（桌面約 96px，行動約 56px）作為每個間距；不疊加內距。
- 英雄區域需在 1366x768 和 375x812 解析度下（包含瀏覽器工具列，約可見 650px 和 635px）位於第一屏。
- 標題：行動版使用 text-wrap: pretty，桌面版使用 text-wrap: balance；不強制換行。
- 每個區塊都有可見的標題或眉題標籤，確保無內容漂浮。
- 素材（確切的檔案路徑；螢幕截圖轉換為 WebP 格式並提供較小的行動版尺寸，低於折疊線的內容使用懶加載；若缺少則顯示佔位符，絕不顯示破圖）
- 頁面內容，從上到下，包含最終文案：Hero、我的專業（3 張卡片）、作品（精選卡片 + 網格 + 實驗室行）、我的建構方式、工具（分組的標籤式顯示）、背景介紹、原則（使用者自己的話語，而非借用引言）、聯絡、頁尾
- SEO 與 Meta（標題、描述、OG 圖片、favicon、語意化 HTML、替代文字、焦點狀態、AA 對比度）
- 預填詳細資料：儲存庫網址、偏好的子網域及備用方案、社群帳號、信箱，讓 Claude Code 無需再詢問
- 稍後（v1 不包含）
重點色：選擇一個與建構作品螢幕截圖顏色有所區隔的顏色。提供明色和暗色模式下的確切十六進位色碼，並在兩種模式下檢查重點色上連結和按鈕文字的 AA 對比度（暗色模式按鈕通常需要在淺色重點色上使用深色文字）。
交付 BRIEF.md 作為一個檔案。
第五階段：設定步驟 + 4 個提示
設定（一次性）：
- 建立一個空的 GitHub 儲存庫，然後在本機資料夾中執行
git clone <儲存庫網址>，以便 git 已設定完畢。 - 將 BRIEF.md 放在根目錄；建立 /assets 和 /assets/shots 資料夾，並放入命名的檔案。
- 在該資料夾中開啟 Claude Code。
提示 1，規劃：
完整閱讀 BRIEF.md。先不要撰寫程式碼。
給我一個簡短的建構計畫：檔案結構、逐區塊版面配置、你將使用的色彩代碼和字型比例，以及你在摘要中看到的任何問題或衝突。保持在一頁以內。
重點色：明色模式下為 <LIGHT_HEX>，暗色模式下為 <DARK_HEX>。謹慎使用它，並確認兩者（包括按鈕文字）都通過 AA 對比度檢查。
協助使用者在一則可貼上的回覆中回答其問題。
提示 2，建構：
嚴格按照 BRIEF.md 和我們同意的計畫建構網站。
- 逐字使用文案。任何地方都不要使用 em-dash。
- 使用純 HTML、CSS、原生 JavaScript。無框架、無建構步驟。
- 重點色：明色模式為 <LIGHT_HEX>，暗色模式為 <DARK_HEX>。其他所有顏色保持中性。
- 遵循 BRIEF.md 中的版面規則（共用容器、一個間距代幣、英雄區域位於第一屏）。
- 使用 /assets 中的 WebP 圖片。如果缺少圖片，顯示一個乾淨的佔位符。
- 支援明色和暗色模式、帶模糊效果的黏性導覽列、支援減少動畫設定的滾動淡入效果。
完成後，啟動一個本地伺服器並告訴我網址，以便我進行檢閱。
提示 3，打磨：
像 Apple 的高級設計師一樣審查網站，然後修正你發現的問題：
1. 在 375px、768px、1366px 和 1440px 寬度下檢查。沒有水平滾動，沒有擁擠的地方。
2. 所有左邊緣對齊；每個區塊間距使用統一的間距代幣。
3. 英雄區域在 1366 和 375 解析度下（包含瀏覽器工具列）需位於第一屏。
4. 暗色模式看起來是有意為之，而非單純反相。重點色在兩種模式下都易於閱讀。
5. 無障礙性：替代文字、焦點狀態、AA 對比度、語意化標題。
6. 搜尋所有檔案中的 em-dash 並替換。
7. 執行 Lighthouse 並讓所有四項評分達到 95 以上。
給我一份你所更改項目的簡短清單。
然後使用者以平實的語言提供回饋，直到滿意為止。
提示 4，推送與部署：
此資料夾已從 <REPO_URL> 複製。
1. 加入 .gitignore 和 netlify.toml（發布目錄 = 根目錄，合理的快取標頭，以及對 BRIEF.md 和原始 PNG 檔案返回 404，確保它們不會公開）。
2. 使用明確的訊息提交所有內容，並推送至 main 分支。
3. 將儲存庫與 Netlify 連結。先嘗試 <SUBDOMAIN>，備用方案 <FALLBACK>。如果 Netlify 的 GitHub 應用程式無法看到該儲存庫，告訴我如何授予其存取權限。
注意：Claude Code 經常一次完成建構、打磨和部署。這沒問題，直接跳到審查階段。
第六階段：推送後審查
當儲存庫或線上網址被分享後：
- 複製儲存庫並檢查：文案是否與 BRIEF.md 一致，無編造內容，無 em-dash，無限制名稱，所有連結正確，圖片為 WebP 格式並帶有替代文字和尺寸，存在 meta/OG/favicon，內部檔案已從線上網站封鎖。
- 在瀏覽器中以 1440 和 1366（明色模式）以及 375（暗色模式）解析度對線上網站進行視覺檢查：邊緣對齊、間距一致性、英雄區域位於第一屏、標題換行正常、無重疊。
- 將修正內容整理成一個可貼上的 Claude Code 提示，然後在推送後重新檢查。 如果儲存庫是空的，直接說明並要求他們先進行推送。
已知問題：
- Netlify 會在 2026 年 8 月 19 日之後建立的 Free 方案專案上加上「Powered by Netlify」徽章。它不在程式碼中：請在專案設定 > General > Powered by Netlify badge 中，針對每個專案關閉它。
- 來自慢速連線的實際 Lighthouse 分數會有所差異；請以 pagespeed.web.dev 而非僅以本地端執行結果為判斷依據。
第七階段：同步其餘的個人資料
提議將 GitHub 個人資料 README（以及其他個人簡介）與作品集對齊：使用相同的定位標語、相同的聯絡信箱、連結至實際作品和作品集，並移除作品集中刻意排除的專案。