Bitwarden

Audit GitHub Actions action usage across an org. Searches for a specific action (incident mode) or sweeps all workflow files for non-compliant action references (audit mode). Produces a read-only report of findings with compliance status and resolved SHAs. Does not modify any files. <example> User: We need to check if any repos are using tj-actions/changed-files Action: Trigger action-audit in incident mode for that action </example> <example> User: Can you find all unpinned actions across the org? Action: Trigger action-audit in audit mode </example>

Remediate GitHub Actions action findings identified by the action-audit skill. Applies the appropriate fix per action type — `@main` ref for internal `bitwarden/` actions, full SHA with inline version comment for external actions, or full replacement — across selected repos and creates draft PRs. Run the action-audit skill first to identify findings before using this skill. <example> User: Go ahead and fix the unpinned actions from the audit Action: Trigger action-remediate to apply fixes and create PRs </example> <example> User: Replace tj-actions/changed-files with the safe version across those repos Action: Trigger action-remediate to swap the action and create PRs </example>

Use when the user is addressing pull request review comments locally and asks for help evaluating, implementing, or drafting responses to reviewer feedback - requires technical rigor and verification, not performative agreement or blind implementation

This skill should be used when the user asks to "analyze code for security issues", "check for OWASP vulnerabilities", "review code against CWE Top 25", "find injection vulnerabilities", "do a security code review", or needs manual security analysis against OWASP Top 10, API Top 10, Mobile Top 10, or CWE/SANS frameworks.

Analyzes git commits and changes within a timeframe or commit range, providing structured summaries for code review, retrospectives, work logs, or session documentation.

Apply Bitwarden brand standards — logo usage, color palette, typography, iconography, and capitalization rules — grounded in bitwarden.com/brand and the bitwarden/brand repository.

Compose the conventions a Bitwarden pull request needs — the conventional commit type prefix and title, the repo's PR template body, and the ai-review label. Use for "what should the PR title be", "draft the PR body", "fill in the PR template", "which ai-review label", or when another delivery skill asks for these. Returns the title, body, resolved t: label, and label choice. Not for opening the pull request itself (that is creating-pull-request), or for the type keyword and t: mapping alone outside a PR being composed (that is labeling-changes).

Architecting solutions at the team level while staying coherent with Bitwarden's holistic architecture. Covers security mindset, architectural judgment, Bitwarden-specific constraints, and working with the architecture group. Use when designing or planning a solution, reviewing architecture within a team's scope, assessing change impact, evaluating trade-offs in different implementations, or deciding whether a choice needs architecture group input.

Use when the user provides a single Jira issue key and asks whether it is still relevant, still applicable, still pending, still a bug, has been fixed, or can be closed. Trigger phrases include "Is [TICKET] still relevant?", "Is this still an issue?", "Is PM-123 still pending?", "Has this been fixed?", "Can we close this?", "Is this ticket still valid?", "Is this still applicable?", "Does this bug still exist?". Fetches the ticket and verifies the described problem against the current codebase to return a verdict with evidence. This skill assesses a single ticket at a time; invoke it iteratively for multiple tickets.

Use when determining what test coverage ALREADY exists for a specific change (a PR, Jira key, Tech Breakdown doc, Testmo CSV, changed paths, or named component). Triggers on "what's already tested", "does this PR have tests", "what coverage exists for", "is this component covered", or "which behaviors have no test today". This is a backward-looking inventory of existing coverage for a concrete change. Do NOT use it to recommend or decide which new tests to add ("should I add integration tests here", "are unit tests enough"), to design a test strategy or plan, to run or fix existing tests, or to explain testing concepts like the test pyramid or which layers a repo uses — those are all out of scope.

Audits an external (third-party) Claude Code plugin pinned in this marketplace for security risk before it is vendored, and writes the report to a file for downstream posting. Use when asked to "audit an external plugin", "audit a vendored plugin", "run a plugin security audit", or when a new or updated external plugin pin needs a pre-merge security review.

Audit all open HackerOne-sourced VULN Jira tickets and their linked engineering child items to identify what needs action. Use this skill whenever the user wants to: check VULN ticket status, see which HackerOne findings need status updates, identify vulnerabilities ready to verify or close, run a remediation audit, check "what do I need to do on my VULN tickets today", or get a prioritized view of open vulnerabilities. Outputs a sorted action table with emoji tokens. Always use this skill for HackerOne/VULN remediation tracking and status correlation tasks — don't try to do it from scratch.

