bitwarden · rkac-bw · Apr 16, 2026 · Feb 25, 2026 · Mar 5, 2026 · Mar 5, 2026
@@ -43,7 +43,7 @@
     {
       "name": "bitwarden-software-engineer",
       "source": "./plugins/bitwarden-software-engineer",
-      "version": "0.3.2",
+      "version": "0.3.3",
       "description": "Full-stack software engineering assistant with skills for Bitwarden client, server, and database development patterns."
     },
     {

@@ -12,7 +12,7 @@ A curated collection of plugins for AI-assisted development at Bitwarden. Enable
 | [bitwarden-init](plugins/bitwarden-init/)                           | 1.1.0   | Initialize and enhance CLAUDE.md files with Bitwarden's standardized template format                                |
 | [bitwarden-product-analyst](plugins/bitwarden-product-analyst/)     | 0.1.5   | Product analyst agent for creating comprehensive Bitwarden requirements documents from multiple sources             |
 | [bitwarden-security-engineer](plugins/bitwarden-security-engineer/) | 1.0.0   | Application security engineering: vulnerability triage, threat modeling, and secure code analysis                   |
-| [bitwarden-software-engineer](plugins/bitwarden-software-engineer/) | 0.3.2   | Full-stack engineering assistant for Bitwarden client, server, and database development patterns                    |
+| [bitwarden-software-engineer](plugins/bitwarden-software-engineer/) | 0.3.3   | Full-stack engineering assistant for Bitwarden client, server, and database development patterns                    |
 | [claude-config-validator](plugins/claude-config-validator/)         | 1.1.1   | Validates Claude Code configuration files for security, structure, and quality                                      |
 | [claude-retrospective](plugins/claude-retrospective/)               | 1.1.1   | Analyze Claude Code sessions to identify successful patterns and improvement opportunities                          |
 

@@ -1,6 +1,6 @@
 {
   "name": "bitwarden-software-engineer",
-  "version": "0.3.2",
+  "version": "0.3.3",
   "description": "Comprehensive full-stack software engineering assistant proficient in modern software development at Bitwarden.",
   "author": {
     "name": "Bitwarden",

@@ -5,6 +5,12 @@ All notable changes to the `bitwarden-software-engineer` plugin will be document
 The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
 and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
+## [0.3.3] - 2026-04-15
+
+### Changed
+
+- Updated `writing-database-queries` skill: clarified dual-ORM architecture, rewrote EDD section to reflect no-rollback deployment model, documented stored procedure compatibility patterns, simplified key locations, and removed Cloud/Self-hosted labels from ORM descriptions
+
 ## [0.3.2] - 2026-04-15
 
 ### Changed

@@ -5,30 +5,42 @@ description: Bitwarden database architecture, migrations, and dual-ORM strategy.
 
 ## Dual-ORM Architecture
 
-Bitwarden maintains two parallel data access implementations:
+Bitwarden maintains two data access implementations, split by database provider:
 
 - **MSSQL:** Dapper with stored procedures
 - **PostgreSQL, MySQL, SQLite:** Entity Framework Core
 
-Every database change requires both implementations. Repository interfaces abstract both — when a stored procedure performs specific operations, the EF implementation must replicate identical behavior.
+These implementations are **mutually exclusive at runtime** — SQL Server uses only Dapper, while the other providers use only EF Core. Both implementations conform to the same repository interfaces.
+
+- When **adding new repository functionality**, implement it in **both** Dapper and EF Core (unless the feature is explicitly EF-only).
+- When **modifying an existing stored procedure** in a backwards-compatible way (for example, adding a new parameter with a default), **EF Core changes are not required**.
+- Some commercial features (for example, **Secrets Manager**) are **EF Core only**.
 
 ## Evolutionary Database Design (EDD)
 
-Bitwarden Cloud uses zero-downtime deployments with a multi-phase migration strategy:
+Bitwarden Cloud uses a **no-rollback** approach to database deployments. The key implication: **server deployments can be rolled back, but database migrations cannot**, so migrations must be designed to avoid being a source of downtime.
+
+All MSSQL migrations live in `util/Migrator/DbScripts/` and execute in chronological order based on the migration filename (`YYYY-MM-DD_##_Description.sql`).
+
+> Note: You may see `util/Migrator/DbScripts_transition/` and `util/Migrator/DbScripts_finalization/` folders. These are not currently used; ignore them for now.
+
+Simple additive changes (new nullable column, new table, new stored procedure) typically require only a single migration script in `util/Migrator/DbScripts/`.
+
+### Stored procedure compatibility
+
+Stored procedure changes fall into two categories:
 
-- **Phase 1 — Initial** (`util/Migrator/DbScripts`): Runs before code deployment. Must be backwards-compatible.
-- **Phase 2 — Transition** (`util/Migrator/DbScripts_transition`): Runs after deployment. Handles batched data migrations only — no schema changes.
-- **Phase 3 — Finalization** (`util/Migrator/DbScripts_finalization`): Runs at the next release. Removes backwards-compatibility scaffolding.
+- **Non-breaking (DEFAULT parameters):** Adding a parameter with a default value (e.g., `@NewParam BIT = NULL`) is backwards-compatible. Existing callers keep working; no `_V2` is needed.
+- **Breaking (`_V2` versioning):** Required when result-set structure changes, calling patterns change (e.g., single result → multiple result sets), required parameters are added without defaults, or query semantics differ. Implement this by creating `ProcedureName_V2` while retaining the original procedure for backwards compatibility.
 
-Simple additive changes (new nullable column, new table, new stored procedure) only need Phase 1.
+Table-level breaking changes (removing columns, changing types) typically cascade into stored procedure changes and often require the `_V2` pattern.
 
-**Always defer to the developer on migration phasing.** The multi-phase approach is complex and context-dependent. When a database change is needed, write the migration script for Phase 1 and ask the developer whether additional phases are required.
+**Always defer to the developer on migration strategy.** The approach is complex and context-dependent. When a database change is needed, write the migration script and ask the developer whether `_V2` versioning or additional steps are required.
 
 ## Key locations
 
 - `src/Sql/dbo` — Master schema source of truth
-- `src/Sql/dbo_finalization` — Future schema state
-- `util/Migrator/DbScripts_manual` — Exceptional cases (index rebuilds)
+- `util/Migrator/DbScripts` — All migrations (single folder, chronological)
 
 ## ORM-Specific Implementation
 
@@ -44,7 +56,7 @@ These are the most frequently violated conventions. Claude cannot fetch the link
 - **All schema objects use `dbo` schema** — never create objects in other schemas
 - **Constraint naming:** `PK_TableName` (primary key), `FK_Child_Parent` (foreign key), `IX_Table_Column` (index), `DF_Table_Column` (default)
 - **Idempotent scripts:** Use `IF NOT EXISTS` / `IF COL_LENGTH(...)` guards before schema changes in migration scripts
-- **Every database change requires both Dapper and EF Core implementations** — never ship one without the other
+- **New repository functionality requires both Dapper and EF Core implementations** — unless the feature is explicitly EF-only or the change is a backwards-compatible stored procedure modification
 - **Integration tests use `[DatabaseData]` attribute** — this runs the test against all configured database providers
 
 ## Further Reading