git-iris
Use this skill when generating commit messages, pull request descriptions, release notes, changelogs, or code reviews in a repository where git-iris is available. Activates on requests like "commit this", "write a commit message", "draft a PR", "generate release notes", "write a changelog", or "review my changes" when git-iris is on PATH.
ソース情報
- リポジトリ
- hyperb1iss/git-iris
- ソースの最終更新活動
- 2026年5月27日 07:01
- 検出された SKILL.md の言語
- 英語
- スター
- 43
- フォーク
- 9
インストール方法
デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。
ソースファイルを確認
インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。
SKILL.md を表示中
SKILL.md
ソースの指示 · 読み取り専用プレビュー- name
- git-iris
- description
- Use this skill when generating commit messages, pull request descriptions, release notes, changelogs, or code reviews in a repository where git-iris is available. Activates on requests like "commit this", "write a commit message", "draft a PR", "generate release notes", "write a changelog", or "review my changes" when git-iris is on PATH.
# Git-Iris
Delegate commit messages, PR descriptions, reviews, changelogs, and release notes to `git-iris`. Iris reads the diff herself, follows project style (gitmoji, presets, project-config), and produces structured output. Your job is to pass the _why_, then commit or post the result.
## When to use
If the repo has `git-iris` on PATH and the user asks for any of:
| Intent | Subcommand |
| -------------------------------- | ------------------------ |
| Write a commit message | `git-iris gen` |
| Draft or update a PR description | `git-iris pr` |
| Generate release notes | `git-iris release-notes` |
| Generate a changelog | `git-iris changelog` |
| Code review of staged changes | `git-iris review` |
Check first: `command -v git-iris`. If it's missing, fall through to writing the message yourself.
If the installed `git-iris` is stale for the current branch, use the branch binary instead:
`cargo run --quiet -- -q gen -p -i "<why>"` or `target/debug/git-iris -q gen -p -i "<why>"`.
The `-q` flag still belongs to `git-iris`, after Cargo's `--`.
## The core pattern
```bash
git-iris -q gen -p -i "<one tight paragraph explaining why>"
```
- `-q` suppresses iris's startup banner. **Always pass `-q` when capturing stdout** or the version banner will pollute the captured message.
- `-p` prints to stdout without committing. Capture, inspect, then commit yourself with `git commit -F-`.
- `-i` is the _why_. Iris already reads the diff, so don't paste it. Pass intent: what user request triggered this, what constraint shaped the choice, what tone applies.
- Drop `-p` and add `-a` to auto-commit when the user is fine with iris's output as-is. `-q` is optional in auto-commit mode (the banner just goes to your terminal, not into the message).
## What goes in `-i`
Good context (one paragraph, roughly 3-5 sentences):
- The user request that triggered the change ("user asked to fix the doubled gitmoji bug")
- Non-obvious constraints ("had to keep the public API unchanged for downstream callers")
- Tone or scope hints ("internal refactor only, no behavior change")
- Related ticket or issue if relevant
Bad context (skip these):
- The diff itself, iris reads it
- File-by-file enumeration, iris reads them
- Restating commit conventions, iris uses project presets
- Boilerplate praise or filler
## Per-capability flags
### Commit messages (`gen`)
| Flag | When |
| ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `-p` / `--print` | Print to stdout, you commit yourself |
| `-a` / `--auto-commit` | Iris commits directly with the generated message |
| `--amend` | Amend the previous commit. Requires `-p` or `-a`; standalone `--amend` is a no-op with a warning |
| `--no-verify` | Skip iris's auto-commit hooks. **Only affects iris's own commit (`-a` mode).** When you commit yourself with `git commit -F-`, pass `--no-verify` to git too if the user asked for it |
| `--critic` / `--no-critic` | Toggle the critic verification pass after generation. Commit messages default off; use `--critic` to opt in |
### PR descriptions (`pr`)
| Flag | When |
| ----------------------------- | ---------------------------------------------------------------------------- |
| `--update` | Push the description to the GitHub PR (requires `gh auth`) |
| `--pr <N>` | Target a specific PR number for `--update`. Has no effect without `--update` |
| `--from <ref>` / `--to <ref>` | Custom commit range |
| `-c` / `--copy` | Copy raw markdown to clipboard |
| `--critic` / `--no-critic` | Toggle the critic verification pass after generation. Default on |
### Changelog and release notes
Both subcommands **require `--from`**. `--to` defaults to `HEAD` if omitted.
| Flag | When |
| -------------------------- | ----------------------------------------------------------------------- |
| `--from <ref>` | **Required.** Starting reference (commit/tag/branch) |
| `--to <ref>` | Ending reference. Defaults to `HEAD` |
| `--version-name <X>` | Explicit version label (works for both `changelog` and `release-notes`) |
| `--file <path>` | Output file path (defaults to `CHANGELOG.md` / `RELEASE_NOTES.md`) |
| `--critic` / `--no-critic` | Toggle the critic verification pass after generation. Default on |
### Code review (`review`)
By default, reviews staged changes. Use the flags below for other scopes.
| Flag | When |
| ----------------------------- | ----------------------------------------------------------------------------------------- |
| `-p` / `--print` | Print review to stdout instead of console-formatted display |
| `--raw` | Raw markdown (good for piping or saving to file) |
| `--include-unstaged` | Include unstaged working-tree changes alongside staged. Incompatible with `--from`/`--to` |
| `--commit <SHA>` | Review a single commit. Mutually exclusive with `--from`/`--to` |
| `--from <ref>` / `--to <ref>` | Review a commit range. `--from` requires `--to` |
| `--github-review` | Post the review to the current GitHub PR (requires `gh auth`) |
| `--github-inline-comments` | Add inline comments at flagged lines when posting |
| `--github-review-event <E>` | GitHub review action: `comment` (default), `request-changes`, `approve` |
| `--pr <N>` | Target a specific PR for `--github-review` |
| `--critic` / `--no-critic` | Toggle the critic verification pass after generation. Default on |
## Attributions and trailers
Iris doesn't manage `Co-Authored-By:` trailers. After capturing iris's output with `-p`, append trailers yourself when committing:
```bash
msg=$(git-iris -q gen -p -i "<why>")
git commit -F- <<EOF
$msg
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
EOF
```
For PR and release-notes markdown, attribution is optional and lives in the body if at all. Don't post-process iris's markdown unless the user asks for it.
## Print vs auto-commit
| Situation | Use |
| --------------------------------------- | ---------------------------------------- |
| User wants to review before commit | `-p`, show stdout, confirm, then commit |
| User said "just commit it" or "ship it" | `-a` |
| User is mid-flow and trusts the output | `-p` and commit silently with trailers |
| You need to add Co-Authored-By trailers | `-p` (auto-commit can't append trailers) |
## Things to know
- **Iris uses the repo's project-config.** Don't pass `--gitmoji` or `--preset` flags unless the user explicitly asks to override.
- **Iris re-runs cleanly.** If the first output isn't right, refine `-i` and call again rather than editing iris's output by hand.
- **Studio TUI exists.** If the user wants to iterate interactively, suggest `git-iris studio` instead of repeated CLI calls.
- **`--debug` is colorful.** When something looks wrong, `git-iris gen --debug -i "..."` shows tool calls and reasoning in color. Don't combine `--debug` with `-q -p` capture; debug output goes to stderr but the visual noise distracts from triage.
## Anti-patterns
- Don't write the commit message yourself when `git-iris` is on PATH and the user wanted iris to do it.
- Don't paste the diff into `-i`. Iris reads the diff.
- Don't chain `-i` with shell-escaped multi-paragraph prose. One paragraph, plain quotes.
- Don't override project style flags unless the user asked.
- Don't skip the user's review step on a non-trivial commit just because `-a` is faster.
GitHubで見る