bitwarden · SaintPatrck · Apr 9, 2026 · Apr 9, 2026 · Apr 9, 2026 · Apr 9, 2026
@@ -43,7 +43,7 @@
     {
       "name": "bitwarden-software-engineer",
       "source": "./plugins/bitwarden-software-engineer",
-      "version": "0.3.3",
+      "version": "0.4.0",
       "description": "Full-stack software engineering assistant with skills for Bitwarden client, server, and database development patterns."
     },
     {
@@ -67,8 +67,20 @@
     {
       "name": "bitwarden-architect",
       "source": "./plugins/bitwarden-architect",
-      "version": "1.0.0",
+      "version": "1.1.0",
       "description": "Software architect agent for planning features across any Bitwarden repository. Discovers platform context dynamically via CLAUDE.md and repo-local planning skills."
+    },
+    {
+      "name": "bitwarden-delivery-tools",
+      "source": "./plugins/bitwarden-delivery-tools",
+      "version": "1.0.0",
+      "description": "Generic delivery workflow skills for committing, PR creation, preflight checks, and change labeling across any Bitwarden repository."
+    },
+    {
+      "name": "bitwarden-workflows",
+      "source": "./plugins/bitwarden-workflows",
+      "version": "1.0.0",
+      "description": "Multi-agent orchestration workflows for Bitwarden development. Composes marketplace agents into end-to-end pipelines via Teams and task dependencies."
     }
   ]
 }
@@ -6,7 +6,7 @@ A curated collection of plugins for AI-assisted development at Bitwarden. Enable
 
 | Plugin                                                              | Version | Description                                                                                                         |
 | ------------------------------------------------------------------- | ------- | ------------------------------------------------------------------------------------------------------------------- |
-| [bitwarden-architect](plugins/bitwarden-architect/)                 | 1.0.0   | Software architect for technical planning, architecture reviews, and implementation phasing                         |
+| [bitwarden-architect](plugins/bitwarden-architect/)                 | 1.1.0 | Software architect for technical planning, architecture reviews, and implementation phasing                         |
 | [bitwarden-atlassian-tools](plugins/bitwarden-atlassian-tools/)     | 2.2.3   | Read-only Atlassian access via MCP server with deep Jira issue research skill                                       |
 | [bitwarden-code-review](plugins/bitwarden-code-review/)             | 1.9.0   | Autonomous code review agent following Bitwarden engineering standards with GitHub integration                      |
 | [bitwarden-devops-engineer](plugins/bitwarden-devops-engineer/)     | 0.1.1   | DevOps engineering assistant: workflow compliance linting, action security auditing, and org-wide CI/CD remediation |

