القائمة
You MUST use this for branch name requests and branch actions. Create, switch, or rename Git branches using repository-aware branch naming conventions.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Scans Jira for stale issues, duplicates, and missing fields, then fixes what the user approves. Use when the user says the board is a mess, asks for a backlog grooming pass, wants to clean up Jira, or asks about stale/duplicate tickets before sprint planning.
The front door to this plugin. Listens to what the user needs right now — vague or specific — and routes them to the right skill. Trigger whenever the user asks "what can you do," "help me with the team/board/sprint," "what should I focus on," or any open-ended project-management request that doesn't clearly match a single skill.
Update, create, or reprioritize the team's roadmap. Use when adding a new initiative and deciding what moves to make room, shifting priorities after new information comes in, moving timelines due to a dependency slip, or building a Now/Next/Later view from Jira epics.
Closes out a 2-week sprint — reconciles planned vs. completed scope, flags spillover and scope creep, writes a retro-ready summary, and gives a heads-up on the next sprint's readiness. Use when the user says the sprint is ending, asks for a sprint report, wants retro prep, or asks what's carrying over to next sprint.
Plan the next 2-week sprint — scope work from the Jira backlog, estimate team capacity (accounting for PTO), set a sprint goal, and draft a sprint plan. Use when kicking off a new sprint, sizing the backlog against team availability, deciding what's P0 vs. stretch, or handling carryover flagged by `sprint-close`.
Generates a one-page weekly status brief from Jira — sprint burndown, what shipped, what's blocked, and the week ahead. Built for a Scrum team running 2-week sprints. Use when the user asks for a status update, standup summary, sprint check-in, or "what's the team working on."
| name | git-branch |
| description | You MUST use this for branch name requests and branch actions. Create, switch, or rename Git branches using repository-aware branch naming conventions. |
| license | Apache-2.0 |
| metadata | {"author":"Oleg Shulyakov","version":"1.0.0","source":"github.com/olegshulyakov/agent.md","catalog":"utility","category":"version-control","tags":["git","branch"]} |
Generate, switch, and apply clear Git branch names that follow repository and team conventions.
Use when the user asks to generate, suggest, improve, or review a branch name.
For pure generation requests, return only the branch name unless the user asks for options or rationale. Reviews may include concise, actionable feedback.
Use when the user asks to create, start, switch, check out, or rename a branch.
<type>/<ticket-id>-<short-description>
| Part | Required | Notes |
|---|---|---|
type | Yes | Category prefix (see below) |
ticket-id | If available | Lowercase issue/ticket ID, e.g. proj-123 or 42 |
short-description | Yes | kebab-case summary of the work |
Examples:
feature/proj-42-user-authenticationbugfix/proj-101-fix-login-redirecthotfix/payment-null-pointer-crashchore/upgrade-node-18release/v2.4.0| Prefix | When to Use |
|---|---|
feature/ | New functionality or user-facing capability |
bugfix/ | Non-urgent bug fixes going through normal workflow |
hotfix/ | Urgent fixes that go directly to production/main |
release/ | Release preparation branches (release/v1.2.0) |
chore/ | Maintenance, dependency updates, config changes, refactors |
docs/ | Documentation-only changes |
test/ | Adding or fixing tests with no production code change |
experiment/ | Exploratory work, spikes, or proof-of-concepts |
Treat these user words as branch action intent:
| User wording | Git behavior |
|---|---|
create a branch | Create a new branch from the current HEAD |
start a branch | Create and switch to a new branch |
checkout a branch | Create/switch if clearly requested by the user |
switch to a branch | Switch to an existing branch, or create if asked |
rename this branch | Rename the current branch after checking context |
Prefer git switch -c <branch> for creating and switching to a new branch. Prefer git switch <branch> for switching to an existing branch.
kebab-case only — Use hyphens, never underscores or spaces.
feature/user-profile-settingsfeature/user_profile_settingsfeature/User Profile SettingsLowercase — All characters should be lowercase.
bugfix/proj-99-fix-api-timeoutBugFix/Proj-99-Fix-API-TimeoutKeep it short but descriptive — Aim for 3–6 words in the description segment. Max ~60 characters total.
feature/add-dark-mode-togglefeature/add-a-new-dark-mode-toggle-setting-to-the-user-preferences-pageNo special characters — Use one / between the type prefix and branch
description. Otherwise, avoid /, \, @, #, ~, ^, :, ?, *,
and spaces; hyphens are the only other allowed non-alphanumeric characters.
Include ticket ID when available — Makes branches traceable to issues.
bugfix/gh-204-session-expiry-errorfeature/123-export-to-csv (if project uses numeric IDs only)No trailing slashes or dots.
feature/add-search.feature/Check it against:
fix or stuff)?Give specific, actionable feedback. If the name is mostly fine, say so and suggest a small tweak. If it's unclear what the branch is for, ask what the task is before suggesting a name.