Java Comment Standards Assistant

Problem

• Class metadata: fields such as @author, @version, @company, and @description often appear inconsistently or with unclear provenance, especially when creating and modifying classes.
• Business comments: line-ending /* ... */, mixed languages, and inconsistent blank lines make code review harder.
• Versioning: it is unclear whether a change should be 1.0, 1.1, or 2.0, which can create misleading version numbers.
• Encoding: a BOM can cause Java compilation to report illegal character: '\ufeff'.

How It Works

The skill turns docs/JAVA_COMMENT_RULES.md into an execution checklist:

1. For new classes, complete the /** ... */ comment and fill the template fields.
2. For existing classes, preserve @createTime and historical @modifyRecord entries, and update @description with the current change.
3. Before changing @version, inspect Git for a release branch or release tag, then compare the same-path class file. If missing, use 1.0; if present with no new method, bump the minor version; if a new method signature is added, bump the major version.
4. Business code comments should be Chinese block comments placed above the target line, not at line endings.
5. Apply blank-line rules: if the comment is the first line inside { ... }, place it directly below {; otherwise keep one blank line above it.
6. Keep files as UTF-8 without BOM and verify that no line-ending block comments remain.

Boundaries

• It supports adding, adjusting, reviewing, and standardizing Java comments, but does not replace the full project specification.
• @author, @registerPosition, and @modifier should be left blank when unknown, or inferred carefully from context.
• @version depends on Git/release availability; fallback reasoning is only an approximation.
• A new method is detected by method signatures; field, import, comment, or internal-logic changes do not count as new methods.