  jiantw83andClaude Opus 5
|
87e4555a90
|
docs(comment-scope): 色碼列進允許項，不再當編號看
「允許寫進註解」那張表加一列：十六進位色碼。理由寫在同一列——它指的是顏
色，不是編號；只有純十進位的才當議題編號看。
守門腳本那一邊已經多剪一條，把井號後面含十六進位字母的色碼先剪掉。正文
是規則的唯一真實來源，腳本剪了一條而正文不動，下一個讀正文的人會以為色
碼仍然違規，於是把註解裡的色碼手動刪掉，或反過來覺得腳本放水。兩邊對不
起來，規則就沒有人信。
補的是一列，不是一段。既有六列的欄位次序照舊，允許項、理由、範例三格都
填滿，範例挑樣式表註解裡標主色那種常見寫法，讀的人一眼看得出這條規則在
講哪種場景。
影響註解範圍的判準本身，也就是所有讀這份正文的人與所有引用它的技能：註
解裡寫色碼從此明文放行，議題編號、需求編號那些照舊禁止。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
2026-09-08 15:04:21 +08:00 |
|
|
jiantw83
|
d472f81cd2
|
feat(狀態回報): 收尾寫一筆 skill-end 事件
現行紀錄只記「被叫用」，沒有成敗也沒有結束碼。跑完整輪的技能與開場就
中止的技能，在紀錄裡長得一模一樣。
start 由技能用量 hook 順手發，不必改技能文件。end 只能由技能自己在收尾
步驟寫——hook 接在技能工具呼叫上，而實際工作發生在之後的模型輪次，它在
原理上看不到成敗。有 start 沒有配對的 end，就是那一輪中止了。
status 五選一，每支技能各自寫明什麼情況選哪一個。找不到回報腳本就安靜
跳過，回報失敗一律不改變技能自己的結論。
|
2026-09-02 16:01:17 +08:00 |
|
|
jiantw83
|
d4fea890c7
|
docs(review): 新增三支技能的行為清單
What：
在既有的 `references/` 目錄新增 `behaviors.md`。
文件分 api-doc、code-review、comment-cleanup 三節。
每節一張五列表：觸發時機、關鍵步驟、外部呼叫、完成條件、可驗證跡象。
Why：
技能驗證缺一份共同的比對基準。
以前只能重讀技能本文推敲行為，判斷因人而異。
清單放在本 repo，技能改動與清單就落在同一個 PR，不會漂移。
也不用為了一次改動跨 repo 開兩條 PR 互卡。
How：
逐支技能盤點行為，再把結果填進五列表。
稽核時修正 comment-cleanup 的外部呼叫敘述。
原本寫成 write-guard.sh 條件式涵蓋這支技能。
實際上那支腳本一律豁免它，而且這支技能根本不呼叫它，已據實改寫。
格式交由 `meta/tools/check-behaviors.sh` 在程式層檢查。
Who：
jsc-review 技能的維護者。
執行技能驗證的人。
日後異動這三支技能的人，都要同步更新這一頁。
|
2026-08-31 13:46:35 +08:00 |
|
|
jiantw83
|
f6cd1f9ef7
|
feat(api-doc): 範例只掛純量成員，類別型往下遞迴
- 使用者要求改判準。類別型參數與中間層的類別屬性只留說明，範例責任往下推給屬性，一路走到最內層的純量。
- 一個值只有一個出處。範例掛在父層，屬性一改就過期，讀的人拿到的是沒有屬性定義背書的一份資料。
- 集合看元素型別，不看外殼；字典看值型別。字串集合與字串判出來一樣，位址集合與位址判出來也一樣。
- 壞味道清單原本寫「輸入與輸出參數都必須有範例」，與新判準衝突，兩支技能會對同一段程式碼給出不同標準。一併改成同一套。
- 說明與範例的兩份檢核表併成一個 sub agent，同一批資料模型檔只讀一次。
- 順帶補上偵測腳本結束碼二漏掉的一個原因：環境缺 grep。原本只寫參數與路徑，遇到這個原因換路徑重跑永遠清不掉。
|
2026-08-31 11:07:05 +08:00 |
|
|
jiantw83
|
aaa0227464
|
feat(comment-scope): 擴充審查流程痕跡規則
|
2026-08-28 09:30:33 +08:00 |
|
|
jiantw83
|
dbaf81005b
|
feat(smells): 第 5 組擴充條列式步驟、導向連結與標示語法
What：references/smells.md 第 5 組擴充。5.1 的方法描述後面要接條列式的處理步驟
與規則，5.3 的回傳值是自訂資料模型時要附上型別定義的導向連結；新增 5.6 內含
功能的導向連結、5.7 XML 註解標籤各占一行、5.8 註解裡的專有名詞與變數依語言
慣例標示。文末的嚴重度分級補上一張表，逐項標明這五個新項目的級別與理由。
Why：使用者提出的產出物文件品質規則裡，有三條講的都是原始碼註解要寫到什麼
程度。動手前先比對過既有內容，第 5 組已經涵蓋大部分，缺的是條列步驟、導向
連結與標示語法這三塊。另開一支技能會跟 code-review 的目標重疊，所以直接擴充
第 5 組。新項目多半屬於可讀性層級，混在原本「註解缺漏」一句話裡分不出輕重，
所以級別另外列。
How：5.1 與 5.3 在原有定義後面接上新要求，偵測訊號與建議重構手法同步補列，
原本的判準一個都不動。5.6 到 5.8 照既有小節的四段結構寫：定義、偵測訊號、
建議重構手法、注意事項。5.8 的標示語法用表格對照 XML 與 JSDoc、docstring
兩類格式。5.6 與 5.7 都寫明註解格式不支援時不適用，避免硬造連結字串，也避免
把 XML 的排版規則套到沒有結束標籤的格式上。
Who：jsc-review 的壞味道參考清單，第 5 組註解契約。
|
2026-08-27 15:41:38 +08:00 |
|
|
jiantw83
|
fd70ce3bc2
|
feat(review): 新增程式碼註解禁止夾帶文件資訊的規則正文
What：新增 references/comment-scope.md 規則正文，並在 references/smells.md
第 2 組加入 2.5 文件編號夾帶，嚴重度分級「低」列補上本項。
Why：註解寫「這件事記在哪份文件」，讀程式碼的人查不到。編號會過期、會搬家、
會落在存取權限外，最後只剩一串無意義的代號。註解該寫的是「為什麼這樣寫」。
How：規則正文限定適用範圍只到程式碼註解，docstring、README、commit 訊息不受限。
禁止清單三十項分四組：追蹤系統編號、jsc wiki 頁面編號、需求與規格編號、
流程與人事資訊。白名單七項：日期與時間戳、需求變更歷程、RFC 與 ISO 標準、CVE、
第三方套件 issue 連結、授權標頭與 SPDX、語言原生標記。
Who：jsc-review 的 code-review 技能，第 2 組可讀性審查。
|
2026-08-26 19:00:38 +08:00 |
|
|
jiantw83andClaude Fable 5
|
3692c9e915
|
style(review): 中文並列改頓號
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
2026-08-21 14:29:47 +08:00 |
|
|
jiantw83andClaude Fable 5
|
2c03779e41
|
style(review): 依 STE100 擬人台灣感規則改寫語感
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
2026-08-21 14:17:32 +08:00 |
|
|
jiantw83andClaude Fable 5
|
e1cc4ed6c4
|
feat(review): 匯入 jsc-review 技能組
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
2026-08-21 13:08:43 +08:00 |
|