메뉴
Use when finishing a code change in any zipe-spring-boot-starters module and about to commit, push, or tell the user the work is done — especially after editing Java under any *-spring-boot-starter module.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Use when asked to publish, release, or deploy zipe-spring-boot-starters to Maven Central (e.g.「發布至 maven central」「出新版」「release 4.x.x.x」)。Covers the GitHub-Action-driven release flow, version/tag rules, branch flow, and pre-flight irreversibility checks.
Use when creating a new *-spring-boot-starter module, adding a new @AutoConfiguration class, or adding @ConfigurationProperties to any zipe-spring-boot-starters module — encodes the golden conventions a starter must follow so agents replicate the established pattern instead of drifting.
Use to audit all zipe-spring-boot-starters modules for convention drift against the authoring-a-starter golden rules — run periodically, before a release, or after adding a starter, to detect packages/naming/overridability/registration that diverge and propose fixes (harness entropy-management / garbage-collection principle).
Use when code changes are made to any zipe-spring-boot-starters module (base, db, job, logon, web-service, web, iam) or when the starters_example / example-kotlin example projects need updating. Triggers on new utilities, API changes, new login methods, new connection types, schedule changes, new REST/SOAP endpoints, or new features in any starter or example module.
Use when writing a git commit message or running git commit in zipe-spring-boot-starters. Commit subjects must be in 繁體中文 and follow the <類型>(<範圍>): <主旨> format with an allowed type and module scope.
| name | local-quality-gate |
| description | Use when finishing a code change in any zipe-spring-boot-starters module and about to commit, push, or tell the user the work is done — especially after editing Java under any *-spring-boot-starter module. |
CI(.github/workflows/ci.yml)會在 push／PR 時跑 mvn verify,其中 Spotless check 綁在 compile 階段——只要格式未正規化,CI 必紅。本 skill 是對應的前饋指引:在本地先把問題擋下,提高首次通過率,而不是推上去才被 CI 發現。
動過任一 *-spring-boot-starter 程式碼後,在 commit／push／宣稱「完成」之前,依序執行下列步驟。
mvn -B spotless:apply
mvn verify 的 spotless check 會失敗。mvn -B verify
mvn -B -pl <module> -am verify 加速,但收尾前仍應跑一次全 reactor。<module>/target/site/jacoco/index.html,確認你動到的類別覆蓋率沒有因新增未測程式碼而下降。.claude/rules/doc-sync.md(純內部重構／測試／無行為變更的 bugfix 不需要)。master 則先開 feature 分支(流程:feature → develop → master)。| 念頭 | 事實 |
|---|---|
| 「格式之後再修,先 commit」 | spotless check 綁 compile,CI 會立刻紅。先 spotless:apply。 |
| 「測試讓 CI 跑就好」 | 本地 verify 才能在 commit 前擋下,這正是「首次通過率」的意義。 |
| 「只是小改,不用 verify」 | 小改也可能弄壞編譯或既有測試。verify 一次,不靠運氣。 |
| 「覆蓋率不關我的事」 | 新增程式碼若無測試會稀釋覆蓋率,讓「測試通過」的綠燈失真。 |
spotless:apply。master 直接 commit:違反分支流程,先開 feature 分支。