sdlc/skills/maintain/SKILL.md

---

name: maintain 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

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 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. Run git fetch --prune origin, then switch the project to develop, falling back to master, and bring it up to origin/{該分支} — the remote is the basis, never the local branch. Local and remote diverged → report and skip that project; never pull --rebase, reset or discard anything on your own.
   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.