start
Skill30 starsChanged 3 months agoMITView on GitHub
Start a new PR by creating a feature branch following repo conventions
130 other projects use a version of this.
Adopted by
Most recently taken up by
- ansvisor/ansvisortheir own version, first seen Nov 8, 2026
- dsifry/metaswarmtheir own version, first seen Nov 8, 2026
- ai-search-guru/getcito-worlds-first-open-source-aio-aeo-or-geo-tooltheir own version, first seen Nov 8, 2026
- paulocsb/worldcup-fifa-pooltheir own version, first seen Nov 8, 2026
- srinator22/New-Projecttheir own version, first seen Nov 8, 2026
- Memolok/Claude-plugintheir own version, first seen Nov 6, 2026
Used with
Projects with it also use setup-engine, team-audio and 10 more.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
CoralGameSkillsetup-engine
Configure the project's game engine and version. Pins the engine in CLAUDE.md, detects knowledge gaps, and populates engine reference docs via WebSearch when the version is beyond the LLM's training data.
Also in 13 projects that use this
CoralGameSkillteam-audio
Orchestrate audio team: audio-director + sound-designer + technical-artist + gameplay-programmer for full audio pipeline from direction to implementation.
Also in 13 projects that use this
lilangMaxSkillcreate-stories
Break a single epic into implementable story files. Reads the epic, its GDD, governing ADRs, and control manifest. Each story embeds its GDD requirement TR-ID, ADR guidance, acceptance criteria, story type, and test evidence path. Run after /create-epics for each epic.
Also in 11 projects that use this
lilangMaxSkillstory-done
End-of-story completion review. Reads the story file, verifies each acceptance criterion against the implementation, checks for GDD/ADR deviations, prompts code review, updates story status to Complete, and surfaces the next ready story from the sprint.
Also in 11 projects that use this
- +5 more from CoralGame
- +3 more from lilangMax
Other versions130 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 130
- anthropics/knowledge-work-plugins★ 35ksame name
- Donchitos/Claude-Code-Game-Studios★ 27ksame name
- openai/plugins★ 7.8ksame name
- SterlingChin/marvin-template★ 1ksame name
- educlopez/ui-craft★ 441same name
- ai-search-guru/getcito-worlds-first-open-source-aio-aeo-or-geo-tool★ 432same name
- dsifry/metaswarm★ 426same name
- pixel-cellar/Claude-Code-Game-Studios★ 324same name
- ansvisor/ansvisor★ 233same name
- alexeykrol/claude-code-starter★ 194same name
120 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository23 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- change-briefSkill
- clean-goneSkill
- close-customer-loopSkill
- commitSkill
- finishSkill
- notificationsSkill
- plan-qaSkill
- plan-tddSkill
- release-notesSkill
- releaseSkill
- review-requestSkill
- reviewSkill
- review-watchSkill
- rfcSkill
- setupSkill
- standupSkill
- start-qaSkill
- statusSkill
- syncSkill
- tddSkill
- updateSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
15 rules. 0 are common, 9 are distinctive, and 6 are very specific to this project.
0
Common
Most of the 117 edited versions we read keep these.
9
Distinctive
This author's own choices. Worth a look.
6
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 54
Ask the user for the following information (use the active host user-input mechanism):
- Very specific: line 76
If commits.requireTicket: true in config, ticket is required
- Distinctive: line 78
If no ticket provided and not required, proceed without it
- Distinctive: line 104
If a ticket ID was provided and issue tracker is configured:
- Distinctive: line 116
If Linear ticket format is detected, use the Linear MCP server:
- Distinctive: line 127
If Jira is configured, use the Jira MCP server:
- Distinctive: line 138
If GitHub format detected:
- Distinctive: line 199
If branch already exists, ask: "Branch exists.
- Distinctive: line 200
If not on expected base branch, warn and confirm
- Very specific: line 204
Create .git-workflow/pr-context.json with collected information:
- Very specific: line 229
Create .git-workflow/ before writing.
- Very specific: line 230
If .git-workflow/pr-context.json exists, ask before overwriting.
- Very specific: line 231
Never overwrite or delete the legacy .claude/.pr-context.json fallback.
- Distinctive: line 248
If ticket details were fetched, include:
- Very specific: line 258
All configurable options from .git-workflow/config.yaml:
“Common” is measured: kept by at least 6 in 10 of the 117 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Cross-runtime: follow runtime compatibility for invocation, delegation, configuration precedence, state paths, and permissions.
You are helping create a new pull request. Your task is to create a properly named feature branch, optionally fetch ticket details, and store context for subsequent commands.
Step 1: Load Configuration
Resolve project configuration with canonical-first precedence:
if [ -f ".git-workflow/config.yaml" ]; then
CONFIG_PATH=".git-workflow/config.yaml"
elif [ -f ".claude/config.yaml" ]; then
CONFIG_PATH=".claude/config.yaml" # legacy read-only fallback
else
CONFIG_PATH=""
fiConfiguration Priority:
.git-workflow/config.yaml(if exists).claude/config.yaml(legacy read-only fallback)- Auto-detection (package.json, pyproject.toml, etc.)
- Sensible defaults
Default Values (when no config):
workflow:
type: staging
developmentBranch: staging
productionBranch: main
branches:
feature: "{type}/{ticket}-{description}"
commits:
types: [Feature, Fix, Hotfix, Refactor, Docs, Test, Chore]
requireTicket: false
ticketPattern: "^[A-Z]+-\\d+$"
issueTracker:
type: autoStep 2: Gather Information
Ask the user for the following information (use the active host user-input mechanism):
Question 1: Ticket ID
Question: "What is the ticket ID or URL?"
- Examples:
PROJ-1234(Jira format)ENG-456(Linear format)#789(GitHub issue)https://linear.app/team/issue/ENG-456/...https://your-org.atlassian.net/browse/PROJ-1234
Parsing Logic:
- Extract ticket ID from URL if provided
- Linear: Pattern
/issue/([A-Z]+-\d+)/ - Jira: Pattern
/browse/([A-Z]+-\d+) - GitHub: Pattern
issues/(\d+)or#(\d+)
Validation:
- If
commits.requireTicket: truein config, ticket is required - Validate against
commits.ticketPatternif provided - If no ticket provided and not required, proceed without it
Question 2: Change Type
Question: "What type of change is this?"
Options (from config or defaults):
feature- New feature or enhancementfix- Bug fixhotfix- Urgent production fixchore- Maintenance, dependencies, etc.refactor- Code refactoringdocs- Documentation changes
Question 3: Short Description
Question: "Provide a brief description (will be converted to kebab-case)"
Examples:
- "add user authentication" ->
add-user-authentication - "fix memory leak in parser" ->
fix-memory-leak-in-parser
Step 3: Fetch Ticket Details (Optional)
If a ticket ID was provided and issue tracker is configured:
Auto-Detect Issue Tracker Type
Based on ticket format and available MCP servers:
^[A-Z]+-\d+$with Linear MCP available -> Linear^[A-Z]+-\d+$with Jira config/MCP available -> Jira^#?\d+$or GitHub URL -> GitHub Issues (viaghCLI)
Linear Integration
If Linear ticket format is detected, use the Linear MCP server:
# Fetch ticket details via Linear MCP
mcp__linear__get_issue(id: ticketId)The MCP server handles authentication automatically via OAuth.
Jira Integration
If Jira is configured, use the Jira MCP server:
# Fetch ticket details via Jira MCP
mcp__jira__get_issue(issueKey: ticketId)The MCP server handles authentication automatically. The jira.baseUrl from config is used to identify the Jira instance.
GitHub Issues
If GitHub format detected:
# Use gh CLI to fetch issue
gh issue view {issue_number} --json title,body,stateStore Fetched Data:
{
"ticket_title": "Fetched title from issue tracker",
"ticket_description": "Description from issue tracker",
"ticket_status": "In Progress"
}Step 4: Create Branch
Generate Branch Name
Apply the branch pattern from config (default: {type}/{ticket}-{description}):
Pattern: {type}/{ticket}-{description}
Type: fix
Ticket: proj-1234
Description: add-user-auth
Result: fix/proj-1234-add-user-authBranch Naming Rules:
- Convert ticket to lowercase
- Convert description to kebab-case (lowercase, hyphens)
- Remove special characters
- Limit total length to 100 characters
Examples:
fix/proj-1234-standardize-token-info-schemafeature/eng-456-add-holder-analysishotfix/abc-789-fix-critical-bugchore/update-dependencies(no ticket)
Create and Checkout Branch
Immediately before running any command below, show the resolved base branch, pull target, new branch name, and canonical context destination. Ask for explicit confirmation to create and check out the branch. Do not treat automatic skill invocation or earlier information-gathering answers as approval.
# Ensure we're on the development branch and up-to-date
git checkout {workflow.developmentBranch} 2>/dev/null || git checkout main
git pull
# Create feature branch
git checkout -b {branch_name}Error Handling:
- If branch already exists, ask: "Branch exists. Switch to it or create a new name?"
- If not on expected base branch, warn and confirm
Step 5: Store Context
Create .git-workflow/pr-context.json with collected information:
mkdir -p .git-workflow{
"ticket_id": "PROJ-1234",
"ticket_url": "https://issue-tracker.com/PROJ-1234",
"ticket_title": "Title from issue tracker (if fetched)",
"branch": "fix/proj-1234-description",
"type": "fix",
"description": "Human readable description",
"started_at": "2025-01-17T12:00:00Z",
"config": {
"workflow": "staging",
"developmentBranch": "staging",
"productionBranch": "main"
}
}Important:
- Create
.git-workflow/before writing. - If
.git-workflow/pr-context.jsonexists, ask before overwriting. - Never overwrite or delete the legacy
.claude/.pr-context.jsonfallback.
Step 6: Confirm
Output a confirmation message:
Created branch: {branch_name}
Ticket: {ticket_id} {ticket_title if fetched}
Type: {type}
Next steps:
1. Make your code changes
2. Run /commit to stage and commit your changes
3. Run /finish to create the pull requestIf ticket details were fetched, include:
Ticket Details:
- Title: {ticket_title}
- Status: {ticket_status}Configuration Reference
All configurable options from .git-workflow/config.yaml:
| Setting | Default | Description |
workflow.developmentBranch | staging | Base branch for feature branches |
branches.feature | {type}/{ticket}-{description} | Branch naming pattern |
commits.types | Feature, Fix, Hotfix... | Allowed change types |
commits.requireTicket | false | Enforce ticket ID |
commits.ticketPattern | ^[A-Z]+-\d+$ | Regex for ticket validation |
issueTracker.type | auto | linear, jira, github, none |
Error Handling
| Scenario | Action |
| Branch already exists | Ask to switch or rename |
| Ticket required but missing | Prompt for ticket ID |
| Invalid ticket format | Show expected format, ask to retry |
| Issue tracker API fails | Warn and continue without ticket details |
| Not on expected branch | Warn and ask for confirmation |
| Uncommitted changes | Warn and ask to stash or commit first |
.pr-context.json exists | Ask to overwrite or abort |
Examples
Basic Usage (No Config)
User: /start
Agent: What is the ticket ID? -> "PROJ-123"
Agent: What type of change? -> "fix"
Agent: Brief description? -> "fix login timeout"
Result: Branch fix/proj-123-fix-login-timeout createdWith Linear Integration (via MCP)
User: /start
Agent: What is the ticket ID? -> "ENG-456"
[Uses Linear MCP to fetch: "Add OAuth2 support"]
Agent: What type? -> "feature"
Agent: Description? -> "oauth2-authentication"
Result: Branch feature/eng-456-oauth2-authentication created
Ticket: ENG-456 - Add OAuth2 supportWithout Ticket (When Not Required)
User: /start
Agent: What is the ticket ID? -> (skip)
Agent: What type? -> "chore"
Agent: Description? -> "update dependencies"
Result: Branch chore/update-dependencies createdDoes it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