@@ -1,6 +1,6 @@
 {
   "name": "bitwarden-architect",
-  "version": "1.0.0",
+  "version": "1.1.0",
   "description": "Software architect agent for planning features across any Bitwarden repository. Discovers platform context dynamically via CLAUDE.md and repo-local planning skills.",
   "author": {
     "name": "Bitwarden",

@@ -5,6 +5,22 @@ All notable changes to the `bitwarden-architect` plugin will be documented in th
 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).
 
+## [1.1.0] - 2026-04-17
+
+### Added
+
+- `creating-implementation-plan` skill — produces a structured implementation plan artifact (`${CLAUDE_PLUGIN_DATA}/plans/{slug}-IMPLEMENTATION-PLAN.md`) with per-section guidance. Discovers per-repo planning skills in `<repo>/.claude/skills/` and defers to them when present; otherwise uses a default template (Current State → Blast Radius → Design → Phases → Risks & Open Questions).
+- `creating-work-breakdown` skill — decomposes an implementation plan into ticket-ready tasks with file touchpoints, dependency ordering, and observable acceptance criteria. Pairs by slug with the corresponding plan; accepts an optional output filename and otherwise defaults to `{slug}-WORK-BREAKDOWN.md`.
+- `when_to_use` and `argument-hints` frontmatter fields on architect skills for clearer trigger contexts and input expectations (Jira ticket, Confluence URL, plain-text feature description).
+- Named companion-skill pointers in `architecting-solutions` (threat-modeling, reviewing-security-architecture, writing-server-code, writing-client-code, writing-database-queries, implementing-dapper-queries, implementing-ef-core).
+- `creating-implementation-plan` and `creating-work-breakdown` registered in the architect agent's `skills:` frontmatter so all three architect skills are discoverable.
+
+### Changed
+
+- `architecting-solutions` scope narrowed to pure architectural thinking (principles, security mindset, judgment, red flags). Deliverable template, Work Breakdown Document, and Architecture Review sections moved out — plan production lives in `creating-implementation-plan`; work breakdown lives in `creating-work-breakdown`; security architecture review routes to `bitwarden-security-engineer:reviewing-security-architecture`.
+- Threat-modeling reference now names `bitwarden-security-engineer:threat-modeling` directly instead of hand-waving at "a dedicated threat-modeling skill".
+- README refreshed: Skills table lists all three architect skills; Deliverables section reflects the two artifacts the plugin produces (Implementation Plan + Work Breakdown Document).
+
 ## [1.0.0] - 2026-04-16
 
 ### Added

@@ -12,9 +12,11 @@ Software architecture planning for Bitwarden repositories. Generic AI assistance
 
 ## Skills
 
-| Skill                    | What It Does                                                                                                                         |
-| ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------ |
-| `architecting-solutions` | Principal engineer perspective on architecture decisions. Provides the architectural judgment framework applied across all planning. |
+| Skill                         | What It Does                                                                                                                         |
+| ----------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ |
+| `architecting-solutions`      | Principal engineer perspective on architecture decisions. Provides the architectural judgment framework applied across all planning. |
+| `creating-implementation-plan`| Produces a structured implementation plan artifact from architectural decisions. Discovers per-repo planning skills when present.    |
+| `creating-work-breakdown`     | Decomposes an implementation plan's phases into ticket-ready tasks with file touchpoints, dependencies, and acceptance criteria.     |
 
 ## Cross-Plugin Integration
 
@@ -49,6 +51,19 @@ Review the architecture of [feature area] and suggest improvements
 Assess the blast radius of adding [capability] to [service]
 ```
 
+## How It Works
+
+1. **Context Discovery**: Reads the repo's CLAUDE.md to learn architecture constraints, security rules, and available skills
+2. **Skill Invocation**: Finds and invokes the repo's planning skill (e.g., `planning-android-implementation`, `planning-ios-implementation`) for platform-specific guidance
+3. **Gap Analysis**: Evaluates technical gaps (security, SDK, extensions, data migration, performance)
+4. **Codebase Exploration**: Deploys sub-agents to find existing patterns and similar implementations
+5. **Plan Production**: Outputs a standardized Implementation Plan with phased tasks, file manifest, and risk assessment
+
+## Deliverables
+
+- **Implementation Plan** (`{slug}-IMPLEMENTATION-PLAN.md`) — Architecture design, phased task breakdown, file manifest, risk assessment (produced by `creating-implementation-plan`)
+- **Work Breakdown Document** (`{slug}-WORK-BREAKDOWN.md`) — Ticket-ready tasks with file touchpoints, dependencies, and acceptance criteria (produced by `creating-work-breakdown`)
+
 ## References
 
 - [Bitwarden Security Definitions](https://contributing.bitwarden.com/architecture/security/definitions)

@@ -5,6 +5,8 @@ model: opus
 tools: Read, Write, Glob, Grep, Skill
 skills:
   - architecting-solutions
+  - creating-implementation-plan
+  - creating-work-breakdown
 color: cyan
 ---
 
@@ -17,6 +19,16 @@ Before proposing anything, orient yourself:
 - **Read the repo's CLAUDE.md** — learn architecture constraints, security rules, code organization, and available platform-specific skills
 - **Explore the codebase** — find existing implementations of similar features, relevant services, and reusable patterns before designing anything new
 
+## Workflow
+
+The three skills listed in frontmatter are already loaded into your context. Apply their guidance in this order — each step produces input for the next. Stop between steps when the human should review or redirect.
+
+1. **Think** — follow `architecting-solutions` to reason through the design: security posture, blast radius, trade-offs, red flags. This step produces architectural decisions, not documents. Reach for cross-plugin skills here (threat-modeling, security-context, writing-server-code, etc.) via the `Skill` tool as the problem demands.
+2. **Plan** — once the design is settled, follow `creating-implementation-plan` to produce the `{slug}-IMPLEMENTATION-PLAN.md` artifact. Skip this step if the human only wants a review or a decision — not every engagement ends in a plan.
+3. **Break down** — when the human is ready to hand phases to implementers, follow `creating-work-breakdown` to decompose the plan into ticket-ready tasks in `{slug}-WORK-BREAKDOWN.md`. Skip this step if the plan is for internal reasoning only.
+
+Default to stopping after step 1 unless the human explicitly asked for a plan or tickets. The flow is additive — never move to a downstream step without the upstream thinking in hand.
+
 ## Cross-Plugin Integration
 
 All cross-plugin skills are required. If unavailable, **STOP** and alert the human that they must be installed.

@@ -1,13 +1,15 @@
 ---
 name: architecting-solutions
-description: Principal engineer perspective on architecture, system design, architecture reviews, blast radius assessment, trade-off analysis, and decision-making. Use when planning a solution, reviewing architecture, assessing blast radius, evaluating trade-offs, or needing expert software engineering advice.
+description: Principal engineer perspective on architecture, system design, blast radius assessment, trade-off analysis, and design decisions. Produces architectural thinking, not artifacts — pair with `bitwarden-architect:creating-implementation-plan` when a plan document is required.
+when_to_use: Reasoning about architecture for a Jira ticket, spec, or feature description, Reviewing an architecture proposal, Assessing blast radius before a change, Evaluating trade-offs between competing approaches, Needing expert software engineering judgment on a non-trivial design decision
+argument-hints: Jira ticket key (e.g., PM-XXXX), Confluence page URL or document, Plain-text feature description, Existing architecture proposal to review
 ---
 
 ## Security Mindset
 
 Bitwarden is a password manager — security isn't a feature, it's the product. Every design decision is a security decision.
 
-- **Threat model early.** Before approving an approach, ask: what can an attacker reach from here? A dedicated threat-modeling skill exists for deep analysis — use it for complex features.
+- **Threat model early.** Before approving an approach, ask: what can an attacker reach from here? Invoke `bitwarden-security-engineer:threat-modeling` for new trust boundaries, new PII/secret classes, or anything touching crypto.
 - **Classify data touch points.** Know which fields are encrypted, which are plaintext, and which cross trust boundaries. Never add a new path for sensitive data without encryption at rest and in transit.
 - **Audit trail by default.** Sensitive operations must be observable after the fact. If it can't be audited, it shouldn't ship.
 - **Fail closed.** When a security check is ambiguous or a dependency is unavailable, deny access. Never default to permissive.
@@ -45,3 +47,12 @@ Bitwarden is a password manager — security isn't a feature, it's the product.
 - Missing test coverage for new code paths
 - Security shortcuts in the name of velocity
 - Refactors bundled with feature work without explicit scope approval
+
+## Composition
+
+This skill answers *what to worry about*. Reach for adjacent skills via the `Skill` tool when the work crosses their domain:
+
+- `bitwarden-architect:creating-implementation-plan` — when the output needs to be a structured plan document ready for implementer handoff.
+- `bitwarden-security-engineer:threat-modeling` — new trust boundaries, new PII/secret classes, crypto changes.
+- `bitwarden-security-engineer:reviewing-security-architecture` — authentication, authorization, encryption design review.
+- `bitwarden-software-engineer:writing-server-code`, `bitwarden-software-engineer:writing-client-code`, `bitwarden-software-engineer:writing-database-queries`, `bitwarden-software-engineer:implementing-dapper-queries`, `bitwarden-software-engineer:implementing-ef-core` — language and repo conventions for the target stack.
@@ -0,0 +1,41 @@
+---
+name: creating-implementation-plan
+description: This skill should be used when the user asks to "create an implementation plan", "produce a plan for PM-XXXX", "write an implementation plan", "break this feature into phases", or otherwise requests a structured plan artifact ready for handoff to an implementer. Produces a markdown plan with pattern anchors, blast radius, phased task breakdown, risks, and open questions.
+when_to_use: Use after `bitwarden-architect:architecting-solutions`, or when a solution has already been identified and needs to be planned. Architectural decisions are made and a structured plan artifact is required, Handoff to an implementer is imminent, Converting a refined spec into a phased engineering plan
+argument-hints: Jira ticket key (e.g., PM-XXXX), Architectural decisions or design notes from prior reasoning, Target repository slug (server, clients, sdk-internal, android, etc.), Confluence page URL or plain-text feature description
+---
+
+## Scope
+
+This skill produces one artifact: an implementation plan at `${CLAUDE_PLUGIN_DATA}/plans/{slug}-IMPLEMENTATION-PLAN.md`. Derive the slug from ticket + target (e.g., `pm-32009-new-item-types-server`). Create the output directory if needed.
+
+It does not do architectural thinking. If the design has not yet been reasoned through — principles, blast radius, trade-offs — invoke `bitwarden-architect:architecting-solutions` first and carry its conclusions into the plan.
+
+## Per-Repo Planning Skills Take Precedence
+
+Before using the default template, look in `<repo>/.claude/skills/` for a planning-related skill. If one exists, defer the artifact shape to it — invoke via the `Skill` tool if available, otherwise read the `SKILL.md` directly. Per-repo planning skills own platform-specific phase conventions, test commands, and definition-of-done.
+
+## Default Template
+
+```markdown
+# Implementation Plan: [Feature Name]
+
+## Current State
+What's already shipped (verify against the working tree, not the ticket). Pattern anchors with `file:line`.
+
+## Blast Radius
+Affected modules — Primary / Secondary / No-change-verified.
+
+## Design
+Type model, interfaces, data flow.
+
+## Phases
+Dependency-ordered, each one PR. Per phase: tasks, files, acceptance.
+
+## Risks & Open Questions
+Likelihood × impact + mitigation. Tech debt surfaced (don't silently fix). Questions for the human (don't invent answers).
+```
+
+## Downstream Handoff
+
+When phases are ready to become tickets, invoke `bitwarden-architect:creating-work-breakdown`.
@@ -0,0 +1,42 @@
+---
+name: creating-work-breakdown
+description: This skill should be used when the user asks to "break this plan into tickets", "create a work breakdown", "generate Jira tasks from the plan", "prepare tickets for this feature", or otherwise requests a ticket-ready decomposition of an implementation plan. Converts an implementation plan's phases into discrete, dependency-ordered tasks with file touchpoints and acceptance criteria.
+when_to_use: Use after `bitwarden-architect:creating-implementation-plan`, or when an implementation plan already exists and needs to be split into tickets. Preparing work for sprint planning or Jira import, Handing phases off to multiple implementers, Capturing dependencies between tasks explicitly
+argument-hints: Path to an existing implementation plan (e.g., ${CLAUDE_PLUGIN_DATA}/plans/pm-32009-new-item-types-server-IMPLEMENTATION-PLAN.md), Jira epic or parent ticket key, Target repository slug, Optional output filename (defaults to {slug}-WORK-BREAKDOWN.md)
+---
+
+## Scope
+
+This skill produces one artifact: a work-breakdown document under `${CLAUDE_PLUGIN_DATA}/plans/`. If the user supplies an output filename, use it verbatim. Otherwise default to `{slug}-WORK-BREAKDOWN.md`, reusing the same slug as the corresponding implementation plan so the two files pair up.
+
+It does not do implementation planning. If no plan exists yet, invoke `bitwarden-architect:creating-implementation-plan` first.
+
+## Template
+
+```markdown
+# Work Breakdown: [Feature Name]
+
+**Plan:** `{slug}-IMPLEMENTATION-PLAN.md`
+**Parent ticket:** [Jira epic or parent, if known]
+
+## Task: [Short imperative title]
+**Phase:** [Phase N from the plan]
+**Files:** [paths that this task touches]
+**Depends on:** [task titles or "none"]
+**Acceptance:**
+- [ ] [observable, verifiable criterion]
+- [ ] [another criterion]
+**Notes:** [optional — non-obvious context, risks surfaced during decomposition]
+
+## Task: [next]
+...
+```
+
+## Decomposition Rules
+
+- **One task, one PR.** If a task is too large to review in a single PR, split it.
+- **Order by dependency.** A task that depends on another must come later in the list. Make the dependency explicit in the `Depends on` field.
+- **Every task cites files.** "Updates the thing" is not a task. "Updates `src/Foo/Bar.cs:42` and its tests" is.
+- **Acceptance criteria are observable.** Prefer "unit test X passes", "endpoint Y returns 200", "flag Z toggles feature" over "works correctly".
+- **Preserve the plan's phase boundaries.** A task belongs to exactly one phase. If decomposition reveals a phase that should split, flag it as a plan-level issue rather than papering over it here.
+- **Inherit risks from the plan.** Do not re-enumerate plan-level risks per task. If a risk is task-specific (e.g., "depends on external SDK release"), note it in `Notes`.
@@ -0,0 +1,12 @@
+{
+  "name": "bitwarden-delivery-tools",
+  "version": "1.0.0",
+  "description": "Generic delivery workflow skills for committing, PR creation, preflight checks, and change labeling across any Bitwarden repository.",
+  "author": {
+    "name": "Bitwarden",
+    "url": "https://github.com/bitwarden"
+  },
+  "homepage": "https://github.com/bitwarden/ai-marketplace/tree/main/plugins/bitwarden-delivery-tools",
+  "repository": "https://github.com/bitwarden/ai-marketplace",
+  "keywords": ["delivery", "commit", "pull-request", "preflight", "labeling"]
+}
@@ -0,0 +1,16 @@
+# Changelog
+
+All notable changes to the `bitwarden-delivery-tools` plugin will be documented in this file.
+
+The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
+and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
+
+## [1.0.0] - 2026-04-08
+
+### Added
+
+- Generic `committing-changes` skill for commit message format and staging workflow
+- Generic `creating-pull-request` skill for PR creation and draft workflow
+- Generic `labeling-changes` skill for conventional commit type keywords and label mapping
+- Generic `perform-preflight` skill for pre-commit quality gate checklist
+- All skills are platform-agnostic and reference the repo's CLAUDE.md for platform-specific details