Reference for Bitwarden GitHub Actions naming conventions that the workflow linter (bwwl) does not enforce. Covers three standards — job IDs (kebab-case), step names (Sentence case imperative), and workflow file names (kebab-case.yml, `_` prefix for reusable) — plus an advisory canonical step-name glossary and reference-sweep procedures for job ID and filename renames. Use when auditing or authoring workflows and questions like "what casing should job IDs use", "should this reusable workflow be build.yml or _build.yml", or "review these workflows for naming consistency" come up. Read alongside bitwarden-workflow-linter-rules, which is the source of truth for linted rules; this skill covers only the gaps.

Use this skill to validate findings during a code review. For each finding, run the rejection criteria and verification checks. If a finding fails any check, drop it. In PR mode it also holds the once-per-review stacked-PR gate that decides whether completeness findings apply to the pull request at all.

Bitwarden's security principles (P01-P06), security vocabulary, and data classification standards. Use when you need foundational security context for any Bitwarden development, review, or security task — such as understanding trust boundaries, data protection requirements, or Bitwarden-specific security terminology.

Reference for all Bitwarden workflow linter (bwwl) rules. Covers all 10 linter rules split into two categories: mechanical rules that can be applied automatically (name_capitalized, permissions_exist, pinned_job_runner, step_pinned, underscore_outputs, job_environment_prefix, check_pr_target) and judgment rules requiring user input (name_exists, step_approved, run_actionlint). Use the workflow-audit skill to run the linter and report findings, and the workflow-fix skill to apply fixes. <example> User: What does the step_pinned rule check for? Action: Consult this skill for the rule definition and fix procedure </example> <example> User: How do I fix a permissions_exist finding? Action: Consult this skill for the fix procedure </example>

Primary-Owner playbook for shepherding a Technical Strategy Idea through Architecture's pre-funnel evaluation into the Software Initiative Funnel.

Use this skill when categorizing code review findings into severity levels. Apply when determining which emoji and label to use for PR comments, deciding if an issue should be flagged at all, or classifying findings as CRITICAL, IMPORTANT, DEBT, SUGGESTED, or QUESTION.

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".

Bitwarden's product content style guide for end-user-facing GUI copy — voice, tone, AP-style-with-exceptions grammar, sentence case in UI, and accessibility-first language at a U.S. 7th-grade reading level.

How team-level patterns flow up into Bitwarden's Technical Strategy Ideas backlog and back down through BW Initiatives into team epics and stories. Covers recognizing which team-level patterns belong in the TSI backlog, framing an idea well enough for Architecture to evaluate it, the ARCH idea ↔ BW Initiative linkage, and defining epic-level and story-level work downward from an initiative. Use when noticing a cross-team pattern of pain that exceeds one team's scope, when surfacing ideas to the architecture group, when understanding how an initiative connects back to its originating idea, or when breaking epic-level work out of an initiative onto a team.

Phase 5 (Implementation) deep-dive playbook — shepherd coordinates teams executing the initiative across the support period, pulse check, retrospective, and closure.

Open a pull request from a branch in a Bitwarden repository. Use whenever the user wants a branch turned into a pull request, however they phrase it — "create a PR", "open a PR", "ship a draft", "ship it", "ready for review", "put it up for review", "get this in front of reviewers", "send it over to the team", "throw together a pull request", "wrap this branch up". Use it too when the user says the title and body are already settled and only the PR needs opening — the gate, the preview, and the submission still apply. Runs the required local code-review gate, takes the title, template body, and ai-review label from applying-pr-conventions, confirms a full submission preview, then pushes and runs gh pr create. Not for composing a title, body, or label when no PR is being opened (that is applying-pr-conventions), conceptual questions ("how do PRs work"), or managing existing PRs (status, merging, addressing comments).

Peer-Reviewer and portfolio-curator side of the TSI Shepherding Model — backlog stewardship, quarterly prioritization, funnel intake handoff.

Bitwarden design team's Code of Conduct combined with the 30/60/90 critique framework — stage-appropriate critique, product-not-designer focus, content evaluated alongside visual design at 60% and 90%.

