AlemTuzlak/skills

Blog Post Writer

從程式碼變更、行銷簡報或功能描述中，撰寫高品質的部落格文章。處理 SEO、結構、語氣匹配和視覺內容。

撰寫規則（不可協商）：永遠不要使用 em-dash（— 或 –）。請改用連字號 -。 適用於所生成內容的每一行。

輸入解析

按以下順序解析參數（如果提供）：

1. 現有行銷簡報檔案的路徑（包含「Executive Summary」或「Key Messages」的 .md 檔案）→ 行銷簡報
2. 符合 GitHub URL 或 #\d+ 模式 → PR
3. 包含 ... 或 .. → git 引用範圍
4. 解析為現有檔案/目錄 → 程式碼庫功能
5. 否則 → 自由文字

如果未提供參數，請詢問：「您想撰寫什麼主題？您可以提供行銷簡報路徑、PR URL/編號、git 引用範圍（例如 v1.0...v2.0）、檔案/目錄路徑，或直接描述主題。」

如果有多種解釋符合，請與使用者確認。

流程

digraph blog_post {
    rankdir=TB;
    "Resolve input" [shape=box];
    "Phase 1: Discovery" [shape=box];
    "Phase 2: Research" [shape=box];
    "Phase 3: Configure" [shape=box];
    "Phase 4: Outline" [shape=box];
    "Outline approved?" [shape=diamond];
    "Phase 5: Write" [shape=box];
    "Phase 6: Output" [shape=box];

    "Resolve input" -> "Phase 1: Discovery";
    "Phase 1: Discovery" -> "Phase 2: Research";
    "Phase 2: Research" -> "Phase 3: Configure";
    "Phase 3: Configure" -> "Phase 4: Outline";
    "Phase 4: Outline" -> "Outline approved?";
    "Outline approved?" -> "Phase 4: Outline" [label="no, revise"];
    "Outline approved?" -> "Phase 5: Write" [label="yes"];
    "Phase 5: Write" -> "Phase 6: Output";
}

不要跳過任何階段。 以自然的節奏提問。不要讓使用者感到壓力，但也不要刻意放慢速度。如果使用者一次回答了多個問題，請接受他們的捆綁答案並跳過後續問題。

如果使用者說「直接選預設值」、「你決定」或類似內容，請根據上下文選擇合理的預設值，說明您的選擇，並在繼續前要求使用者確認一次。

未經確認，切勿做出假設。

第一階段：探索

步驟 1 - 分析輸入

輸入類型	讀取內容
行銷簡報	閱讀簡報 - 提取問題陳述、價值主張、目標受眾、關鍵訊息、競爭定位。如果簡報缺乏產品背景，仍執行步驟 2，然後繼續步驟 3。
PR	Diff、PR 描述、審查評論、提交訊息（gh pr view、gh pr diff）。對於大型 PR（20+ 檔案），專注於使用者面向的變更。
Git 引用	引用之間的 git diff 和 git log。對於大型範圍，優先處理提交訊息和使用者面向的變更。
程式碼庫功能	讀取指定的檔案/目錄。
自由文字	解析使用者的描述。如果缺乏具體細節（沒有功能名稱、沒有價值主張、沒有背景），請要求使用者提供更多細節或指向特定檔案/PR。只有在他們無法提供時，才退回使用開放式問題。

使用者面向的變更包括：新功能、UI 變更、API 變更、效能改進、錯誤修復和文件更新。內部變更包括：重構、新增測試、CI 變更和依賴項升級。如果不確定，列出您找到的內容並詢問使用者哪些是相關的。

錯誤處理：

• gh 未安裝/未驗證 → 通知使用者，建議 gh auth login，提供替代輸入
• 無效的 PR/引用 → 告知使用者，請其驗證
• 找不到檔案 → 要求提供正確路徑

步驟 2 - 閱讀更廣泛的產品背景

讀取如果存在的內容：README、docs/、package.json（或同等檔案）、行銷參考資料。

目標：了解產品是什麼、為誰設計、做什麼。

如果什麼都沒找到，請詢問：「我在儲存庫中找不到產品背景。您能簡要描述一下產品及其目標使用者嗎？」

步驟 3 - 呈現理解

「以下是我理解的內容：」

• 功能 A - 簡短描述
• 功能 B - 簡短描述

「部落格文章應涵蓋哪些項目？需要新增、刪除或修正任何內容嗎？」

視需要提出問題，以充分了解範圍。在使用者確認之前，不要繼續。

步驟 4 - 標記敏感項目

掃描：重大變更、棄用功能、安全修復、遷移需求。

如果找到，標記每個項目並詢問如何在繼續前進行處理。

第二階段：競爭對手部落格研究

在配置文章之前，搜尋領域中類似的部落格文章：

