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
chore(claude): refine skills and switch statusline
- switch statusline from ccusage to ccstatusline with zero padding
- add issue-start skill symlink in claude.nix
- drop model pinning from commit and create-pr skills
- require bullet-pointed body in every commit with no exceptions
- add scope-language rule so Japanese scopes are allowed for Japanese commits and PRs
- document HEREDOC quoting pitfalls and recommend `<<'EOF'` when messages contain backticks
- Use the **imperative mood** in the description (e.g., "add", not "added" or "adds").
46
45
- Keep the **summary concise** (max ~72 characters).
47
46
-**Body rules**:
48
-
-By default, always include a body.
49
-
-Exception: if the change is extremely simple and self-explanatory, a summary alone is acceptable.
50
-
-Insert one blank line after the summary, then write the body in **bullet points**.
51
-
- Each bullet should describe a reason, context, or detail of the change.
47
+
-**Always include a body — no exceptions**, even for trivial-looking changes
48
+
-Insert one blank line after the summary, then write the body
49
+
-The body **must** be written as bullet points — **never** use prose paragraphs or a single free-form line
50
+
- Each bullet should describe a reason, context, or detail of the change
52
51
- Example:
53
52
54
53
```
@@ -62,12 +61,24 @@ Based on the above context:
62
61
- **Language rule**:
63
62
- Use the same language as the majority of recent commits
64
63
- If `$ARGUMENTS` includes a language instruction, follow that instead
64
+
- **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.
65
65
- **Focus rule**:
66
66
- Do **not** write vague phrases like "fixed review comments", or "minor fix".
67
67
- Always describe **what was actually changed** (e.g., "remove unused import", "fix null check in auth flow").
68
68
- **Arguments rule**:
69
69
- Treat `$ARGUMENTS` as additional context or instruction for the commit message
70
70
71
+
## HEREDOC Handling for Commit Messages
72
+
73
+
When composing a multi-line commit message with `git commit -m "$(cat <<...EOF ... EOF)"`, the HEREDOC quoting style affects how backticks are interpreted:
74
+
75
+
- **Single-quoted HEREDOC (`<<'EOF'`)**: No shell expansion happens, so write raw backticks directly (e.g., inline `` `functionName` `` or `` `file.ts` `` is safe)
76
+
- **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
77
+
78
+
**Rationale**: In double-quoted/unquoted HEREDOC, backticks sometimes get auto-escaped as `` \` ``, which leaks literal backslashes into the commit message.
79
+
80
+
**Recommendation**: Prefer `<<'EOF'` whenever the commit message contains backticks or code identifiers — it is the safest default.
@@ -102,7 +101,9 @@ N/A - [brief description of the purpose]
102
101
-**Title format**:
103
102
- Follow the same convention as commit messages if applicable
104
103
- Be descriptive but concise (max ~72 characters)
105
-
- Example: `feat(auth): Add user authentication with OAuth2`
104
+
-**Scope language matches the title language**: for Japanese PRs the scope may be written in Japanese; for English PRs keep the scope in English
105
+
- Example (English): `feat(auth): Add user authentication with OAuth2`
106
+
- Example (Japanese): `feat(認証): OAuth2 ログイン機能を追加`
106
107
107
108
-**Issue section**:
108
109
- Use `fixes #<number>` to automatically close related issues
@@ -137,6 +138,17 @@ N/A - [brief description of the purpose]
137
138
-**Arguments rule**:
138
139
- Treat `$ARGUMENTS` as additional context or instruction for the PRtitle/description
139
140
141
+
## HEREDOC Handling for PR Body
142
+
143
+
When composing the PR body with `gh pr create --body "$(cat <<...EOF ... EOF)"`, the HEREDOC quoting style affects how backticks are interpreted:
144
+
145
+
-**Single-quoted HEREDOC (`<<'EOF'`)**: No shell expansion happens, so write raw backticks directly (both inline `` ` `` and fenced ```` ``` ````)
146
+
-**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
147
+
148
+
**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).
149
+
150
+
**Recommendation**: Prefer `<<'EOF'` whenever the PR body contains backticks, code identifiers, or code blocks — it is the safest default.
151
+
140
152
## Important Notes
141
153
142
154
- Always ensure all changes are committed before creating a PR
0 commit comments