nickolaslin33
- 7 skills
- 0 followers
- 1 day ago last updated
- ▌ Reentry · nickolaslin33 bundle人與 AI agent 工作一整天之後要離開、或隔了幾小時到一個週末回來接手時，用這套流程留下與讀取「重建材料」。收工分四個階段——人離開工作畫面憑記憶寫、agent 校驗、人修正、整理任務狀態；回來時照固定順序讀出來。它解的不是記憶問題：在這個時間尺度上恢復成本十幾秒就飽和，回來時發生的幾乎都是重建，真正的病是理解債——在尚未真正理解前就讓任務往下推進，症狀看起來像忘了，實際是當時就沒形成足夠的理解。觸發情境：使用者說「我回來了」「繼續某某專案」「上次做到哪」「我忘記做到哪了」「重新進入狀況」「哪個專案還沒做完」，或說「收工」「今天到這」「先記一下進度」「交接一下」「幫我留個紀錄」；也包含任何檢視完 agent 的產出準備離開、或隔了一段時間要接回某個專案的時刻。使用者不必說出 reentry 這個詞——只要他們在問「我上次在幹嘛」或正要結束一段工作，就用這個 skill。Also triggers on — resume work, pick up where I left off, where was I, wrap up, end of session, handoff notes, context recovery, what did I do last time.
- ▌ Eli Adhd 5 · nickolaslin33用「像我有 ADHD、又只有五歲」的方式寫東西給沒空看的工程師。兩種模式：回報工作時開頭三行講做了什麼、還能不能跑、對方可能會反對的決定；寫 README、設計文件、PR 描述、除錯紀錄時開頭三件事講這是什麼、現在能不能信、你可能會反對的設計決定。只有使用者明確指名 eli-adhd-5 或 ELI-ADHD-5 時才使用；不要因為對話很長、內容很技術、或使用者說「講簡單一點」就自己套用。
- ▌ Gh Shoulders · nickolaslin33 bundle規劃新功能、設計架構或做技術選型之前，先到 GitHub 調查開源世界怎麼解同一個問題，產出含候選比較、深讀解析與 license 判定的調查報告。只要需求裡有開源世界可能已經處理過的通用成分，就先用這個 skill，即使使用者沒有明講要做調查——憑既有知識直接開始設計，等於放棄別人已經驗證過的做法，以及別人已經遇過、你還沒遇到的問題。觸發情境：規劃新功能、設計架構、技術選型、要不要自己寫、有沒有現成的、別人怎麼做、找類似專案、參考開源作法、先例調查、prior art、find similar projects、站在開源巨人的肩上。修 bug、小幅修改、純內部領域邏輯（公司專屬設定資料、內部專有協定）不適用。
- ▌ My English Cpr · nickolaslin33 bundle使用者用中文工作、句子裡夾英文單字或整句用英文發問時，回答完他的問題之後，順便指出英文可以改進的地方。目的是他在做正事的同時把英文練起來，所以糾錯永遠放在回答之後、不搶正事的位置。只要使用者的訊息裡出現英文單字或英文句子，就套用這個 skill，即使他沒有要求檢查英文——他要的就是不必開口也會發生。夾雜在中文裡的單字只看選詞對不對，拼字失誤與單複數放過；整句英文才做完整檢查。觸發情境：使用者訊息含英文、幫我看英文、我的英文對嗎、這樣講對不對、check my english、is my english correct、英文糾錯。純中文訊息、使用者引用別人寫的英文、程式碼與指令內的英文不適用。
- ▌ Neutral Examples · nickolaslin33 bundle寫任何會離開這台機器的東西時，範例素材一律用虛構但一樣具體的名字，不要把手邊的真實專案名、家目錄路徑、email、GitHub 帳號、公司內部系統代號寫進去。用在撰寫 skill（SKILL.md、references/、evals/）、README、公開 repo 的文件、部落格、對外的技術報告、要貼到 issue 或聊天室給別人看的程式碼片段與終端機輸出。特別是被 skill-creator 觸發、或正在寫任何要 push 到公開 repo 的文件時，務必套用——那個情境最容易把真實資訊寫進去，因為 Agent 的 context 裡剛好有當前工作目錄、工作區裡其他專案的名字與這段對話提到的真實專案，需要舉例時它們是最現成的材料。觸發詞：「去識別化」「不要用我的專案當範例」「這要公開」「要 push 到公開 repo」「寫 skill」「寫 README」「整理成對外文件」「匿名化」「這段可以貼出去嗎」「幫我看有沒有夾帶個資」。反過來說，只在本機的筆記、私有 repo 的內部文件、commit 訊息、程式碼註解不適用——那些地方寫真實名稱才是對的。
- ▌ Clear Technical Chinese · nickolaslin33 bundle用自然、精準、讀者第一次看就懂的繁體中文寫作，並清掉 AI 模板句型。分兩種模式：撰寫或潤飾 README、SKILL.md、規格、設計文件、技術說明、操作流程時用「技術文件模式」（完整、精準、可執行）；一般問答、進度回報、方案討論時用「日常回覆模式」（簡潔、自然、直接）。只要你正要用中文寫任何給人看的東西——文件、回覆、commit 訊息、報告、註解——就套這個 skill，即使使用者沒說「幫我潤飾」。特別是當你正想寫「沒破」「炸掉」「卡死」「撈不到」這類工程師黑話、想把 contract 一律翻成「契約」、想用「邊界」「語意」「機制」「脈絡」這類看似專業實際模糊的詞、或正要寫出「不是 A，而是 B」「真正的問題是」「核心在於」「讓我們來看」「你可能會問」這類看起來在給洞見、實際沒給可查證內容的句型的時候。改別人已經寫好的草稿時同樣適用，那裡多一條限制：事實、數字、但書與例外不准在潤飾過程中被改掉。觸發詞：「用中文寫」「幫我潤飾」「去 AI 味」「太像 ChatGPT」「這段看不懂」「講白話一點」「太文言」「太像 AI 寫的」「寫份文件」「寫 README」「整理成說明」「技術文件」。
- ▌ Format Preserving Edits · nickolaslin33 bundle改既有的設定檔或資料檔時，只動你要動的那幾行，其餘排版原封不動，讓 diff 只剩真正的異動。適用 JSON / YAML / TOML / INI / XML / .env / CSV。只要你正要在既有檔案裡新增一筆設定、刪掉一個 key、改一個參數、批次改多個 config、把大檔拆成小檔或搬設定，就用這個 skill——即使看起來只是改一行。特別是當你想呼叫 json.dump / yaml.dump / ConfigParser.write / xml pretty-print 或任何 parser round-trip 的時候：那些 API 會把整份檔案正規化，製造上千行假 diff，還會吃掉註解與鍵序，務必改用這裡的做法。觸發詞：「不要幫我排版」「維持原本的排版」「照原本的格式」「不要動格式」「diff 太亂」「只改該改的」「preserve formatting」「don't reformat」「keep the existing style」「minimal diff」，以及任何改設定檔 / 改 config / 加一筆資料的請求。