Leo/system-dev-template
1
0
Fork 0
Code Issues 1 Pull Requests Actions Packages Projects Releases Wiki Activity

Initial commit

Browse Source
This commit is contained in:
richblack
2026-06-08 16:06:18 +08:00
commit 8aa1b68ca0
19 changed files with 1284 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
skills/llm-wiki/SKILL.md
+134
View File
@@ -0,0 +1,134 @@
---
name: llm-wiki
description: >-
為任何開發專案建立或維護 LLM Wiki 記憶系統——一套讓 CC（Claude Code）不再重複犯錯、
不忘決策脈絡的雙空間文件結構。觸發時機：
（1）新專案 init——「幫我建立 wiki 系統」「新專案要設置文件結構」；
（2）老專案 migrate——「幫我整理文件」「文件太亂了」「散落的 md 幫我收一收」；
（3）對話結論 capture——「把剛才的討論記下來」「這個決定要存起來」「我不想再解釋一次」；
（4）wiki 更新——「更新 status」「記錄這個 mistake」「加一條決策」。
只要涉及「讓 CC 記住某件事」或「整理專案文件讓 CC 好找」，都用這個 skill。
---
# LLM Wiki Skill
讓 CC 不再是失憶的協作者。這個 skill 幫你在任何專案裡建立一套
**人寫文件 + CC 整理 wiki** 的雙空間系統，讓每次 session 都能無縫接上。
靈感來源：Andrej Karpathy 的 LLM Wiki 概念——不用 embedding，
只靠 pre-compile 把知識整理成 LLM 友善的格式。
---
## 四種使用情境
| 情境 | 觸發訊號 | 跳到 |
|------|---------|------|
| **A. 新專案 init** | 空專案、剛開始 | → [流程 A](#流程-a新專案-init) |
| **B. 老專案 migrate** | 已有文件但很亂 | → [流程 B](#流程-b老專案-migrate) |
| **C. 對話結論 capture** | 剛討論完某個決策 | → [流程 C](#流程-c對話結論-capture) |
| **D. Wiki 日常更新** | session 結束、踩到坑 | → [流程 D](#流程-d-wiki-日常更新) |
---
## 雙空間架構
```
專案根目錄/
├── CLAUDE.md ← 導航牌，≤100 行，永遠不增長
├── docs/ ← 原始文件空間（人寫，CC 讀）
│ ├── README.md
│ ├── 1-vision/
│ ├── 2-architecture/decisions/
│ ├── 3-specs/
│ ├── 4-guides/
│ ├── 5-records/{incidents,test-reports}/
│ └── 6-user/
└── .claude/wiki/ ← CC 整理的知識（CC 寫）
├── INDEX.md
├── mistakes.md
├── status.md
└── decisions-summary.md
```
三條原則：docs/ 人寫 CC 不改 | wiki/ CC 維護 | CLAUDE.md ≤100 行
詳細格式見 `references/templates.md`。
---
## 流程 A：新專案 Init
1. 建立目錄結構
2. 依 `references/templates.md` 建立六個核心檔案
3. 訪談（每次一個問題）：做什麼 / 技術限制 / 技術棧 / 現有規範
4. 填入 CLAUDE.md，完成確認
---
## 流程 B：老專案 Migrate
⚠️ 三個階段，每階段等確認再繼續。
**階段一：掃描 + 分類計畫**
遞迴找所有 .md，標注建議位置和信心度，列清單等確認。
分類規則：
```
子系統設計文件 → docs/3-specs/[子系統]/
為什麼做某決定 → docs/2-architecture/decisions/
怎麼操作 → docs/4-guides/
歷史記錄 → docs/5-records/
給使用者看的 → docs/6-user/
不確定 → 列為「待確認」，問使用者
```
**階段二：讀文件，建 wiki**
每個文件讀完後提取到對應 wiki 檔案，全部讀完後展示結果等確認。
**階段三：歸檔**
按確認好的分類移動，根目錄只留必要項目，更新 CLAUDE.md 路徑。
---
## 流程 C：對話結論 Capture
這是最容易被忘記、也最重要的情境。
| 內容類型 | 存到哪 |
|---------|-------|
| 架構決策 | `decisions-summary.md` + `docs/2-architecture/decisions/[日期]-[主題].md` |
| CC 誤解被糾正 | `mistakes.md` |
| 狀態更新 | `status.md` |
操作：辨識 → 列清單給使用者確認 → 寫入 → 告知存到哪裡
**Mistakes 格式：**
```
⚠️ MISTAKE: [錯誤描述]
症狀: [CC 的表現]
正確做法: [應該怎麼做]
原因: [背景]
日期: [YYYY-MM-DD]
```
---
## 流程 D：Wiki 日常更新
Session 結束時固定更新 status.md：
- 這次做了什麼
- 遇到什麼問題
- 下次從哪裡開始
- 有新誤解 → 同時 append mistakes.md
- 有新決策 → 同時 append decisions-summary.md
---
## 維護規則
1. `docs/` 只讀不改
2. `.claude/wiki/` 只增不刪
3. `CLAUDE.md` 不增長，超過 100 行就是放錯地方
4. 分類不確定就問
5. 對話結論當場 capture
skills/llm-wiki/references/templates.md
+250
View File
@@ -0,0 +1,250 @@
# LLM Wiki 範本集
---
## CLAUDE.md 範本
```markdown
# CLAUDE.md — [專案名稱]
> 導航牌。細節在兩個地方，不在這裡。
> Hook 機制在 `.claude/hooks/`（如果有的話）。
---
## 絕對鐵律（違反 = 停手）
1. [專案最重要的限制，例如：任何 code 變動前必須先讀 SDD]
2. [技術棧限制]
3. [...]
找不到對應文件 → **停手問 [負責人名稱]**，不要自行決定。
---
## 工作流程（強制）
開始任一任務，按順序：
1. 讀 `.claude/wiki/status.md`（3 分鐘）
2. 確認有對應 SDD（`docs/3-specs/`）
3. 動手前宣告範圍
4. 完成後更新 wiki
---
## Wiki 讀取順序
| 檔案 | 時機 | 用途 |
|------|------|------|
| `.claude/wiki/status.md` | session 開始第一件事 | 當前進度、下一步 |
| `.claude/wiki/mistakes.md` | 做新功能前 | 已知誤解 + 快速檢查清單 |
| `.claude/wiki/decisions-summary.md` | 遇到設計判斷時 | 架構決策快速查 |
| `.claude/wiki/INDEX.md` | 找不到東西時 | wiki 導引 |
---
## 規範索引
| 檔案 | 內容 |
|-----|------|
| [規範檔路徑] | [說明] |
---
## 文件位置
| 類別 | 位置 |
|------|------|
| 原始文件 | `docs/`（見 `docs/README.md`） |
| 架構決策 | `docs/2-architecture/decisions/` |
| SDD | `docs/3-specs/` |
| 操作手冊 | `docs/4-guides/` |
| 事件記錄 | `docs/5-records/incidents/` |
```
---
## docs/README.md 範本
```markdown
# [專案名稱] 文件分類索引
## 分類規則
| 目錄 | 放什麼 | 例子 |
|------|--------|------|
| **1-vision/** | 為什麼做這個 | 產品願景、北極星 |
| **2-architecture/** | 系統怎麼設計的 | MVP 架構、元件關係 |
| **2-architecture/decisions/** | 架構決策（為什麼選A不選B）| ADR 文件 |
| **3-specs/** | 需求和 SDD | design.md + tasks.md |
| **4-guides/** | 操作手冊：怎麼做 | 部署、CLI 用法 |
| **5-records/** | 歷史記錄 | 壓測報告、問題追蹤 |
| **5-records/incidents/** | 生產問題復盤 | 故障原因、改進方案 |
| **5-records/test-reports/** | 測試結果 | 功能驗收、效能測試 |
| **6-user/** | 對外文件 | self-hosted 安裝、FAQ |
## 分類判斷規則
- 子系統設計文件 → `3-specs/[子系統]/`
- 決策記錄（為什麼）→ `2-architecture/decisions/`
- 操作說明（怎麼做）→ `4-guides/`
- 歷史記錄（發生過）→ `5-records/`
- 給外部使用者看的 → `6-user/`
- 不確定 → 列為「待確認」，問使用者
```
---
## .claude/wiki/INDEX.md 範本
```markdown
# .claude/wiki/ — [專案名稱] LLM 記憶系統
> 新 session 開始時從這裡導航。
> 目的：讓 CC 不需要重新學習已知的事。
## 核心檔案
| 檔案 | 何時讀 | 內容 |
|------|-------|------|
| `status.md` | session 開始第一件事 | 當前進度、下一步 |
| `mistakes.md` | 做新功能前 | 已知誤解、快速檢查清單 |
| `decisions-summary.md` | 遇到設計判斷時 | 架構決策摘要 |
## 維護規則
- `mistakes.md`：只 append，不刪除
- `status.md`：每次 session 結束更新
- `decisions-summary.md`：重大決策後更新
- 所有 wiki 檔案：CC 維護，不是人類維護的地方
```
---
## .claude/wiki/mistakes.md 範本
```markdown
# CC 已知誤解 + 避坑方法
> 做新功能前讀一遍。格式：每條必須有症狀 + 正確做法 + 原因。
## 快速檢查清單
- [ ] 有對應 SDD 嗎？沒有 → 停手
- [ ] 這次修改影響哪些模組？有沒有連帶破壞？
- [ ] 驗收標準是什麼？有客觀證據嗎？
## 誤解記錄
（初始化時為空，隨專案進行 append）
```
---
## .claude/wiki/decisions-summary.md 範本
```markdown
# 架構決策摘要
> 遇到設計判斷時查這裡。完整脈絡在 docs/2-architecture/decisions/。
（初始化時為空，隨專案進行 append）
格式：
## [主題] — [YYYY-MM-DD]
**結論**：[一句話]
**原因**：[簡短說明]
**詳細**：docs/2-architecture/decisions/[對應檔案]
```
---
## ADR 範本（docs/2-architecture/decisions/YYYY-MM-DD-topic.md）
```markdown
# [主題]
**日期**：[YYYY-MM-DD]
**狀態**：[提議中 / 已採納 / 已廢棄]
## 背景
[為什麼需要做這個決定？]
## 決定
[結論，一句話]
## 原因
[詳細說明]
## 放棄的選項
| 選項 | 放棄原因 |
|------|---------|
| [選項 A] | [原因] |
## 影響
[影響哪些地方，有什麼後續要注意]
```
---
## SDD design.md 範本（docs/3-specs/[子系統]/design.md）
```markdown
# [子系統] — Design
> 狀態：[草稿 / 已採納]
> 建立：[YYYY-MM-DD]
## 一句話說明
## 背景與問題
## 範圍
In Scope：
Out of Scope：
## 設計
### 架構概覽
### 關鍵決策
### API 定義
### 資料模型
## 技術限制
## 驗收標準
- [ ] [可客觀驗證的條件]
```
---
## SDD tasks.md 範本（docs/3-specs/[子系統]/tasks.md）
```markdown
# [子系統] — Tasks
> 動手前標 [🔄]，完成立刻標 [x]，不批次更新。
## Phase 1：[名稱]
- [ ] 1.1 [task 描述]
- 驗收：[客觀標準]
## 狀態說明
| 標記 | 意義 |
|------|------|
| `[ ]` | 未開始 |
| `[🔄]` | 進行中 |
| `[x]` | 完成 |
| `[~]` | 暫緩 |
| `[!]` | 阻擋中 |
```