github-starred/android
2
0
Fork 0
mirror of https://github.com/bitwarden/android.git synced 2026-06-20 20:47:48 -05:00
Code Issues 2.4k Packages Projects Releases 129 Wiki Activity

[PR #6963] [MERGED] llm: Add interface KDoc rule to implementing-android-code skill #100393

New Issue
Closed
opened 2026-05-31 05:13:36 -05:00 by GiteaMirror · 0 comments
GiteaMirror commented 2026-05-31 05:13:36 -05:00
Owner
Copy Link

📋 Pull Request Information

Original PR: https://github.com/bitwarden/android/pull/6963
Author: @SaintPatrck
Created: 5/22/2026
Status: ✅ Merged
Merged: 5/22/2026
Merged by: @SaintPatrck

Base: main ← Head: chore/implementing-android-skill-interface-kdoc

📝 Commits (1)

  • 1d93693 llm: Add interface KDoc rule to implementing-android-code skill

📊 Changes

1 file changed (+42 additions, -1 deletions)

View changed files

📝 .claude/skills/implementing-android-code/SKILL.md (+42 -1)

📄 Description

🎟️ Tracking

No Jira ticket — meta change to the implementing-android-code skill itself, originating from repeated review feedback.

📔 Objective

Reviewers have repeatedly flagged interface member KDoc that drifts into describing how the implementation fulfills the contract — naming concrete collaborators, describing call ordering, mentioning caching or fallback behavior. The contract belongs on the interface; the why (when non-obvious) belongs on the ...Impl override; the what belongs nowhere because well-named identifiers already convey it.

Encoding the rule in the skill turns a per-PR correction into a guardrail that applies to every future change that triggers the implementing-android-code skill.

What's in the skill update (v0.1.3 → v0.1.4)

  • Section D — Data Layer Implementation gains a "KDoc on Interfaces vs. Implementations" subsection covering:
    • The contract-vs-implementation distinction, with wrong/right examples on a Repository interface.
    • Red flags that an interface KDoc has drifted into implementation territory (naming concrete collaborators, describing ordering, mentioning caching/retries/logging/threading, restating the signature in prose).
    • The "would a different valid implementation be free to change this behavior?" test for separating contract from implementation detail.
    • The carve-out for behaviors callers genuinely depend on (e.g., "safe to call before vault unlock", "cached for the session") — those are contract.
  • Anti-pattern list gains a NEVER put implementation details in interface KDoc entry that points back to section D.

The rule applies to every interface in the codebase — repositories, managers, data sources, validators, UI-layer interfaces alike — and aligns interface KDoc with the project-wide comment rule from CLAUDE.md (WHY not WHAT, only when non-obvious).

🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.

## 📋 Pull Request Information **Original PR:** https://github.com/bitwarden/android/pull/6963 **Author:** [@SaintPatrck](https://github.com/SaintPatrck) **Created:** 5/22/2026 **Status:** ✅ Merged **Merged:** 5/22/2026 **Merged by:** [@SaintPatrck](https://github.com/SaintPatrck) **Base:** `main` ← **Head:** `chore/implementing-android-skill-interface-kdoc` --- ### 📝 Commits (1) - [`1d93693`](https://github.com/bitwarden/android/commit/1d9369357c0dc50309ad3e8c2ccaee23a1ceb920) llm: Add interface KDoc rule to implementing-android-code skill ### 📊 Changes **1 file changed** (+42 additions, -1 deletions) <details> <summary>View changed files</summary> 📝 `.claude/skills/implementing-android-code/SKILL.md` (+42 -1) </details> ### 📄 Description ## 🎟️ Tracking No Jira ticket — meta change to the `implementing-android-code` skill itself, originating from repeated review feedback. ## 📔 Objective Reviewers have repeatedly flagged interface member KDoc that drifts into describing **how** the implementation fulfills the contract — naming concrete collaborators, describing call ordering, mentioning caching or fallback behavior. The contract belongs on the interface; the *why* (when non-obvious) belongs on the `...Impl` override; the *what* belongs nowhere because well-named identifiers already convey it. Encoding the rule in the skill turns a per-PR correction into a guardrail that applies to every future change that triggers the `implementing-android-code` skill. ### What's in the skill update (`v0.1.3` → `v0.1.4`) - **Section D — Data Layer Implementation** gains a "KDoc on Interfaces vs. Implementations" subsection covering: - The contract-vs-implementation distinction, with wrong/right examples on a `Repository` interface. - Red flags that an interface KDoc has drifted into implementation territory (naming concrete collaborators, describing ordering, mentioning caching/retries/logging/threading, restating the signature in prose). - The "would a different valid implementation be free to change this behavior?" test for separating contract from implementation detail. - The carve-out for behaviors callers genuinely depend on (e.g., "safe to call before vault unlock", "cached for the session") — those *are* contract. - **Anti-pattern list** gains a `NEVER put implementation details in interface KDoc` entry that points back to section D. The rule applies to every interface in the codebase — repositories, managers, data sources, validators, UI-layer interfaces alike — and aligns interface KDoc with the project-wide comment rule from `CLAUDE.md` (WHY not WHAT, only when non-obvious). --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
GiteaMirror added the pull-request label 2026-05-31 05:13:36 -05:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
app:authenticator
app:password-manager
bug
bug-passkey
customer-support
duplicate
enhancement
good first issue
help wanted
needs-reply
needs-response
pull-request
Mirrored from GitHub Pull Request
 question
No Label pull-request
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/android#100393
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?