Issues and Branches
Create Jira issues and verified Bitbucket branches
KimJ
@alvolutionor
Install
$ openclaw skills install @alvolutionor/create-branchCreate issues and branches
Resolve the requested issue content and repositories from the conversation and Git remotes. Ask only for missing facts that prevent execution. Use scripts/create_branch.py relative to this skill; scripts/create_jira.py is its internal Jira helper. The helpers need Python 3.10+ and requests. See setup for private configuration and complete examples.
Creating or changing this skill does not run it. An explicit request to create issues or branches authorizes those requested operations and established defaults. Do not add Slack messages, commits, merges, deployments or working-tree switches. A preview request stays read-only.
Choose the requested operation
- New issue only:
--input <request.json>without--repo. Bitbucket access is unnecessary. - Branches for an existing issue: provide its key and repeat
--repo <slug>for each requested repository. Reuse the issue; never create a replacement. - New issue and branches: provide
--inputand the requested repositories. Use the newly returned issue key. - Read existing issue: pass its key without repositories. This stays read-only even with
--apply.
Commands preview by default. Add --apply only for the user-requested writes. A new-issue preview lists the issue defaults and requested repositories; final branch names and base commits are resolved after Jira supplies the real key.
Write the issue
Use a concise, factual summary and description in the project's language. For a defect, include observed and expected behavior, reproduction or a concrete example, and the environment when known. Do not invent requirements or include unresolved scope decisions in a created card. Ask the missing questions first. Preserve explicit assignee and status choices from the conversation.
Input requires summary and description. Description accepts text or an Atlassian Document Format document: structured JSON with type: doc, version: 1 and nonempty content. Optional keys are project, issue_type, assignee_account_id and status. Project defaults to private configuration; type defaults to Task, status to To Do, and assignee to the authenticated Jira user. Use Bug for a defect when that type exists.
Resolve exactly one active sprint on the configured board before issue creation. If none or several are active, resolve the target instead of guessing. Set assignment during creation, transition if needed, add sprint membership, then read all three back. Do not report an accepted create response as complete until the final verification succeeds.
Resolve and create branches
Read the issue and determine the repositories from the requested scope. Do not add frontend/backend repositories simply because they exist. Obtain branch-type prefixes and development/production bases from each repository's branching model. Default to bugfix for a Bug and feature otherwise; --type and --from override when requested. Hotfix uses the production base by default.
The branch suffix is KEY-summary-slug, capped at 40 characters before the configured prefix. Reuse an existing branch containing the issue key; if several candidates exist, establish the intended branch before continuing. Preserve a card's in-progress or later status unless the user explicitly requests moving it.
The helper validates the local clone's origin against the configured workspace and repository. It fetches the selected base commit and pushes that commit to the new branch ref without switching the user's worktree. Never force-push, delete/recreate a branch to refresh indexing, or claim immediate Jira Development-panel indexing: that depends on the consuming team's integration.
Read back the remote branch and Jira assignment/status/sprint before reporting success. An unknown create/push outcome requires inspection before retrying. If the issue already exists after a partial failure, continue on its returned key and reuse existing branches; never rerun the new-issue create operation blindly.
Return the issue URL, verified assignee, status and sprint, and each requested branch URL. State incomplete steps explicitly. Add attachments or issue links only when separately requested and verified.
Top skills in this category
GitHub
@byungkyuGitHub API integration with managed OAuth. Access repositories, issues, pull requests, commits, branches, and users. Use this skill when users want to interact with GitHub repositories, manage issues and PRs, search code, or automate workflows. For other third party apps, use the api-gateway skill (https://clawhub.ai/byungkyu/api-gateway). Calls run through the `maton` CLI with OAuth login, or over raw HTTP with a Maton API key where the CLI cannot be installed. Every call is authenticated as the user's connection and reaches only what that connection's authorization allows, which the provider enforces on every request; the endpoints documented here are the ones this skill uses, and any other endpoint of this app needs the user to ask for it by name. Default to read and list calls, and confirm every write or new connection with the user. This file also documents the three constructs that turn a GitHub connection into automation, in the order they are used: the connection (the first step), a hosted function that runs a GitHub action through the Maton SDK, and a trigger that calls that function on a schedule or on an event. Those sections are the platform's own reference text, shared with the api-gateway skill, with GitHub examples; they add no GitHub capability - GitHub is itself an event source, so its own events are in `references/github/triggers.md`, and the files under `references/<source>/triggers.md` are the platform's event catalogues for the sources Maton offers (time, Calendly, GitHub, Gmail, HubSpot, Linear, Notion, Slack, Stripe).
google-slides
@byungkyuGoogle Slides API integration with managed OAuth. Create presentations, add slides, insert content, and manage slide formatting. Use this skill when users want to interact with Google Slides. For other third party apps, use the api-gateway skill (https://clawhub.ai/byungkyu/api-gateway). Calls run through the `maton` CLI with OAuth login, or over raw HTTP with a Maton API key where the CLI cannot be installed. Every call is authenticated as the user's connection and reaches only what that connection's authorization allows, which the provider enforces on every request; the endpoints documented here are the ones this skill uses, and any other endpoint of this app needs the user to ask for it by name. Default to read and list calls, and confirm every write or new connection with the user. This file also documents the three constructs that turn a Google Slides connection into automation, in the order they are used: the connection (the first step), a hosted function that runs a Google Slides action through the Maton SDK, and a trigger that calls that function on a schedule or on an event. Those sections are the platform's own reference text, shared with the api-gateway skill, with Google Slides examples; they add no Google Slides capability - Google Slides is not an event source, a trigger cannot read Google Slides data, and the files under `references/<source>/triggers.md` are the platform's event catalogues for the sources Maton offers (time, Calendly, GitHub, Gmail, HubSpot, Linear, Notion, Slack, Stripe).
google-workspace-admin
@byungkyuGoogle Workspace Admin SDK integration with managed OAuth. This is a write-capable administrative integration for users, groups, organizational units, roles, and domain settings. Only connect with a least-privileged Google admin account, restrict OAuth scopes to the specific resources needed, and revoke the connection after use. All write operations require explicit user approval showing the exact HTTP method, endpoint path, and target resource identifier before execution. Use this skill only when users need Google Workspace administration. For other third party apps, use the api-gateway skill (https://clawhub.ai/byungkyu/api-gateway). Calls run through the `maton` CLI with OAuth login, or over raw HTTP with a Maton API key where the CLI cannot be installed. Every call is authenticated as the user's connection and reaches only what that connection's authorization allows, which the provider enforces on every request; the endpoints documented here are the ones this skill uses, and any other endpoint of this app needs the user to ask for it by name. Default to read and list calls, and confirm every write or new connection with the user. This file also documents the three constructs that turn a Google Workspace Admin connection into automation, in the order they are used: the connection (the first step), a hosted function that runs a Google Workspace Admin action through the Maton SDK, and a trigger that calls that function on a schedule or on an event. Those sections are the platform's own reference text, shared with the api-gateway skill, with Google Workspace Admin examples; they add no Google Workspace Admin capability - Google Workspace Admin is not an event source, a trigger cannot read Google Workspace Admin data, and the files under `references/<source>/triggers.md` are the platform's event catalogues for the sources Maton offers (time, Calendly, GitHub, Gmail, HubSpot, Linear, Notion, Slack, Stripe).
Linear
@byungkyuLinear API integration with managed OAuth. Query and manage issues, projects, teams, cycles, and labels using GraphQL. Use this skill when users name Linear explicitly or ask about their Linear issues, cycles, projects, or teams — for example "create a Linear issue for this bug", "what is in my current cycle", "move ENG-412 to done". Not for GitHub issues, Jira, or generic task lists, and not for planning work that is not tracked in Linear. For other third party apps, use the api-gateway skill (https://clawhub.ai/byungkyu/api-gateway). Requires network access and valid Maton API key. Calls run through the `maton` CLI with OAuth login, or over raw HTTP with a Maton API key where the CLI cannot be installed. Every call is authenticated as the user's connection and reaches only what that connection's authorization allows, which the provider enforces on every request; the endpoints documented here are the ones this skill uses, and any other endpoint of this app needs the user to ask for it by name. Default to read and list calls, and confirm every write or new connection with the user. This file also documents the three constructs that turn a Linear connection into automation, in the order they are used: the connection (the first step), a hosted function that runs a Linear action through the Maton SDK, and a trigger that calls that function on a schedule or on an event. Those sections are the platform's own reference text, shared with the api-gateway skill, with Linear examples; they add no Linear capability - Linear is itself an event source, so its own events are in `references/linear/triggers.md`, and the files under `references/<source>/triggers.md` are the platform's event catalogues for the sources Maton offers (time, Calendly, GitHub, Gmail, HubSpot, Linear, Notion, Slack, Stripe).
google-play
@byungkyuGoogle Play Developer API (Android Publisher) integration with managed OAuth. Manage apps, subscriptions, in-app purchases, and reviews. Use this skill when users want to interact with Google Play Console programmatically. For other third party apps, use the api-gateway skill (https://clawhub.ai/byungkyu/api-gateway). Calls run through the `maton` CLI with OAuth login, or over raw HTTP with a Maton API key where the CLI cannot be installed. Every call is authenticated as the user's connection and reaches only what that connection's authorization allows, which the provider enforces on every request; the endpoints documented here are the ones this skill uses, and any other endpoint of this app needs the user to ask for it by name. Default to read and list calls, and confirm every write or new connection with the user. This file also documents the three constructs that turn a Google Play connection into automation, in the order they are used: the connection (the first step), a hosted function that runs a Google Play action through the Maton SDK, and a trigger that calls that function on a schedule or on an event. Those sections are the platform's own reference text, shared with the api-gateway skill, with Google Play examples; they add no Google Play capability - Google Play is not an event source, a trigger cannot read Google Play data, and the files under `references/<source>/triggers.md` are the platform's event catalogues for the sources Maton offers (time, Calendly, GitHub, Gmail, HubSpot, Linear, Notion, Slack, Stripe).