name	java-docs
description	Javadoc and Java API documentation guidance. Use when documenting public Java types, controllers, service contracts, records, exceptions, or non-obvious backend behavior in backend/*/.java.

Java Documentation Best Practices

Source: adapted from github/awesome-copilot skill java-docs and this repository's preference for succinct, useful comments.

Document public and protected types and members when they form a reusable contract or would be unclear to a caller.
Do not add Javadoc that merely repeats method names or obvious implementation details.
Make the first sentence a concise summary ending with a period.
Use @param for method parameters. Start descriptions with lowercase text and omit trailing periods unless the description is a full sentence.
Use @return when the return value needs explanation.
Use @throws for exceptions that callers should deliberately handle.
Use {@code ...} for inline code and <pre>{@code ...}</pre> for multi-line examples.
Use {@inheritDoc} when inherited documentation remains accurate; document differences when behavior changes.
Avoid @author and @version unless the project already uses them consistently.
Prefer examples that are stable and small. Keep larger guidance in Markdown docs or ADRs.

name	java-docs
description	Javadoc and Java API documentation guidance. Use when documenting public Java types, controllers, service contracts, records, exceptions, or non-obvious backend behavior in backend/*/.java.

Source: adapted from github/awesome-copilot skill java-docs and this repository's preference for succinct, useful comments.

Document public and protected types and members when they form a reusable contract or would be unclear to a caller.
Do not add Javadoc that merely repeats method names or obvious implementation details.
Make the first sentence a concise summary ending with a period.
Use @param for method parameters. Start descriptions with lowercase text and omit trailing periods unless the description is a full sentence.
Use @return when the return value needs explanation.
Use @throws for exceptions that callers should deliberately handle.
Use {@code ...} for inline code and <pre>{@code ...}</pre> for multi-line examples.
Use {@inheritDoc} when inherited documentation remains accurate; document differences when behavior changes.
Avoid @author and @version unless the project already uses them consistently.
Prefer examples that are stable and small. Keep larger guidance in Markdown docs or ADRs.

java-docs