Skip to main content
Running a ticket-to-pull-request pipeline surfaces a handful of recurring questions. Each has a skill that answers it:
  • The shape of the work isn’t settled yet — what are the big pieces, and in what order? → bd-high-plan
  • I have a design or an objective — how do I turn it into well-scoped tickets the agent can finish in one pass? → bd-build-up, or bd-mega-build-up when the design should be pressure-tested first
  • I have a stack of planned tickets — what order should they go out in, and which will fail without more context? → bd-summit-push
  • I have a pile of open pull requests from the agent — which merge, which need another pass, and which are blocked? → bd-build-down, or bd-super-build-down for many at once
  • Did the preview actually work, or did the agent just make the diff look right? → bd-smoke-jumper
  • Has this already been decided, tried, or filed before? → bd-kg-search
  • Why isn’t my ticket running? → bd-system-questions
A few sit outside that sequence:
  • bd-project-setup runs once to wire a project to its tools
  • bd-kg-create and bd-kg-refresh stand up and update the project memory that bd-kg-search reads
  • bd-belay-on formalizes handing a question to a different tool at any point along the way

​
How the skills fit together

​
Issue lifecycle

​
Knowledge graph

​
What they have in common

The skills share one autonomy model, so a skill either acts or asks for the same reasons throughout. They also read the same recorded project bindings rather than each asking you where your issues live — which is what bd-project-setup exists to write. They assume a common setup: a connected ticketing system, a connected GitHub account, browser automation for preview testing, and a coding agent that responds to pull request comments. Most run entirely inside your own Claude Code session, separate from the AI-Implement orchestrator that later picks up a marked issue and opens the pull request. bd-system-questions is the one that needs the orchestrator outright — it asks the orchestrator about itself, and does nothing without one. A bound knowledge graph changes the picture more softly. Every planning and landing skill consults it before acting, as does bd-belay-on, and all of them skip silently on a project that has none.

​
Ticketing support

Ticketing provider support varies by skill. bd-build-up, bd-mega-build-up, and bd-build-down carry dedicated Jira handling alongside Linear. bd-summit-push and bd-super-build-down describe Jira behavior projected from their Linear behavior rather than fully adapted to it, so Linear assumptions may show through on Jira projects.
bd-project-setup binds either ticketing system. bd-smoke-jumper needs one too — to read issue context and file the failures it finds — but treats Linear and Jira identically rather than branching its behavior. bd-belay-on is the only skill with no ticketing dependency at all.

​
Feature-branch grouping

Every planning and landing skill understands feature-branch grouping. When a parent issue and its children are marked together, they treat the tree as one unit that rolls up to a single reviewable pull request rather than as unrelated issues. bd-project-setup knows about it too, for a different reason — it re-syncs a target repo’s workflow so grouped runs are accepted in the first place.

​
Available skills

​
Plan the work

​
Land the work

​
Project knowledge

​
Setup and support

​
Next step

Install the skills

Add the plugin to Claude Code and choose a release channel.