適用情境

公司已開辦上崗（見開辦上崗與新增崗位）。這個範例用一項真實任務——「官網文章沒流量，升級寫 SEO 文章的 Skill」——把整套協作機制跑一遍：你只對總經理說一句話，之後全靠任務卡流轉。它同時是張考卷：練習材料裡故意埋了毛病，看你的團隊能不能查出來。

流程總覽

老闆（一句話）
  └─ gm 寫任務卡 → content（黃燈）
        ├─ ① 三位臨時幫手並行查資料（tmp-guide / tmp-tools / tmp-talk）
        │      └─ 三份資料寫進 研究/ → 讀完三頁關掉
        ├─ ② content 彙總 → 寫改進版
        └─ ③ 任務卡交 growth（換一家模型）審 → 只提意見不重寫
              └─ content 逐條處理 → 交回 gm
  └─ gm 彙總報告 → 停在「要不要寫回」→ 老闆點頭 → 改正式文件 + git
  └─ gm 與 content 各自在 工作記錄/ 沉澱經驗

第一步：放練習材料（準備段提示詞）

交給 Herdr 裡任何一位（通常 gm）：

先幫我放一份練習材料：在公司根目錄建 工具/技能/seo-writing/ 資料夾，把下面這份「練習用舊 Skill」原樣寫進 工具/技能/seo-writing/SKILL.md。它是故意留著毛病的練習材料，一個字都不要改，也不要順手修。然後按 工具/AGENTS.md 裡「Skill 放哪」掛兩個連結：.claude/skills/seo-writing 和 .agents/skills/seo-writing，都指向 ../../工具/技能/seo-writing。最後在公司根目錄存一次 git（git add 工具/技能/seo-writing .claude/skills/seo-writing .agents/skills/seo-writing，再 git commit -m "放入練習用舊 Skill"），告訴我文件路徑、兩處連結的檢查輸出和 git log --oneline -1 的輸出。這一次只做這些，別的什麼都不做。文件已經存在，就不要覆蓋，告訴我它現在的內容。

——練習用舊 Skill（從下一行開始原樣寫入）——
---
name: seo-writing
description: 寫官網 SEO 文章時用：從提綱到成稿的寫作規則。
---
# SEO 寫作 Skill
1. 先列文章提綱，提綱定了再寫正文。
2. 標題要把主題寫全，可以寫到五十字以內。
3. 核心關鍵詞（例如「AI 工作流」）在全文至少出現二十次，開頭、結尾、每個小標題都要放。
4. 每個小標題下寫三五句話，先給結論再解釋。
5. 需要數據時，可以直接寫「據統計」「業內普遍認為」，不用一一標來源。
6. 寫正文時想到哪寫到哪，寫完再補提綱。
7. 結尾用一句話總結，再邀請讀者在評論區說說自己的做法。
8. 全文用中文。

開頭兩條 --- 之間是 Skill 的格式要求（名字和什麼時候用），各家 agent 靠它認出這是一個 Skill，不算毛病；下面八條才是正文。工具/ 下的文件是正式文件，寫入和掛連結時會亮紅燈請你確認，放行即可。

第二步：交代任務（完整提示詞）

同樣交給 gm：

老闆交代：我們官網最近發的文章幾乎沒有流量，怎麼辦？幫我把寫 SEO 文章的這個 Skill（工具/技能/seo-writing/SKILL.md）升級一下：讓內容經理去查業界的最佳實踐，搜尋引擎官方的內容指南、開源工具裡的檢查規則、大家最近的討論都看一看；流量的事請成長經理審一遍；最後把改了什麼、為什麼改、出處在哪，彙總給我，我確認了再寫回正式文件。這是公司第一次做這件事，所以交代得細一點。

【規矩】
1. 按總規矩裡的協作規矩辦，每一步用協作規矩裡寫好的命令。
2. 先用三五句話說你的安排：誰做哪一步、每一步的產出放哪。我說「可以」再交出去。
3. 你自己不寫長稿。改 工具/技能/seo-writing/SKILL.md 之前必須停下來，把報告和改前改後的對比給我看，等我點頭。
4. 哪一頁停著等確認，不要硬發，告訴我是哪一頁。

【要做的幾件事】
第一件：準備。
  - 工具/技能/seo-writing/SKILL.md 不存在，就停下來告訴我「先做準備那一步」，不要自己編一份。
  - 名冊裡臨時幫手用的是反重力的話，確認 ~/.gemini/antigravity-cli/settings.json 的 permissions.allow 裡已經有 "read_url(*)"（裝 Herdr 那段配過）。沒有就告訴我，我說「可以」再補上，免得三位幫手查資料時輪流停下來要批准。
  - 名冊裡只有一家 agent 的話：三位臨時幫手和成長經理都用這一家，各開新的一頁就行；審閱的那一位沒參與起草，照樣算換人審。
