skilld
All skills
bitwarden avatar

bitwarden/ai-plugins

AI plugin marketplace.

mainGitHub
README badge for bitwarden/ai-plugins

Repository statistics

  • Indexed skills

    67

  • Skill groups

    1

  • GitHub stars

    0

  • Forks

    0

Skills

67 total

/applying-pr-conventions

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

/creating-pull-request

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

/recommending-test-layers

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

/perform-security-review

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.

/performing-multi-agent-code-review

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.

/managing-workflow-secrets

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.

/writing-manual-test-cases

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.

/reviewing-claude-config

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.

/reviewing-command-definitions

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.

/reviewing-agent-definitions

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.

/reviewing-project-guidance

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.

/reviewing-runtime-configuration

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.

/auditing-workflow-conventions

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.

/navigating-the-initiative-funnel

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.

/assessing-jira-issue-relevance

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.

/contributing-to-technical-strategy

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.

/assessing-test-coverage

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.

/action-remediate

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>

/workflow-fix

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>

/reviewing-dependency-changes

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.

/action-audit

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>

/bitwarden-workflow-linter-rules

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>

/auditing-hackerone-vulns

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.

/running-work-transitions

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.

/researching-jira-issues

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.

/workflow-audit

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>

GitHub repository metadata loaded, but the SKILL.md file scan is unavailable right now.

Add to your README

The badge links readers to this page. It shows the skilld mark and no counts, and it follows the reader's light or dark GitHub theme.

<a href="https://skilld.dev/gh/bitwarden/ai-plugins"> <picture> <source media="(prefers-color-scheme: dark)" srcset="https://skilld.dev/b/bitwarden/ai-plugins?theme=dark"> <source media="(prefers-color-scheme: light)" srcset="https://skilld.dev/b/bitwarden/ai-plugins?theme=light"> <img alt="Skill repository on skilld.dev" src="https://skilld.dev/b/bitwarden/ai-plugins?theme=light"> </picture> </a>