From JavaDoc Generator
Generate or update JavaDoc comments following Oracle's "How to Write Doc Comments for the Javadoc Tool" and Atlassian's Confluence Javadoc standards, with modern JDK (records, sealed types, {@snippet}, inline {@return}). Use when asked to document Java code — a class, method, interface, enum, record, package, file, or set of changes — or to add/fix Javadoc to meet a documentation standard. Documents the full public/protected API thoroughly; skips private internals and pure signature-paraphrases.
How this skill is triggered — by the user, by Claude, or both
Slash command
/javadoc:javadocThis skill is limited to the following tools:
The summary Claude sees in its skill listing — used to decide when to auto-load this skill
A workflow for writing or updating JavaDoc comments on Java code so that the **public and protected API is documented thoroughly and consistently**, following the consolidated conventions of:
A workflow for writing or updating JavaDoc comments on Java code so that the public and protected API is documented thoroughly and consistently, following the consolidated conventions of:
{@snippet}, inline {@return} / {@summary}, /// Markdown commentsThe full convention catalog — every tag's phrasing rules, the source-conflict resolutions, and worked examples — lives in the companion file patterns.md next to this one. This file is the procedure; reach into patterns.md for the detail behind any rule.
Use it when the user wants Java documentation produced to a standard, e.g.:
MoneyUtil"com.example.http"Do NOT use it for:
// why comments on private implementation logic — that's ordinary commenting, not Javadoc.This skill documents the entire public/protected API surface — that is Atlassian's baseline and the point of the skill. It applies Oracle's rigor (first-sentence summary, @param/@return/@throws, null behavior, side-effects, thrown conditions) to that surface.
It is balanced, not dogmatic, in two ways:
/** Gets the name. @return the name */ noise. But do not leave the broader public API undocumented.// ... comment, not a doc comment.The dividing line from a minimalist style: here the default for public/protected API is to document it. You skip only the trivial paraphrase, not the API at large.
Determine exactly what to document. Infer from the user's phrasing; ask only if genuinely ambiguous.
| Target | How to enumerate it |
|---|---|
| A class / file | The named .java file(s). Document the type and its public/protected members. |
| A package / directory | Every .java file under that directory (non-recursive unless the user says "and subpackages"). |
| A whole module / source tree | All .java under the source root. Large — confirm with the user first and consider doing it package-by-package so the change is reviewable. |
| A set of changes (diff mode) | git fetch origin then git diff origin/main...HEAD for branch work, or git diff / git diff --staged for uncommitted. Document the public/protected members the diff added or changed. The three-dot form diffs against the merge-base, excluding drift on the base branch. |
Produce a concrete work-list: the set of types and members to be documented. Everything downstream operates on this list.
For each type in the work-list, list its public/protected members (and the type itself). Read the source — don't work from a diff or signature alone. For each, note the current doc state:
Classify each member: type, constructor, method, constant/field, record component, enum constant.
DOCUMENT (default for the public/protected surface):
@param, @return, @throws), covering null behavior, side-effects, ranges, and thrown conditions per Oracle/Atlassian rigor.@param <component> per component on the record header (see patterns.md).MAY SKIP or reduce to a single summary line:
{@inheritDoc} in patterns.md.SKIP (no Javadoc):
private / package-private members. (A genuine gotcha there → inline // comment, not Javadoc.)When in doubt on a public member, document it (that's the standard). When in doubt on a private member, leave it.
Full detail and examples in patterns.md; the high-frequency rules:
First sentence — a self-standing summary; Javadoc extracts it verbatim into tables and the index.
. (period+space). Avoid "e.g."/"i.e." (write "for example"); if unavoidable, wrap the summary in {@summary …} (JDK 10+).Block-tag order (omit any that don't apply):
@param → @return → @throws → @see → @since → @deprecated
@param — parameter NAME then a lowercase phrase (no leading dash, no <code> around the name; Javadoc adds both). Order to match the signature. Carry real info: units, ranges, null/empty contract, collection element type. @param key the cache key; must not be null@return — for every documented non-void method; be specific, cover special cases (null/empty/sentinel, out-of-range, collection element type). Omit for void and constructors. Prefer inline {@return …} when the whole description is the return value: /** {@return the number of cached entries} */.@throws (preferred over @exception) — every checked exception and any unchecked one a caller might reasonably catch; phrase as an if-clause: @throws IOException if an I/O error occurs. Skip NullPointerException/Error and implementation-bound exceptions.@deprecated — state when and the replacement via {@link} (or "No replacement"); pair with the @Deprecated annotation.@see — for genuinely interesting collaborators/companion helpers, not obvious neighbors.@author / @version — Oracle permits them; Atlassian and modern practice drop them (authorship/history live in version control). Default: omit. @since is the one versioning tag worth using on a published surface — never invent a version.Special shapes:
@param <component> per component on the record header's class comment only. Never repeat @param on the canonical/compact constructor or hand-write docs on generated accessors.{@sealed} tag; in prose state it's sealed and {@link} each permitted subtype with its meaning.{@inheritDoc} plus the override-specific note (any comment suppresses the automatic full-text copy).<code>…</code> (or backticks in a /// Markdown comment on new code).{@snippet}, never <pre>{@code}</pre>.@param/@return):
javadoc -Xdoclint:all -d <scratch-dir> <files> # -d points anywhere throwaway; doclint runs regardless of OS
or rely on the project's own check (Checkstyle's JavadocMethod/SummaryJavadoc, an IDE's Javadoc inspection). Surface warnings rather than silencing them.patterns.md (same directory) — the full consolidated pattern catalog: per-tag phrasing notes, the six source-conflict resolutions, records/sealed/modern-feature rules, and worked good-vs-bad examples. Consult it whenever a situation isn't covered by the condensed rules above.
Fetches up-to-date documentation from Context7 for libraries and frameworks like React, Next.js, Prisma. Use for setup questions, API references, and code examples.
Applies a firm's KYC/AML rules grid to parsed onboarding records: assigns risk rating, checks required documents, outputs rule outcomes with citations, and routes for escalation.
Generates daily or weekly digests of activity from connected sources (chat, email, docs, tasks, CRM), highlighting action items, decisions, mentions, and project updates.
npx claudepluginhub ahnafeusa/javadoc-plugin --plugin javadoc