Skip to content
Draft
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 5 additions & 5 deletions .claude-plugin/marketplace.json
Original file line number Diff line number Diff line change
Expand Up @@ -24,7 +24,7 @@
{
"name": "bitwarden-code-review",
"source": "./plugins/bitwarden-code-review",
"version": "1.13.0",
"version": "1.14.0",
"description": "Comprehensive code review system with organization-wide standards."
},
{
Expand All @@ -36,13 +36,13 @@
{
"name": "bitwarden-product-analyst",
"source": "./plugins/bitwarden-product-analyst",
"version": "0.1.5",
"version": "0.2.0",
"description": "Product analyst agent for creating comprehensive Bitwarden requirements documents from multiple sources"
},
{
"name": "bitwarden-software-engineer",
"source": "./plugins/bitwarden-software-engineer",
"version": "1.0.0",
"version": "1.1.0",
"description": "Software engineer agent for a Bitwarden product team. Implements stories, tasks, and bugs in the team's domain with code quality, performance, and security in mind. Participates in refinement, reviews PRs, collaborates with QA, and follows Git conventions."
},
{
Expand All @@ -66,7 +66,7 @@
{
"name": "bitwarden-tech-lead",
"source": "./plugins/bitwarden-tech-lead",
"version": "2.3.2",
"version": "2.4.0",
"description": "Tech lead agent for a Bitwarden product team. The team's primary technical resource β€” architects solutions in the team's domain, partners with the EM on scoping and backlog, partners with peer tech leads on cross-team architecture, and serves as the team's conduit for cross-team technical decisions."
},
{
Expand All @@ -78,7 +78,7 @@
{
"name": "bitwarden-delivery-tools",
"source": "./plugins/bitwarden-delivery-tools",
"version": "2.0.0",
"version": "2.1.0",
"description": "Delivery lifecycle skills for Bitwarden initiatives β€” initiative funnel navigation, work transitions, tech breakdowns and task decomposition, commits, pull requests, preflight checks, and change labeling."
},
{
Expand Down
10 changes: 5 additions & 5 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -6,18 +6,18 @@ A curated collection of plugins for AI-assisted development at Bitwarden. Enable

| Plugin | Version | Description |
| ------------------------------------------------------------------- | ------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- |
| [bitwarden-tech-lead](plugins/bitwarden-tech-lead/) | 2.3.2 | Tech lead for technical planning, architecture coherence, and surfacing patterns to Technical Strategy Ideas |
| [bitwarden-tech-lead](plugins/bitwarden-tech-lead/) | 2.4.0 | Tech lead for technical planning, architecture coherence, and surfacing patterns to Technical Strategy Ideas |
| [bitwarden-shepherd](plugins/bitwarden-shepherd/) | 1.0.0 | Champion of a technical strategy β€” shepherds a TSI through evaluation into the funnel, then through to adoption |
| [bitwarden-atlassian-tools](plugins/bitwarden-atlassian-tools/) | 2.2.7 | Read-only Atlassian access via MCP server with deep Jira issue research skill |
| [bitwarden-code-review](plugins/bitwarden-code-review/) | 1.13.0 | Autonomous code review agent following Bitwarden engineering standards with GitHub integration |
| [bitwarden-delivery-tools](plugins/bitwarden-delivery-tools/) | 2.0.0 | Delivery lifecycle skills: initiative funnel navigation, work transitions, tech breakdowns and task decomposition, commits, PRs, preflight, labeling |
| [bitwarden-code-review](plugins/bitwarden-code-review/) | 1.14.0 | Autonomous code review agent following Bitwarden engineering standards with GitHub integration |
| [bitwarden-delivery-tools](plugins/bitwarden-delivery-tools/) | 2.1.0 | Delivery lifecycle skills: initiative funnel navigation, work transitions, tech breakdowns and task decomposition, commits, PRs, preflight, labeling |
| [bitwarden-designer](plugins/bitwarden-designer/) | 0.1.0 | Product designer persona: Code of Conduct and 30/60/90 critique, critique facilitation; dispatches into bitwarden-design-tools |
| [bitwarden-design-tools](plugins/bitwarden-design-tools/) | 0.1.0 | Design toolkit: content style guide, Figma Dev Mode MCP, Bitwarden brand application, handoff prep, Design System governance, Product and Design Jira |
| [bitwarden-devops-engineer](plugins/bitwarden-devops-engineer/) | 0.1.3 | DevOps engineering assistant: workflow compliance linting, action security auditing, and org-wide CI/CD remediation |
| [bitwarden-init](plugins/bitwarden-init/) | 1.2.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-product-analyst](plugins/bitwarden-product-analyst/) | 0.2.0 | Product analyst agent for creating comprehensive Bitwarden requirements documents from multiple sources |
| [bitwarden-security-engineer](plugins/bitwarden-security-engineer/) | 1.2.0 | Application security engineering: vulnerability triage, threat modeling, and secure code analysis |
| [bitwarden-software-engineer](plugins/bitwarden-software-engineer/) | 1.0.0 | Software engineer agent for a Bitwarden product team. Implements stories, tasks, and bugs with code quality, performance, security, and team comms in mind. |
| [bitwarden-software-engineer](plugins/bitwarden-software-engineer/) | 1.1.0 | Software engineer agent for a Bitwarden product team. Implements stories, tasks, and bugs with code quality, performance, security, and team comms in mind. |
| [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 |

Expand Down
2 changes: 1 addition & 1 deletion plugins/bitwarden-code-review/.claude-plugin/plugin.json
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
{
"name": "bitwarden-code-review",
"version": "1.13.0",
"version": "1.14.0",
"description": "Comprehensive code review system with organization-wide standards.",
"author": {
"name": "Bitwarden",
Expand Down
6 changes: 6 additions & 0 deletions plugins/bitwarden-code-review/CHANGELOG.md
Original file line number Diff line number Diff line change
Expand Up @@ -5,6 +5,12 @@ All notable changes to the Bitwarden Code Review Plugin will be documented in th
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.14.0] - 2026-06-29

### Added

- `performing-multi-agent-code-review`: optional "Behavioral-Spec Drift (Allium)" section. When the repo under review carries an [Allium](https://github.com/juxt/allium) `.allium` spec and the Allium plugin is installed, the reviewer may invoke its `/weed` drift check before Step 2 and pass surfaced divergence to the architecture & pattern-compliance agent as additional context. Additive and optional β€” it does not alter the numbered pipeline, and is skipped entirely when no `.allium` spec is present. Allium is a third-party, MIT-licensed tool, not a Bitwarden plugin.

## [1.13.0] - 2026-06-23

### Added
Expand Down
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
---
name: bitwarden-code-reviewer
version: 1.13.0
version: 1.14.0
description: Conducts thorough code reviews following Bitwarden standards. Finds all issues first pass, avoids false positives, respects codebase conventions. Invoke when user mentions "code review", "review code", "review", "PR", or "pull request".
model: opus
skills: avoiding-false-positives, classifying-review-findings, posting-bitwarden-review-comments, posting-review-summary, reviewing-dependency-changes
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -58,6 +58,10 @@ Applies to all agents and subagents.
- Don't write to GitHub. All findings go to a local markdown file.
- Tool discipline (see Orchestration β†’ Tool Discipline) applies to the main agent and is propagated verbatim to every subagent. Rationale for the WebFetch/WebSearch ban: bypasses `gh` auth, skips audit trails, can return stale cached pages.

## Optional: Behavioral-Spec Drift (Allium)

When the repo under review carries an [Allium](https://github.com/juxt/allium) `.allium` specification β€” a third-party, MIT-licensed behavioral spec language β€” spec↔code divergence is a useful review input. This is optional and additive; it does **not** alter the numbered pipeline below. When a spec is present and the Allium plugin is installed, you may invoke its `/weed` drift check before Step 2 and pass any surfaced divergence to the architecture & pattern-compliance agent as additional context β€” a diff that violates a stated `ensures` rule is an architectural finding. Absent a `.allium` spec, skip this entirely; it is not a prerequisite and the pipeline runs unchanged.

## Orchestration

### Project Preamble Propagation
Expand Down
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
{
"name": "bitwarden-delivery-tools",
"version": "2.0.0",
"version": "2.1.0",
"description": "Delivery lifecycle skills for Bitwarden initiatives β€” initiative funnel navigation, work transitions, tech breakdowns and task decomposition, commits, pull requests, preflight checks, and change labeling.",
"author": {
"name": "Bitwarden",
Expand Down
6 changes: 6 additions & 0 deletions plugins/bitwarden-delivery-tools/CHANGELOG.md
Original file line number Diff line number Diff line change
Expand Up @@ -5,6 +5,12 @@ All notable changes to the `bitwarden-delivery-tools` plugin will be documented
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).

## [2.1.0] - 2026-06-29

### Added

- `developing-breakdown-spec`: optional "seed a behavioral spec" note in Phase 3. When the affected product repo maintains (or the team wants to adopt) an [Allium](https://github.com/juxt/allium) `.allium` specification, the WHAT captured in the Specification can be carried into it as `when / requires / ensures` rules. External and optional; the Specification section stays the source of truth, and the `.allium` spec is authored in the product repo, not in `tech-breakdowns`.

## [2.0.0] - 2026-06-19

### Added
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -76,6 +76,8 @@ Capture in the Specification section:
- **Why** β€” the problem being solved; cite the source (PRD section, Jira issue, Clarifications Log entry).
- **Link the PRD or Architecture Plan; do not paste.** Pasted content drifts the moment the source moves.

**Optional β€” seed a behavioral spec.** If the affected product repo maintains (or the team wants to adopt) an [Allium](https://github.com/juxt/allium) `.allium` specification β€” a third-party, MIT-licensed behavioral spec language β€” the WHAT captured here can be carried into it as `when / requires / ensures` rules so intent survives into implementation and test generation. This is external and optional; the Specification section stays the source of truth. The `.allium` spec is authored in the product repo, not in `tech-breakdowns` β€” note the intent here and leave the authoring to implementation time.

### Phase 4: Spec Alternatives

Surface the question explicitly: is there a smaller change that delivers most of the value? The point isn't to find a smaller version; it's to make the scope decision visible. Capture each alternative considered with its rejection reason.
Expand Down
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
{
"name": "bitwarden-product-analyst",
"version": "0.1.5",
"version": "0.2.0",
"description": "Product analyst agent for creating comprehensive Bitwarden requirements documents from multiple sources",
"author": {
"name": "Bitwarden",
Expand Down
6 changes: 6 additions & 0 deletions plugins/bitwarden-product-analyst/CHANGELOG.md
Original file line number Diff line number Diff line change
Expand Up @@ -5,6 +5,12 @@ All notable changes to the Bitwarden Product Analyst plugin will be documented i
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).

## [0.2.0] - 2026-06-29

### Added

- `requirements-elicitation`: optional "Capture a Behavioral Specification (Allium)" section. When the working product repo maintains an [Allium](https://github.com/juxt/allium) `.allium` behavioral spec, extracted functional requirements and P01–P06 security requirements can be carried into it as `when / requires / ensures` rules via `/elicit` and `/distill`. External and optional β€” Allium is a third-party, MIT-licensed tool, not a Bitwarden plugin; this document remains the source of truth.

## [0.1.5] - 2026-04-03

### Changed
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -72,6 +72,15 @@ Always consider and document:
- **Cross-platform** β€” Works on all Bitwarden clients?
- **Backwards compatibility** β€” Maintains existing behavior?

## Optional: Capture a Behavioral Specification (Allium)

When you are working in a product repo that maintains a behavioral specification with [Allium](https://github.com/juxt/allium) β€” a third-party, MIT-licensed spec language that keeps a `.allium` file beside the code β€” the requirements you extract here have a natural downstream home:

- Functional requirements and their acceptance criteria map onto Allium rules: `when` an event occurs, `requires` these preconditions hold, `ensures` these outcomes follow. Use `/elicit` to carry an agreed requirement into the spec through conversation; use `/distill` to recover the spec already implied by existing code.
- Security requirements grounded in P01–P06 β€” zero-knowledge, data-state, and access-control guarantees β€” can be expressed as Allium invariants, so they persist across sessions instead of living only in this document.

This is external and optional: Allium is not a Bitwarden tool, and it applies only when the working repo has adopted it. This document stays the source of truth for the WHAT and WHY; a `.allium` spec is a complementary, machine-checkable artifact.

## Example

See `examples/export-functionality.md` for a complete worked example.
Expand Down
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
{
"name": "bitwarden-software-engineer",
"version": "1.0.0",
"version": "1.1.0",
"description": "Software engineer agent for a Bitwarden product team. Implements stories, tasks, and bugs in the team's domain with code quality, performance, and security in mind. Participates in refinement, reviews PRs, collaborates with QA, and follows Git conventions.",
"author": {
"name": "Bitwarden",
Expand Down
6 changes: 6 additions & 0 deletions plugins/bitwarden-software-engineer/CHANGELOG.md
Original file line number Diff line number Diff line change
Expand Up @@ -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).

## [1.1.0] - 2026-06-29

### Added

- `AGENT.md`: optional "External Spec Tooling" section. When implementing against an [Allium](https://github.com/juxt/allium) `.allium` behavioral spec, the agent can `/distill` the spec implied by existing code before changing it, `/propagate` tests from the rules, `/weed` to surface spec↔code divergence before declaring done, and `/tend` for targeted spec edits. External and optional β€” Allium is a third-party, MIT-licensed tool, not a Bitwarden plugin; skipped entirely absent a `.allium` file.

## [1.0.0] - 2026-05-19

### Changed
Expand Down
13 changes: 13 additions & 0 deletions plugins/bitwarden-software-engineer/agents/AGENT.md
Original file line number Diff line number Diff line change
Expand Up @@ -71,3 +71,16 @@ These skills are available across plugins and agent-neutral by design β€” invoke
- `Skill(analyzing-code-security)` when handling user input that reaches SQL, HTML, the file system, or URLs.
- `Skill(reviewing-dependencies)` when adding or updating dependencies.
- `Skill(detecting-secrets)` when working with secrets or configuration.

## External Spec Tooling (Optional)

Some repos maintain a behavioral specification with [Allium](https://github.com/juxt/allium) β€” a third-party, MIT-licensed spec language that keeps a `.allium` file beside the code describing intent as `when` an event occurs, `requires` preconditions, `ensures` outcomes. It is **not** a Bitwarden plugin; use it only where your team has adopted it and the repo actually carries a `.allium` file.

When implementing against an Allium spec:

- `/distill` β€” recover the spec implied by existing code before you change it, so you implement against intent rather than guessing it.
- `/propagate` β€” generate tests from the behavioral rules, complementing (not replacing) the repo's own testing discipline.
- `/weed` β€” surface divergence between the spec and your changes before you declare done.
- `/tend` β€” make a targeted spec edit when intent legitimately changes (surface that as scope drift first, per the working approach above).

Absent a `.allium` file, skip this β€” it is not a prerequisite for any work.
2 changes: 1 addition & 1 deletion plugins/bitwarden-tech-lead/.claude-plugin/plugin.json
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
{
"name": "bitwarden-tech-lead",
"version": "2.3.2",
"version": "2.4.0",
"description": "Tech lead agent for a Bitwarden product team. The team's primary technical resource β€” architects solutions in the team's domain, partners with the EM on scoping and backlog, partners with peer tech leads on cross-team architecture, and serves as the team's conduit for cross-team technical decisions.",
"author": {
"name": "Bitwarden",
Expand Down
6 changes: 6 additions & 0 deletions plugins/bitwarden-tech-lead/CHANGELOG.md
Original file line number Diff line number Diff line change
Expand Up @@ -5,6 +5,12 @@ All notable changes to the `bitwarden-tech-lead` 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).

## [2.4.0] - 2026-06-29

### Added

- `architecting-solutions`: optional "Behavioral Specifications (Allium)" section. For features with a rich behavioral contract or cross-client invariants, a persistent [Allium](https://github.com/juxt/allium) `.allium` spec can keep intent legible across sessions and flag spec↔code drift (`/weed`). Explicitly scoped as narrower at the architecture-judgment layer than at requirements or implementation time. External and optional β€” third-party, MIT-licensed, not a Bitwarden plugin.

## [2.3.2] - 2026-06-15

### Changed
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -74,6 +74,12 @@ Two failure modes to avoid:

`Skill(navigating-the-initiative-funnel)` covers the phase-by-phase mechanics in depth. This section is the working principle.

## Optional: Behavioral Specifications (Allium)

For a feature with a rich behavioral contract β€” many state transitions, or invariants that must hold identically across web, browser, desktop, CLI, and self-hosted β€” a persistent specification keeps intent legible across sessions better than prose. [Allium](https://github.com/juxt/allium) (third-party, MIT-licensed) maintains a `.allium` spec beside the code in `when / requires / ensures` form and can flag spec↔code drift (`/weed`).

Applicability is narrower at the architecture-judgment layer than at requirements or implementation time β€” reach for it when the behavioral surface is genuinely complex, not for routine changes. External and optional; relevant only when the repo has adopted it.

## Red Flags to Surface

- Over-engineering for hypothetical requirements (YAGNI)
Expand Down
Loading