菜单
Plan implementation, design an approach, or create an architecture plan for a Bitwarden iOS feature. Use when asked to "plan implementation", "design approach", "architecture plan", "how should I implement", "what files do I need", or to create a design doc before writing code.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Build the project, run tests, lint, format, spell check, generate mocks, or verify the build passes for Bitwarden iOS. Use when asked to "build", "run tests", "lint", "format", "verify build", "check if it compiles", "run swiftlint", "run swiftformat", "generate mocks", or to execute any part of the build/test/verify pipeline.
Implement, write code, add a new screen, create a feature, new view, new processor, or wire up a new service in Bitwarden iOS. Use when asked to "implement", "write code", "add screen", "create feature", "new view", "new processor", "add service", or when translating a design doc into actual Swift code.
Performs comprehensive code reviews for Bitwarden iOS projects, verifying architecture compliance, style guidelines, compilation safety, test coverage, and security requirements. Use when reviewing pull requests, checking commits, analyzing code changes, verifying Bitwarden coding standards, evaluating unidirectional data flow pattern, checking services container dependency injection usage, reviewing security implementations, or assessing test coverage. Automatically invoked by CI pipeline or manually for interactive code reviews.
Write tests, add test coverage, unit test, or add missing tests for Bitwarden iOS. Use when asked to "write tests", "add test coverage", "test this", "unit test", "add tests for", "missing tests", or when creating test files for new implementations.
Convert an XCTest file to Swift Testing framework. Use when asked to "convert to Swift Testing", "migrate XCTest", "convert test file", "xctest to swift testing", "migrate tests to Swift Testing", or when explicitly asked to convert existing XCTest-based tests.
Convert a hand-written bespoke mock to a Sourcery AutoMockable-generated mock. Use this skill whenever the user says "convert this mock", "migrate mock to AutoMockable", "replace bespoke mock", "use Sourcery for this mock", or mentions wanting to convert a Mock*.swift file to use `// sourcery: AutoMockable`. Also use this skill proactively when you notice a new protocol being created without the annotation, or when an existing bespoke mock is being modified and AutoMockable would be sufficient.
| name | planning-ios-implementation |
| description | Plan implementation, design an approach, or create an architecture plan for a Bitwarden iOS feature. Use when asked to "plan implementation", "design approach", "architecture plan", "how should I implement", "what files do I need", or to create a design doc before writing code. |
Use this skill to design a complete implementation plan before writing code. Output is saved as a design document.
refining-ios-requirements first.Docs/Architecture.md before proceeding — it is the authoritative source for all patterns.Determine the change type to guide scope and planning depth:
| Type | Description | Typical Scope |
|---|---|---|
| New Feature | Entirely new functionality, screens, or flows | New files + modifications, multi-phase |
| Enhancement | Extending existing feature with new capabilities | Mostly modifications, 1-2 phases |
| Bug Fix | Correcting incorrect behavior | Targeted modifications, single phase |
| Refactoring | Restructuring without behavior change | Modifications only, migration-aware |
| Infrastructure | Build, CI, tooling, or dependency changes | Config files, minimal code changes |
State the classification and rationale before proceeding.
Search the codebase for similar existing implementations to follow:
BitwardenKit/UI/ has reusable components for the new UIFor each file, specify path, action (create/modify), domain placement, and purpose. Group by layer:
### New Files (Create)
#### Core Layer
- `BitwardenShared/Core/<Domain>/<Feature>/Services/<Feature>Service.swift`
- Protocol + Default<Feature>Service + Has<Feature>Service
#### UI Layer
- `BitwardenShared/UI/<Domain>/<Feature>/<Feature>Coordinator.swift`
- `BitwardenShared/UI/<Domain>/<Feature>/<Feature>Processor.swift`
- `BitwardenShared/UI/<Domain>/<Feature>/<Feature>State.swift`
- `BitwardenShared/UI/<Domain>/<Feature>/<Feature>Action.swift`
- `BitwardenShared/UI/<Domain>/<Feature>/<Feature>Effect.swift`
- `BitwardenShared/UI/<Domain>/<Feature>/<Feature>View.swift`
#### Tests (co-located with implementation)
- `BitwardenShared/UI/<Domain>/<Feature>/<Feature>ProcessorTests.swift`
- `BitwardenShared/Core/<Domain>/<Feature>/Services/<Feature>ServiceTests.swift`
### Modified Files
- `BitwardenShared/Core/Platform/Services/ServiceContainer.swift` — Add new service
- `<Existing>Coordinator.swift` — Add new route
Order phases so each builds on the previous:
### Phase 1: Data / Core Layer
Models, CoreData entities (if needed), service protocols, repository protocols
### Phase 2: Service/Repository Implementations
Default<Name>Service/Repository — business logic, SDK calls, network
### Phase 3: DI Wiring
ServiceContainer extensions, Has* protocol additions
### Phase 4: Processor + State
StateProcessor subclass, State struct, Action enum, Effect enum
### Phase 5: View + Coordinator
SwiftUI View with store.binding, Coordinator with routes, navigation wiring
### Phase 6: Tests
ProcessorTests (action/effect paths), ServiceTests (business logic), ViewTests (snapshots if UI)
Identify risks and mitigations:
Save the plan to .claude/outputs/plans/<ticket-id>.md.
Present the plan to the user and ask: "Here is the implementation plan. Should I proceed with implementation?"