jiantw83andClaude Opus 5
543fd8c695
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
31 lines
3.1 KiB
Markdown
31 lines
3.1 KiB
Markdown
---
|
|
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.
|