You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
- remove Claude Code-specific AskUserQuestion guidance
- replace commit and PR skills with compact Codex workflows
- ignore local .codex directories in global git excludes
Co-authored-by: Codex <codex@openai.com>
Copy file name to clipboardExpand all lines: home/codex/skills/commit/SKILL.md
+35-80Lines changed: 35 additions & 80 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -3,83 +3,38 @@ name: commit
3
3
description: Create a git commit following the Conventional Commits specification. Use when the user wants to commit staged changes, create a commit message, or run git commit. Handles commit message language detection (English/Japanese) based on recent commits.
- Use the **imperative mood** in the description (e.g., "add", not "added" or "adds").
44
-
- Keep the **summary concise** (max ~72 characters).
45
-
-**Body rules**:
46
-
-**Always include a body — no exceptions**, even for trivial-looking changes
47
-
- Insert one blank line after the summary, then write the body
48
-
- The body **must** be written as bullet points — **never** use prose paragraphs or a single free-form line
49
-
- Each bullet should describe a reason, context, or detail of the change
50
-
- Example:
51
-
52
-
```
53
-
feat(auth): add OAuth2 login support
54
-
55
-
- implement login with OAuth2
56
-
- update user model with providerId
57
-
- add tests for OAuth2 flow
58
-
```
59
-
60
-
- **Language rule**:
61
-
- Use the same language as the majority of recent commits
62
-
- If `$ARGUMENTS` includes a language instruction, follow that instead
63
-
- **Scope language matches the message language**: for Japanese commits, the scope may also be written in Japanese (e.g., `feat(認証): OAuth2 ログインを追加`). For English commits, keep the scope in English.
64
-
- **Focus rule**:
65
-
- Do **not** write vague phrases like "fixed review comments", or "minor fix".
66
-
- Always describe **what was actually changed** (e.g., "remove unused import", "fix null check in auth flow").
67
-
- **Arguments rule**:
68
-
- Treat `$ARGUMENTS` as additional context or instruction for the commit message
69
-
70
-
## HEREDOC Handling for Commit Messages
71
-
72
-
When composing a multi-line commit message with `git commit -m "$(cat <<...EOF ... EOF)"`, the HEREDOC quoting style affects how backticks are interpreted:
73
-
74
-
- **Single-quoted HEREDOC (`<<'EOF'`)**: No shell expansion happens, so write raw backticks directly (e.g., inline `` `functionName` `` or `` `file.ts` `` is safe)
75
-
- **Double-quoted or unquoted HEREDOC (`<<"EOF"` / `<<EOF`)**: Bash may interpret backticks as command substitution. Avoid inline single backticks — use triple-backtick fenced blocks (```` ``` ````) if a code span is needed
76
-
77
-
**Rationale**: In double-quoted/unquoted HEREDOC, backticks sometimes get auto-escaped as `` \` ``, which leaks literal backslashes into the commit message.
78
-
79
-
**Recommendation**: Prefer `<<'EOF'` whenever the commit message contains backticks or code identifiers — it is the safest default.
80
-
81
-
## Important Notes
82
-
83
-
- Do not execute `git add`
84
-
- The changes are already staged with the correct granularity and responsibility.
85
-
- Do not execute `git push`
6
+
## Commit Workflow
7
+
8
+
1. Inspect the repository state before committing:
9
+
-`git status --short`
10
+
-`git diff --staged`
11
+
-`git log -n 10 --pretty=format:%s`
12
+
-`git branch --show-current`
13
+
2. Commit only staged changes. Do not run `git add` unless the user explicitly asks.
14
+
3. If unstaged changes exist, leave them untouched and mention them after the commit.
15
+
4. Check staged changes for secrets, broken partial edits, or obviously wrong files. If found, stop and ask the user.
16
+
5. Choose the commit message language from recent commits unless the user specifies one.
17
+
6. Run `git commit` and verify with `git status --short`.
18
+
19
+
## Commit Message
20
+
21
+
- Use Conventional Commits: `<type>(scope): <description>`.
description: Create a GitHub pull request using the gh CLI. Use when the user wants to create a PR, submit changes for review, push and open a pull request on GitHub, or share a branch with collaborators. Handles PR title/body language detection (English/Japanese) and uses repository PR templates when available.
4. Ensure all intended changes are committed before creating the PR.
19
+
5. If there are unstaged or uncommitted changes, stop and ask the user unless they explicitly said a draft/WIP PR is acceptable with local changes left out.
20
+
6. Push the current branch with `git push -u origin HEAD`.
21
+
7. Create the PR with `gh pr create`.
22
+
8. After creating the PR, report the PR URL and a short summary.
23
+
9. Do not merge the PR unless explicitly instructed.
24
+
25
+
## Pull Request Content
26
+
27
+
- Use the repository PR template if one exists.
28
+
- If no repository template exists, use the default template below.
29
+
- Use the same language as the majority of recent commits unless the user specifies one.
30
+
- Make the title concise and descriptive, about 72 characters or less.
31
+
- Use a Conventional Commit-style title when it fits: `<type>(scope): <description>`.
32
+
- For Japanese PR titles, the scope may also be Japanese, e.g. `feat(認証): OAuth2 ログイン機能を追加`.
33
+
- Treat user-provided arguments as additional context for the title and body.
34
+
- Keep bullet lists compact. Do not insert blank lines between bullet points.
35
+
- Write sections equivalent to Changes (e.g. `変更内容`, `変更したこと`) and Verification (e.g. `確認したこと`) at a level a PM can read and understand.
36
+
- Do not overload PR readers with excessive detail; keep these sections short and high-signal.
37
+
- In verification/checklist sections, do not list CI-only checks such as lint, typecheck, or tests unless the reviewer must manually verify them.
38
+
- Keep verification items unchecked and phrased as reviewer acceptance criteria.
39
+
- Include implementation notes only when they help reviewers understand the approach or trade-offs.
40
+
- Include this comment at the top of the PR body unless the user asks otherwise:
50
41
51
-
## Default PR Template
42
+
```markdown
43
+
<!-- Instructions for GitHub Copilot Code Review: Please provide your comments and review this pull request in Japanese. -->
44
+
```
52
45
53
-
Use this template when no repository-specific template is found:
46
+
## Default PR Template
54
47
55
48
```markdown
56
49
<!-- Instructions for GitHub Copilot Code Review: Please provide your comments and review this pull request in Japanese. -->
57
50
58
51
## Issue
59
52
60
-
<!--
61
-
If there's a related issue: fixes #123
62
-
If no related issue: N/A - Brief description of the purpose
63
-
Examples:
64
-
- fixes #42
65
-
- N/A - Add TypeScript configuration
66
-
- N/A - Update dependencies
67
-
-->
68
-
69
53
N/A - [brief description of the purpose]
70
54
71
55
## Changes
72
56
73
-
<!--
74
-
List the main changes made in this PR using bullet points
75
-
Examples:
76
-
- Add user authentication feature
77
-
- Fix memory leak in data processing
78
-
- Update React from v17 to v18
79
-
-->
80
-
81
57
-[Describe the main changes made]
82
58
83
59
## Verification
84
60
85
-
<!--
86
-
Do NOT list items already verified by CI (tests, lint, type checks, etc.).
87
-
List manual verification steps that reviewers should actually confirm.
88
-
These should serve as acceptance criteria — if all are met, the PR can be approved.
89
-
-->
90
-
91
61
-[ ][Describe the expected behavior or manual verification step]
92
62
93
63
## Additional Notes
94
-
95
-
<!-- Any additional context, implementation details, or notes for reviewers -->
96
64
```
97
65
98
-
## Pull Request Guidelines
99
-
100
-
-**Title format**:
101
-
- Follow the same convention as commit messages if applicable
102
-
- Be descriptive but concise (max ~72 characters)
103
-
-**Scope language matches the title language**: for Japanese PRs the scope may be written in Japanese; for English PRs keep the scope in English
104
-
- Example (English): `feat(auth): Add user authentication with OAuth2`
105
-
- Example (Japanese): `feat(認証): OAuth2 ログイン機能を追加`
106
-
107
-
-**Issue section**:
108
-
- Use `fixes #<number>` to automatically close related issues
109
-
- Use `N/A - <description>` if no related issue exists
110
-
- Provide brief context when there's no issue number
111
-
112
-
-**Changes section**:
113
-
- List all significant changes in bullet points
114
-
- Group related changes together
115
-
- Be specific about what was modified, added, or removed
116
-
117
-
-**Verification section**:
118
-
- Do not list items already verified by CI (tests, lint, type checks, etc.)
119
-
- List manual verification steps that reviewers should actually confirm
120
-
- All items should serve as acceptance criteria — if met, the PR can be approved
121
-
- Keep checkboxes unchecked (`- [ ]`)
122
-
123
-
-**Additional Notes section**:
124
-
- Include implementation details for complex changes
125
-
- Add context that helps reviewers understand the approach
126
-
- Mention any trade-offs or alternatives considered
127
-
128
-
-**Verification in repository templates**:
129
-
- If the repository's PR template has a verification/confirmation section (e.g., "確認したこと", "Verification", "Checklist"), apply the same rules as the Verification section above
130
-
- Do not list CI-verified items — only include manual verification steps reviewers should confirm
131
-
132
-
-**Language rule**:
133
-
- Use the same language as the majority of recent commits
134
-
- If `$ARGUMENTS` includes a language instruction, follow that instead
135
-
136
-
-**Arguments rule**:
137
-
- Treat `$ARGUMENTS` as additional context or instruction for the PR title/description
138
-
139
-
## HEREDOC Handling for PR Body
140
-
141
-
When composing the PR body with `gh pr create --body "$(cat <<...EOF ... EOF)"`, the HEREDOC quoting style affects how backticks are interpreted:
142
-
143
-
-**Single-quoted HEREDOC (`<<'EOF'`)**: No shell expansion happens, so write raw backticks directly (both inline `` ` `` and fenced ```` ``` ````)
144
-
-**Double-quoted or unquoted HEREDOC (`<<"EOF"` / `<<EOF`)**: Bash may try to interpret backticks as command substitution. Avoid inline single backticks — use triple-backtick fenced code blocks (```` ``` ````) instead
145
-
146
-
**Rationale**: In double-quoted/unquoted HEREDOC, backticks sometimes get auto-escaped as `` \` ``, which breaks Markdown rendering on GitHub (the code block fails to display properly).
147
-
148
-
**Recommendation**: Prefer `<<'EOF'` whenever the PR body contains backticks, code identifiers, or code blocks — it is the safest default.
149
-
150
-
## Important Notes
66
+
## Command Notes
151
67
152
-
- Always ensure all changes are committed before creating a PR
153
-
- Do not force push unless absolutely necessary
154
-
- If the PR template exists in the repository, always use it over the default
155
-
- Check CI/CD status after creating the PR
156
-
- Do not merge the PR unless explicitly instructed
157
-
- The GitHub Copilot instruction comment helps ensure reviews are provided in the appropriate language
68
+
- Prefer a single PR body file or single-quoted heredoc (`<<'EOF'`) so Markdown renders correctly and bullet lists stay contiguous.
0 commit comments