第二件：寫任務卡，交給內容經理 content。目標：把這個 Skill 升級成寫出來的文章更容易被搜到、被讀完的版本。材料：現在的 Skill，和 業務/ 裡最近發的幾篇文章（沒有就略過）。規矩：每條改動都要有出處，不直接改正式文件。產出：三樣都放進 駕駛艙/任務/，檔名以任務卡開頭：改進版、成長經理的審閱意見、逐條處理說明。按協作規矩第 2、3、6、7 條交過去並等結果；內容經理這一趟要查資料、請人審，時間長，按第 6 條一輪一輪等，不催、不重發。
  任務卡裡按順序寫明內容經理要做的三步，這些由內容經理自己做，你不用替它做：
  ① 查資料：資料分三塊，按協作規矩第 5 條臨時請三位幫手（用名冊裡臨時幫手的那家），各開一頁同時查，每位一張任務卡，目標就是下面這一句：
     tmp-guide：去查搜尋引擎官方公開的內容品質指南，列出和寫文章有關的要點，每條附上原文連結，寫進研究目錄。
     tmp-tools：去查開源的 SEO 檢查工具裡寫著哪些規則，列出和寫文章有關的檢查項，每條附上原文連結，寫進研究目錄。
     tmp-talk：去查最近討論區裡大家怎麼談 AI 寫 SEO 文章，列出說得最多的幾種看法，每條附上原文連結，寫進研究目錄。
     每張卡裡都寫一句：查網頁只用你自帶的搜尋和讀網頁功能，不要用 curl、python 這類命令去抓網頁（命令抓網頁每次都要老闆批准）。
     三份結果讀完，把三頁一一關掉。
  ② 彙總方案、寫改進版：對照三份資料和業界的最佳實踐，逐條寫出要改什麼、為什麼、出處在哪，再寫出改進版。
  ③ 請成長經理審：流量歸成長經理管，內容經理按協作規矩第 1、3、6、7 條寫一張任務卡交給 growth：對照原來的 Skill、改進版和 研究/ 裡的三份資料，從流量的角度逐條看每個改動有沒有依據、能不能帶來搜尋流量；寫清哪一條、為什麼、建議怎麼改；只提意見，不重寫；意見放進 駕駛艙/任務/。growth 用的是 Codex 的話，做完常顯示「拿不準」，按協作規矩第 6、7 條以產出文件為準。拿到意見，內容經理逐條處理（採納就改，不採納寫理由），寫成處理說明，再回你一句「完成」。
第三件：內容經理交回後，打開三樣產出核對：審閱意見確實是 growth 寫的，每條意見在處理說明裡都有下落。缺了就把缺什麼告訴內容經理，請它補齊。
第四件：把整件事彙總成一份報告，放進 駕駛艙/任務/：查了哪三塊資料、改了哪幾條、每條的出處、成長經理提了什麼、各自怎麼處理的，最後附上這份 Skill 改前改後的逐條對比。然後停下來請我確認。我點頭，你再改 工具/技能/seo-writing/SKILL.md（只改這份實體，掛連結的兩處不用動），並存一次 git。
第五件：把經驗沉澱下來，下次一句話就夠。寫回以後，你和內容經理各自在 工作記錄/ 裡記一筆：這一套怎麼查、找誰審、文件放在哪、踩了什麼坑。值得以後照做的，各自整理成手冊裡的一小段流程，寫好先給我看（改手冊算改正式文件），我說「可以」再寫進去。目標是下次我只說一句「SEO Skill 再按最新的做法更新一遍」，你們就知道該怎麼做。

【最後給我一份彙報】
就是第四件那份報告，外加每張任務卡的路徑，和第五件裡記下的工作記錄路徑、準備寫進手冊的那一小段。

【過關標誌】
側欄裡 content 亮起黃燈；tmp-guide、tmp-tools、tmp-talk 三位同時出現，做完後被關掉；growth 亮過黃燈；研究/ 裡多了三份資料；駕駛艙/任務/ 裡有改進版、審閱意見、處理說明和報告；你停在「要不要寫回」，等我點頭；寫回以後，你和內容經理的工作記錄裡都記下了這一項任務的經驗。

這一仗能看到什麼

• 側欄即戰況：content 黃燈（在忙）、三個 tmp-* 同時出現又依次消失（用完即關）、growth 亮過黃燈（互審發生過）。
• 寫回閘門：gm 停在「要不要寫回」等你點頭——正式文件的最後一道鎖在老闆手裡，整個流程沒有任何一步繞過你。
• 換模型互審：起草的 content 與審閱的 growth 是不同家模型、不同進程、不同 context——審的人沒參與起草，才審得動。

考卷解答：八條裡埋的毛病

團隊跑完後對一對，找得出幾條就是這家公司的水平：

準備段之所以反覆強調「原樣寫入、一個字都不要改、別的什麼都不做」：駕馭工程看到有毛病的東西會忍不住順手修，那練習就沒意義了。