This skill should be used when the user asks to "find hardcoded secrets", "audit for credential leaks", "check for API keys in code", "review secret scanning alerts", "rotate a leaked secret", or needs to detect hardcoded credentials, review secret handling patterns, or remediate exposed secrets.

Propose a new UI pattern or modify an existing Design System component per Bitwarden's published governance process — design-team alignment, Core vs. Recipe/Snowflake decision with UI Foundation, Figma branching and property conventions, review gates, merge timing.

Locates, lists, filters, and extracts structured data from Claude Code native session logs. Supports both single and multiple session analysis.

Run or participate in a Bitwarden design critique session — the weekly team critique and one-off product design reviews — grounded in the team's published etiquette guide and the Product Design Review Guidelines.

Turn a tech breakdown's tasks.md into Jira ticket drafts — an epic parent plus one child story/task per task entry, each a real ticket with acceptance criteria and mapped Blocked-by/Depends-on links — then hand off to filing-jira-tickets to file them.

File Jira work items that stand on their own, with real ticket titles, acceptance criteria in whatever field the target project provides, and verified dependency links. Reads the target project's create screen first, so no project's field layout is assumed.

Apply one intent across many targets at once — a fleet of repositories across the Bitwarden ecosystem, or many projects inside a monorepo — as N consistent, idempotent, reviewable draft PRs.

Conventional commit type keywords for PR titles and commit messages. Use when determining the change type for commits or PRs, or when another delivery skill asks for the type keyword and its t: label. Triggered by "what type", "label", "change type", "conventional commit", "t: label".

Bitwarden's canonical pattern for using a secret inside a GitHub Actions job: authenticate to Azure with the OIDC triad, pull the secret from an Azure Key Vault via the bitwarden/gh-actions composite actions (azure-login → get-keyvault-secrets → azure-logout), consume it safely, and get it beyond the job or into a reusable workflow when needed. Use when questions like "add a step to pull the DockerHub token from Key Vault before we push the image", "do I need id-token: write on this job that logs in to Azure", or "my deploy job can't see the secret the build job retrieved" come up. Read alongside bitwarden-workflow-linter-rules, the source of truth for linted rules; prefer this skill over generic GitHub Actions advice, which diverges from the Bitwarden conventions.

Move design work through Bitwarden's Product and Design Jira workflow — final designs attached to tickets, the 30/60/90 critique cadence tracked in Figma, status transitions on engineering epics and stories, and the one-off engineering story flow.

Phase-by-phase guidance for participating in Bitwarden's Software Initiative Funnel. Covers shepherd vs tech-lead ownership, running an epic breakdown after Scoping & Commitment handoff, sizing, cross-team dependency tracking, and escalation paths that protect team autonomy. Use when receiving an initiative epic, participating in an Architectural Assessment or PoC, preparing the Scoping & Commitment breakdown, or surfacing concerns to the shepherd or engineering leadership.

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".

Performs a security-focused code review by launching multiple specialized agents and a verification agent to ensure comprehensive coverage and accurate findings. Use this skill when the user asks for a "perform-security-review", "bitwarden-security-review", "execute a security review", "run a comprehensive security audit", "perform an end-to-end security assessment", or needs to coordinate multiple security checks across code, dependencies, secrets, and configurations. The skill manages the workflow, delegates tasks to specialized agents, and presents final findings to the user.

Perform a rigorous, multi-agent code review with architecture-compliance, parallel quality/security analysis, finding validation, and severity audit. Use when the user asks for a structured, deep, thorough, multi-pass, or multi-agent code review — or a review that includes architecture/pattern compliance, confidence-scored findings, or a severity audit. Use when the user asks for a code review across a commit range, time window, or N most recent commits in a locally checked-out repo.

Use this skill when emitting inline review comments, whether posted to a GitHub pull request or written to a local file under caller-declared local-file output. Apply when formatting comments following Bitwarden engineering standards with severity emojis, clear explanations, and actionable suggestions. Use after findings are classified and ready to emit. DO NOT USE when posting summary comments.

Use this skill when posting the final summary comment, including its No Verdict form when nothing could be reviewed and no inline comments exist. Otherwise apply as the LAST step of code review, after all findings are classified and inline comments are complete. Detects context (caller-declared local-file output, agent mode sticky comment, GitHub Actions MCP tool, or local file) and routes output accordingly.

Prepare a Bitwarden design handoff — the Figma file in Ready-for-Dev state and the Jira state transitions that go with it. The end-of-In-Design gate / checklist.