1. 使用 WebSearch 尋找 3-5 篇涵蓋相同主題、競爭產品或類似功能公告的現有部落格文章
2. 分析那些文章的優缺點 - 結構、標題、鉤子、SEO 關鍵字、深度
3. 識別內容缺口 - 競爭對手沒有涵蓋而這篇文章可以涵蓋的內容
4. 使用這些發現來制定 SEO 策略、標題生成和內容結構

如果 WebSearch 不可用，請跳過此階段並依賴您自己的知識。

向使用者呈現簡短摘要：

「我在這個領域找到了一些類似的文章。我注意到以下幾點：」

• [關於有效做法的關鍵發現]
• [內容缺口 / 機會]
• [SEO 關鍵字機會]

「我將利用這些見解來塑造這篇文章。」

第三階段：配置

詢問以下問題：

問題 1 - 目標受眾：「這篇部落格文章的目標受眾是誰？」（開發人員、終端使用者、技術決策者、一般大眾、其他）

**問題 2 - 語氣：**閱讀儲存庫中現有的部落格文章、README 和文件，以偵測產品的語調。然後確認：

「根據您現有的內容，語調似乎是 [例如 對話式且對開發人員友善]。我應該沿用那種語調，還是採用不同的方向？」

如果沒有現有內容可分析，直接詢問使用者想要的語氣。

**問題 3 - 文章類型：**根據輸入和目標受眾，推薦一種文章類型並確認：

• 功能公告 - 「我們發布了 X，這就是它重要的原因」（約 600-1000 字）
• 深入技術探討 - 「我們如何建立 X，其中的決策與架構」（約 1500-2500 字）
• 問題解決敘事 - 「您有問題 X，這是我們如何解決的」（約 1000-2000 字）

「根據 [輸入/目標受眾]，我建議採用 [類型] 文章，因為 [原因]。聽起來合適嗎？」

**問題 4 - 行動呼籲：**從上下文推斷最合適的行動呼籲：

• 開源 → 為儲存庫加星、貢獻、試用
• SaaS → 註冊、開始免費試用
• 功能更新 → 試用新功能、閱讀文件
• 函式庫/SDK → 安裝它、閱讀遷移指南

「我建議行動呼籲為：[推斷的行動呼籲]。要採用這個還是其他選項？」

問題 5 - 參與程度：「您在寫作過程中的參與程度為何？」

• A) 直接撰寫 - 我將處理所有事情，選擇最佳標題，並儲存最終文章。您之後可以要求修改。
• B) 先給我看大綱 - 批准結構，然後我將撰寫完整文章
• C) 逐步引導我 - 大綱批准，然後逐節確認

第四階段：大綱

產生結構化的大綱：

## [暫定標題]

1. **鉤子/引言** - [方法：問題/統計/大膽陳述/故事]
   - 要建立的關鍵點
   - 過渡到正文

2. **章節名稱** - [目的]
   - 關鍵點
   - 估計字數

3. **章節名稱** - [目的]
   - 關鍵點
   - 估計字數

[...根據需要設定多個章節]

N. **結論** - [總結 + 行動呼籲]
   - 要強化的關鍵要點
   - 行動呼籲：[具體行動]

估計總字數：約 X 字

如果參與程度是 A，則在內部生成大綱而不顯示。對於 B 和 C，呈現大綱並等待批准。

第五階段：撰寫

內部撰寫流程（無論參與程度如何，始終執行）

對於每個章節：

1. 撰寫該章節
2. 自我審查： 分析內容是否可以以不同方式結構化、是否缺少讀者理解和消化所需的背景、或者是否存在會使不熟悉該主題的人感到困惑的缺口
3. 補足： 如果發現缺失的部分，在繼續之前加入過渡段落、背景或重新結構化內容

如果參與程度是 C，在自我審查後呈現每個章節，並在繼續前取得確認。對於 A 和 B，靜默執行此流程。

標題

正文完成後，使用不同的公式生成 3-5 個標題選項：

• 操作方法（「[Product] 如何解決 [problem]」）
• 數字/列表（「[feature] 改變 [workflow] 的 3 個原因」）
• 提問（「厭倦了 [pain point] 嗎？」）
• 大膽陳述（「[Feature] 是達成 [outcome] 最快的方法」）
• 前/後對比（「[Pain] → [Result]：[feature] 如何實現這一點」）

推薦一個並解釋為什麼它最適合這篇文章的目標受眾、SEO 和背景。也要解釋其他選項的取捨。

對於參與程度 B 和 C，呈現選項並讓使用者選擇後再繼續。對於程度 A，使用您的推薦。

將可讀性置於 SEO 限制之上。首先撰寫最佳標題。如果它不符合 50-60 個字元的 SEO 標題限制，則為前端元資料製作一個單獨的較短標題標籤。

SEO 前端元資料

在文章頂部生成 YAML 前端元資料：

