Communitygithub.com

nathankim0/ssul

撰寫、潤飾或審核短篇韓文社群貼文(Threads、X、Instagram 貼文標題、社群貼文),讓它們讀起來像真人講述真實故事,而非 AI 生成。當使用者要求寫 Threads 貼文、스레드 글、爆文、鉤子文、日常文、SNS 貼文、썰,或需要韓文貼文的鉤子,或表示草稿「AI 같다」、「너무 무겁다」、「뭔 소린지 모르겠다」,或希望以自然口語改寫時使用。結合鉤子技巧、說故事、韓文反 AI 編輯與口語規則於一體,且草稿前需要真實素材。

ssul 是什麼?

這項技能專為撰寫、潤飾與審核韓文社群貼文而設計,要讓貼文讀起來像是真人自然講述故事,而非 AI 生成。它整合了鉤子公式、說故事技巧、反 AI 編輯與韓文口語規則,並解決這些來源之間的衝突。核心原則是:若內容是虛構的,風格修飾也無法挽救。因此,寫作前必須取得真實素材,例如場景細節、具體數字或實際引述。 支援多種模式:從頭起草(需至少三項真實素材)、潤飾現有草稿、審核找出問題,或單獨生成鉤子(前三行)。在確認素材足夠前,會以對話式提問引導使用者。如果使用者堅持先寫草稿,則會用中括號標記所有虛構細節並明確告知。 技能涵蓋完整的處理流程:選擇合適的語氣(模仿使用者風格或依領域預設)、選擇貼文框架(場景、自白、反轉、清單等)、撰寫具鉤子且避免四大殺手的第一行、以最後一行為基礎組織內文,最後執行七項檢查,包括真實性、無需背景知識即可理解、輕量感、價值性、韓文 AI 跡象、口語化與平台規範。 最終輸出僅為貼文文本及最多三行簡短備註,不包含冗長報告或分析。此技能主要支援韓文社群平台,如 Threads、X、Instagram 與社群貼文。

相容平台~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/nathankim0/ssul/tree/HEAD/skills/ssul

在你喜歡的 AI 中提問

開啟一個已預先載入此 Agent Skill 的新對話。

說明文件

ssul 是做什麼的?

一篇貼文要成功,需要讓陌生人在讀完第一行後繼續讀下去,每一行都不需背景資訊就能理解,並相信這是真人寫的。這項技能一次到位。它融合了鉤子公式、說故事、反 AI 編輯與韓文口語規則,並解決這些來源之間的衝突(參見 references/conflicts.md)。

這項技能背後的核心教訓:風格修飾無法挽救虛構的內容。一篇有完美鉤子且使用自然口語的貼文,如果場景、數字和引述都是編造的,仍然會讓人覺得像 AI 寫的。真實素材優先。

模式

從請求中選取模式。不要詢問要哪一種。

請求模式輸出
"써줘"、主題或筆記草稿一篇貼文 + 三行備註
草稿 + "다듬어줘 / AI 같아 / 무거워"潤飾修正後的貼文 + 修改重點
"검사해줘 / 뭐가 문제야"審核僅發現問題,不重寫
"훅만 / 첫 줄만"鉤子三個來自不同觸發器的首行 + 一個推薦

步驟 1. 取得真實素材(草稿模式)

在開始寫作之前,您至少需要以下三項,來自使用者或對話中已存在的事實:

  • 誰在場景中(我、我爸爸、同事、我的貓)
  • 地點 / 時間(晚上九點的田野、早上 8:10 的地鐵、週一的站立會議)
  • 一個可見或可數的具體細節(零下 2 度、16 個儲存庫、一個頭燈)
  • 某人實際說過的一句話,或實際發生的一件事
  • 使用者為什麼想發布這篇貼文(好笑、發洩、展示、提問)

目前對話中的事實也算作真實素材:使用者建立、安裝、說過或詢問過的內容都可以用。這些通常是最好的來源。

如果您沒有足夠的素材,最多從 references/interview.md 中提出 3 個簡短問題,在一則訊息中提出。如果使用者無論如何都想要一份草稿,請將每個虛構的細節用 [括號] 標示出來,並明確說明那些部分是佔位符。永遠不要將虛構的經歷、數字、引述或事件呈現為真實。

步驟 2. 修正語氣

