Merge pull request 'feat(sdlc): 匯入 jsc-sdlc 技能組並統一 marketplace 為 jsc' (#2) from develop into master

Reviewed-on: #2
Reviewed-by: 系統管理員 <1+admin@noreply.localhost>
This commit was merged in pull request #2.
This commit is contained in:
2026-08-21 06:41:35 +00:00
20 changed files with 450 additions and 278 deletions
+66 -3
View File
@@ -1,11 +1,74 @@
{
"name": "template",
"name": "jsc",
"plugins": [
{
"name": "jsc-template",
"name": "jsc-ask",
"source": {
"source": "url",
"url": "https://gitea.jsc.idv.tw/plugins/template.git"
"url": "https://gitea.jsc.idv.tw/plugins/ask.git"
}
},
{
"name": "jsc-cli",
"source": {
"source": "url",
"url": "https://gitea.jsc.idv.tw/plugins/cli.git"
}
},
{
"name": "jsc-git",
"source": {
"source": "url",
"url": "https://gitea.jsc.idv.tw/plugins/git.git"
}
},
{
"name": "jsc-gitea",
"source": {
"source": "url",
"url": "https://gitea.jsc.idv.tw/plugins/gitea.git"
}
},
{
"name": "jsc-hooks",
"source": {
"source": "url",
"url": "https://gitea.jsc.idv.tw/plugins/hooks.git"
}
},
{
"name": "jsc-log",
"source": {
"source": "url",
"url": "https://gitea.jsc.idv.tw/plugins/log.git"
}
},
{
"name": "jsc-meta",
"source": {
"source": "url",
"url": "https://gitea.jsc.idv.tw/plugins/meta.git"
}
},
{
"name": "jsc-pkg",
"source": {
"source": "url",
"url": "https://gitea.jsc.idv.tw/plugins/pkg.git"
}
},
{
"name": "jsc-review",
"source": {
"source": "url",
"url": "https://gitea.jsc.idv.tw/plugins/review.git"
}
},
{
"name": "jsc-sdlc",
"source": {
"source": "url",
"url": "https://gitea.jsc.idv.tw/plugins/sdlc.git"
}
}
]
+80 -5
View File
@@ -1,14 +1,89 @@
{
"name": "template",
"description": "JSC 跨 AI 助理共用 skills 的 Claude Code marketplace。",
"name": "jsc",
"description": "jsc 跨 AI 助理技能組的統一 marketplace(claude / codex / copilot / antigravity / kiro)。",
"owner": {
"name": "JSC"
},
"plugins": [
{
"name": "jsc-template",
"source": "./",
"description": "JSC 共用 skills(跨 AI 助理)"
"name": "jsc-ask",
"source": {
"source": "url",
"url": "https://gitea.jsc.idv.tw/plugins/ask.git"
},
"description": "決策樹問詢與問詢紀錄(QUESTION_* wiki 頁)"
},
{
"name": "jsc-cli",
"source": {
"source": "url",
"url": "https://gitea.jsc.idv.tw/plugins/cli.git"
},
"description": "CLI 偵測、模型能力標籤與技能庫批次部署"
},
{
"name": "jsc-git",
"source": {
"source": "url",
"url": "https://gitea.jsc.idv.tw/plugins/git.git"
},
"description": "Commit 分組認可與 Push Request 建立"
},
{
"name": "jsc-gitea",
"source": {
"source": "url",
"url": "https://gitea.jsc.idv.tw/plugins/gitea.git"
},
"description": "Gitea API 工具、Wiki 讀寫與存取庫批次同步"
},
{
"name": "jsc-hooks",
"source": {
"source": "url",
"url": "https://gitea.jsc.idv.tw/plugins/hooks.git"
},
"description": "跨 CLI hooks:STE100 語言強制、工時計時、技能用量記錄"
},
{
"name": "jsc-log",
"source": {
"source": "url",
"url": "https://gitea.jsc.idv.tw/plugins/log.git"
},
"description": "工作日誌(LOG_* wiki 頁)與技能使用統計"
},
{
"name": "jsc-meta",
"source": {
"source": "url",
"url": "https://gitea.jsc.idv.tw/plugins/meta.git"
},
"description": "技能組自我管理:新建/更新/刪除技能與技能準則"
},
{
"name": "jsc-pkg",
"source": {
"source": "url",
"url": "https://gitea.jsc.idv.tw/plugins/pkg.git"
},
"description": "套件批次更新(nodejs/python/dotnet),失敗還原"
},
{
"name": "jsc-review",
"source": {
"source": "url",
"url": "https://gitea.jsc.idv.tw/plugins/review.git"
},
"description": "程式碼審查:Refactoring 壞味道六組 + 註解規範 + 淺模組"
},
{
"name": "jsc-sdlc",
"source": {
"source": "url",
"url": "https://gitea.jsc.idv.tw/plugins/sdlc.git"
},
"description": "開發生命週期:規劃/分析/實作/維護(wiki 追蹤)"
}
]
}
+11 -6
View File
@@ -1,12 +1,17 @@
{
"name": "jsc-template",
"version": "0.0.3",
"description": "JSC 跨 AI 助理共用 plugin 模板(Claude Code / Codex / Antigravity / OpenCode)。所有 skills 以 SKILL.md 為共通標準,於 Claude Code 以 /jsc-template: 前綴呼叫。",
"name": "jsc-sdlc",
"version": "0.0.1",
"description": "開發生命週期:規劃/分析/實作/維護(wiki 追蹤)",
"skills": "./skills",
"author": {
"name": "JSC"
},
"homepage": "https://gitea.jsc.idv.tw/plugins/template",
"repository": "https://gitea.jsc.idv.tw/plugins/template.git",
"keywords": ["template", "skills", "cross-tool", "jsc"]
"homepage": "https://gitea.jsc.idv.tw/plugins/sdlc",
"repository": "https://gitea.jsc.idv.tw/plugins/sdlc.git",
"keywords": [
"jsc",
"sdlc",
"skills",
"cross-tool"
]
}
+3 -3
View File
@@ -1,6 +1,6 @@
{
"name": "jsc-template",
"version": "0.0.3",
"description": "JSC 跨 AI 助理共用 plugin 模板。所有 skills 以 SKILL.md 為共通標準。",
"name": "jsc-sdlc",
"version": "0.0.1",
"description": "開發生命週期:規劃/分析/實作/維護(wiki 追蹤)",
"skills": "./skills"
}
+10 -10
View File
@@ -1,15 +1,15 @@
# jsc-template — 共用 Skills(跨 AI 助理)
# jsc-sdlc — 給 AI 助理的指引
本 repo 是一組以 **Agent Skills(`SKILL.md`)** 標準撰寫的共用 skills,可同時被 Claude Code、Codex、Antigravity、OpenCode 使用。
本 repo 是 jsc 技能組的 `sdlc` domain(開發生命週期:規劃、分析、實作、維護,wiki 追蹤),可同時被 Claude Code / Codex / Copilot / Antigravity / Kiro 使用。
## 給 AI 助理的指引
## 規則
- 所有可用的 skills 位於本 repo 的 `skills/<name>/SKILL.md`。
- 在處理任務前,先比對使用者需求與各 skill `SKILL.md` frontmatter 的 `description`,若相符請載入並依其步驟執行。
- **呼叫慣例**:在 Claude Code 與 Antigravity 中,這些 skill 以 `/jsc-template:<name>` 呼叫;Codex 以 `$<name>`、OpenCode 由模型依描述自動觸發 — 兩者沒有 `/jsc-template:` 前綴,不需強制加。
- 完整清單與每個 skill 的用途,請見 `README.md` 的「Skills 目錄」。
1. 所有交談與輸出內容使用 STE100 繁體中文,帶擬人台灣感:短句、一句一指令、台灣用語、全形標點、去 AI 味、直接講重點。完整規則的唯一來源:`plugins/meta` 的 `references/ste100.md`。
2. 技能位於 `skills/{name}/SKILL.md`;處理任務前先比對需求與各技能的 `description`,相符就載入並依其步驟執行。
3. 技能準則的唯一來源:`plugins/meta` 存取庫的 `references/guidelines.md`。
4. 所有 hook 只放在 `jsc-hooks`;gitea 操作一律經由 `jsc-gitea` 的 `tools/gitea.sh`;問使用者一律依 `jsc-ask:ask` 的決策樹規則。
5. 主 agent 不需要處理細節的流程,一律建立 sub agent 處理。
## 慣例
## 呼叫慣例
- 新增 skill 一律放在 `skills/<name>/`,且 `<name>` 使用小寫與連字號。
- `description` 要寫清楚觸發條件(何時用、何時不用),這是跨助理自動載入的唯一依據。
Claude Code / Antigravity:`/jsc-sdlc:{name}`;Codex:`$name`;Copilot / Kiro / OpenCode:描述需求自動觸發。
+44 -209
View File
@@ -1,228 +1,63 @@
# jsc-template — 跨 AI 助理 Plugin 模板
# jsc-sdlc — 開發生命週期
一個可同時被 **Claude Code、Codex、Antigravity、OpenCode、GitHub Copilot** 安裝的 plugin 模板。
核心是以 [Agent Skills(`SKILL.md`)](https://agentskills.io) 標準撰寫的共用 skills(唯一真實來源放在 `skills/`),
搭配各助理各自的 plugin manifest,讓**同一個 repo** 可用各家**原生 plugin CLI** 安裝。
在 Claude Code 與 Antigravity 中,skill 以 **`/jsc-template:` 前綴**呼叫(例如 `/jsc-template:hello`)。
jsc 技能組的 sdlc domain:規劃 → 分析 → 實作 → 維護四個階段,全程以 wiki 頁追蹤(`PLAN_*`、`ANALYZE_*`、`REPO_*`、`MAINTAIN_CONTENTS`)。每階段先做模型能力檢查,不適合就阻擋流程。
---
## 安裝、更新、移除
## 前綴與呼叫方式
Marketplace 統一為 `jsc`(https://gitea.jsc.idv.tw/plugins/jsc.git),安裝 token 為 `jsc-sdlc@jsc`。每個指令一行:
| 助理 | 安裝方式 | 呼叫 | `/jsc-template:` 前綴 |
| CLI | 安裝 | 更新 | 移除 |
| --- | --- | --- | --- |
| Claude Code | `claude plugin`(marketplace) | `/jsc-template:<name>` 或自動觸發 | ✅ |
| Codex | `codex plugin`(marketplace) | `$<name>` 或 `/skills` 選單 | ❌(用 `$name`) |
| Antigravity | `agy plugin install` | `/jsc-template:<name>` 或自動觸發 | ✅ |
| OpenCode | skills 目錄(複製/clone) | 描述需求自動觸發 | ❌(依名稱) |
| GitHub Copilot CLI | `copilot plugin`(marketplace) | 自然語言或 plugin skills | ❌(無 `/jsc-template:` 前綴) |
| claude | `claude plugin marketplace add https://gitea.jsc.idv.tw/plugins/jsc.git && claude plugin install jsc-sdlc@jsc` | `claude plugin marketplace update jsc && claude plugin update jsc-sdlc@jsc` | `claude plugin uninstall jsc-sdlc@jsc` |
| codex | `codex plugin marketplace add https://gitea.jsc.idv.tw/plugins/jsc.git && codex plugin add jsc-sdlc@jsc` | `codex plugin marketplace upgrade jsc` | `codex plugin remove jsc-sdlc@jsc` |
| copilot | `copilot plugin marketplace add https://gitea.jsc.idv.tw/plugins/jsc.git && copilot plugin install jsc-sdlc@jsc` | `copilot plugin marketplace update jsc && copilot plugin update jsc-sdlc@jsc` | `copilot plugin uninstall jsc-sdlc@jsc` |
| antigravity | `git clone https://gitea.jsc.idv.tw/plugins/sdlc.git ~/plugins/sdlc && agy plugin install ~/plugins/sdlc` | `git -C ~/plugins/sdlc pull && agy plugin uninstall jsc-sdlc && agy plugin install ~/plugins/sdlc` | `agy plugin uninstall jsc-sdlc` |
| kiro | `kiro-cli plugin marketplace add https://gitea.jsc.idv.tw/plugins/jsc.git && kiro-cli plugin install jsc-sdlc@jsc` | `kiro-cli plugin marketplace update jsc && kiro-cli plugin update jsc-sdlc@jsc` | `kiro-cli plugin uninstall jsc-sdlc@jsc` |
> Codex 不支援自訂前綴(skill 以 `$name` 呼叫);OpenCode 由模型依描述自動呼叫;Copilot CLI 透過原生 plugin 安裝後以自然語言或 plugin skills 使用。三者皆**不強制**前綴。
---
## 目錄結構
同一個 repo 同時帶四種 manifest,彼此以路徑隔離、互不干擾;各助理都讀同一份 `skills/`。
```
template/
├── .claude-plugin/
│ ├── plugin.json # Claude 外掛定義(name: "jsc-template")
│ └── marketplace.json # Claude marketplace(name: "template",source 指向本 repo)
├── .codex-plugin/
│ └── plugin.json # Codex 外掛定義(name: "jsc-template",skills: "./skills")
├── .agents/plugins/
│ └── marketplace.json # Codex marketplace(name: "template",url source 指向本 repo)
├── plugin.json # Antigravity 外掛定義(name: "jsc-template",skills: "./skills/")
├── skills/ # ★ 唯一真實來源:所有 skills
│ └── hello/SKILL.md
├── AGENTS.md # 跨助理共用指引
└── README.md
```
---
## 安裝 / 更新 / 移除(各助理)
> 指令中的 repo 網址換成你的:`https://gitea.jsc.idv.tw/plugins/template.git`
>
> **Claude / Codex 從 git URL 安裝(會 clone 遠端),請先把本 repo `push` 到 gitea。**
> **Antigravity 的 `agy plugin install <url>` 目前只支援 github.com**;gitea 請改用「clone + 本地路徑」(見 Antigravity 節)。
> 本機/離線:Claude 可用本地路徑加 marketplace;Antigravity 用本地路徑安裝。
> **⚠ 從 0.0.1 升上來的人請先移除再安裝。** 0.0.2 起 marketplace 名由 `jsc-plugins` 改為 `template`
> (舊名與 `jsc-persona` 的 marketplace 撞名)。各助理以 `<plugin 名>@<marketplace 名>` 當安裝識別鍵,
> 改名後是兩筆獨立條目,**不能用 update 遷移**:
>
> ```bash
> claude plugin uninstall jsc-template@jsc-plugins
> claude plugin marketplace remove jsc-plugins # 若你沒有裝 jsc-persona 才移除,它也用這個名字
> claude plugin marketplace add https://gitea.jsc.idv.tw/plugins/template.git
> claude plugin install jsc-template@template
> ```
>
> 移除後記得清掉 `~/.claude/settings.json` 裡 `enabledPlugins` 的舊鍵 `jsc-template@jsc-plugins`,
> 並重開工作階段。Codex/Copilot 同理(`remove`/`uninstall` 後重新 `add`+`install`)。
### Claude Code
```bash
# 安裝
claude plugin marketplace add https://gitea.jsc.idv.tw/plugins/template.git
claude plugin install jsc-template@template
# 更新
claude plugin marketplace update template
claude plugin update jsc-template@template
# 移除
claude plugin uninstall jsc-template@template
claude plugin marketplace remove template
```
- 工作階段內 slash 版(等價):把 `claude plugin` 換成 `/plugin`。
- 本機開發(免 push):`claude plugin marketplace add C:\Users\h3285\source\repos.plugins\template`(本地路徑)後再 install。
- **呼叫**:`/jsc-template:<name>`(例 `/jsc-template:hello`)。
### Codex
```bash
# 安裝
codex plugin marketplace add https://gitea.jsc.idv.tw/plugins/template.git
codex plugin add jsc-template@template
# 更新(重新抓取 marketplace 的 git 快照)
codex plugin marketplace upgrade template
# 移除
codex plugin remove jsc-template@template
codex plugin marketplace remove template
```
- 安裝 token `jsc-template@template` = plugin 名(`.codex-plugin/plugin.json` 的 `name`)@ marketplace 名(`.agents/plugins/marketplace.json` 的 `name`)。
- 本 repo 的 Codex marketplace 以 `url` 來源指向自己,故 Codex **一律從 gitea 安裝**(需先 push);安裝後重啟 Codex。
- **呼叫**:`$<name>`(例 `$hello`),或用 `/skills` 選單。
### Antigravity(`agy`)
> `agy plugin install <url>` 目前**只支援 github.com**;gitea 等自架 git 不支援 URL 安裝,請先 `git clone` 再用**本地路徑**安裝。
```bash
# 安裝:clone 後用本地路徑
git clone https://gitea.jsc.idv.tw/plugins/template.git ~/plugins/template
agy plugin install ~/plugins/template
# 更新(agy 無 update 子指令 → git pull 後重裝)
git -C ~/plugins/template pull
agy plugin uninstall jsc-template
agy plugin install ~/plugins/template
# 移除
agy plugin uninstall jsc-template
```
- 若把 skills 放到 GitHub,則可直接 `agy plugin install https://github.com/<owner>/<repo>`。
- 其他:`agy plugin list`、`agy plugin enable jsc-template` / `disable jsc-template`、`agy plugin validate <path>`。安裝後重啟工作階段。
- **呼叫**:`/jsc-template:<name>`(例 `/jsc-template:hello`)或依描述自動觸發。
### OpenCode
OpenCode 的「plugin」是 TypeScript/npm 套件,不適用於 skill 包;skills 改用**目錄安裝**。
OpenCode 會讀 `~/.config/opencode/skills/`(也會讀 `~/.claude/skills/`、`~/.agents/skills/`)。
```bash
# 安裝
git clone https://gitea.jsc.idv.tw/plugins/template.git ~/plugins/template
mkdir -p ~/.config/opencode/skills
cp -r ~/plugins/template/skills/* ~/.config/opencode/skills/
# 更新
git -C ~/plugins/template pull
cp -r ~/plugins/template/skills/* ~/.config/opencode/skills/
# 移除
rm -rf ~/.config/opencode/skills/hello
```
> **Windows PowerShell**:`cp -r A B` → `Copy-Item A B -Recurse -Force`、`rm -rf X` → `Remove-Item X -Recurse -Force`、`~` → `$HOME`。
- **呼叫**:直接描述需求,模型會依 skill 描述自動透過 skill 工具呼叫。
### GitHub Copilot CLI
Copilot CLI 支援與 Claude Code 類似的原生 plugin / marketplace 指令,可直接從 marketplace 安裝、更新與移除本 plugin。
```bash
# 安裝
copilot plugin marketplace add https://gitea.jsc.idv.tw/plugins/template.git
copilot plugin install jsc-template@template
# 更新
copilot plugin marketplace update template
copilot plugin update jsc-template@template
# 移除
copilot plugin uninstall jsc-template@template
copilot plugin marketplace remove template
```
- 安裝 token `jsc-template@template` = plugin 名(plugin manifest 的 `name`)@ marketplace 名。
- `copilot plugin marketplace add` 支援 GitHub `owner/repo`、git URL 與本地路徑;Gitea repo 可用上方 HTTPS URL。
- **呼叫**:在 Copilot CLI 中用自然語言描述需求,例如 `copilot -i "跑 hello 確認 plugin 裝好了"`。
---
## 用 CLI 直接執行 skill(headless / 一次性)
安裝好之後,不必進互動介面,一行指令就能叫某個 skill 跑完並印出結果:
| 助理 | headless 指令 | 執行 `hello` skill |
| --- | --- | --- |
| Claude Code | `claude -p "<prompt>"` | `claude -p "/jsc-template:hello"` |
| Codex | `codex exec "<prompt>"` | `codex exec '$hello'` |
| Antigravity | `agy -p "<prompt>"` | `agy -p "/jsc-template:hello"` |
| OpenCode | `opencode run "<message>"` | `opencode run "用 hello skill 打個招呼"` |
| GitHub Copilot CLI | `copilot -p "<message>"` | `copilot -p "用 hello skill 打個招呼"` |
- Claude / Antigravity 支援 `/jsc-template:` 前綴,直接 `-p "/jsc-template:<name>"` 即可。
- Codex 以 `$<name>` 觸發;在 shell 請用**單引號**避免 `$` 被展開:`codex exec '$hello'`。
- OpenCode 與 Copilot 沒有前綴,用自然語言描述需求;Copilot CLI 會讀取已安裝 plugin 提供的 skills。
- 帶引數就接在後面,例如 `claude -p "/jsc-template:hello 參數"`、`codex exec '$hello 參數'`。
---
> antigravity 不支援 gitea URL 安裝,改用本地 clone 路徑。批次操作五個 CLI:使用 `/jsc-cli:deploy`。
## Skills 目錄
> 此區塊列出本 plugin 內含的所有 skills(名稱/描述/使用方法)。
> 新增或修改 skill 後,請同步手動更新標記之間的內容。
呼叫方式:Claude / Antigravity `/jsc-sdlc:{name}`;Codex `${name}`;Copilot / Kiro 描述需求自動觸發。
<!-- JSC-SKILLS:START -->
### `hello`
### `plan`
範例 skill,用來驗證 jsc plugin 是否安裝成功,也是新增 skill 的範本。當使用者輸入 hello、想測試 plugin、或想看 skill 模板長什麼樣子時觸發;回覆一句問候並簡述此 plugin 的用途。
規劃:讀計畫目錄 → 補充或新建計畫 → 決策樹補全目標、範圍、可行性至共識 → 產生使用者故事 → 寫回 `PLAN_{yyyyMMdd}_{HHmmss}_{HASH}`。純邏輯,禁止程式碼與修改檔案。
- **Claude Code / Antigravity**:`/jsc-template:hello`
- **Codex**:`$hello`,或用 `/skills` 選單
- **OpenCode / GitHub Copilot CLI**:描述需求自動觸發
### `analyze`
分析:搭配現況(工作目錄與 `REPO_{HASH}` 盤點複用)分析使用者故事 → WBS 產生編號工作包 → CPM 估工時與天數 → TDD 拆待辦 → 寫回 `ANALYZE_{yyyyMMdd}_{HHmmss}_{HASH}`。純邏輯,禁止程式碼與修改檔案。
### `implement`
實作:產生工作證鎖定「未完成、無相依、無工作證」的工作包 → 逐項 TDD 實作、每完成一項立即更新 wiki → 程式碼審查 → 詢問是否加入維護目錄。
### `maintain`
維護:讀取維護期內的專案,每個專案一個 sub agent:切 develop/master → 至少五種建議維護方法 → commit / push / PR → 更新前次維護時間。
<!-- JSC-SKILLS:END -->
---
## 範本與參考
## 新增一個 skill
| 檔案 | 用途 |
| --- | --- |
| `templates/plan-page.md`、`templates/plan-contents.md` | 計畫頁與計畫目錄 |
| `templates/analyze-page.md`、`templates/analyze-contents.md` | 分析頁(WBS、CPM、TDD 待辦)與分析目錄 |
| `templates/repo-page.md`、`templates/repo-contents.md` | 存取庫盤點頁(功能與端點,附 commit sha)與盤點目錄 |
| `templates/maintain-contents.md` | 維護目錄(截止日 NULL = 永久維護) |
| `references/tdd.md` | 接縫、紅綠循環規則、反模式 |
1. 複製範本:`cp -r skills/hello skills/<your-skill-name>`
2. 編輯 `skills/<your-skill-name>/SKILL.md` 的 frontmatter:
- `name`:小寫、數字、連字號(`-`),最長 64 字元。**這就是 Claude Code / Antigravity 的 `/jsc-template:<name>`**。
- `description`:第三人稱,寫清楚「何時用、何時不用」與觸發關鍵字 — 這是各助理自動載入的唯一依據。
3. 在內文寫下 skill 的具體步驟。
4. 手動把這個 skill 補進上方「Skills 目錄」區塊。
5. **bump 版本並 push**:各助理都以 git 內容/版本判斷更新,請把 `.claude-plugin/plugin.json`、`.codex-plugin/plugin.json`、`plugin.json` 三個 manifest 的 `version` 一起 bump,commit 後 push 到 gitea。
6. 讓各助理更新:
- Claude:`claude plugin update jsc-template@template`
- Codex:`codex plugin marketplace upgrade template`
- Antigravity:`git -C ~/jsc-plugin pull && agy plugin uninstall jsc-template && agy plugin install ~/jsc-plugin`
- OpenCode:`git pull` 後重新複製 `skills/`
- Copilot:`copilot plugin marketplace update template && copilot plugin update jsc-template@template`
## 環境變數
Wiki 位置:`JSC_WIKI_REPO_PLAN` / `JSC_WIKI_REPO_ANALYZE` / `JSC_WIKI_REPO_REPO` / `JSC_WIKI_REPO_MAINTAIN`,未設定退回 `JSC_WIKI_REPO`,再未設定就詢問(見 `jsc-gitea`)。
## 相關 domain
- [`jsc-cli`](https://gitea.jsc.idv.tw/plugins/cli):模型能力標籤(`jsc-cli:models`)
- [`jsc-gitea`](https://gitea.jsc.idv.tw/plugins/gitea):wiki 讀寫
- [`jsc-review`](https://gitea.jsc.idv.tw/plugins/review):實作完成後的程式碼審查
- [`jsc-git`](https://gitea.jsc.idv.tw/plugins/git) / [`jsc-pkg`](https://gitea.jsc.idv.tw/plugins/pkg):維護階段的 commit / PR 與套件更新
- [`jsc-log`](https://gitea.jsc.idv.tw/plugins/log):完工後的工作日誌
+3 -3
View File
@@ -1,6 +1,6 @@
{
"name": "jsc-template",
"version": "0.0.3",
"description": "JSC 跨 AI 助理共用 plugin 模板。所有 skills 以 SKILL.md 為共通標準;於 Antigravity 以 /jsc-template: 前綴呼叫。",
"name": "jsc-sdlc",
"version": "0.0.1",
"description": "開發生命週期:規劃/分析/實作/維護(wiki 追蹤)",
"skills": "./skills/"
}
+17
View File
@@ -0,0 +1,17 @@
# TDD 參考(拆解待辦與逐項實作時引用)
## 接縫(Seam)
測試只寫在**接縫**:可觀察行為的公開介面,不綁內部實作。拆解待辦前先列出受測接縫,依 `jsc-ask:ask` 與使用者確認;未確認的接縫不寫測試,測試力道集中在關鍵路徑與複雜邏輯。
## 循環規則
1. **先紅後綠**:先寫會失敗的測試,再寫剛好通過的實作;不預寫未來的測試、不加投機功能。
2. **一次一片(vertical slice)**:一個接縫、一個測試、一個最小實作為一個循環;下一片依上一片學到的調整。
3. **重構不在循環內**:重構屬於審查階段(`jsc-review:code-review`),不混入紅綠循環。
## 反模式(發現即重寫該測試)
- **綁實作**:mock 內部協作者、測私有方法、繞過介面從旁通道驗證。徵兆:重構沒改行為,測試卻壞了。
- **套套邏輯**:斷言用與實作相同的方式重算期望值,永遠通過。期望值必須來自獨立的真實來源(已知正確的字面值、規格、實算範例)。
- **水平切片**:先寫完全部測試再寫全部實作。這是在測想像中的形狀;改用垂直切片逐一循環。
+34
View File
@@ -0,0 +1,34 @@
---
name: analyze
description: SDLC analysis stage. Gate on model capability tags, pick a plan from PLAN_CONTENTS, analyze user stories against the current state (working directory plus REPO_{HASH} inventory for reuse). Run WBS to produce numbered work packages, estimate them with CPM, split each into TDD todos, and write wiki page ANALYZE_{yyyyMMdd}_{HHmmss}_{HASH}. Logic only - never write code or modify files. Use after planning and before implementation.
---
# analyze
Goal: create or extend the wiki analysis page `ANALYZE_{yyyyMMdd}_{HHmmss}_{HASH}`.
This skill is a **logic-only** stage: never output code, and **never modify any file**.
`{HASH}` = first 8 chars of the SHA-1 of `{owner}/{repo}`, uppercase.
All wiki reads and writes go through `jsc-gitea:wiki`.
## Steps
1. **Model capability gate**: check the capability tags from `jsc-cli:models` and confirm the current model qualifies for analysis. If not, block the flow and tell the user which model to switch to.
2. Read `PLAN_CONTENTS` via `jsc-gitea:wiki` for plans whose status is the literal 「未分析」 (name and HASH), and read `ANALYZE_CONTENTS` for existing analyses.
3. Let the user choose per `jsc-ask:ask` rules: **extend an existing analysis** or **analyze a new plan**. State the impact scope on every option.
4. Analyze the plan page's user stories one by one against the **current state**, questioning via the `jsc-ask:ask` decision tree until no doubt remains; keep asking while consensus is missing. Current state means:
1. Every file in the working directory.
2. **Reuse existing methods and endpoints whenever possible**:
- Check the `REPO_{HASH}` inventory page first. Re-inventory when the feature or endpoint is missing, or when the recorded commit sha differs from the current one.
- Re-inventory **MUST run as a sub agent**: analyze the repository's features and endpoints, attach the current commit sha, write back to `REPO_{HASH}` with `templates/repo-page.md`, and update `REPO_CONTENTS` per `templates/repo-contents.md`.
- For each reuse candidate, confirm the file path and method name first, then analyze whether its logic fits the requirement.
5. Run a **Work Breakdown Structure (WBS)**: split the user stories into work packages, number them sequentially (`WP-01`, `WP-02`, ...) and mark dependencies.
6. Estimate every work package's effort in hours and days with the **Critical Path Method (CPM)**, and mark the critical path.
7. Split every work package into todos with **Test-Driven Development (TDD)**, formatted `[ ]` (open) / `[x]` (done). Each todo is one vertical slice: one seam, one test, one minimal implementation. Seams and anti-patterns: `references/tdd.md`.
8. Apply `templates/analyze-page.md` to create or update the analysis page and write it back via `jsc-gitea:wiki`. The page content is Traditional Chinese, exactly as the template dictates.
9. If the analysis page is new: add it to `ANALYZE_CONTENTS` per `templates/analyze-contents.md`, and flip the plan's status in `PLAN_CONTENTS` to the literal 「已分析」.
## Hard limits
- Never output a code snippet (file paths and method names are allowed).
- Never modify any file in the working directory.
-38
View File
@@ -1,38 +0,0 @@
---
name: hello
description: 範例 skill,用來驗證 jsc plugin 是否安裝成功,也是新增 skill 的範本。當使用者輸入 hello、想測試 plugin、或想看 skill 模板長什麼樣子時觸發;回覆一句問候並簡述此 plugin 的用途。
---
# hello(範例 skill)
這是 `jsc-template` plugin 的範例 skill。它有兩個用途:
1. **驗證安裝** — 跨各家 AI 助理確認 skill 已被正確載入。
2. **作為範本** — 複製這個資料夾即可新增一個新的 skill。
## 呼叫方式
| 助理 | 呼叫方式 |
| --- | --- |
| Claude Code | `/jsc-template:hello` |
| Antigravity | `/jsc-template:hello`,或描述需求自動觸發 |
| Codex | 在提示詞輸入 `$hello`,或用 `/skills` 選單 |
| OpenCode | 直接描述需求,模型會透過 skill 工具自動呼叫 |
| GitHub Copilot CLI | 直接描述需求,Copilot 會讀取已安裝 plugin 的 skills |
## 行為
當這個 skill 被觸發時:
1. 回覆「Hello from **jsc** 👋」。
2. 用一句話說明 `jsc-template` 是一個跨 AI 助理的共用 skill 集合。
3. 提示使用者可以在 README 的「Skills 目錄」查看所有可用的 skills。
## 如何以此為範本新增 skill
1. 複製 `skills/hello/` 為 `skills/<your-skill-name>/`。
2. 修改 `SKILL.md` 的 frontmatter:
- `name`:小寫、數字、連字號(`-`),最長 64 字元。**這個名稱會成為 Claude Code / Antigravity 的 `/jsc-template:<name>` 指令**。
- `description`:第三人稱,寫清楚「什麼時候該用、什麼時候不該用」與觸發關鍵字 — 各家助理靠這段文字決定是否自動載入。
3. 在內文寫下 skill 的具體步驟。
4. 手動把新 skill 補進 README 的「Skills 目錄」區塊。
+27
View File
@@ -0,0 +1,27 @@
---
name: implement
description: SDLC implementation stage. Gate on model capability tags, claim a ready work package from ANALYZE_CONTENTS with a work ticket, then complete its TDD todos one by one, updating the wiki after every item. Ends with jsc-review code-review and an optional MAINTAIN_CONTENTS entry. Use when analysis is done and code must be written; not for planning or analysis.
---
# implement
Goal: complete the analysis page's todos one by one; **update the wiki status immediately after every completed item**.
All wiki reads and writes go through `jsc-gitea:wiki`.
## Steps
1. **Model capability gate**: check the capability tags from `jsc-cli:models` and confirm the current model qualifies for implementation. If not, block the flow and tell the user which model to switch to.
2. **Generate a work ticket**: format `TICKET_{first 8 chars of session id}_{yyyyMMddHHmmss}`. Try to rename the current session to the ticket name (skip when the CLI does not support it).
3. Read `ANALYZE_CONTENTS` via `jsc-gitea:wiki` and list what is unfinished: plan name, HASH, work package number, count of open items. A selectable work package must satisfy all three: **unfinished, dependency-free (or all dependencies done), and not holding a work ticket**.
4. Let the user pick a work package per `jsc-ask:ask` rules (options state open-item count and estimated effort). Write the ticket into that work package's ticket column (the zh-TW field 「工作證」) on the analysis page and save it back to the wiki. **Only after the ticket is saved successfully may you proceed.**
5. List every open item of the work package and implement them **one at a time**:
- Follow the TDD loop: red before green, one slice at a time; rules and anti-patterns in `references/tdd.md` (refactoring belongs to the review stage).
- After each item, flip its `[ ]` to `[x]` on the analysis page and save to the wiki before starting the next item.
6. When all items are done, call `jsc-review:code-review` and wait for the review; on failure, fix and re-review until it passes.
7. Ask per `jsc-ask:ask` rules whether to register this project for maintenance: append to `MAINTAIN_CONTENTS` with `templates/maintain-contents.md`. Required: repository `{owner}/{repo}`, maintenance method, start date. Optional: end date (NULL = maintain forever), last-maintained time.
## Rules
- The work ticket is a mutex: always skip work packages that already hold a ticket; never take one over.
- Never batch wiki updates across items; one item, one update.
- Everything the skill writes out (wiki content, commit messages, PR descriptions) stays Traditional Chinese per the STE100 rule.
+26
View File
@@ -0,0 +1,26 @@
---
name: maintain
description: SDLC maintenance stage. Gate on model capability tags, read projects still inside their maintenance window from MAINTAIN_CONTENTS, then run one sub agent per project: switch to develop or master, propose at least five maintenance actions, commit to a new branch, push, and PR. Update the last-maintained timestamp afterward. Use for periodic upkeep of delivered projects.
---
# maintain
Goal: run routine maintenance for every project in the maintenance contents page.
All wiki reads and writes go through `jsc-gitea:wiki`.
## Steps
1. **Model capability gate**: check the 「SDLC 階段需求」 table from `jsc-cli:models` and confirm the current model qualifies for maintenance (any tag qualifies, but the model must be listed in the mapping table). If not, block the flow and tell the user which model to switch to.
2. Read `MAINTAIN_CONTENTS` via `jsc-gitea:wiki` and filter projects **still inside their maintenance window**: start date ≤ today, and (end date is NULL or ≥ today).
3. Every project **MUST run as a sub agent** with this flow:
1. Switch the project to the `develop` branch, falling back to `master`, and pull to latest.
2. Propose **at least five** maintenance methods and apply the ones that fit the project, for example:
- dependency updates (reuse `jsc-pkg:pkg-update`)
- security vulnerability scan and patching
- dead code and stale comment cleanup
- test coverage reinforcement
- docs and README synchronization
- build warning elimination
3. Commit the changes to a new branch per `jsc-git:commit`, push, then open a PR back to develop or master per `jsc-git:pr`.
4. Update the project's last-maintained field (the zh-TW column 「前次維護時間」) in `MAINTAIN_CONTENTS` to today.
4. The main agent reports the summary: maintenance methods applied per project, PR links, and failure reasons. The report and all generated wiki content, commits, and PR descriptions stay Traditional Chinese per the STE100 rule.
+31
View File
@@ -0,0 +1,31 @@
---
name: plan
description: SDLC planning stage. Gate on model capability tags, pick or create a plan from PLAN_CONTENTS, then run a decision tree until goal, scope, and feasibility reach consensus. Produce user stories into wiki page PLAN_{yyyyMMdd}_{HHmmss}_{HASH}. Logic only - never write code or modify files. Use when the user wants to start or refine a plan; not for analysis or implementation.
---
# plan
Goal: create or extend the wiki plan page `PLAN_{yyyyMMdd}_{HHmmss}_{HASH}`.
This skill is a **logic-only** stage: never output code, and **never modify any file**.
`{HASH}` = first 8 chars of the SHA-1 of `{owner}/{repo}`, uppercase.
All wiki reads and writes go through `jsc-gitea:wiki`.
## Steps
1. **Model capability gate**: check the capability tags from `jsc-cli:models` and confirm the current model qualifies for planning. If not, block the flow and tell the user which model to switch to.
2. Read `PLAN_CONTENTS` via `jsc-gitea:wiki` and list the plans whose status is the literal 「未分析」 (not analyzed), with names and HASH.
3. Let the user choose per `jsc-ask:ask` rules: **extend an existing plan** (list the not-analyzed plans as options) or **create a new plan**. State the impact scope on every option.
4. Question via the `jsc-ask:ask` decision tree until no doubt remains on all three items; keep asking while consensus is missing:
- Goal: the problem to solve and the criteria for success.
- Scope: what is included, what is excluded, which repositories are involved.
- Feasibility: whether the system architecture and data sources support the goal.
5. Turn the consensus into **user stories** (the zh-TW pattern 「身為⋯⋯我想要⋯⋯以便⋯⋯」), one per line.
6. Apply `templates/plan-page.md` to create or update the plan page, and write it back via `jsc-gitea:wiki`. The page content is Traditional Chinese, exactly as the template dictates.
7. If the plan page is new, add it to `PLAN_CONTENTS` using the entry format of `templates/plan-contents.md`, with status set to the literal 「未分析」.
## Hard limits
- Never output a code snippet.
- Never modify any file in the working directory.
- Never skip the decision tree and assume requirements.
+5
View File
@@ -0,0 +1,5 @@
# 分析目錄
| 計畫名稱 | 分析頁 | HASH | 工作包 | 未完成項目 | 狀態 |
| --- | --- | --- | --- | --- | --- |
| {計畫名稱} | [[ANALYZE_{yyyyMMdd}_{HHmmss}_{HASH}]] | {HASH} | WP-01、WP-02 | {n} | 未完成 |
+33
View File
@@ -0,0 +1,33 @@
# 分析:{計畫名稱}
- 頁名:`ANALYZE_{yyyyMMdd}_{HHmmss}_{HASH}`
- 對應計畫:[[PLAN_{yyyyMMdd}_{HHmmss}_{HASH}]]
- 存取庫:`{owner}/{repo}`
- 狀態:未完成 <!-- 未完成 | 已完成 -->
## 現況摘要
- 工作目錄:{關鍵檔案與結構摘要}
- 複用來源:[[REPO_{HASH}]](commit sha:`{sha}`)
- 複用決策:{複用哪些方法/端點、為什麼;不複用的原因}
## 工作分解結構(WBS)
| 編號 | 工作包名稱 | 相依 | 工時(h) | 天數 | 工作證 | 狀態 |
| --- | --- | --- | --- | --- | --- | --- |
| WP-01 | {名稱} | - | {h} | {d} | | 未完成 |
| WP-02 | {名稱} | WP-01 | {h} | {d} | | 未完成 |
- 關鍵路徑:{WP-01 → WP-02 → ⋯⋯},總天數 {d}
## 待辦事項(TDD)
### WP-01 {工作包名稱}
- [ ] 撰寫 {對象} 的測試:{預期行為}
- [ ] 實作 {對象} 使測試通過
- [ ] 重構 {對象} 並保持測試綠燈
### WP-02 {工作包名稱}
- [ ] ⋯⋯
+7
View File
@@ -0,0 +1,7 @@
# 維護目錄
<!-- 維護截止日 NULL = 永久維護 -->
| 存取庫 | 維護方式 | 維護起始日 | 維護截止日 | 前次維護時間 |
| --- | --- | --- | --- | --- |
| {owner}/{repo} | {例:套件更新與安全掃描} | {yyyy-MM-dd} | NULL | {yyyy-MM-dd} |
+5
View File
@@ -0,0 +1,5 @@
# 計畫目錄
| 計畫名稱 | 計畫頁 | 存取庫 | HASH | 狀態 | 建立時間 |
| --- | --- | --- | --- | --- | --- |
| {計畫名稱} | [[PLAN_{yyyyMMdd}_{HHmmss}_{HASH}]] | {owner}/{repo} | {HASH} | 未分析 | {yyyy-MM-dd} |
+31
View File
@@ -0,0 +1,31 @@
# 計畫:{計畫名稱}
- 頁名:`PLAN_{yyyyMMdd}_{HHmmss}_{HASH}`
- 存取庫:`{owner}/{repo}`
- 狀態:未分析 <!-- 未分析 | 已分析 -->
- 建立時間:{yyyy-MM-dd HH:mm:ss}
## 目標
{要解決的問題與成功判斷標準}
## 範圍
- 包含:{項目}
- 排除:{項目}
- 涉及存取庫:{owner}/{repo} 清單
## 可行性
- 系統架構:{現有架構如何支撐目標}
- 資料來源:{資料從哪裡來、是否可取得}
- 風險:{已知風險與對策}
## 使用者故事
1. 身為 {角色},我想要 {功能},以便 {價值}。
2. ⋯⋯
## 問詢共識
{決策樹問答達成的關鍵共識摘要,逐條列出}
+5
View File
@@ -0,0 +1,5 @@
# 盤點目錄
| 存取庫 | 盤點頁 | HASH | commit sha | 盤點時間 |
| --- | --- | --- | --- | --- |
| {owner}/{repo} | [[REPO_{HASH}]] | {HASH} | `{sha}` | {yyyy-MM-dd} |
+11
View File
@@ -0,0 +1,11 @@
# 盤點:{owner}/{repo}
- 頁名:`REPO_{HASH}`
- commit sha:`{sha}`
- 盤點時間:{yyyy-MM-dd HH:mm:ss}
## 功能與端點
| 檔案路徑 | 方法/端點名稱 | 類型 | 邏輯摘要 |
| --- | --- | --- | --- |
| {path} | {method 或 HTTP 動詞加路由} | 方法 \| 端點 | {做什麼、輸入輸出概要} |