29 lines
3.1 KiB
Markdown
29 lines
3.1 KiB
Markdown
---
|
|
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. **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.
|
|
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
|
|
|
|
- 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.
|