-
Notifications
You must be signed in to change notification settings - Fork 205
feat(docs): public api kdocs #658
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
8e4b23f
f5a8e3a
078811e
e2fc8b0
ebfa6ba
e647f13
85a5ccf
c2c1a1a
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,74 @@ | ||
| --- | ||
| name: kdoc | ||
| description: "Add KDoc documentation to Kotlin public API. Use whenever the user asks to document Kotlin code, add KDoc, generate API docs, mentions undocumented public declarations, or wants to improve existing documentation. Also trigger when the user says 'add docs', 'document this class/file/module', 'write KDoc', or asks about missing documentation in Kotlin code." | ||
| --- | ||
|
|
||
| # KDoc Generator | ||
|
|
||
| Add KDoc comments to public Kotlin API declarations. | ||
|
|
||
| ## What to document | ||
|
|
||
| All public declarations (no explicit `private`/`internal`/`protected`): | ||
| - Classes, interfaces, objects, sealed classes/interfaces | ||
| - Functions, extension functions | ||
| - Properties | ||
| - Enum classes and entries | ||
| - Type aliases, annotation classes | ||
|
Comment on lines
+14
to
+17
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It this looks like too obvious
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is not obvious to the agent. In the test eval, the agent missed some points, so I add it explicitly |
||
|
|
||
| Include `@Deprecated` elements. | ||
|
|
||
| ## Context | ||
|
|
||
| Read the implementation, not just the signature, to write accurate descriptions. Understanding what the code actually does prevents superficial or misleading documentation. | ||
|
|
||
| ## KDoc format | ||
|
|
||
| **Class/interface example:** | ||
|
|
||
| ````kotlin | ||
| /** | ||
| * Manages active client sessions and their lifecycle. | ||
| * | ||
| * Sessions are created on first connection and cleaned up | ||
| * when the transport closes. | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Adding example for a class also make sense, e.g. how to construct the class
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It seems that constructor signatures are enough, at least for now, while we are using simple constructors |
||
| * | ||
| * @property maxSessions upper limit on concurrent sessions | ||
| * @property timeout idle timeout before a session is evicted | ||
| */ | ||
| ```` | ||
|
|
||
| **Function example:** | ||
|
|
||
| ````kotlin | ||
| /** | ||
| * Registers a new tool with the given handler. | ||
| * | ||
| * Example: | ||
| * ```kotlin | ||
| * server.addTool( | ||
| * name = "echo", | ||
| * description = "Echoes input back", | ||
| * ) { request -> | ||
| * CallToolResult(content = listOf(TextContent("Echo: ${request.arguments}"))) | ||
| * } | ||
| * ``` | ||
| * | ||
| * @param name unique tool identifier | ||
| * @param description human-readable tool description | ||
| * @param handler suspend function invoked when the tool is called | ||
| * @return the registered tool definition | ||
| */ | ||
| ```` | ||
|
|
||
| ## Rules | ||
|
|
||
| - Summary: concise first sentence starting with a third-person verb ("Creates", "Returns", "Represents"). Expand to 2-3 sentences only when genuinely complex | ||
| - **@property** in class-level KDoc for all public properties (never as individual KDoc on the property); **@param** for function parameters | ||
| - **@return** for non-Unit return types | ||
| - **Example block**: add for DSL builders, complex functions, extension functions with non-obvious usage. Skip for trivial one-liners and simple getters | ||
| - **DSL builders**: always include an Example showing full usage with the receiver scope — this is critical for discoverability | ||
| - KDoc links (`[ClassName]`, `[methodName]`): only where it adds clear navigational value | ||
| - No **@throws** — don't document exceptions | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is questionable. It is very helpful to keep exceptions documented, especially for non-trival use cases
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Agreed. Exceptions should be documented in non-trivial cases or when custom exceptions are involved. In kotlin-sdk, there is only |
||
| - No **suspend** notes — coroutine nature is visible from the signature | ||
| - **Existing KDoc**: rewrite if incomplete (missing @param/@return/@property) or low quality | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should also trigger automatically when adding or updating public facing api. User will simply forget to ask about kdoc.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This doesn't violate solid principles, only makes the skill-use condition more explicit. Detekt definitely helps, but it may consume more tokens on the first failing gradle run than this skill consumes.
Did you verify that if you ask the Agent to write a new method or to update the public method without KDoc, the skill is applied and the required KDoc is generated?
Not blocking for this PR but a room for improvement