Use when deciding WHICH new tests a change needs and at WHICH layer each belongs, working from a Jira key, a Testmo CSV, an assessing-test-coverage report, a PR, or a feature description. Triggers on "should I add integration tests here", "are unit tests enough", "what tests should I add and where", "what layer should this test go at", "which of these cases should be automated and at what layer", "what's the right test strategy for this feature", "pyramid or trophy for this change". This is a forward-looking recommendation of where to test. Do NOT use it to inventory what tests ALREADY exist or which layers they land at (use assessing-test-coverage), to author manual Gherkin test cases for Testmo (use writing-manual-test-cases), to run, fix, or refactor existing tests, or to explain testing concepts in the abstract with no change to place (how the pyramid or trophy works).

Extract complete, unambiguous requirements from specifications. Use when analyzing feature requests, processing enhancement specifications, or identifying missing information. Trigger phrases: "extract requirements", "analyze specification", "identify requirements", "clarify ambiguities". After extracting requirements, use the `work-breakdown` skill.

Use whenever the user mentions a Jira issue key and wants more than a surface-level lookup — "Read PROJ-123", "What's PROJ-123 about?", "Give me context on PROJ-123", "Deep dive PROJ-123", "What's blocking PROJ-123?", "Summarize PROJ-123 and its dependencies", "I need to work on PROJ-123, what should I know?", or any request to understand an issue's purpose, scope, or requirements. Thoroughly researches and synthesizes a Jira issue including all linked issues, sub-tasks, blocked dependencies, and supporting Confluence documentation.

Performs comprehensive analysis of Claude Code sessions, examining git history, conversation logs, code changes, and gathering user feedback to generate actionable retrospective reports with insights for continuous improvement.

Reviews Claude Code agent definition files for tool-access security, triggering quality, and system prompt clarity. Use when reviewing changes to agents/<name>.md or agents/<name>/AGENT.md, whether under .claude/agents/ or inside a plugin. Flags over-privileged tool grants, unjustified Bash access, descriptions with no activation triggers, and system prompts too vague to act on. Also use when asked to audit a subagent's tool access or check whether an agent will trigger. Normally reached through `reviewing-claude-config`, which runs an always-on secret scan and a finding filter first.

Reviews Claude configuration files for security, structure, and prompt engineering quality. Use when reviewing changes to CLAUDE.md, agents, prompts, commands, hooks, or settings. Routes each file type to a targeted review skill and returns classified findings. Flags settings.local.json appearing in a changeset, hardcoded secrets, malformed YAML, insecure agent tool access, and unsafe hook commands. Does not review SKILL.md files — plugin-dev:skill-reviewer owns those.

Reviews Claude Code slash command and prompt files for purpose clarity, completeness, shell-execution safety, and correct skill references. Use when reviewing changes to commands/**/*.md at any location, or .claude/prompts/**/*.md. Flags argument interpolation into a shell string, commands with no stated purpose or usage, complex tasks left as one vague instruction, and references to skills that do not exist. Also use when asked to check a slash command or review what a command actually runs. Normally reached through `reviewing-claude-config`, which runs an always-on secret scan and a finding filter first.

This skill should be used when the user asks to "review Dependabot alerts", "check for vulnerable dependencies", "audit third-party packages", "assess supply chain risk", "run an Aikido scan", or needs to evaluate dependency health, transitive risk, or supply chain security.

Use this skill when a PR diff contains changes to dependency manifest files (package.json, .csproj, Cargo.toml, go.mod, requirements.txt, etc.) or when reviewing Renovate/Dependabot bot PRs. Evaluates new dependencies for AppSec approval process compliance, major version bump significance, lock file hygiene, and dependency removal completeness. Does NOT perform deep security or license analysis — that is handled by the bitwarden-security-engineer plugin's reviewing-dependencies skill.

Reviews CLAUDE.md files for security, structure, and directive clarity. Use when reviewing changes to CLAUDE.md at a project root, in .claude/, or scoped to a subdirectory. Flags credentials and sensitive paths in guidance text, detailed specifications that belong in their own docs, directives too vague to act on, and directives that loosen the harness itself such as `--dangerously-skip-permissions` or `--no-verify`. Also use when asked to review project instructions or CLAUDE.md quality. Normally reached through `reviewing-claude-config`, which runs an always-on secret scan and a finding filter first.