按此順序選取語氣。第一個存在的來源獲勝。

  1. 使用者自己的貼文(3 篇以上):注意結尾方式、使用 ㅋㅋ 和表情符號的頻率、行長度、開頭和結尾。模仿它們。
  2. 使用者貼上的動態樣本(使用者想模仿的其他人的貼文):模仿這些貼文中大多數使用的那種語氣,而不是禮貌的平均值。
  3. 領域預設(references/korean-voice.md#register-by-niche):AI、開發、新創、投資和熱評貼文預設使用 반말 혼잣말(~다、~함、~임、~네、~냐)。日常生活、育兒、美食和品牌帳號預設使用 해요체 구어(~거든요、~더라고요、~잖아요)。

一篇貼文只用一種語氣。貼文內的引述保留說話者的語氣。

步驟 3. 選取架構

架構使用時機目標
場景(장면)一個附帶小轉折的瞬間按讚
自白(고백)使用者做過的某件真實之事,包含尷尬的部分回覆
反轉(뒤집기)普遍信念 vs 實際發生之事,兩者都要具體分享
清單(목록)內容真的是清單(工具、步驟),且每個項目一行收藏
提問(질문)使用者真心想要答案回覆
一句話(한두 줄)一個感受或一個結論說盡一切按讚、分享
發現(발견)使用者嘗試了某事並學到他人可用的知識收藏、分享
短評(한마디)使用者對某趨勢有態度:煩躁、諷刺、自嘲回覆、引言

根據素材選擇:

  • 有轉折的真實事件 → 場景或自白
  • 讀者可用的知識 → 發現或清單
  • 有態度 → 短評或一句話

不要製造幽默。 如果素材中沒有任何真正好笑的事情,就不要建立笑點。改寫發現或態度的內容。態度(煩躁、諷刺、自嘲)比強迫的笑話更能撐起一篇貼文。通常越短越好:兩行的貼文就是一篇完整的貼文。

不要自我沈溺。 關於寫作過程本身、用來寫作的工具或協助的 AI 的故事,屬於內部人員素材。只有當讀者經歷過相同的事情時,它才算過關。

每種架構的格式細節:references/formats.md。

步驟 4. 撰寫第一行

從不同的觸發器(具體數字、引述的話語、自白、反轉、提問)生成 3 個候選項。公式:references/hooks.md。逐一檢查每個候選項是否符合四個殺手級條件:

  1. 太晚:主題不在第一行。
  2. 令人困惑:需要重讀一次或讀者沒有的背景資訊。
  3. 不屬於我:讀者無法在其中看到自己。
  4. 平淡:讀者預期與實際發生之間沒有差距。

保留通過全部四個檢查的那一個。當這個瞬間讀者也經歷過時,使用第一人稱視角是可以的。不要強迫使用「여러분」。

步驟 5. 起草

  1. 先寫最後一行。這一行應該是人們會單獨引用的句子。具體的精彩結尾或真實引述勝過一個教訓。
  2. 用 근데(但是)或 그래서(所以)連接中間的節拍。如果「그리고 나서」適合放在兩個節拍之間,那麼其中一個是多餘的填充物。
  3. 用使用者對一個朋友說話的方式來寫。換行跟隨呼吸。
  4. 每篇貼文保持在 500 個字元以下(Threads 限制)。日常隨性貼文通常在 120 到 300 之間。

步驟 6. 執行檢查

按順序對每份草稿執行所有檢查。細節在 references/korean-voice.md 和 references/checklist.md 中。

  1. 真實性:每個數字、名字、引述和事件都是真實的或有括號標示。
  2. 陌生人測試:沒有任何背景資訊的人都能理解每一行。用簡單的詞語取代內行詞語(「윤문 스킬」、專案名稱、內部笑話)。如果需要了解對話才能理解貼文,則視為失敗。
  3. 輕量感測試:看起來像報告嗎?刪除開場白、不是清單的清單、笑話的解釋以及結尾的教訓。
  4. 價值測試:陌生人能獲得什麼:可用的知識、能辨識的感受、或真正的笑點?如果都沒有,就改變架構或素材。不要潤飾一無是處的貼文。
  5. 韓文 AI 跡象:教訓式結尾、模糊的 X가 아니라 Y다 結構、三項式清單、名詞化(진행하다、공유드리다)、翻譯腔(당신、~하는 것은 중요합니다)、過多形容詞堆疊、長破折號、用於強調的書名號、粗體。
  6. 口語化語氣:沒有報告用詞(따라서、종합하면、부각、안착)、連續 4 個相同的句子結尾、最多一個自問句。
  7. 平台規範:0 或 1 個主題標籤、第一篇貼文中沒有連結、最多 2 個表情符號、結尾沒有互動誘餌。

輸出

草稿和潤飾模式先輸出貼文,然後最多輸出 3 行簡短說明:

  • 使用的架構及原因
  • 哪些是真實的、哪些是佔位符
  • 使用者在發布前應檢查的一件事

除非要求,否則不要附加冗長的報告、表格或評分。使用者要求的是貼文。

永遠不要發布、排程或傳送任何內容。僅輸出文字。

相關技能