[PM-33572] llm: Add implementing-ios-code skill with Swift templates#2446
[PM-33572] llm: Add implementing-ios-code skill with Swift templates#2446SaintPatrck merged 3 commits intomainfrom
Conversation
|
Great job! No new security vulnerabilities introduced in this pull request |
|
Claude finished @SaintPatrck's task in 7m 27s —— View job I'll analyze this and get back to you. |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #2446 +/- ##
==========================================
- Coverage 87.09% 85.95% -1.14%
==========================================
Files 1859 2089 +230
Lines 164348 179153 +14805
==========================================
+ Hits 143132 153995 +10863
- Misses 21216 25158 +3942 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
Overall Assessment: APPROVE Reviewed 2 new files adding an LLM skill for implementing Bitwarden iOS features with step-by-step workflow and code templates. Code Review Details
|
Inline FindingsFinding 1 -
|
- SKILL.md: step-by-step implementation workflow (Core layer first, then UI file-set, DI wiring, security checklist, documentation); prerequisites check for design doc and Docs/Architecture.md - templates.md: minimal copy-paste skeletons derived from actual codebase files — Coordinator, Processor, State/Action/Effect, View, Service, Repository; each template references the source file it was based on
6f815a6 to
8668f72
Compare
Bitwarden Claude Code ReviewOverall Assessment: APPROVE Reviewed 2 new markdown files adding an LLM skill for implementing Bitwarden iOS features. SKILL.md provides a step-by-step workflow (scope determination, core layer, UI file-set, DI wiring, security checklist, documentation) and templates.md provides copy-paste skeletons for Coordinator, Processor, State/Action/Effect, View, Service, and Repository patterns. The latest commit addresses prior review feedback on persistence guidance, security checklist terminology, MARK conventions, and coordinator creation heuristics. Templates correctly reflect codebase conventions including the weak optional Code Review DetailsNo new findings. Prior review threads have been addressed or acknowledged by the author. |
| **Data Models** (if needed) | ||
| - Request/Response types in `Core/<Domain>/Models/Request/` and `Response/` | ||
| - Enum types in `Core/<Domain>/Models/Enum/` | ||
| - CoreData entities only if persistence is needed (add to `Bitwarden.xcdatamodeld`) |
There was a problem hiding this comment.
🤔 We basically never add anything to Core Data. If something's stored on disk, it's either in UserDefaults or the Keychain, depending on how sensitive of data it is.
Maybe this should be
- More-sensitive information persisted to disk is in `KeychainRepository`. Less-sensitive information persisted to disk is in `AppSettingsStore`. Both of these are exposed through `StateService`. Try to use a separate protocol instead of adding to the `StateService, `AppSettingsStore`, and `KeychainRepository` protocols, to ensure interface segregation.
There was a problem hiding this comment.
Rephrased. LMK what you think.
|
|
||
| Before finishing: | ||
| - [ ] Vault data? → Must use `BitwardenSdk` for all encryption/decryption | ||
| - [ ] Storing credentials? → Must use `KeychainRepository`, not `UserDefaults` |
There was a problem hiding this comment.
| - [ ] Storing credentials? → Must use `KeychainRepository`, not `UserDefaults` | |
| - [ ] Storing credentials? → Must use `KeychainRepository`, not `AppSettingsStore` |
|
|
||
| All new public types and methods require DocC (`///`) documentation. | ||
| Exceptions: protocol property/function implementations (docs live in the protocol), mock classes. | ||
| Use `// MARK: -` sections to organize code within files. |
There was a problem hiding this comment.
| Use `// MARK: -` sections to organize code within files. | |
| Use pragma marks to organize code. `// MARK: -` is used to denote different objects in the same file; `// MARK:` is used to denote different sections within an object. |
| When adding a new screen, create these files (replace `<Feature>` throughout): | ||
|
|
||
| ``` | ||
| BitwardenShared/UI/<Domain>/<Feature>/ |
There was a problem hiding this comment.
🤔 Sometimes a new screen requires a coordinator, but not always; often one coordinator manages multiple screens (and therefore multiple processors). I'm not sure how best to capture that judgement call here.
There was a problem hiding this comment.
Added detail about this, giving guidance on how to make the "correct" decision. LMK what you think.
There was a problem hiding this comment.
Oh, that sounds good.
…onventions, coordinator heuristic
| When adding a new screen, create these files (replace `<Feature>` throughout): | ||
|
|
||
| ``` | ||
| BitwardenShared/UI/<Domain>/<Feature>/ |
There was a problem hiding this comment.
Oh, that sounds good.

🎟️ Tracking
https://bitwarden.atlassian.net/browse/PM-33572
📔 Objective
Adds a Claude skill for implementing Bitwarden iOS features following established patterns.
What changed:
skills/implementing-ios-code/SKILL.md— Step-by-step implementation workflow: determines scope from a design doc, builds the Core layer first (models, services, repositories), then the full UI file-set (Coordinator, Processor, State, Action, Effect, View), wires DI intoServiceContainer, runs a security checklist (zero-knowledge, Keychain, InputValidator, NonLoggableError, extension memory), and ensures DocC documentation. ReferencesDocs/Architecture.mdas authoritative and does not duplicate it.skills/implementing-ios-code/templates.md— Minimal copy-paste skeletons derived from actual codebase files: Coordinator, Processor, State/Action/Effect, View (withstore.bindingandstore.perform), Service (protocol +Default*+Has*+// sourcery: AutoMockable), and Repository. Each template notes the source file it was based on.