Merge pull request '發佈 jsc-sdlc 0.0.5：階段閘門程式化、分支確認與交接優先' (#7) from develop into master
Reviewed-on: #7 Reviewed-by: 系統管理員 <1+admin@noreply.localhost>
This commit was merged in pull request #7.
This commit is contained in:
@@ -1,75 +1,89 @@
|
||||
{
|
||||
"name": "jsc",
|
||||
"description": "jsc 跨 AI 助理技能組的統一 marketplace（claude / codex / copilot / antigravity / kiro）。",
|
||||
"owner": {
|
||||
"name": "JSC"
|
||||
},
|
||||
"plugins": [
|
||||
{
|
||||
"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 追蹤）"
|
||||
}
|
||||
]
|
||||
}
|
||||
|
||||
@@ -59,7 +59,7 @@
|
||||
"source": "url",
|
||||
"url": "https://gitea.jsc.idv.tw/plugins/meta.git"
|
||||
},
|
||||
"description": "技能組自我管理：新建/更新/刪除技能與技能準則"
|
||||
"description": "技能組自我管理：新建、更新、刪除技能與技能準則"
|
||||
},
|
||||
{
|
||||
"name": "jsc-pkg",
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
{
|
||||
"name": "jsc-sdlc",
|
||||
"version": "0.0.2",
|
||||
"version": "0.0.5",
|
||||
"description": "開發生命週期：規劃/分析/實作/維護（wiki 追蹤）",
|
||||
"skills": "./skills",
|
||||
"author": {
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
{
|
||||
"name": "jsc-sdlc",
|
||||
"version": "0.0.2",
|
||||
"version": "0.0.5",
|
||||
"description": "開發生命週期：規劃/分析/實作/維護（wiki 追蹤）",
|
||||
"skills": "./skills"
|
||||
}
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# jsc-sdlc — 開發生命週期
|
||||
|
||||
jsc 技能組的 sdlc domain：規劃 → 分析 → 實作 → 維護四個階段，全程以 wiki 頁追蹤（`PLAN_CONTENTS`、`PLAN_{HASH}`、`ANALYZE_CONTENTS`、`ANALYZE_{HASH}`、`REPO_CONTENTS`、`REPO_{HASH}`、`MAINTAIN_CONTENTS`）。另有異常頁（`ERROR_CONTENTS`、`ERROR_{HASH}`）記錄 hook 或流程失敗。每次切換階段才重新檢查該階段需要的模型能力標籤；同一階段內不重複變更。
|
||||
jsc 技能組的 sdlc domain：規劃 → 分析 → 實作 → 維護四個階段，全程以 wiki 頁追蹤（`PLAN_CONTENTS`、`PLAN_{HASH}`、`ANALYZE_CONTENTS`、`ANALYZE_{HASH}`、`REPO_CONTENTS`、`REPO_{HASH}`、`MAINTAIN_CONTENTS`）。另有異常頁（`ERROR_CONTENTS`、`ERROR_{HASH}`）記錄 hook 或流程失敗。每次切換階段先過模型閘門：由 `jsc-hooks/hooks/sdlc-gate.sh lock {stage}` 從 transcript 讀出**實際**模型 id，比對該階段的必要能力標籤（plan、analyze 需 `reasoning-max`；implement 需 `coding`；maintain 任意），不符就拒絕上鎖、該階段不得執行。判定全在程式層，模型不得自評標籤。通過後鎖定到下一階段的閘門重新上鎖；同一階段內把模型換成不合格的，下一輪提示會被 hook 以 exit 2 擋下。分析前先與使用者確認來源分支，寫檔前先確認目標分支。
|
||||
|
||||
## 安裝、更新、移除
|
||||
|
||||
@@ -36,7 +36,7 @@ Marketplace 統一為 `jsc`（https://gitea.jsc.idv.tw/plugins/jsc.git），安
|
||||
|
||||
### `maintain`
|
||||
|
||||
維護：讀取維護期內的專案，每個專案一個 sub agent：切 develop/master → 至少五種建議維護方法 → commit / push / PR → 更新前次維護時間。
|
||||
維護：讀取維護期內的專案，每個專案一個 sub agent：切 develop/master → 至少五種建議維護方法 → commit / push / PR → 更新前次維護時間。僅適用於維護期內已交付的專案；尚在實作中或未登記於 `MAINTAIN_CONTENTS` 的專案不適用。
|
||||
|
||||
<!-- JSC-SKILLS:END -->
|
||||
|
||||
@@ -55,11 +55,12 @@ Marketplace 統一為 `jsc`（https://gitea.jsc.idv.tw/plugins/jsc.git），安
|
||||
|
||||
Wiki 位置：`PLAN_{HASH}` / `PLAN_CONTENTS` 只讀 `JSC_WIKI_REPO_PLAN`，再退回 `JSC_WIKI_REPO`；`ANALYZE_{HASH}` / `ANALYZE_CONTENTS` 只讀 `JSC_WIKI_REPO_ANALYZE`，再退回 `JSC_WIKI_REPO`；`REPO_{HASH}` / `REPO_CONTENTS` 只讀 `JSC_WIKI_REPO_REPO`，再退回 `JSC_WIKI_REPO`；`MAINTAIN_CONTENTS` 只讀 `JSC_WIKI_REPO_MAINTAIN`，再退回 `JSC_WIKI_REPO`。不同類型不可互相代用；兩者都未設定才詢問（見 `jsc-gitea`）。
|
||||
|
||||
HASH 規則：一律先算 `{owner}/{repo}` 的 SHA-1 前 8 碼並轉大寫；若第一碼是數字，或 `A`、`B`、`C`，就改成 `H` 加上原 SHA-1 前 7 碼，總長維持 8 碼。
|
||||
HASH 規則：`{owner}/{repo}` 的共用 wiki hash 一律由 `jsc-gitea/tools/hash-id` 計算（見 `jsc-gitea:wiki`），此 domain 不重複實作演算法。
|
||||
|
||||
## 相關 domain
|
||||
|
||||
- [`jsc-cli`](https://gitea.jsc.idv.tw/plugins/cli)：模型能力標籤（`jsc-cli:models`）
|
||||
- [`jsc-cli`](https://gitea.jsc.idv.tw/plugins/cli)：模型能力標籤與階段閘門判定（`tools/model-tags.sh`、`references/model-tags.md`、`jsc-cli:models`）、偏好模型鏈（`tools/model-config.sh`）
|
||||
- [`jsc-hooks`](https://gitea.jsc.idv.tw/plugins/hooks)：sdlc-gate 階段模型鎖定
|
||||
- [`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 與套件更新
|
||||
|
||||
+1
-1
@@ -1,6 +1,6 @@
|
||||
{
|
||||
"name": "jsc-sdlc",
|
||||
"version": "0.0.2",
|
||||
"version": "0.0.5",
|
||||
"description": "開發生命週期：規劃/分析/實作/維護（wiki 追蹤）",
|
||||
"skills": "./skills/"
|
||||
}
|
||||
|
||||
+41
-12
@@ -1,6 +1,6 @@
|
||||
---
|
||||
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_{HASH}. Logic only - never write code or modify files. Use after planning and before implementation.
|
||||
description: SDLC analysis stage. Gate on capability tags enforced in code by sdlc-gate (analyze requires reasoning-max, verified against the transcript's actual model id), confirm the source branch with the user, pick a plan from PLAN_CONTENTS, analyze user stories against the current state (working directory plus REPO_{HASH} inventory for reuse). Run WBS with handover work packages ranked first (spec before implementation), estimate them with CPM, split each into TDD todos, and write wiki page ANALYZE_{HASH} with real sample data. Logic only - never write code or modify files. Use after planning and before implementation.
|
||||
---
|
||||
|
||||
# analyze
|
||||
@@ -8,27 +8,56 @@ description: SDLC analysis stage. Gate on model capability tags, pick a plan fro
|
||||
Goal: create or extend the wiki analysis page `ANALYZE_{HASH}`.
|
||||
This skill is a **logic-only** stage: never output code, and **never modify any file**.
|
||||
|
||||
`{HASH}` = the shared wiki hash for `{owner}/{repo}`: take the first 8 uppercase hex chars of its SHA-1. If the first char is a digit, or `A`/`B`/`C`, replace it with `H` and keep the next 7 chars.
|
||||
`{HASH}` = the shared wiki hash for `{owner}/{repo}` used to build the `ANALYZE_{HASH}` page name, computed by `jsc-gitea/tools/hash-id` (see `jsc-gitea:wiki`).
|
||||
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.
|
||||
1. **Model gate and stage lock** (capability tags, enforced in code — never self-assessed):
|
||||
1. Run `jsc-cli/tools/model-tags.sh sync` to refresh `$JSC_HOME/model-tags.tsv` from `jsc-cli/references/model-tags.md`.
|
||||
2. Run `jsc-hooks/hooks/sdlc-gate.sh lock analyze`. The script reads the **actual** model id from the transcript, compares it against this stage's required tags (`reasoning-max`), and locks the stage only when they match.
|
||||
3. **Never claim a capability tag you have not verified with that script**, and never substitute your own judgement for its verdict. Non-zero exit = blocked: relay the script's message verbatim, stop the skill, do nothing else this turn. Do not run `unlock` to get past the gate; only the user may decide that.
|
||||
4. Exit 0 means the stage is locked. From now until the next stage's gate runs, the sdlc-gate hook blocks every prompt whose model stops satisfying the tags.
|
||||
2. **Confirm the source branch** — the branch whose code counts as the current state:
|
||||
1. Report the working directory's current branch, plus the remote branches available (`git branch -r`) and whether the working tree is clean.
|
||||
2. Ask per `jsc-ask:ask` rules which branch the analysis reads from; state the impact scope on every option (analysing the wrong branch produces work packages for code that does not exist).
|
||||
3. When the chosen branch is not the current one, **stop and ask the user to switch**. This stage never switches branches, never stashes, and never touches the working tree — see `/jsc-shared:spec-git-safety`.
|
||||
4. Record the confirmed branch and its head sha on the analysis page. Completion condition: the user has confirmed the branch explicitly; never infer it from the current checkout alone.
|
||||
3. Read `PLAN_CONTENTS` via `jsc-gitea:wiki` for plans whose status is the literal 「未分析」 (name and HASH), and read `ANALYZE_CONTENTS` for existing analyses.
|
||||
4. 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.
|
||||
5. 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, on the branch confirmed in step 2.
|
||||
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 「已分析」.
|
||||
6. Run a **Work Breakdown Structure (WBS)**: split the user stories into work packages, number them sequentially (`WP-01`, `WP-02`, ...) and mark dependencies.
|
||||
7. **Rank handover work packages first** — see 「交接優先」 below. Spec-shaped packages ship before implementation-shaped ones.
|
||||
8. Estimate every work package's effort in hours and days with the **Critical Path Method (CPM)**, and mark the critical path.
|
||||
9. 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`.
|
||||
10. 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.
|
||||
11. 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 「已分析」.
|
||||
|
||||
## 交接優先（handover first）
|
||||
|
||||
A work package is a **handover package** when someone else — another person, another CLI, another team — has to act on its output. Interfaces, schemas, spec documents, acceptance criteria and sample payloads are handover output; endpoint bodies and UI wiring are not.
|
||||
|
||||
- Mark every work package as 交接 `是` / `否` in the WBS table.
|
||||
- **Order handover packages before implementation packages**, so the receiving side gets the spec while implementation is still open. Implementation packages are the backup queue (實作候補): they are still numbered, estimated and kept on the page, just ranked later.
|
||||
- Dependencies still win: never place a package before one it depends on. Within the same dependency level, handover packages come first.
|
||||
- Do not merge a spec and its implementation into one package — that removes the ability to hand the spec over early. Split them.
|
||||
|
||||
## 範例資料（sample data）
|
||||
|
||||
Every sample value on the analysis page — request and response payloads, field values, config snippets, test fixtures — follows this order:
|
||||
|
||||
1. **Real data first.** Take values from an actual source: the database schema and rows, a real API response, an existing config or fixture file, logs. Record where each sample came from in the WBS table's 資料來源 column (for example `真實：dbo.Member`).
|
||||
2. **Only when no source exists**, derive the value by reasoning from the surrounding logic — and label it as inferred (for example `推論：無來源`), so the receiving side knows it is unverified.
|
||||
3. Never invent a plausible-looking value and present it as real, and never leave the origin of a sample unstated.
|
||||
4. Real data goes on the page as **structure and format only**: field names, types, shapes. Never copy personal data onto the wiki — mask any personal identifier, and prefer describing the format over pasting the value.
|
||||
|
||||
## Hard limits
|
||||
|
||||
- Never output a code snippet (file paths and method names are allowed).
|
||||
- Never modify any file in the working directory.
|
||||
- Never switch, create or clean branches in this stage; ask the user to do it.
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
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.
|
||||
description: SDLC implementation stage. Gate on capability tags enforced in code by sdlc-gate (implement requires coding, verified against the transcript's actual model id), confirm the target branch with the user before writing any file, then claim a ready work package from ANALYZE_CONTENTS with a work ticket and 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
|
||||
@@ -10,11 +10,20 @@ 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. **Resolve environment first**: inspect `JSC_WIKI_REPO_ANALYZE`, `JSC_WIKI_REPO`, `JSC_WIKI_REPO_QUESTION`, `GITEA_HOST`, and `GITEA_TOKEN` before asking the user anything. Use inherited shell values first. If the env vars are present but the tool cannot read them, check the current shell environment before asking.
|
||||
3. **Generate a work ticket**: format `TICKET_{yyyyMMdd}_{HHmmss}_{HASH}`. Use the shared wiki hash for `{owner}/{repo}` for `{HASH}`: take the first 8 uppercase hex chars of its SHA-1, then replace a leading digit or `A`/`B`/`C` with `H` plus the next 7 chars. Try to rename the current session to the ticket name (skip when the CLI does not support it).
|
||||
1. **Model gate and stage lock** (capability tags, enforced in code — never self-assessed):
|
||||
1. Run `jsc-cli/tools/model-tags.sh sync` to refresh `$JSC_HOME/model-tags.tsv` from `jsc-cli/references/model-tags.md`.
|
||||
2. Run `jsc-hooks/hooks/sdlc-gate.sh lock implement`. The script reads the **actual** model id from the transcript, compares it against this stage's required tags (`coding`), and locks the stage only when they match.
|
||||
3. **Never claim a capability tag you have not verified with that script**, and never substitute your own judgement for its verdict. Non-zero exit = blocked: relay the script's message verbatim, stop the skill, do nothing else this turn. Do not run `unlock` to get past the gate; only the user may decide that.
|
||||
4. Exit 0 means the stage is locked. From now until the next stage's gate runs, the sdlc-gate hook blocks every prompt whose model stops satisfying the tags.
|
||||
2. **Confirm the target branch** — do this **before writing any file**:
|
||||
1. Report the current branch, whether the working tree is clean, and which of `origin/develop` / `origin/master` exist, plus the remote default branch resolved per `/jsc-shared:spec-git-safety`.
|
||||
2. Ask per `jsc-ask:ask` rules which branch this work merges into; state the impact scope on every option (the answer decides the PR target and, when it collides with the current branch, forces a new working branch).
|
||||
3. Uncommitted changes in the working tree → warn first and let the user commit or back them up; never discard them.
|
||||
4. Apply `/jsc-shared:spec-git-safety` to the confirmed target: source branch and target branch sharing a name means creating a new working branch instead of committing on the target; report the resulting branch name.
|
||||
5. Record the confirmed target branch on the analysis page next to the work ticket, and reuse it as the PR target in `jsc-git:pr`. Completion condition: the user has confirmed the target branch explicitly; never fall back to `develop` silently.
|
||||
3. **Generate a work ticket**: format `TICKET_{yyyyMMdd}_{HHmmss}_{HASH}`. `{HASH}` = the shared wiki hash for `{owner}/{repo}`, computed by `jsc-gitea/tools/hash-id` (see `jsc-gitea:wiki`). Try to rename the current session to the ticket name (skip when the CLI does not support it).
|
||||
4. 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**.
|
||||
5. 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. Let the user pick a work package per `jsc-ask:ask` rules (options state open-item count and estimated effort). **List handover packages (交接 `是`) first** — the analysis page ranks spec delivery ahead of implementation, so keep that order in the options. 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.**
|
||||
6. 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.
|
||||
@@ -25,4 +34,5 @@ All wiki reads and writes go through `jsc-gitea:wiki`.
|
||||
|
||||
- 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.
|
||||
- Sample data written into code or fixtures follows the analysis page's 資料來源 column: real data where a source exists, reasoned values labelled as inferred where none does. Never invent a value and present it as real, and never copy personal data into fixtures — keep the format, drop the identity.
|
||||
- Everything the skill writes out (wiki content, commit messages, PR descriptions) stays Traditional Chinese per the STE100 rule.
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
name: maintain
|
||||
description: SDLC maintenance stage. Gate on model capability tags for the maintenance stage, 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.
|
||||
description: SDLC maintenance stage. Gate on capability tags enforced in code by sdlc-gate (maintenance requires no specific tag, but the actual model id must be determinable from the transcript), 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 inside their maintenance window; not for projects still mid-implementation or not yet registered in MAINTAIN_CONTENTS.
|
||||
---
|
||||
|
||||
# maintain
|
||||
@@ -10,7 +10,11 @@ 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. Re-check only when the stage changes.
|
||||
1. **Model gate and stage lock** (capability tags, enforced in code — never self-assessed):
|
||||
1. Run `jsc-cli/tools/model-tags.sh sync` to refresh `$JSC_HOME/model-tags.tsv` from `jsc-cli/references/model-tags.md`.
|
||||
2. Run `jsc-hooks/hooks/sdlc-gate.sh lock maintain`. The script reads the **actual** model id from the transcript and checks it against this stage's required tags — maintenance requires no specific tag, so the gate passes as long as the actual model can be determined at all.
|
||||
3. **Never claim a capability tag you have not verified with that script**, and never substitute your own judgement for its verdict. Non-zero exit = blocked: relay the script's message verbatim, stop the skill, do nothing else this turn. Do not run `unlock` to get past the gate; only the user may decide that.
|
||||
4. Exit 0 means the stage is locked. Run this gate only when the stage changes; inside the maintenance stage the lock already covers every project, so never re-gate between projects.
|
||||
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.
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
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_{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.
|
||||
description: SDLC planning stage. Gate on capability tags enforced in code by sdlc-gate (plan requires reasoning-max, verified against the transcript's actual model id), 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_{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
|
||||
@@ -8,12 +8,16 @@ description: SDLC planning stage. Gate on model capability tags, pick or create
|
||||
Goal: create or extend the wiki plan page `PLAN_{HASH}`.
|
||||
This skill is a **logic-only** stage: never output code, and **never modify any file**.
|
||||
|
||||
`{HASH}` = the shared wiki hash for `{owner}/{repo}`: take the first 8 uppercase hex chars of its SHA-1. If the first char is a digit, or `A`/`B`/`C`, replace it with `H` and keep the next 7 chars.
|
||||
`{HASH}` = the shared wiki hash for `{owner}/{repo}` used to build the `PLAN_{HASH}` page name, computed by `jsc-gitea/tools/hash-id` (see `jsc-gitea:wiki`).
|
||||
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.
|
||||
1. **Model gate and stage lock** (capability tags, enforced in code — never self-assessed):
|
||||
1. Run `jsc-cli/tools/model-tags.sh sync` to refresh `$JSC_HOME/model-tags.tsv` from `jsc-cli/references/model-tags.md`.
|
||||
2. Run `jsc-hooks/hooks/sdlc-gate.sh lock plan`. The script reads the **actual** model id from the transcript, compares it against this stage's required tags (`reasoning-max`), and locks the stage only when they match.
|
||||
3. **Never claim a capability tag you have not verified with that script**, and never substitute your own judgement for its verdict. Non-zero exit = blocked: relay the script's message verbatim, stop the skill, do nothing else this turn. Do not run `unlock` to get past the gate; only the user may decide that.
|
||||
4. Exit 0 means the stage is locked. From now until the next stage's gate runs, the sdlc-gate hook blocks every prompt whose model stops satisfying the tags.
|
||||
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:
|
||||
|
||||
@@ -4,6 +4,7 @@
|
||||
- HASH：`{HASH}`
|
||||
- 對應計畫：[[PLAN_{HASH}]]
|
||||
- 存取庫：`{owner}/{repo}`
|
||||
- 來源分支：`{使用者確認的分支}`（head sha：`{sha}`）
|
||||
- 狀態：未完成 <!-- 未完成 | 已完成 -->
|
||||
- 建立時間：{yyyy-MM-dd HH:mm:ss}
|
||||
|
||||
@@ -15,12 +16,17 @@
|
||||
|
||||
## 工作分解結構（WBS）
|
||||
|
||||
| 編號 | 工作包名稱 | 相依 | 工時(h) | 天數 | 工作證 | 狀態 |
|
||||
| --- | --- | --- | --- | --- | --- | --- |
|
||||
| WP-01 | {名稱} | - | {h} | {d} | | 未完成 |
|
||||
| WP-02 | {名稱} | WP-01 | {h} | {d} | | 未完成 |
|
||||
交接工作包（規格、介面、驗收條件）排在實作工作包之前；實作為候補。相依關係優先於交接排序。
|
||||
資料來源欄記錄範例資料的出處：`真實：{來源}` 或 `推論：無來源`。
|
||||
|
||||
- 關鍵路徑：{WP-01 → WP-02 → ⋯⋯}，總天數 {d}
|
||||
| 編號 | 工作包名稱 | 交接 | 相依 | 工時(h) | 天數 | 資料來源 | 工作證 | 狀態 |
|
||||
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
|
||||
| WP-01 | {規格類名稱} | 是 | - | {h} | {d} | 真實：{來源} | | 未完成 |
|
||||
| WP-02 | {交接文件名稱} | 是 | WP-01 | {h} | {d} | 真實：{來源} | | 未完成 |
|
||||
| WP-03 | {實作類名稱} | 否 | WP-01 | {h} | {d} | 推論：無來源 | | 未完成 |
|
||||
|
||||
- 關鍵路徑：{WP-01 → WP-03 → ⋯⋯}，總天數 {d}
|
||||
- 交接批次：{WP-01、WP-02}；實作候補：{WP-03、⋯⋯}
|
||||
|
||||
## 待辦事項（TDD）
|
||||
|
||||
|
||||
Reference in New Issue
Block a user