// Run a phased git workflow: create branch (optional), commit, push, and open a GitHub pull request. Reports success or failure per phase and surfaces the PR URL when the final phase succeeds. Use when the user wants to ship a feature branch end-to-end or wants a single scripted pipeline with phase status.
Create new Jira Cloud issues via the Atlassian MCP: bugs, tasks, stories, sub-tasks. Loads project defaults from a local config file. Use when the user asks to create a Jira ticket, file a bug, add a task, add a story, or log a new issue.
Search and browse Jira Cloud issues via the Atlassian MCP. Run JQL queries, view backlogs, sprint scope, bug lists, stale issues, and any JQL-driven list. Use when the user asks for Jira backlog items, project issues, sprint issues, open bugs, issues by status, or wants to run a JQL query.
Update existing Jira Cloud issues via the Atlassian MCP: transition statuses, add comments, edit fields (priority, labels, fix version, summary), and link issues. Use when the user asks to move an issue to a different status, add a comment to a ticket, change a field on an existing issue, or link two issues together.
Security and structural validation for skills in the workspace. Scans all skills or a single named skill and returns a table showing Structure, Content Safety, Script Safety, Secrets, and Permissions results with a per-skill risk level. Use whenever someone asks to validate, audit, or security-check skills, or says things like "check all skills for issues", "is skill X safe?", "audit the workspace skills", "run a security scan on skills", "validate skills before committing", or "check skill health". Also trigger when a new skill has just been added and the user hasn't reviewed it yet.
Copy or sync skills between the .claude/skills, .cursor/skills, and .github/skills folders in the current repository. Use this skill whenever the user wants to copy skills between tool folders, sync skill directories, mirror skills, keep skills in sync across tools, or says things like "copy skills to cursor", "sync github skills to claude", "mirror skills", "copy skills from .github to .claude", "propagate skills", or asks to copy/move skills from one AI tool folder to another.
Generate or convert any content into a Slack Block Kit JSON payload using markdown blocks, ready to paste into the Slack API or a webhook. Accepts freeform text, structured data (status updates, reports, meeting summaries), or existing standard markdown and handles Slack-specific quirks like the 12,000-character limit, image-to-link conversion, and flat header rendering. Use this skill whenever the user says "format this for Slack", "create a Slack message", "convert to Slack markdown", "generate a Slack notification", "make this Slack-ready", "write a Slack announcement", or mentions Slack messages, Slack Block Kit, Slack webhooks, or Slack markdown — even if they just paste content and say "send this to Slack" or "post this in our channel".
| name | git-workflow-orchestrator |
| description | Run a phased git workflow: create branch (optional), commit, push, and open a GitHub pull request. Reports success or failure per phase and surfaces the PR URL when the final phase succeeds. Use when the user wants to ship a feature branch end-to-end or wants a single scripted pipeline with phase status. |
| argument-hint | branch name, commit message, or 'use orchestrator script' |
Coordinate git-branch-creator, git-commit-creator, git-push-creator, and git-pr-creator as sequential phases. After the last phase, return the pull request URL when available.
Use it for requests like:
Do not use it for:
main or develop) as the branch to push (push-creator blocks it)Opening a PR needs a GitHub token with the same resolution as git-pr-creator: GITHUB_TOKEN or GH_TOKEN, then repo-root github-pr.local.json (preferred for Copilot + Cursor skill layouts), then legacy .github/skills/git-pr-creator/config/github-pr.local.json. Details: git-pr-creator README.
Script-driven: run-git-ship-workflow.ps1 checks the token before Phase 1 when -DryRun is not set, then sets GH_TOKEN for subprocesses.
Agent-driven: Confirm a token is configured before Phase 4 (or at workflow start); if missing, stop and point to the git-pr-creator README.
Run each underlying skill in order. After every phase, state SUCCESS or FAILED and paste relevant script output. Stop on first failure.
Phase 1 — Branch — Follow git-branch-creator (staging question N/A; use its script with the requested branch name).
create-branch.ps1 exits 0, or user is already on the intended branch and you document SKIPPED with reason.Phase 2 — Commit — Follow git-commit-creator (staging prompt, preview, proposed message OK / Not OK, then commit).
git status --short if ambiguous).Phase 3 — Push — Follow git-push-creator (push-branch.ps1).
Phase 4 — PR — Follow git-pr-creator (create-pr.ps1).
gh pr create).When the user supplies a final commit message and wants one command, run:
pwsh -NoProfile -File ./.github/skills/git-workflow-orchestrator/scripts/run-git-ship-workflow.ps1 `
-BranchName "<name>" `
-CommitMessage "<message>" `
[-SkipBranch] `
[-BaseBranch <branch>] `
[-PrBase <branch>] `
[-ApproveInstall] [-ApproveAuth] `
[-AllowDuplicatePrefix] `
[-DryRun] `
[-ReportTokens]
-CommitMessage is required (stages all changes and commits in one step).-SkipBranch omits Phase 1 (use when already on the target branch).-BaseBranch is omitted, the script auto-detects the core branch (main preferred, then develop).-PrBase is omitted, it defaults to the resolved -BaseBranch value.-ApproveInstall / -ApproveAuth for headless gh setup when needed.Phase banners and subprocess output use the host stream so they stay visible when the script is invoked from tools that assign function output. On success, the script also emits PR_URL: <url> on the success stream for redirection or piping.
Interpret the script’s phase lines and final PR_URL: line for the user.
After all phases, respond with a compact table:
| Phase | Name | Status | Notes |
| ----- | ------ | -------- | ----- |
| 1 | Branch | SUCCESS | ... |
| 2 | Commit | SUCCESS | ... |
| 3 | Push | SUCCESS | ... |
| 4 | PR | SUCCESS | ... |
PR: <paste URL verbatim from gh output>
Use FAILED and stop populating later phases if a step errors. Include a short Notes reason on failure.
Activate by saying "with token reporting", "show tokens used", or "report_tokens: true".
Before Phase 1 — snapshot current session token count from the Claude Code session log:
# macOS / Linux
find "$HOME/.claude/projects" -name "*.jsonl" -type f 2>/dev/null \
| xargs ls -t 2>/dev/null | head -1
# Windows (PowerShell)
Get-ChildItem "$env:USERPROFILE\.claude\projects" -Recurse -Filter "*.jsonl" `
-ErrorAction SilentlyContinue | Sort-Object LastWriteTime -Descending `
| Select-Object -First 1 -ExpandProperty FullName
Read the last line of the JSONL file and extract the cumulative token total. Save as TOKENS_BEFORE.
After Phase 4 — read again, save as TOKENS_AFTER. Report the delta as tokens consumed during this workflow run.
If the session log is not readable, skip token reporting and note it in the summary.
-ReportTokens)The PowerShell subprocess has no access to Claude's session log. Instead it records per-phase wall-clock timing and appends it to the workflow summary:
=== Phase timing ===
Phase 1 Branch : 1.2s
Phase 2 Commit : 0.8s
Phase 3 Push : 3.1s
Phase 4 PR : 4.7s
Total : 9.8s
Note: token count unavailable in script-driven mode.
| Phase | Name | Status | Notes |
| ----- | ------ | ------- | ----- |
| 1 | Branch | SUCCESS | ... |
| 2 | Commit | SUCCESS | ... |
| 3 | Push | SUCCESS | ... |
| 4 | PR | SUCCESS | ... |
PR: <url>
Tokens used during orchestration: ~12,400 (input: 9,800 / output: 2,600)
.github/skills/*/scripts/; do not reimplement git operations in the orchestrator narrative.main or develop) via this workflow (push-creator will refuse; report FAILED if attempted).