plugins/sdlc
2
0
Fork 0
Code Issues Pull Requests 1 Actions Packages Projects Releases Wiki Activity

fix(wiki): 統一 SDLC wiki 頁命名與 ERROR 範本

Browse Source
This commit is contained in:
jiantw83
2026-08-21 16:53:17 +00:00
parent a245ae8eea
commit 1153f7f064
16 changed files with 77 additions and 27 deletions
Download Patch File Download Diff File Expand all files Collapse all files
skills/implement/SKILL.md
+7 -6
View File
@@ -11,14 +11,15 @@ 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**:
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).
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.**
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.
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.
7. When all items are done, call `jsc-review:code-review` and wait for the review; on failure, fix and re-review until it passes.
8. 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