---
title: "[選定的標題]"
meta_description: "[140-160 字元，包含主要關鍵字，引人注目的價值主張]"
primary_keyword: "[主要目標關鍵字]"
secondary_keywords: ["關鍵字1", "關鍵字2", "關鍵字3"]
long_tail_keywords: ["較長詞組 1", "較長詞組 2"]
slug: "[網址友善的短語]"
---

規則：

• 標題標籤：50-60 字元，主要關鍵字置前
• 元描述：140-160 字元，為人類撰寫，包含獨特的價值主張
• 關鍵字由第二階段的競爭研究提供資訊
• 不要堆砌關鍵字 - 僅使用自然語言

內容格式規則

• 簡短段落： 最多 2-4 句
• 子標題： 使用 H2 作為主要章節，H3 作為子章節。子標題應能自成一個可掃描的大綱。
• 將關鍵詞組加粗 以支援 F 型掃描
• 項目符號和列表 用於任何 3 個以上的項目集合
• 一個段落一個想法
• 永遠不要在生成的內容中使用 em-dash。不要使用「—」字元。請改用逗號、冒號、句號或括號。

鉤子/引言

引言包含三個組成部分：

1. 鉤子（前 1-2 句） - 一個令人驚訝的統計數據、大膽的主張、相關的痛點或挑釁性的問題。必須在閱讀的三秒鐘內引起好奇心或情感共鳴。
2. 權威性 - 簡要說明為什麼這很重要，或為什麼讀者應該相信這一點
3. 承諾 - 清楚說明讀者將從這篇文章中獲得什麼

保持引言在 3-5 個簡短段落內。不要有文字牆。

結論

1. 重申主要要點（不要引入新想法）
2. 單一、清晰的行動呼籲，包含動詞（「立即試用」、「為儲存庫加星」、「開始免費試用」）
3. 可選擇以展望未來的陳述或問題結尾，以引發討論

視覺內容

盡可能直接生成：

• 架構圖 → mermaid 程式碼區塊或內嵌 SVG
• 資料流程圖 → mermaid 程式碼區塊
• 比較表格 → markdown 表格
• 程式碼範例 → 語法反白的程式碼區塊

對於需要外部創建的圖片：

<!-- TODO: 在此加入圖片 -->
<!-- 建議：[圖片應顯示內容的描述] -->
<!-- LLM 提示：「[可供圖片生成模型直接使用的提示，例如「一個乾淨、極簡的插圖，顯示帶有深色模式切換的儀表板，扁平設計風格，開發工具美學，16:9 比例」」 -->
![替代文字描述](placeholder.png)

在需要幫助理解的地方使用視覺內容 - 在解釋複雜概念之後、比較選項時、或顯示 UI 變更時。

程式碼範例

對於開發人員受眾，至少包含一個展示功能實際運作的程式碼範例。偏好最小、可執行的程式碼片段（5-15 行）。在展示改進時顯示「之前/之後」的對比。

第五階段 b：完整草稿審查

在所有章節撰寫完成且標題選定後，組合完整的文章（前端元資料 + 正文）。

• 程度 A： 跳過審查。直接進入輸出。呈現最終文章並儲存。使用者之後可以要求修改。
• 程度 B： 在儲存前將完整草稿呈現給使用者審查。「這是完整的文章。在我儲存之前，您想進行任何更改嗎？」
• 程度 C： 使用者已經分別看過每個章節，但仍然呈現組合後的草稿以供最終審查。「這是完整的文章。在我儲存之前，您想進行任何更改嗎？」

對於 B 和 C，如果使用者要求修改，進行修改並再次呈現。只有在使用者批准後才進入輸出。

第六階段：輸出

首先偵測現有的部落格目錄。 檢查：

• content/blog/、src/pages/blog/、_posts/、blog/、posts/、articles/

如果找到，使用該目錄。如果沒有，預設為 blog/posts/。

呈現給使用者：

「我將把這個儲存到 [偵測到的或預設路徑]/<slug>.md。您想放到其他位置，還是跳過儲存直接列印？」

如果目錄不存在，則建立它。

如果檔案已存在： 詢問是否要覆蓋或建立一個帶有版本編號的副本。

錯誤處理

• gh 不可用 → 通知使用者，提供替代輸入
• 無效的 PR/引用 → 請使用者驗證
• 沒有產品背景 → 請使用者描述產品
• WebSearch 不可用 → 跳過第二階段，使用自己的知識繼續
• 沒有現有的部落格目錄 → 預設為 blog/posts/，建立它

此技能不做的事

• 生成社交媒體文案（請使用 /social-copy）
• 將文章發布或部署到任何平台
• 生成行銷簡報（請使用 /marketing-brief）
• 為不同受眾建立多個變體 - 針對不同受眾請再次執行此技能