メニュー
Git conventions for commit messages and workflow. Use for git commit, conventional commits, branch strategy, rebasing, merge conflicts, git workflow. Not for general code changes that happen to need a commit afterward.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | source-control |
| description | Git conventions for commit messages and workflow. Use for git commit, conventional commits, branch strategy, rebasing, merge conflicts, git workflow. Not for general code changes that happen to need a commit afterward. |
| allowed-tools | ["Bash"] |
git commit -m "feat: add user authentication"
git checkout -b feat/user-auth
git fetch origin && git rebase origin/main
git stash && git stash pop
Format: <type>(<scope>): <subject> (scope/body/footer optional)
| Type | Use |
|---|---|
feat | New feature |
fix | Bug fix |
docs | Documentation |
style | Formatting |
refactor | Code restructure |
perf | Performance |
test | Tests |
chore | Maintenance |
ci | CI/CD |
build | Build system |
revert | Revert commit |
Rules: Imperative mood, present tense, lowercase, no period, max 50 chars
# Good
git commit -m "feat(auth): add JWT validation"
git commit -m "fix: resolve race condition"
# Bad
git commit -m "Fixed stuff" # Not conventional
git commit -m "Feat: Add thing" # Capital letter
Check state:
git status && git diff HEAD && git branch --show-current && git log --oneline -5
Verify NOT on main/master (abort if so, unless authorized)
Stage specific files (never git add -A):
git add <specific-files>
Commit with conventional format:
git commit -m "<type>(<scope>): <subject>"
| Type | Pattern |
|---|---|
| Feature | feat/user-auth, feature/dashboard |
| Fix | fix/login-bug, bugfix/api-error |
| Hotfix | hotfix/security-patch |
| Chore | chore/update-deps |
# Start feature
git checkout main && git pull origin main
git checkout -b feat/user-auth
# Keep up to date
git fetch origin && git rebase origin/main
# After PR merged
git checkout main && git pull
git branch -d feat/user-auth
| Use | When |
|---|---|
| Rebase | Keep feature branch current, clean linear history |
| Merge | Integrate to main (via PR), preserve history |
After a PR is opened, CI failures and review comments arrive asynchronously. Instead of Max polling, offer a time-based loop:
/loop 10m check PR #<N>: if CI failed, diagnose and fix; if new review comments, address them; commit fixes on the PR branch and push; stop when CI is green and no comments are unaddressed
Rules for the loop:
/loop on a PR is the explicit push authorization, scoped to that PR branch and that loop session only. Outside a PR loop, the NEVER-push rule stands unchanged.--force-with-lease only, and only for rebase-on-main conflicts Max asked for.make check && make test-e2e); hooks are never bypassed under loop time pressure.main/master unless explicitly authorized--force-with-lease, never bare --force on shared branchesmake check && make test-e2e before committing (see language skills for the expansion)Execution trace capture and token baselining. Use when user says trace, extract trace, count tokens, token baseline, or /harness-trace. Not for harness optimization (use harness-mechanic).
Release prep and tagging with pre-flight verification. Use when user says release, tag, ship it, push to production, create release, or bump version. Not for editing a version string outside a release, a lockfile or a changelog entry by hand, and not for reading what changed in a past release: those are ordinary edits, just do them.
Mine LEARNING.md retrospectives across all repos for recurring failure-modes, then propose harness changes (hooks, rules, skills, checklist items) with falsifiable change-contracts. Also runs the doc-gardening pass over the governance docs (stale rules, dead cross-references, skill-table drift). Use when user says learning loop, mine learnings, recurring failures, what should I fix in my process, cross-repo retrospective, doc gardening, stale docs, or run learning-loop. Runs on human schedule, never autonomously. Not for single-project retrospectives (use learning-docs) or trace/token analysis (use harness-mechanic).
Full contractor-mode loop: sub-protocols (LOCALIZE, BENCH-BASELINE, REPRODUCE, DRIFT), review routing by file pattern, blast radius, UAT, parallelism and effort caps, escalation, just-do-it, goal-backed runs. Load it to RUN that loop, once you have an approved plan and are entering step 1, or when a step needs its detail. It is a protocol, not a way to do the work: it never replaces the language, review or planning skill the task itself calls for, and a task small enough to just edit (SKIP_SET) needs none of it. The always-on spine lives in rules/orchestrator-protocol.md. Not for trace capture (harness-trace) or harness optimization (harness-mechanic).
Ruby on Rails with service-oriented architecture, Dry-validation, Sidekiq/Solid Queue, Hotwire. Use for Rails API, Rails services, Rails forms, RSpec, ActiveRecord, Rails migrations. Not for standalone Ruby gems (use ruby skill), and not for judging whether a migration is safe to run in production (that is the database-reviewer agent).
Get three independent second opinions (isolated Claude + isolated Gemini + isolated DeepSeek) on a problem Claude is analyzing. Use when user says second opinion, another perspective, challenge this approach, or asks gemini/deepseek about a decision, approach, or diagnosis. Also invoke on your own initiative, without being asked: on a complex task before planning, after 2 failed root-cause attempts, on a 🔴 decision (rewrite, core logic, security), or when the review loop is stuck below 80 after 2 fix rounds. Gathers context, writes a focused prompt, calls all reviewers in isolated Docker containers, and synthesizes all viewpoints. Not for reviewing code or changes, even phrased as 'ask gemini to review' (use gemini-review).