diff --git a/.claude-plugin/marketplace.json b/.claude-plugin/marketplace.json index f72f7374..34b713c6 100644 --- a/.claude-plugin/marketplace.json +++ b/.claude-plugin/marketplace.json @@ -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." } ] } diff --git a/README.md b/README.md index 1922b9ce..f1764862 100644 --- a/README.md +++ b/README.md @@ -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 | diff --git a/plugins/bitwarden-architect/.claude-plugin/plugin.json b/plugins/bitwarden-architect/.claude-plugin/plugin.json index 26924cf4..cd922ae4 100644 --- a/plugins/bitwarden-architect/.claude-plugin/plugin.json +++ b/plugins/bitwarden-architect/.claude-plugin/plugin.json @@ -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", diff --git a/plugins/bitwarden-architect/CHANGELOG.md b/plugins/bitwarden-architect/CHANGELOG.md index 21fc5a7c..96bbaa4b 100644 --- a/plugins/bitwarden-architect/CHANGELOG.md +++ b/plugins/bitwarden-architect/CHANGELOG.md @@ -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 `/.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 diff --git a/plugins/bitwarden-architect/README.md b/plugins/bitwarden-architect/README.md index df660200..30b962dc 100644 --- a/plugins/bitwarden-architect/README.md +++ b/plugins/bitwarden-architect/README.md @@ -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) diff --git a/plugins/bitwarden-architect/agents/AGENT.md b/plugins/bitwarden-architect/agents/AGENT.md index 1804cc62..1dcab92d 100644 --- a/plugins/bitwarden-architect/agents/AGENT.md +++ b/plugins/bitwarden-architect/agents/AGENT.md @@ -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. diff --git a/plugins/bitwarden-architect/skills/architecting-solutions/SKILL.md b/plugins/bitwarden-architect/skills/architecting-solutions/SKILL.md index 734126ed..8608967a 100644 --- a/plugins/bitwarden-architect/skills/architecting-solutions/SKILL.md +++ b/plugins/bitwarden-architect/skills/architecting-solutions/SKILL.md @@ -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. diff --git a/plugins/bitwarden-architect/skills/creating-implementation-plan/SKILL.md b/plugins/bitwarden-architect/skills/creating-implementation-plan/SKILL.md new file mode 100644 index 00000000..440cc39c --- /dev/null +++ b/plugins/bitwarden-architect/skills/creating-implementation-plan/SKILL.md @@ -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 `/.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`. diff --git a/plugins/bitwarden-architect/skills/creating-work-breakdown/SKILL.md b/plugins/bitwarden-architect/skills/creating-work-breakdown/SKILL.md new file mode 100644 index 00000000..811fee72 --- /dev/null +++ b/plugins/bitwarden-architect/skills/creating-work-breakdown/SKILL.md @@ -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`. diff --git a/plugins/bitwarden-delivery-tools/.claude-plugin/plugin.json b/plugins/bitwarden-delivery-tools/.claude-plugin/plugin.json new file mode 100644 index 00000000..3d2913fb --- /dev/null +++ b/plugins/bitwarden-delivery-tools/.claude-plugin/plugin.json @@ -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"] +} diff --git a/plugins/bitwarden-delivery-tools/CHANGELOG.md b/plugins/bitwarden-delivery-tools/CHANGELOG.md new file mode 100644 index 00000000..3b982345 --- /dev/null +++ b/plugins/bitwarden-delivery-tools/CHANGELOG.md @@ -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 diff --git a/plugins/bitwarden-delivery-tools/README.md b/plugins/bitwarden-delivery-tools/README.md new file mode 100644 index 00000000..9c8d9b7c --- /dev/null +++ b/plugins/bitwarden-delivery-tools/README.md @@ -0,0 +1,24 @@ +# Bitwarden Delivery Tools + +Generic delivery workflow skills for committing, PR creation, preflight checks, and change labeling across any Bitwarden repository. + +## Overview + +These skills define the delivery **process** — commit formats, PR workflows, quality gates, and labeling conventions. Platform-specific details (build commands, lint tools, test runners) are discovered dynamically from each repo's CLAUDE.md. + +## Skills + +| Skill | Triggers | Purpose | +|-------|---------|---------| +| `committing-changes` | "commit", "stage changes" | Commit message format, staging best practices | +| `creating-pull-request` | "create PR", "open PR" | PR title/body format, draft workflow, AI review labels | +| `labeling-changes` | "label", "change type" | Conventional commit type keywords, CI label mapping | +| `perform-preflight` | "preflight", "self review" | Pre-commit quality gate checklist | + +## Design Principle + +Each skill owns the **workflow** (what steps to follow, what format to use). The repo's CLAUDE.md owns the **platform specifics** (which linter to run, which test command to use, which security rules apply). This separation allows the same skills to work across Android, iOS, Server, SDK, and Clients repos. + +## Installation + +Install via the Bitwarden AI Marketplace. diff --git a/plugins/bitwarden-delivery-tools/skills/committing-changes/SKILL.md b/plugins/bitwarden-delivery-tools/skills/committing-changes/SKILL.md new file mode 100644 index 00000000..12adaf84 --- /dev/null +++ b/plugins/bitwarden-delivery-tools/skills/committing-changes/SKILL.md @@ -0,0 +1,68 @@ +--- +name: committing-changes +description: Git commit conventions and workflow for Bitwarden repositories. Use when committing code, writing commit messages, or preparing changes for commit. Triggered by "commit", "git commit", "commit message", "prepare commit", "stage changes". +--- + +# Git Commit Conventions + +## Commit Message Format + +``` +[PM-XXXXX] : + + +``` + +### Rules + +1. **Ticket prefix**: Always include `[PM-XXXXX]` matching the Jira ticket +2. **Type keyword**: Select from the table below. The keyword drives automatic `t:` label assignment via CI (`.github/scripts/label-pr.py` reads `.github/label-pr.json`). CI matches `:` or `(` in the lowercased title. + +| Type | Label | Use for | +|------|-------|---------| +| `feat` | `t:feature` | New features or functionality | +| `fix` | `t:bug` | Bug fixes | +| `refactor` | `t:tech-debt` | Code restructuring without behavior change | +| `chore` | `t:tech-debt` | Maintenance, cleanup, minor tweaks | +| `test` | `t:tech-debt` | Adding or updating tests | +| `perf` | `t:tech-debt` | Performance improvements | +| `docs` | `t:docs` | Documentation changes | +| `ci` / `build` | `t:ci` | CI/CD and build system changes | +| `deps` | `t:deps` | Dependency updates | +| `llm` | `t:llm` | LLM/Claude configuration changes | +| `breaking` | `t:breaking-change` | Breaking changes requiring migration | +| `misc` | `t:misc` | Changes that do not fit other categories | + +CI also accepts aliases (e.g., `revert`, `bugfix`, `cleanup`). See `.github/label-pr.json` for the full mapping. **If the type cannot be confidently determined, ask the user.** + +### Examples + +``` +[PM-12345] feat: Add biometric unlock timeout configuration + +Users reported confusion about when biometric prompts appear. +This adds a configurable timeout setting to the security preferences. +``` + +Ambiguous cases — choosing between similar types: +``` +# Refactor that also fixes a bug? Use the primary intent: +[PM-12345] fix: Resolve null pointer in vault sync retry logic + +# Test-only change: +[PM-12345] test: Add unit tests for biometric timeout edge cases +``` + +### Followup Commits + +Only the first commit on a branch needs the full format (ticket prefix, type keyword, body). Subsequent commits can use a short, descriptive summary with no prefix or body required. + +``` +Update error handling in login flow +``` + +--- + +## Pre-Commit Quality Gate + +Before staging, run the `perform-preflight` skill for the full quality gate checklist (tests, lint, security, architecture). Consult the repo's CLAUDE.md for platform-specific build and lint commands. \ No newline at end of file diff --git a/plugins/bitwarden-delivery-tools/skills/creating-pull-request/SKILL.md b/plugins/bitwarden-delivery-tools/skills/creating-pull-request/SKILL.md new file mode 100644 index 00000000..6b746c89 --- /dev/null +++ b/plugins/bitwarden-delivery-tools/skills/creating-pull-request/SKILL.md @@ -0,0 +1,86 @@ +--- +name: creating-pull-request +description: Pull request creation workflow for Bitwarden repositories. Use when creating PRs, writing PR descriptions, or preparing branches for review. Triggered by "create PR", "pull request", "open PR", "gh pr create", "PR description". +--- + +# Create Pull Request + +## PR Title Format + +``` +[PM-XXXXX] : +``` + +**Type keywords** (triggers automatic `t:` label via CI): + +| Type | Label | Use for | +|------|-------|---------| +| `feat` | `t:feature` | New features or functionality | +| `fix` | `t:bug` | Bug fixes | +| `refactor` | `t:tech-debt` | Code restructuring without behavior change | +| `chore` | `t:tech-debt` | Maintenance, cleanup, minor tweaks | +| `test` | `t:tech-debt` | Adding or updating tests | +| `perf` | `t:tech-debt` | Performance improvements | +| `docs` | `t:docs` | Documentation changes | +| `ci` / `build` | `t:ci` | CI/CD and build system changes | +| `deps` | `t:deps` | Dependency updates | +| `llm` | `t:llm` | LLM/Claude configuration changes | +| `breaking` | `t:breaking-change` | Breaking changes requiring migration | +| `misc` | `t:misc` | Changes that do not fit other categories | + +**Examples:** +- `[PM-12345] feat: Add autofill support for passkeys` +- `[PM-12345] fix: Resolve crash during vault sync` +- `[PM-12345] refactor: Simplify authentication flow` + +--- + +## PR Body + +**Always follow the repo's PR template at `.github/PULL_REQUEST_TEMPLATE.md`.** Read it and fill in each section. If no template exists, use this fallback: + +```markdown +## Type of change + + +## Objective + + +## Code changes + + +## Before you submit +- [ ] Tests added/updated +- [ ] Lint/format passing +- [ ] Self-reviewed changes +``` + +Delete the Screenshots section entirely if there are no UI changes. + +--- + +## Creating the PR + +Before creating, run `perform-preflight` if not already done. + +```bash +git push -u origin +gh pr create --draft --title "[PM-XXXXX] feat: Short summary" --body "" +``` + +**Default to draft PRs.** Only create a non-draft PR if the user explicitly requests it. + +--- + +## AI Review Label + +Before running `gh pr create`, **always** use the `AskUserQuestion` tool to ask whether to add an AI review label: + +- **Question**: "Would you like to add an AI review label to this PR?" +- **Options**: `ai-review-vnext`, `ai-review`, `No label` + +If the user selects a label, include it via the `--label` flag: + +```bash +gh pr create --draft --label "ai-review-vnext" --title "..." --body "..." +``` \ No newline at end of file diff --git a/plugins/bitwarden-delivery-tools/skills/labeling-changes/SKILL.md b/plugins/bitwarden-delivery-tools/skills/labeling-changes/SKILL.md new file mode 100644 index 00000000..2227ac2f --- /dev/null +++ b/plugins/bitwarden-delivery-tools/skills/labeling-changes/SKILL.md @@ -0,0 +1,49 @@ +--- +name: labeling-changes +description: Conventional commit type keywords for PR titles and commit messages. Use when determining the change type for commits or PRs. Triggered by "what type", "label", "change type", "conventional commit", "t: label". +--- + +# Labeling Changes + +PR titles and commit messages must include a conventional commit type keyword. This keyword drives automatic `t:` label assignment via CI (`.github/scripts/label-pr.py` reads `.github/label-pr.json`). + +## Format + +The type keyword appears after the Jira ticket prefix: + +``` +[PM-XXXXX] : +``` + +## Type Keywords + +| Type | Label | Use for | +|------|-------|---------| +| `feat` | `t:feature` | New features or functionality | +| `fix` | `t:bug` | Bug fixes | +| `refactor` | `t:tech-debt` | Code restructuring without behavior change | +| `chore` | `t:tech-debt` | Maintenance, cleanup, minor tweaks | +| `test` | `t:tech-debt` | Adding or updating tests | +| `perf` | `t:tech-debt` | Performance improvements | +| `docs` | `t:docs` | Documentation changes | +| `ci` / `build` | `t:ci` | CI/CD and build system changes | +| `deps` | `t:deps` | Dependency updates | +| `llm` | `t:llm` | LLM/Claude configuration changes | +| `breaking` | `t:breaking-change` | Breaking changes requiring migration | +| `misc` | `t:misc` | Changes that do not fit other categories | + +## Selecting a Type + +Infer the type from the task description and changes made. **If the type cannot be confidently determined, ask the user.** + +The CI labeling script matches `:` or `(` in the lowercased PR title, so the keyword must be followed by a colon or parenthesis. CI also accepts additional aliases (e.g., `revert`, `bugfix`, `cleanup`). See `.github/label-pr.json` for the full mapping. + +### Examples + +Ambiguous cases where type selection is non-obvious: + +- Refactor that incidentally fixes a bug → use the **primary intent**: `fix:` if the bug was the goal, `refactor:` if the restructuring was the goal +- Adding tests for existing untested code → `test:` (not `chore:`) +- Updating a dependency to fix a vulnerability → `deps:` (not `fix:`) +- Changing Claude/LLM configuration files → `llm:` (not `chore:`) +- Removing dead code → `refactor:` (not `chore:` — it changes the codebase structure) \ No newline at end of file diff --git a/plugins/bitwarden-delivery-tools/skills/perform-preflight/SKILL.md b/plugins/bitwarden-delivery-tools/skills/perform-preflight/SKILL.md new file mode 100644 index 00000000..1501a66e --- /dev/null +++ b/plugins/bitwarden-delivery-tools/skills/perform-preflight/SKILL.md @@ -0,0 +1,36 @@ +--- +name: perform-preflight +description: Quality gate checklist to run before committing or creating a PR. Use when finishing implementation, checking work quality, or preparing to commit. Triggered by "preflight", "self review", "ready to commit", "check my work", "quality gate". +--- + +# Preflight Checklist + +Run this checklist before committing or creating a PR. Consult the repo's CLAUDE.md for platform-specific commands (test runner, linter, formatter). + +## Tests + +- [ ] Run tests for affected modules (consult CLAUDE.md for commands) +- [ ] New code has test coverage +- [ ] No existing tests broken + +## Code Quality + +- [ ] Lint and format pass (consult CLAUDE.md for commands) +- [ ] No TODO comments without Jira ticket references +- [ ] Public APIs documented per repo convention (KDoc, DocC, XML docs, etc.) + +## Bitwarden Security + +- [ ] Zero-knowledge architecture preserved — no unencrypted vault data logged, persisted, or transmitted +- [ ] Sensitive data uses platform-appropriate secure storage (consult CLAUDE.md Security Rules) +- [ ] No sensitive data in log statements + +## Architecture + +- [ ] Changes follow patterns in CLAUDE.md and architecture docs +- [ ] DI/injection and error handling follow repo convention +- [ ] String resources added to the correct location (if applicable) + +## On Failure + +If any check fails, fix the issue before proceeding. For test failures, diagnose the root cause rather than skipping. For lint/format failures, run the repo's auto-fix command if available. If a check cannot be resolved, flag it to the user with the specific failure output. \ No newline at end of file diff --git a/plugins/bitwarden-software-engineer/.claude-plugin/plugin.json b/plugins/bitwarden-software-engineer/.claude-plugin/plugin.json index 671295b5..293f93a8 100644 --- a/plugins/bitwarden-software-engineer/.claude-plugin/plugin.json +++ b/plugins/bitwarden-software-engineer/.claude-plugin/plugin.json @@ -1,6 +1,6 @@ { "name": "bitwarden-software-engineer", - "version": "0.3.3", + "version": "0.4.0", "description": "Comprehensive full-stack software engineering assistant proficient in modern software development at Bitwarden.", "author": { "name": "Bitwarden", diff --git a/plugins/bitwarden-software-engineer/agents/bitwarden-software-engineer.md b/plugins/bitwarden-software-engineer/agents/bitwarden-software-engineer.md index 0ed1ffad..e4c7aeb1 100644 --- a/plugins/bitwarden-software-engineer/agents/bitwarden-software-engineer.md +++ b/plugins/bitwarden-software-engineer/agents/bitwarden-software-engineer.md @@ -1,63 +1,78 @@ --- name: bitwarden-software-engineer -description: Full-stack software engineer specializing in C#, JavaScript, TypeScript, and SQL. Coordinates complex development tasks across languages. Use for feature implementation, and cross-language refactoring. +description: "Autonomously implements features, fixes bugs, and completes development tasks across any Bitwarden repository. Drives the full implementation lifecycle (implement, test, build, preflight, commit) with self-review at each phase. Use for end-to-end implementation, cross-language refactoring, or when planning output is ready for implementation." +version: 0.4.0 model: opus -tools: Read, Write, Edit, Bash, Glob, Grep -skills: - - writing-client-code - - writing-server-code - - writing-database-queries +tools: Bash, Read, Edit, Write, Glob, Grep, Agent, Skill color: blue --- -You are a senior full-stack software engineer with expertise across C#, JavaScript, TypeScript, and SQL. You're an engineer working with the team, not just executing commands. Focus intently on code quality **over** code quantity. You avoid over-engineering because you focus on what's needed, not what might be needed. +You are a senior software engineer working across Bitwarden's full stack. You autonomously drive implementation from start to finish, acting as both the implementer and the quality reviewer at each phase. -## Purpose +## Step 1: Context Discovery -Coordinate complex software development tasks that span multiple languages, architectural concerns, or require full-stack reasoning. +Before implementing, orient yourself in the target repository: -## Working Approach +1. **Read the repo's CLAUDE.md** to learn: + - Architecture constraints and key principles + - Security rules (especially zero-knowledge requirements) + - Code organization and module structure + - Available skills and commands from the **Skills & Commands** table -1. **Understand context:** Before creating or modifying code, read the relevant existing files to understand current patterns. Don't assume — verify. -2. **Clarify, don't invent.** If requirements are ambiguous or incomplete, ask the human rather than making assumptions. State what you're uncertain about. -3. **Stay in scope.** Implement what was asked. Don't add features, abstractions, or "nice-to-haves" that weren't requested. If you see an improvement opportunity, mention it — don't just build it. -4. **Build incrementally, validate continuously.** Start with core functionality, run tests, check for regressions, and confirm the implementation meets requirements before declaring done. +2. **Identify implementation skills** from the Skills & Commands table — look for skills matching triggers like "implement", "write code", "add screen", "create feature". **Use the `Skill` tool to invoke them by name.** Do NOT read the SKILL.md file directly. -## Skill Routing +3. **Identify the testing skill** — look for triggers like "write tests", "add test coverage", "unit test". Invoke it when writing tests. + +4. **Identify the build/verify skill** — look for triggers like "build", "run tests", "lint", "format". Invoke it for build and verification commands. -The architectural skills (`writing-client-code`, `writing-server-code`, `writing-database-queries`) are preloaded. For implementation tasks, activate the appropriate skill: +5. **Identify the implementation command** — look for a command matching "full workflow", "implement", "work on" (e.g., `/work-on-android`, `/work-on-ios`). If one exists, **use the `Skill` tool to invoke it** — it defines the phases and structures the entire implementation lifecycle. Let the command drive the phase sequence rather than manually orchestrating skills. -- **Dapper/stored procedure work** (creating SPs, MSSQL migrations, Dapper repository methods) → activate `implementing-dapper-queries` -- **EF Core work** (EF repositories, EF migrations, PostgreSQL/MySQL/SQLite) → activate `implementing-ef-core` -- **Both ORMs** (new repository interface that needs both implementations) → activate both implementation skills +6. **If no implementation command exists**: Drive the lifecycle manually using the skills you discovered. -## Verification +## Step 2: Implementation Lifecycle -After making changes, always verify your work before declaring done. Use the appropriate commands for the codebase you modified: +Whether driven by a command or manually, the lifecycle follows these phases: -### Server repo (C#/.NET) +1. **Implement** — Write code following repo patterns. Search the codebase for existing examples before inventing anything. +2. **Test** — Write tests covering happy path, error cases, and edge cases. +3. **Build & Verify** — Run the repo's build, test, and lint tools. Fix any failures. +4. **Preflight** — Use the `bitwarden-delivery-tools:perform-preflight` skill for quality gate checks. +5. **Commit** — Use the `bitwarden-delivery-tools:committing-changes` skill for commit format and staging. -- **Build:** `dotnet build` from the solution root -- **Unit tests:** `dotnet test` targeting the relevant test project (e.g., `test/Core.Test`) -- **Integration tests:** Run tests with `[DatabaseData]` attribute when database changes are involved +## Self-Review Protocol -### Client repo (Angular/TypeScript) +At each phase transition, evaluate your own output: + +``` +--- Phase Review: [Phase Name] --- +Status: APPROVED / NEEDS REFINEMENT +Findings: [brief assessment] +Action: [Proceeding to next phase / Iterating on: X] +--- +``` + +If status is NEEDS REFINEMENT, iterate up to 3 times before proceeding with the best available output and noting remaining concerns. + +## Skill Routing -- **Build:** `npm run build` in the relevant app directory (`apps/web`, `apps/browser`, etc.) -- **Lint:** `npm run lint` to catch style violations -- **Unit tests:** `npm run test` in the relevant library or app directory +All skills are discovered dynamically from the repo's CLAUDE.md Skills & Commands table and from installed marketplace plugins. For server-specific work, the following plugin skills are available: -### Database changes +- **Dapper/stored procedure work** → `Skill(implementing-dapper-queries)` +- **EF Core work** → `Skill(implementing-ef-core)` +- **Both ORMs** → invoke both implementation skills +- **Client code** → `Skill(writing-client-code)` +- **Server code** → `Skill(writing-server-code)` +- **Database queries** → `Skill(writing-database-queries)` -- Verify your changes against the conventions in the active database skill (`implementing-dapper-queries`, `implementing-ef-core`, or `writing-database-queries`) +For repos with local implementation skills (Android, iOS, SDK, etc.), discover and invoke them via the Skills & Commands table in CLAUDE.md. ## Security-Aware Development -When the `bitwarden-security-engineer` plugin is installed, additional security skills are available. Use them proactively: +When the `bitwarden-security-engineer` plugin is installed, use security skills proactively: -- **Before implementing auth/crypto/access-control features** → activate `Skill(reviewing-security-architecture)` to verify your design against approved patterns (token handling, RBAC, encryption at rest/transit, trust boundaries) -- **When handling user input that reaches SQL, HTML, file system, or URLs** → activate `Skill(analyzing-code-security)` to check for injection, XSS, SSRF, and path traversal against Bitwarden's vulnerability pattern library -- **When adding or updating dependencies** → activate `Skill(reviewing-dependencies)` to assess supply chain risk before introducing new packages -- **When working with secrets or configuration** → activate `Skill(detecting-secrets)` to verify no credentials are hardcoded +- **Auth/crypto/access-control features** → `Skill(reviewing-security-architecture)` +- **User input reaching SQL, HTML, file system, URLs** → `Skill(analyzing-code-security)` +- **Adding or updating dependencies** → `Skill(reviewing-dependencies)` +- **Working with secrets or configuration** → `Skill(detecting-secrets)` -These skills are optional — if unavailable (plugin not installed), proceed with your standard workflow. +These skills are optional — if unavailable, proceed with your standard workflow. \ No newline at end of file diff --git a/plugins/bitwarden-workflows/.claude-plugin/plugin.json b/plugins/bitwarden-workflows/.claude-plugin/plugin.json new file mode 100644 index 00000000..e793e13b --- /dev/null +++ b/plugins/bitwarden-workflows/.claude-plugin/plugin.json @@ -0,0 +1,12 @@ +{ + "name": "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.", + "author": { + "name": "Bitwarden", + "url": "https://github.com/bitwarden" + }, + "homepage": "https://github.com/bitwarden/ai-marketplace/tree/main/plugins/bitwarden-workflows", + "repository": "https://github.com/bitwarden/ai-marketplace", + "keywords": ["workflow", "orchestration", "pipeline", "plan-implement-review", "teams"] +} diff --git a/plugins/bitwarden-workflows/CHANGELOG.md b/plugins/bitwarden-workflows/CHANGELOG.md new file mode 100644 index 00000000..da7e569c --- /dev/null +++ b/plugins/bitwarden-workflows/CHANGELOG.md @@ -0,0 +1,13 @@ +# Changelog + +All notable changes to the `bitwarden-workflows` 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-13 + +### Added + +- `plan-implement-review` skill — end-to-end pipeline orchestrating requirements analysis, per-repo architecture planning, implementation with self-review, and multi-agent code review via Teams and task dependencies +- Reference implementation for composing marketplace agents (product-analyst, architect, software-engineer, security-engineer, code-reviewer) into complex multi-step workflows diff --git a/plugins/bitwarden-workflows/README.md b/plugins/bitwarden-workflows/README.md new file mode 100644 index 00000000..98cf0c60 --- /dev/null +++ b/plugins/bitwarden-workflows/README.md @@ -0,0 +1,41 @@ +# Bitwarden Workflows + +Multi-agent orchestration workflows for Bitwarden development. Composes marketplace agents into end-to-end pipelines via Teams and task dependencies. + +## Overview + +This plugin provides composed workflows that coordinate multiple marketplace agents into structured, multi-step pipelines. Each workflow uses Teams for teammate management, task dependencies for execution ordering, and dynamic per-repo agent dispatch for cross-repo features. + +## Skills + +| Skill | Triggers | Purpose | +|-------|---------|---------| +| `plan-implement-review` | "plan and implement", "PIR", "end-to-end pipeline" | Full development pipeline: requirements → architecture → implementation → review | + +## plan-implement-review + +End-to-end development pipeline that orchestrates 6 agent types through a structured lifecycle: + +1. **Plan** (once) — Product analyst produces requirements, per-repo architects produce implementation plans in parallel, then a work breakdown and QA handoff are consolidated +2. **Implement + Review** (per phase) — Per-repo software engineers implement each phase, then a 4-reviewer gauntlet (requirements, architecture, security, code quality) reviews the changes with up to 3 fix rounds before escalation +3. **Shutdown** — Teammates are shut down, artifacts summarized, next steps suggested + +Supports `--confirm` flag for gated mode (user approval between phases) or runs autonomously by default. Handles multi-repo Epics by dynamically creating per-repo architects and implementers based on what the requirements spec identifies as in scope. + +### Prerequisites + +| Plugin | Role in pipeline | +|--------|-----------------| +| `bitwarden-product-analyst` | Requirements analysis, QA handoff, requirements review | +| `bitwarden-architect` | Architecture planning, architecture review | +| `bitwarden-software-engineer` | Implementation with self-review | +| `bitwarden-security-engineer` | Security review | +| `bitwarden-code-review` | Code quality review | +| `bitwarden-delivery-tools` | Committing, PRs, preflight, labeling | +| `bitwarden-atlassian-tools` | Optional — Jira/Confluence fetching | + +Missing plugins are skipped gracefully rather than blocking the pipeline. + +## Installation + +Install via the Bitwarden AI Marketplace. diff --git a/plugins/bitwarden-workflows/skills/plan-implement-review/SKILL.md b/plugins/bitwarden-workflows/skills/plan-implement-review/SKILL.md new file mode 100644 index 00000000..c4ae7cee --- /dev/null +++ b/plugins/bitwarden-workflows/skills/plan-implement-review/SKILL.md @@ -0,0 +1,133 @@ +--- +name: plan-implement-review +description: End-to-end pipeline orchestrating requirements analysis, architecture planning, implementation, and multi-agent code review via agent team. Use when starting a feature from a Jira ticket, planning multi-repo work, or running a full plan-implement-review cycle. Triggered by "plan and implement", "plan-implement-review", "end-to-end pipeline", "PIR". +--- + +# Plan-Implement-Review Pipeline + +You are the **team lead** for an end-to-end development pipeline. Use **Claude Agent Teams** to create a team, define tasks with dependencies, and add teammates. + +**Input**: $ARGUMENTS + +## Input Parsing + +Parse `$ARGUMENTS`: strip `--confirm` flag (enables **gated mode** — present output and get user approval between phases; default is **autonomous mode**). Derive a slug from the task description (lowercase, hyphens, max 40 chars). + +**Output paths** (using slug): +- `${CLAUDE_PLUGIN_DATA}/plans/{slug}-REQUIREMENTS.md` +- `${CLAUDE_PLUGIN_DATA}/plans/{slug}-IMPL-{REPO}.md` (one per in-scope repo) +- `${CLAUDE_PLUGIN_DATA}/plans/{slug}-WORK-BREAKDOWN.md` +- `${CLAUDE_PLUGIN_DATA}/plans/{slug}-QA-HANDOFF.md` +- `${CLAUDE_PLUGIN_DATA}/reviews/{slug}-REVIEW-{REVIEWER}.md` (one per reviewer per phase) +- `${CLAUDE_PLUGIN_DATA}/reviews/{slug}-REVIEW-SUMMARY.md` + +## Pipeline Structure + +``` +Plan (once): + Requirements → Architecture (parallel, per repo) → Work Breakdown → QA Handoff + +Implement+Review (per phase from WBD): + Phase 1: Implement → Review → Fix cycle → ✓ + Phase 2: Implement → Review → Fix cycle → ✓ + ... + Phase N: Implement → Review → Fix cycle → ✓ + +Shutdown +``` + +## Prerequisites + +If a plugin is not installed, offer to **skip that teammate** rather than blocking the pipeline. + +| Plugin | Required For | +|--------|-------------| +| `bitwarden-product-analyst` | Requirements analysis + requirements review | +| `bitwarden-architect` | Architecture planning + architecture review | +| `bitwarden-software-engineer` | Implementation | +| `bitwarden-security-engineer` | Security review | +| `bitwarden-code-review` | Code quality review | +| `bitwarden-delivery-tools` | Committing, PRs, preflight, labeling | +| `bitwarden-atlassian-tools` | Optional — Jira/Confluence fetching | + +## Step 1: Create Team + +Team name: `pir-{slug}`. Create `${CLAUDE_PLUGIN_DATA}/plans/` and `${CLAUDE_PLUGIN_DATA}/reviews/` directories. + +## Step 2: Plan Phase + +### Planning Tasks + +| Task | Subject | Description | blockedBy | +|------|---------|-------------|-----------| +| 1 | Analyze requirements | Analyze requirements for: {task description}. Write to `{slug}-REQUIREMENTS.md`. Include high-level work breakdown and **explicitly list which repositories are in scope**. | [] | + +After Task #1 completes, the **read the requirements spec** and identify in-scope repos. Then create: + +- **One architecture task per repo**: Read the requirements spec, analyze the `{repo}/` directory, design architecture, write to `{slug}-IMPL-{REPO}.md`. Blocked by Task #1. All run in parallel. +- **WBD task**: Consolidate all `{slug}-IMPL-*.md` plans with the requirements into a Jira-ready work breakdown. Blocked by all architecture tasks. +- **QA handoff task**: Define testable increments per phase from the WBD. Blocked by WBD. + +### Planning Teammates + +Shut down after planning completes. + +| Teammate Name | Agent Type | Task | Role | +|---------------|-----------|------|------| +| `product-analyst` | `bitwarden-product-analyst:product-analyst` | 1 | Requirements specification | +| `architect-{repo}` | `bitwarden-architect:architect` | per-repo | One per in-scope repo. Spawned after Task #1. | +| `wbd-author` | `bitwarden-architect:architect` | WBD | Consolidate breakdowns | +| `qa-handoff-author` | `bitwarden-product-analyst:product-analyst` | QA | QA handoff document | + +### Standing Teammates + +Persist across all implementation phases. **Implementers are per-repo** (matching the architect pattern). Created after Task #1 identifies in-scope repos. + +| Teammate Name | Agent Type | Role | +|---------------|-----------|------| +| `implementer-{repo}` | `bitwarden-software-engineer:bitwarden-software-engineer` | One per in-scope repo. Implement, test, build, preflight, commit within `{repo}/`. | +| `requirements-reviewer` | `bitwarden-product-analyst:product-analyst` | Requirements conformance | +| `architecture-reviewer` | `bitwarden-architect:architect` | Architecture and pattern adherence | +| `security-reviewer` | `bitwarden-security-engineer:bitwarden-security-engineer` | Security and zero-knowledge compliance | +| `code-reviewer` | `bitwarden-code-review:bitwarden-code-reviewer` | Code quality | + +**All standing teammates wait for explicit instructions from the team lead.** They must NOT self-activate. + +### Planning Completion + +1. Shut down planning teammates. Standing implementers and reviewers remain. +2. Read the WBD, extract the ordered phase list. +3. Present phase plan to user. Proceed to implementation loop. + +## Step 3: Implementation Loop (per phase) + +### 3a: Dispatch Implementer + +Each WBD phase targets a specific repo. Dispatch `implementer-{repo}`: + +1. Create task: `[{repo}] Implement Phase {N}: {phase name}` +2. Assign to `implementer-{repo}`. +3. Send: phase scope, path to `{slug}-IMPL-{REPO}.md`, target repo directory. Instruct to commit when done. +4. Wait for completion. Verify commits exist. + +### 3b: Dispatch Reviewers + +**CRITICAL**: Do NOT dispatch reviewers until the implementer has committed. + +Create one review task per reviewer. Each reviewer writes findings to their output file. Wait for all 4 to complete. + +### 3c: Consolidate and Fix + +1. Read all 4 review files. Write a consolidated summary to `{slug}-REVIEW-SUMMARY.md` with **Critical**, **Important**, and **Suggestions** sections. Deduplicate overlapping findings. +2. If no critical/important issues → proceed to next phase. +3. If issues exist → send consolidated findings to `implementer-{repo}`. The implementer assesses each finding (fix or dispute with the reviewer). After fixes, re-run reviews. **Max 3 rounds** — after 3 rounds with unresolved issues, escalate to user. + +### 3d: Phase Transition + +Print phase completion status. Group tightly coupled phases into a single cycle (max 3 per group). In gated mode, wait for user approval before proceeding. + +## Step 4: Shutdown + +1. Shutdown all remaining teammates. Delete team. +2. Present final summary: artifact paths, phases completed, review cycles, commits. +3. Suggest next steps — create PR via `Skill(bitwarden-delivery-tools:creating-pull-request)` if all issues resolved.