Handle an explicit Git intent such as branch/worktree setup, commit organization, history archaeology, conflict resolution, PR preparation, or versioning; do not trigger as a process skill for every code or file change.
インストール方法を見るインストールする前に、エージェントに与えられる指示の中身を確認できます。
Git is your safety net. Treat commits as save points, branches as sandboxes, and history as documentation. With AI agents generating code at high speed, disciplined version control is the mechanism that keeps changes manageable, reviewable, and reversible.
Use when the user asks for a Git operation or artifact, or when a concrete branch/worktree/conflict/history decision is the current primary task. Ordinary implementation follows the canonical global Git safety rules directly without loading this workflow.
Near misses: checking status/diff as routine evidence, editing several files, making a savepoint note, or finishing implementation does not select this skill by itself.
ROSE/aili-delivery-flow owns lifecycle state, safe-local execution, approvals, and verification. This skill owns one bounded Git loop and returns complete, need-user, need-evidence, material-delta, blocked, or Unverified. It does not invoke planning, implementation, review, release, or another process skill. Exact commit/push/merge/rebase/history/worktree/A33 approvals and canonical claim-matched verification override generic advice below.
For any task that writes files, do not work directly on main, master, or trunk. Treat protected trunks as integration targets, not AI editing areas.
Before editing:
git status --short --branch.main, master, or trunk, create and switch to a task branch before editing.🛑 Hard gates:
| Situation | Required action |
|---|---|
On main, master, or trunk for a write task | Do not edit until on an approved task branch/worktree. |
| User/task forbids commits | Do not create savepoint commits; still inspect diff and verify. |
| Push, merge, PR creation, branch deletion, or worktree removal requested | Require explicit user approval for that exact action. |
| Force-push, reset hard, clean, skipped hooks, or shared-history rewrite | Require explicit approval and report safer alternatives first. |
| Unrelated dirty workspace | Stop and ask; do not auto-stash, auto-clean, or auto-worktree. |
Branch naming:
feature/<short-slug> for featuresfix/<short-slug> for bug fixesrefactor/<short-slug> for refactorsdocs/<short-slug> for documentationchore/<short-slug> for tooling/configurationSmall changes:
git switch -c <type>/<task-slug> so the working tree actually moves to the new branch.Large or risky changes:
../<repo>-<task-slug>..worktrees/<task-slug> only if .worktrees/ is ignored in that downstream project; do not add .worktrees/ to this workflow repository just because another project uses worktrees.git worktree add -b <type>/<task-slug> ../<repo>-<task-slug> <base-branch>.Savepoint commits:
git diff and git diff --staged before committing.wip: checkpoints are allowed only when the current task explicitly approves a private unverified checkpoint on a private task branch; they must not be merged as-is.Task-end branch/worktree hygiene for non-trivial changes:
git status --short --branch in the target repository and inspect the relevant diff.Never:
main, master, or trunkUse this mode when organizing unstaged or staged changes, planning commits, drafting commit messages, or preparing a PR.
Rules:
git status --short --branch, git diff, and git diff --staged before proposing commits.Use this mode when the user asks:
Workflow:
git log, git show, git blame, and targeted path history.Use this mode when preparing a change for review or PR.
Rules:
Decision matrix:
| Task type | Branch | Worktree | Savepoint commit |
|---|---|---|---|
| Read-only explanation or review | No | No | No |
| Small docs change | Required | Usually no | Only when current task/project rules allow |
| Small code fix | Required | Usually no | Only when current task/project rules allow |
| Multi-file feature | Required | Recommended | Per complete verified slice when allowed |
| Large refactor or migration | Required | Required | Per complete verified phase when allowed |
| Parallel subagent or multi-approach exploration | Required | Required | Independently per approach when allowed |
| Current workspace has unrelated changes | Required | Required | Avoid mixing existing edits; ask first |
| User says not to pollute the current branch | Required | Usually required | Only in isolated branch/worktree and when allowed |
Keep main always deployable. Work in short-lived feature branches that merge back within 1-3 days. Long-lived development branches are hidden costs — they diverge, create merge conflicts, and delay integration. DORA research consistently shows trunk-based development correlates with high-performing engineering teams.
main ──●──●──●──●──●──●──●──●──●── (always deployable)
╲ ╱ ╲ ╱
●──●─╱ ●──╱ ← short-lived feature branches (1-3 days)
This is the recommended default. Teams using gitflow or long-lived branches can adapt the principles (atomic commits, small changes, descriptive messages) to their branching model — the commit discipline matters more than the specific branching strategy.
When current task/project rules explicitly allow task-scoped verified commits, each successful increment can get its own savepoint commit. Otherwise, record the verified increment in the cleanup package and ask once instead of committing proactively. Don't accumulate large unreviewed changes.
Work pattern:
Implement slice → Test → Verify → Commit if allowed / report savepoint → Next slice
Not this:
Implement everything → Hope it works → Giant commit
Allowed commits are save points. If the next change breaks something, use an approved recovery path to return to the last known-good state. When commits are not allowed, preserve the verified state in the cleanup package and ask for the next git action.
Each commit does one logical thing:
# Good: Each commit is self-contained
git log --oneline
a1b2c3d Add task creation endpoint with validation
d4e5f6g Add task creation form component
h7i8j9k Connect form to API and add loading state
m1n2o3p Add task creation tests (unit + integration)
# Bad: Everything mixed together
git log --oneline
x1y2z3a Add task feature, fix sidebar, update deps, refactor utils
Commit messages explain the why, not just the what:
# Good: Explains intent
feat: add email validation to registration endpoint
Prevents invalid email formats from reaching the database.
Uses Zod schema validation at the route handler level,
consistent with existing validation patterns in auth.ts.
# Bad: Describes what's obvious from the diff
update auth.ts
Format:
<type>: <short description>
<optional body explaining why, not what>
Types:
feat — New featurefix — Bug fixrefactor — Code change that neither fixes a bug nor adds a featuretest — Adding or updating testsdocs — Documentation onlychore — Tooling, dependencies, configDon't combine formatting changes with behavior changes. Don't combine refactors with features. Each type of change should be a separate commit — and ideally a separate PR:
# Good: Separate concerns
git commit -m "refactor: extract validation logic to shared utility"
git commit -m "feat: add phone number validation to registration"
# Bad: Mixed concerns
git commit -m "refactor validation and add phone number field"
Separate refactoring from feature work. A refactoring change and a feature change are two different changes — submit them separately. This makes each change easier to review, revert, and understand in history. Small cleanups (renaming a variable) can be included in a feature commit at reviewer discretion.
Prefer coherent, reviewable commits over artificial line-count targets. Changes over ~1000 lines should be split by behavior, risk, or ownership. See the splitting strategies in code-review-and-quality for how to break down large changes.
Focused complete change → Easy to review, easy to revert
Single logical change → Acceptable when scoped and verified
Oversized mixed change → Split into smaller changes
Branching is mandatory for write tasks. git branch <name> only creates a branch head; it does not switch the working tree. Use git switch -c <branch> for small changes, or git worktree add -b <branch> <path> <base> for isolated large work.
main (always deployable)
│
├── feature/task-creation ← One feature per branch
├── feature/user-settings ← Parallel work
└── fix/duplicate-tasks ← Bug fixes
main (or the team's default branch) before editingfeature/<short-description> → feature/task-creation
fix/<short-description> → fix/duplicate-tasks
docs/<short-description> → docs/api-examples
chore/<short-description> → chore/update-deps
refactor/<short-description> → refactor/auth-module
When the active contract selects a33-attached-shared-trust-domain, this section overrides the generic sibling-worktree examples below.
<session-root>/.worktrees/<repo_key>/<worktree_key>. Both keys must match ^[A-Za-z0-9][A-Za-z0-9._-]{0,63}$; reserved/path-like/control values and all path, key, branch, or worktree collisions block without guessing, suffixing, forcing, -B, orphan creation, remote guessing, or implicit ref selection./.worktrees/, with no re-inclusion or tracked destination. Missing ignore admission blocks and requires an explicit user-owned host ignore change..gitmodules, mode-160000 gitlinks, source/superproject relations, malformed submodule topology, and ambiguous symlink/junction/mount/path escape.branch_mode:existing|create, source reflog_policy:enabled|disabled, operation class, expiry, and accepted trusted-code risk under one fresh approval. Every later non-force remove requires a distinct fresh approval after complete deletion inventory.Record exact no-digest A33Identity host/source/target objects and compare typed fields, sorted canonical repository-relative file arrays, and explicit before/after admin deltas directly. Re-read target rules at each operation/dispatch boundary; they may narrow but never broaden, and same-level conflicts block. One lane targets one declared repository and writes artifacts there. All declared result fields are present; JSON null represents absent/inapplicable data, except observed REMOVE approval trusted_code_risk:not_applicable.
For parallel AI agent work, use git worktrees to run multiple branches simultaneously:
# Create and checkout feature branches in separate worktrees
git worktree add -b feature/task-creation ../project-task-creation main
git worktree add -b feature/user-settings ../project-user-settings main
# Each worktree is a separate directory with its own branch
# Agents can work in parallel without interfering
ls ../
project/ ← main branch
project-task-creation/ ← task-creation branch
project-user-settings/ ← user-settings branch
# After approved merge, clean up the worktree only with user approval
git worktree remove ../project-task-creation
Benefits:
Agent starts work
│
├── Makes a change
│ ├── Test passes? → Commit if allowed; otherwise note in cleanup package → Continue
│ └── Test fails? → Revert to last commit → Investigate
│
├── Makes another change
│ ├── Test passes? → Commit if allowed; otherwise note in cleanup package → Continue
│ └── Test fails? → Revert to last commit → Investigate
│
└── Feature complete → All commits form a clean history
This pattern means you never lose more than one increment of work. If an agent goes off the rails, return to the last verified save point using an approved recovery path; destructive commands such as git reset --hard still require explicit user approval.
After any modification, provide a structured summary. This makes review easier, documents scope discipline, and surfaces unintended changes:
CHANGES MADE:
- src/routes/tasks.ts: Added validation middleware to POST endpoint
- src/lib/validation.ts: Added TaskCreateSchema using Zod
THINGS I DIDN'T TOUCH (intentionally):
- src/routes/auth.ts: Has similar validation gap but out of scope
- src/middleware/error.ts: Error format could be improved (separate task)
POTENTIAL CONCERNS:
- The Zod schema is strict — rejects extra fields. Confirm this is desired.
- Added zod as a dependency (72KB gzipped) — already in package.json
This pattern catches wrong assumptions early and gives reviewers a clear map of the change. The "DIDN'T TOUCH" section is especially important — it shows you exercised scope discipline and didn't go on an unsolicited renovation.
Before every commit:
# 1. Check what you're about to commit
git diff --staged
# 2. Ensure no secrets
git diff --staged | grep -i "password\|secret\|api_key\|token"
# 3. Discover and run the most relevant focused project command
# Prefer AGENTS.md, README, Makefile, package scripts, pyproject, Cargo.toml,
# or CI config over generic npm examples.
If the project documents exact commands, use those commands. If no command is documented, state the discovery path and run the most relevant focused verification available before committing.
Automate checks with project-approved hooks only; do not add hook tooling or dependencies unless the task explicitly asks:
// package.json (using lint-staged + husky)
{
"lint-staged": {
"*.{ts,tsx}": ["eslint --fix", "prettier --write"],
"*.{json,md}": ["prettier --write"]
}
}
package-lock.json, Prisma migrations)dist/, .next/), environment files (.env), or IDE config (.vscode/settings.json unless shared).gitignore that covers: node_modules/, dist/, .env, .env.local, *.pem# Find which commit introduced a bug
git bisect start
git bisect bad HEAD
git bisect good <known-good-commit>
# Git checkouts midpoints; run your test at each to narrow down
# View what changed recently
git log --oneline -20
git diff HEAD~5..HEAD -- src/
# Find who last changed a specific line
git blame src/services/task.ts
# Search commit messages for a keyword
git log --grep="validation" --oneline
| Rationalization | Reality |
|---|---|
| "I'll commit when the feature is done" | One giant commit is impossible to review, debug, or revert. Create verified slice savepoints when allowed; otherwise ask once with the cleanup package. |
| "The message doesn't matter" | Messages are documentation. Future you (and future agents) will need to understand what changed and why. |
| "I'll squash it all later" | Squashing destroys the development narrative. Prefer clean incremental commits from the start. |
| "Branches add overhead" | Short-lived branches are free and prevent conflicting work from colliding. Long-lived branches are the problem — merge within 1-3 days. |
| "I'll split this change later" | Large changes are harder to review, riskier to deploy, and harder to revert. Split before submitting, not after. |
| "I don't need a .gitignore" | Until .env with production secrets gets committed. Set it up immediately. |
main, master, or trunkgit branch <name> and assuming the working tree switched branches.gitignore in the projectnode_modules/, .env, or build artifactsFor every commit:
.gitignore covers standard exclusionsまだレビューはありません。使ってみた感想をお寄せください。
概要と使いどころ
Review a single academic paper, preprint, DOI, arXiv link, or user-provided PDF/text with source-grounded critique. Use for paper summaries, methodology review, novelty checks, reproducibility concerns, or "review this paper" requests; do not use for multi-paper surveys, systematic literature reviews, citation management, or implementation from a paper.
日本語の概要は準備中です。原文の説明を表示しています。
AI regression scouting routing. Use when agents, prompts, skills, model/tool routing, harness fixtures, or generated-output expectations change and need regression scenarios; do not use for ordinary product-code regressions.
日本語の概要は準備中です。原文の説明を表示しています。
Run the AILI delivery lifecycle from natural-language IDEATE, DEFINE, BUILD, and SHIP intent or the equivalent slash shortcuts; use for idea shaping, spec/test definition, bounded BUILD package queues, review-repair closeout, or adapter routing without exposing internal stage commands.
日本語の概要は準備中です。原文の説明を表示しています。
Android native Kotlin/Compose app development, Material 3 UI, accessibility, and Gradle builds.
日本語の概要は準備中です。原文の説明を表示しています。
Guides stable API and interface design. Use when designing APIs, module boundaries, or any public interface. Use when creating REST or GraphQL endpoints, defining type contracts between modules, or establishing boundaries between frontend and backend.
日本語の概要は準備中です。原文の説明を表示しています。
Route an explicitly requested independent/delegated browser QA assignment or durable E2E evidence need; do not trigger for direct Playwright/DOM/console/network inspection, ordinary UI implementation, backend-only work, or production-mutating flows.
日本語の概要は準備中です。原文の説明を表示しています。