plugins/sdlc
2
0
Fork 0
Code Issues Pull Requests 1 Actions Packages Projects Releases Wiki Activity
Files
04bcdab4cb739cad2a02bf8d112899d32e620365
sdlc/skills/implement/SKILL.md
T

14 KiB
Raw Blame History

name: implement description: SDLC implementation stage. Gate on capability tags enforced in code by sdlc-gate (implement requires coding), then confirm the analysis page's source branch - it is both the worktree base and the PR target. Every already-open work package's PR comments get triaged via tools/wp-gate.sh check (sub agents fix them in that package's own worktree), but that never blocks a different, unrelated package - independent work packages can proceed in parallel. Picking a candidate is gated per-candidate in code by tools/wp-gate.sh check-deps, which re-reads the analysis page's WBS dependency column and queries Gitea itself: only a candidate whose own declared dependencies are merged may be claimed. Claim a ready work package from ANALYZE_CONTENTS with a work ticket, confirm a delivery package's content type, then complete its TDD todos one at a time inside a worktree built from origin/{source-branch}, updating the wiki after every item, closing with jsc-review code-review, one PR back to the source branch, the chosen delivery document, an optional MAINTAIN_CONTENTS entry, and a tools/stage-report.sh report covering the model tag verdict, the worklog link, every wiki link written, the worktree and the three branches. 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 gate and stage lock — run jsc-cli/tools/model-tags.sh sync, then jsc-hooks/hooks/sdlc-gate.sh lock implement. This stage requires the coding capability tag. Rules: references/model-gate.md. Completion condition: the script exited 0, and you have reported the stage, the required tag, the actual model id it read from the transcript, and the verdict.

  2. Confirm the source branch — it is also this stage's PR target:

    1. Run git fetch --prune origin, then read the source branch from the analysis page and report it, along with the current branch and whether the working tree is clean.
    2. Ask per jsc-ask:ask rules to confirm that origin/{source-branch} is both the worktree's base and the PR target for every work package in this analysis. State the impact scope: each finished work package merges back into the source branch, and that branch as a whole reaches develop later as its own separate PR.
    3. A source branch missing from the remote is a stop-and-report condition, never a silent fallback. That rule (section 「來源分支在遠端找不到」), the remote-only basis and the uncommitted-changes rules: references/branch.md.
    4. Completion condition: the user has confirmed the source branch explicitly, and it is recorded on the analysis page next to the work ticket.

  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). Rename the current session to the ticket name; skip the rename only when the CLI exposes no rename command. Completion condition: the ticket string exists, and you have reported it together with which branch applied — renamed, or skipped because this CLI has no rename command.

  4. Settle every already-open work-package PR's comments — this keeps existing PRs moving, but does not by itself decide which new package may start (that's step 6):

    1. Read the analysis page's PR column. For every work package holding a PR that is not marked merged, run jsc-sdlc/tools/wp-gate.sh check {owner}/{repo} {index} --since {the comment timestamp recorded in that PR column}. Drop --since when that package has no recorded timestamp yet.
    2. Exit 0 (status=merged) clears that package: remove its worktree (references/branch.md) and mark the package done on the analysis page.
    3. Exit 1 (status=open or status=closed-unmerged) means that package's own PR is not settled yet. Fix every comment the script printed — issue comments, review verdicts and inline comments alike. Each round of fixes MUST run as a sub agent inside that package's own worktree, pushing to the same work branch, so the PR updates itself. Never open a second PR for the same package, and never ask whether to fix or wait: the gate already decided. This does not block picking a different, unrelated work package — SDLC implementation can run several independent packages in parallel; an unmerged PR only holds back packages that depend on it (step 6 checks that specifically), never the whole analysis page.
    4. Give every printed comment an outcome — fixed, no fix needed, or cannot fix. Ignore what you cannot fix, plus pure discussion and praise: do not reply on the PR and do not stop the flow, and list each ignored comment with its reason in your final report.
    5. Write the script's latest= value into that work package's PR column, appended after the existing PR link as #{index} 已處理留言 {ISO time}, and save the page back to the wiki. Next run passes it as --since, so handled comments stay handled. Reuse the existing PR column; the analysis page's columns belong to analyze.
    6. Exit 3 means the gate could not decide (a missing dependency, or the PR could not be found). Report it and stop — an undecidable gate never counts as merged.
    7. Completion condition: every work package holding an unmerged PR has had this run's comments triaged (fixed, no fix needed, or cannot fix) and reported; a package left unmerged after this does not block step 5/6 for packages that do not depend on it.

  5. 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, not holding a work ticket, and — verified by step 6's wp-gate.sh check-deps, never by eyeballing the 相依 column yourself — dependency-free or all dependencies merged. Completion condition: you have listed every selectable work package, or reported that none is selectable and stopped.

  6. Before picking, the candidate's own dependencies decide — the gate lives in code, not in this text, and it is scoped to that one candidate, never to every open PR on the page:

    1. For the candidate work package the user is about to choose, run jsc-sdlc/tools/wp-gate.sh check-deps {owner}/{repo} {wp-number}. It re-reads the analysis page and queries Gitea itself — it does not trust anything you already read or concluded.
    2. Exit 0 (status=ready) → eligible; proceed to claim it. Exit 1 (status=blocked) → not eligible; report which dependency work package's PR is not merged yet, and offer the user the other eligible candidates instead of this one. Exit 3 (status=missing-dep) is an undecidable gate — report it and stop; never treat an undecidable result as either ready or blocked.
    3. A dependency phrased as text pointing outside this analysis page (another plan, another analysis) cannot be checked by the script; it comes back listed separately as needing manual confirmation. Confirm it with the user before proceeding — an unchecked cross-page dependency is not the same as a cleared one.
    4. Let the user pick per jsc-ask:ask rules from the eligible candidates only (options state open-item count and estimated effort). List delivery packages (交付 是) first — the analysis page makes WP-01 the standalone delivery package, 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. Completion condition: check-deps returned status=ready for the picked candidate (any cross-page dependency confirmed with the user), the ticket is saved on the wiki; only then may you proceed.

  7. A delivery/handover package confirms its content before its first todo:

    1. Ask per jsc-ask:ask rules what this delivery must contain. The options are fixed: 1. API 文件 and 2. 由使用者輸入. State the impact scope on each. Never assume the type, and never skip this — the answer decides what the whole package produces.
    2. Required fields, sample-data order and the new-versus-existing parameter marking: references/deliver-formats.md.
    3. Completion condition: the confirmed type is written into the analysis page's 交付型別 column and saved back to the wiki before the first todo starts.

  8. Create the worktree — before touching any code. Run git fetch --prune origin, read the source branch and the repositories involved from the analysis page, then ask per jsc-ask:ask rules how to handle the branch. Path layout, the two git worktree add options, quoting, .git/info/exclude and the reporting duty: references/branch.md. Completion condition: every repository the analysis page names has a worktree built from origin/{source-branch}, and you have reported each worktree's path, checked-out branch, source branch and starting commit sha.

  9. Complete the work package's open items one at a time. Every item MUST run as a sub agent, working inside the worktree:

    1. One sub agent takes one item and follows the TDD loop: red before green, one vertical slice. Rules and anti-patterns: references/tdd.md (refactoring belongs to the review stage).
    2. The main agent keeps only the wiki bookkeeping: when the sub agent reports the item done, flip its [ ] to [x] on the analysis page and save to the wiki.
    3. Completion condition: every item of the package shows [x] on the saved analysis page, and each save happened before the next item's sub agent started.

  10. When all items are done, call jsc-review:code-review and wait for the verdict. Each round of fixes MUST run as a sub agent inside the same worktree. Completion condition: the review passes.

  11. One work package finished → commit, push, PR back to the source branch. Then stop and wait for that PR:

    1. Call jsc-git:pr from inside the worktree, passing {source-branch} as the base branch. One package, one PR; the branch rules behind that are in references/branch.md.
    2. Write the PR URL and number into that work package's PR column on the analysis page and save it back to the wiki, so the next run of this skill can find it (step 4).
    3. Run jsc-sdlc/tools/wp-gate.sh lock {owner}/{repo} {index}. The lock is what makes step 4's gate hold across work sessions — a new session starts blocked until that PR merges.
    4. Do not start another work package. Completion condition: the PR exists, its URL is saved on the analysis page and reported to the user, the lock exists (status=locked), and the skill has stopped.

  12. Delivery document — a finished work package is a delivery, so always ask before producing it; never pick a format silently and never skip this step:

    1. Ask per jsc-ask:ask rules which format to produce. The options are fixed: a DELIVER_{HASH} wiki page or a Gitea issue comment. State the impact scope on each (the wiki page lives beside the plan and analysis pages; the issue comment reaches whoever follows that issue).
    2. Both formats use the same structure — templates/deliver-page.md, in Traditional Chinese. Only the destination differs. Sample values and personal-data handling: references/deliver-formats.md.
    3. Wiki page: write DELIVER_{HASH} through jsc-gitea:wiki, where {HASH} comes from jsc-gitea/tools/hash-id over {owner}/{repo} plus the work package number (for example plugins/sdlc#WP-01), so each work package gets its own page instead of overwriting the previous one. A new page is added to DELIVER_CONTENTS per templates/deliver-contents.md.
    4. Issue comment: confirm the issue number with the user (propose the one referenced by the work package or the PR; never guess), then post via jsc-gitea/tools/gitea.sh api POST /repos/{owner}/{repo}/issues/{n}/comments with the body passed in as a UTF-8 file — real newlines, never a literal \n.
    5. Completion condition: the chosen format has actually been produced, and you have reported where it landed (wiki page name, or the comment URL).

  13. 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. Completion condition: the user has answered, and a chosen registration is saved on the wiki.

  14. Stage report — the last thing this stage does, including every early stop (the work package gate blocked, no work package was selectable, the source branch was missing from the remote). Run tools/stage-report.sh implement with:

    • one --page TYPE:{page} per wiki page this run wrote — ANALYZE_{HASH}, DELIVER_{HASH} and DELIVER_CONTENTS, MAINTAIN_CONTENTS;
    • --worklog and --worklog-heading when a work log entry exists; otherwise write this stage's log content to a file and pass --pending-file {file} --log-hash {HASH}, which holds it for the next jsc-log:worklog run;
    • --worktree {path} --source-branch {name} --work-branch {name} --pr {url} — the script reads the commit count, the push state and whether the source branch exists on the remote by itself, so pass the names, not your own count.

    Rules and exit codes: references/stage-report.md. Exit 1 is a warning, never a block. Completion condition: the script's output is reported to the user verbatim, and it names the worktree, all three branches and every wiki page this run wrote.

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.
  • Sample data written into code or fixtures follows the analysis page's 資料來源 column, under the rules in references/deliver-formats.md.
  • Everything the skill writes out (wiki content, commit messages, PR descriptions) stays Traditional Chinese per the STE100 rule.
Reference in New Issue View Git Blame Copy Permalink