ワンクリックでManusで任意のスキルを実行

git-workflow

スター6

フォーク0

更新日2026年6月25日 13:05

Standard git workflow for everyday development — branching, committing, rebasing, pull requests, reviewing, merging, and changelog generation. Use when asked to perform git operations, prepare a PR, resolve merge conflicts, or generate release notes.

インストール

Codex または Claude でインストールこの Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。

Manusで実行

ソース

Eslzzyl

Eslzzyl/tidev

GitHub リポジトリを開く Creator のリポジトリを見る

ダウンロード

Manusで実行

Git Workflow

Standard git operations for any project.

Branching

Never create a new branch for simple commits or pushes. Always commit directly to the current branch unless the user explicitly requests otherwise.
PRs are the exception. When the user asks to open a pull request, creating a feature/fix branch is expected as part of the PR workflow.
Conventions when branching IS explicitly requested:
- Feature branches: feat/<short-description> or <username>/<feature-name>
- Bug fixes: fix/<issue-number>-<description>
- Chores/refactoring: chore/<description>
- Base feature/fix branches off the default branch (main, master, dev)

Committing

Write clear, conventional commit messages:

<type>: <short summary>                 (subject, max 72 chars)

<body>                                   (optional, wrap at 72 chars)

Common types: feat, fix, chore, refactor, docs, test, style, perf, ci

Guidelines:

One logical change per commit
The subject line should complete "This commit will..." (e.g., "fix: handle empty input gracefully")
Use imperative mood ("add" not "added" or "adds")
Reference issue numbers when applicable: fix #123: ...

Pull Requests

Before Opening

Rebase onto the latest target branch: git rebase origin/main
Resolve any merge conflicts locally
Run tests: build, lint, typecheck, test
Review your own diff before submitting
Ensure each commit compiles and passes tests (bisect-friendly)

PR Description

## Summary
What this change does and why.

## Changes
- Bullet list of key changes
- Focus on what is notable, not every file touched

## Testing
How the change was tested: specific commands, scenarios, edge cases.

## Breaking Changes
List any breaking changes and migration steps, or "None."

Code Review

Respond to review comments promptly
Each comment should get a reply or a fix
After addressing feedback, re-request review
Keep conversations focused on the code

Merging

Strategies

Squash merge: For feature branches with many small/pending commits. Produces one clean commit.
Rebase merge: When you want to preserve individual commit history with linear history.
Merge commit: For collaborative branches where multiple people committed.

After Merge

Delete the feature branch (remote and local)
Update any related issues

Changelog Generation

To generate changelog from git history between two references:

git log --oneline <from-tag>..HEAD --no-decorate

Categorize changes by type (feat, fix, chore, etc.) using the commit message prefixes. Group breaking changes separately with a "⚠️ Breaking Changes" header.

Handling Merge Conflicts

git merge <branch> or git rebase <branch> will stop at conflicts
Use git status to find conflicted files
Open each file and resolve conflict markers (<<<<<<<, =======, >>>>>>>)
git add <resolved-file> to mark as resolved
git rebase --continue or git merge --continue
Verify the build still works after resolution

このリポジトリの他の Skills

同じリポジトリ

code-review

Eslzzyl/tidev

General code review methodology covering logic, security, performance, readability, testing, and breaking changes. Use when asked to review code, check a pull request, evaluate a diff, or assess code quality in any language.

2026-06-256

debug

Eslzzyl/tidev

Systematic debugging methodology for any programming language or project. Use when investigating a bug, unexpected behavior, test failure, or error condition. Provides a structured approach to isolate root causes and verify fixes.

2026-06-256

skill-creator

Eslzzyl/tidev

Create or improve AgentSkills for this coding assistant. Use when asked to create a new skill, package a skill, edit an existing skill, or set up skill infrastructure. Guides designing SKILL.md with proper YAML frontmatter, writing effective prompts, organizing companion files, and testing skills.

2026-06-256

inspect-tidev-db

Eslzzyl/tidev

Debug tidev's database by searching session titles, exporting decompressed copies, and inspecting messages. Use when investigating session data, diagnosing storage issues, or auditing conversation history.

2026-05-176

name	git-workflow
description	Standard git workflow for everyday development — branching, committing, rebasing, pull requests, reviewing, merging, and changelog generation. Use when asked to perform git operations, prepare a PR, resolve merge conflicts, or generate release notes.

Git Workflow

Standard git operations for any project.

Branching

Never create a new branch for simple commits or pushes. Always commit directly to the current branch unless the user explicitly requests otherwise.
PRs are the exception. When the user asks to open a pull request, creating a feature/fix branch is expected as part of the PR workflow.
Conventions when branching IS explicitly requested:
- Feature branches: feat/<short-description> or <username>/<feature-name>
- Bug fixes: fix/<issue-number>-<description>
- Chores/refactoring: chore/<description>
- Base feature/fix branches off the default branch (main, master, dev)

Committing

Write clear, conventional commit messages:

<type>: <short summary>                 (subject, max 72 chars)

<body>                                   (optional, wrap at 72 chars)

Common types: feat, fix, chore, refactor, docs, test, style, perf, ci

Guidelines:

One logical change per commit
The subject line should complete "This commit will..." (e.g., "fix: handle empty input gracefully")
Use imperative mood ("add" not "added" or "adds")
Reference issue numbers when applicable: fix #123: ...

Pull Requests

Before Opening

Rebase onto the latest target branch: git rebase origin/main
Resolve any merge conflicts locally
Run tests: build, lint, typecheck, test
Review your own diff before submitting
Ensure each commit compiles and passes tests (bisect-friendly)

PR Description

## Summary
What this change does and why.

## Changes
- Bullet list of key changes
- Focus on what is notable, not every file touched

## Testing
How the change was tested: specific commands, scenarios, edge cases.

## Breaking Changes
List any breaking changes and migration steps, or "None."

Code Review

Respond to review comments promptly
Each comment should get a reply or a fix
After addressing feedback, re-request review
Keep conversations focused on the code

Merging

Strategies

Squash merge: For feature branches with many small/pending commits. Produces one clean commit.
Rebase merge: When you want to preserve individual commit history with linear history.
Merge commit: For collaborative branches where multiple people committed.

After Merge

Delete the feature branch (remote and local)
Update any related issues

Changelog Generation

To generate changelog from git history between two references:

git log --oneline <from-tag>..HEAD --no-decorate

Categorize changes by type (feat, fix, chore, etc.) using the commit message prefixes. Group breaking changes separately with a "⚠️ Breaking Changes" header.

Handling Merge Conflicts

git merge <branch> or git rebase <branch> will stop at conflicts
Use git status to find conflicted files
Open each file and resolve conflict markers (<<<<<<<, =======, >>>>>>>)
git add <resolved-file> to mark as resolved
git rebase --continue or git merge --continue
Verify the build still works after resolution