Reviews Claude Code settings and hook definitions for security, permission scoping, and command safety. Use when reviewing changes to .claude/settings.json, .claude/settings.local.json, or hooks.json in a repository or plugin. Flags local settings appearing in a changeset, hardcoded secrets, filesystem-wide permissions, dangerous auto-approvals, and hook commands that exfiltrate data or route their input into a shell. Also use when asked to review hooks, audit permissions, or check what runs without a prompt. Normally reached through `reviewing-claude-config`, which runs an always-on secret scan and a finding filter first.

This skill should be used when the user asks to "review the security architecture", "check authentication patterns", "evaluate trust boundaries", "review encryption implementation", "assess authorization design", or needs to evaluate system designs for authentication, authorization, data protection, or cryptographic correctness.

Phase 3 (Proof of Concept) deep-dive playbook — validates the Research recommendation in real Bitwarden code and drafts the ADR.

Phase 2 (Research) deep-dive playbook — drafts the Architectural Assessment.

Six-phase playbook for running ownership transitions in either direction — receiving work from another team (initiative handoffs from shepherds, frameworks from Platform, operational responsibilities from SRE), or originating a transition (handing off a built framework, transitioning a shepherded initiative, or moving operational responsibilities). Applies Bitwarden's Work Transition Playbook from whichever side a team is on. Use when a team is about to take on or hand off transferred work, when preparing materials or sessions, when the support period is underway, or when running a pulse check or retrospective on a handoff.

Phase 4 (Scoping & Commitment) deep-dive playbook — High-Level Architecture Plan, child epics, per-team handoffs, leadership go/no-go.

Five-phase umbrella playbook for an initiative shepherd. Dispatches to phase-deep skills (Research, PoC, Scoping, Implementation) at the right moment.

This skill should be used when the user asks to "create a threat model", "define security goals", "generate a data flow diagram", "write security definitions", "perform an initial security assessment", or needs to produce threat model artifacts for new features or architecture changes.

This skill should be used when the user asks to "triage security findings", "fix an Aikido finding", "review Aikido issues", "dismiss a false positive", "check SAST/IaC alerts", or needs to work with Aikido feed issues, GitHub Dependabot alerts, or GitHub secret scanning alerts.

Read and inspect Figma designs via the Dev Mode MCP server — selects the right tool, parses Figma URLs into fileKey and nodeId, and turns design context into useful input for critique, copy review, handoff prep, and Design System work.

Break down features and requirements into actionable, implementable tasks with clear scope and acceptance criteria. Use when planning implementation, organizing complex work, or creating task lists. Trigger phrases: "break down tasks", "create work plan", "organize implementation", "plan development". This skill works best when preceded by `requirements-elicitation` skill use.

Run the Bitwarden workflow linter (bwwl) against one or more repos and report findings. Strictly read-only — does not modify any files. Categorizes findings as mechanical or judgment using the bitwarden-workflow-linter-rules skill. Supports single repo, multiple repos, or single file/directory scope. <example> User: Run the workflow linter on the server repo Action: Trigger workflow-audit for that repo </example> <example> User: Lint the workflows across server, clients, and android Action: Trigger workflow-audit in multi-repo mode </example>

Apply fixes for workflow linter findings identified by the workflow-audit skill. Applies mechanical fixes automatically, pauses for judgment calls, verifies with a re-lint, and creates draft PRs. Run the workflow-audit skill first to identify findings before using this skill. <example> User: Go ahead and fix the linter findings from the audit Action: Trigger workflow-fix to apply fixes and create PRs </example> <example> User: Fix the workflow linter issues in server and clients Action: Trigger workflow-fix for those repos </example>

Use when authoring NEW manual test cases in Gherkin format from a feature description, Jira ticket, acceptance criteria, PR, or design doc — the kind a QA engineer imports into Testmo. Triggers on "write test cases for", "manual test cases", "Gherkin scenarios for this ticket", "test cases for Testmo", "what scenarios should we test for this feature". Produces a paired .txt and Testmo-importable .csv. Do NOT use it to write automated test code (NUnit, Jest, xUnit, Playwright), to inventory what tests already exist for a change (use assessing-test-coverage), to run or fix existing tests, or to review a PR.

Write user-facing release notes for a Bitwarden release from a Jira release tag and the