How do I install the Writing Javadoc skill?

Run npx skillmds@latest add redis/writing-javadoc in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Writing Javadoc safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Writing Javadoc?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Writing Javadoc free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Writing Javadoc?

redis (@redis) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Writing Javadoc by redis — Agent Skill

Name: Writing Javadoc
Author: redis

Writing Javadoc

Use when writing or editing Javadoc for Lettuce public API — new methods, classes, deprecations, or when a reviewer asks to fix or improve doc comments. Points to the full house ruleset in .agents/docs/javadoc.md (imperative method summaries, fixed tag order, @param/@return/@throws/@since/@deprecated house forms) and the rule that command-interface Javadoc is written on the sync interface first and mirrored to the other flavors. Trigger on "write javadoc for", "document this method", "add a deprecation notice", "fix the doc comment".

redis f7c5c50 3.2 KB Updated Sep 17, 2026

File contents

Writing Javadoc for Lettuce

The complete, authoritative ruleset is .agents/docs/javadoc.md — read it before writing. This skill is the operating checklist; the doc wins on any detail.

Before you write

Is it a command interface? The command interfaces are hand-edited, with the sync interface's Javadoc as the reference text. Write or fix the comment on the sync method first, then mirror it to every flavor that declares the method, with the flavor-appropriate @return phrasing (RedisFuture, Mono/Flux, …):
- src/main/java/io/lettuce/core/api/{sync,async,reactive}/
- the Kotlin coroutine interfaces (src/main/kotlin/…/api/coroutines/)
- the cluster node-selection interfaces (src/main/java/io/lettuce/core/cluster/api/{sync,async}/NodeSelection…)
- the Sentinel interfaces (src/main/java/io/lettuce/core/sentinel/api/… and their Kotlin flavor)
Javadoc parity is not test-enforced — keep the flavors in sync by hand. See api-consistency.md.

The rules most often gotten wrong

Golden rule: document the caller-facing contract (inputs, outputs, effects, errors, nullability) — never implementation details or refactor rationale.
First sentence: imperative verb for methods ("Append…", "Get…", "Remove…"), noun phrase for types. Not "This method…". Ends in a clean period.
Tag order: @param → @return → @throws → @author → @since → @see → @deprecated.
@param for every parameter (type params <K>/<V> first); state nullability with the house phrases must not be {@code null}. / can be {@code null}.
@return for non-void; describe the value and its meaningful states, not the type.
@since is a bare version — @since 7.7 (see .agents/docs/javadoc.md for deriving the version from the build).
@deprecated — keep the @Deprecated annotation and the tag in sync; house form: @deprecated since <version>, use {@link Replacement} instead; scheduled for removal in a future major release.
@author on types only — the maintainer's name (an agent must not invent one); don't reorder existing authors.
Use {@code null} for literals; {@link} only to types resolvable on the compile classpath (else {@code TypeName}).

Verify, don't guess

Match the surrounding file, and consult .agents/docs/javadoc.md for any subtle case rather than inventing a rule. Javadoc lint is off in the build (<doclint>none</doclint>), so review is the only check — get it right by hand.

---name: writing-javadocdescription: Use when writing or editing Javadoc for Lettuce public API — new methods, classes, deprecations, or when a reviewer asks to fix or improve doc comments. Points to the full house ruleset in .agents/docs/javadoc.md (imperative method summaries, fixed tag order, @param/@return/@throws/@since/@deprecated house forms) and the rule that command-interface Javadoc is written on the sync interface first and mirrored to the other flavors. Trigger on "write javadoc for", "document this method", "add a deprecation notice", "fix the doc comment".---# Writing Javadoc for LettuceThe complete, authoritative ruleset is **[.agents/docs/javadoc.md](../../../.agents/docs/javadoc.md)** —read it before writing. This skill is the operating checklist; the doc wins on anydetail.## Before you write- **Is it a command interface?** The command interfaces are hand-edited, with the **sync** interface's Javadoc as the reference text. Write or fix the comment on the sync method first, then mirror it to **every** flavor that declares the method, with the flavor-appropriate `@return` phrasing (`RedisFuture`, `Mono`/`Flux`, …): - `src/main/java/io/lettuce/core/api/{sync,async,reactive}/` - the Kotlin coroutine interfaces (`src/main/kotlin/…/api/coroutines/`) - the cluster node-selection interfaces (`src/main/java/io/lettuce/core/cluster/api/{sync,async}/NodeSelection…`) - the Sentinel interfaces (`src/main/java/io/lettuce/core/sentinel/api/…` and their Kotlin flavor) Javadoc parity is **not** test-enforced — keep the flavors in sync by hand. See [api-consistency.md](../../../.agents/docs/api-consistency.md).## The rules most often gotten wrong1. **Golden rule:** document the caller-facing contract (inputs, outputs, effects, errors, nullability) — never implementation details or refactor rationale.2. **First sentence:** imperative verb for methods ("Append…", "Get…", "Remove…"), noun phrase for types. Not "This method…". Ends in a clean period.3. **Tag order:** `@param` → `@return` → `@throws` → `@author` → `@since` → `@see` → `@deprecated`.4. **`@param`** for every parameter (type params `<K>`/`<V>` first); state nullability with the house phrases `must not be {@code null}.` / `can be {@code null}.`5. **`@return`** for non-void; describe the value and its meaningful states, not the type.6. **`@since`** is a bare version — `@since 7.7` (see .agents/docs/javadoc.md for deriving the version from the build).7. **`@deprecated`** — keep the `@Deprecated` annotation and the tag in sync; house form: `@deprecated since <version>, use {@link Replacement} instead; scheduled for removal in a future major release.`8. **`@author`** on types only — the *maintainer's* name (an agent must not invent one); don't reorder existing authors.9. Use `{@code null}` for literals; `{@link}` only to types resolvable on the compile classpath (else `{@code TypeName}`).## Verify, don't guessMatch the surrounding file, and consult `.agents/docs/javadoc.md` for any subtle caserather than inventing a rule. Javadoc lint is off in the build (`<doclint>none</doclint>`),so review is the only check — get it right by hand.

Frequently asked questions