Stats
Actions
Tags
'%20stop-opacity%3D'0.16'%2F%3E%3Cstop%20offset%3D'1'%20stop-color%3D'rgb(200%2C90%2C60)'%20stop-opacity%3D'0.03'%2F%3E%3C%2FlinearGradient%3E%3C%2Fdefs%3E%3Crect%20width%3D'320'%20height%3D'200'%20fill%3D'url(%23g)'%2F%3E%3Ccircle%20cx%3D'250'%20cy%3D'56'%20r%3D'92'%20fill%3D'rgb(200%2C90%2C60)'%20fill-opacity%3D'0.06'%2F%3E%3Ccircle%20cx%3D'64'%20cy%3D'172'%20r%3D'58'%20fill%3D'rgb(200%2C90%2C60)'%20fill-opacity%3D'0.05'%2F%3E%3C%2Fsvg%3E)
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".
How this skill is triggered — by the user, by Claude, or both
Slash command
/bitwarden-delivery-tools:labeling-changesThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
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`).
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).
The type keyword appears after the Jira ticket prefix:
[PM-XXXXX] <type>: <imperative summary>
Read ${CLAUDE_PLUGIN_ROOT}/references/change-type-labels.md for the full table of type keywords, their CI label mappings, and guidance for selecting a type (including ambiguous cases).
The CI labeling script matches <type>: or <type>( in the lowercased PR title, so the keyword must be followed by a colon or parenthesis. If the type cannot be confidently determined, ask the user.
npx claudepluginhub denobotion/ai-plugins --plugin bitwarden-delivery-toolsGuides collaborative design exploration before implementation: explores context, asks clarifying questions, proposes approaches, and writes a design doc for user approval.
Creates structured, bite-sized implementation plans from specs or requirements before writing code. Useful for breaking down multi-step tasks into testable steps with file structure and task boundaries.
Synthesizes the current conversation into a structured spec (PRD) and publishes it to the project issue tracker with a ready-for-agent label, without interviewing the user.