원클릭으로
refactor-align-order
Align declaration order across related files so items appear in consistent sequence.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
메뉴
Align declaration order across related files so items appear in consistent sequence.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Improve comments and docs so they capture non-obvious intent, caller-visible contracts, invariants, and why-context; prune comments that only restate code. Use whenever writing or modifying code (any new or edited source file), not just on explicit cleanup requests. Triggers on "주석 정리", "주석 다듬기", "comment cleanup", "prune comments", "의도 정리", "clarify code intent", "intent comments", "contract docs", "API contract comments".
Write or update Java class-level Javadoc that documents responsibility, caller-visible boundaries, invariants, and thread-safety. Use when modifying API-facing or boundary-owning Java types, SPI and extension types, factories or coordinators that choose policy or workflow, abstract/interface contracts, or behavior-bearing core domain types whose responsibility, invariants, lifecycle, or threading are not obvious.
Write or update Java method-level Javadoc that documents caller-visible contracts, preconditions, postconditions, exceptions, externally visible side effects, and performance constraints. Use when modifying API, SPI, extension, or reused internal Java methods whose caller-visible or durable internal contract is non-obvious or not encoded by signatures, annotations, validation, or inherited documentation.
Write or update Java package-info.java documentation that defines package responsibility, durable boundaries, optional non-responsibilities, package-wide invariants, and extension points. Use when adding, renaming, moving, or splitting packages; changing responsibility across package boundaries; or creating/updating package-info.java for API-facing or shared packages with durable ownership rules.
Write unit tests following London School (mockist) TDD style.
Rebase current branch onto latest main/master.
| name | refactor-align-order |
| description | Align declaration order across related files so items appear in consistent sequence. |
align-order <source-file> <target-file>
If only one file is given, treat it as the target and infer the source:
If inference fails, ask the user.