git-pr 系 skill の PR 作成ルールを明確化する

.agents/skills/git-pr-ja/SKILL.md

@@ -5,4 +5,19 @@ user-invocable: true
 allowed-tools: Bash, Skill
 ---
 
-Use /git-pr to create the PR, but write the PR title and body **in Japanese**.
+Before creating a PR, read `.agents/skills/git-pr/SKILL.md` and follow it
+completely. The Japanese rules below are additional hard requirements, not a
+replacement for `/git-pr`.
+
+## Hard Requirements
+
+- Use `/git-pr` to create the PR.
+- Create a draft PR. Use `gh pr create --draft`.
+- Check whether a PR template exists before writing the body. If one exists,
+  follow it.
+- If no template exists, use the `/git-pr` default body structure:
+  `close`, `Summary`, `Changes`, and `Notes`.
+- Write the PR title and body in Japanese.
+- Never pass a Markdown PR body inline through the shell. Write the body to a
+  temporary file and use `gh pr create --body-file <file>` or
+  `gh pr edit --body-file <file>`.

.agents/skills/git-pr/SKILL.md

@@ -23,13 +23,27 @@ Review current branch changes and autonomously create a PR as draft.
 
 If a `--path <dir>` argument is provided (e.g. invoked as `git-pr --path /tmp/feat-foo`), all git and gh commands must be run inside that directory by prepending `cd <dir> &&` to every Bash command. This overrides the current working directory.
 
+## Hard Requirements
+
+- Always create the PR as a draft. Use `gh pr create --draft`.
+- Check whether a PR template exists before writing the body. If one exists,
+  follow it.
+- Never pass a Markdown PR body inline through the shell. Write the body to a
+  temporary file and use `gh pr create --body-file <file>` or
+  `gh pr edit --body-file <file>`.
+- After creating the PR, verify it with:
+  `gh pr view --json isDraft,title,body,baseRefName,headRefName,url`
+
 1. Run `git log --oneline main..HEAD` and `git diff main...HEAD` to understand the changes
 2. **Granularity check** (skip if `--path` was provided — the caller already performed this check): Before writing the PR, assess whether the changes belong to a single concern:
    - Group changed files by what they do (feature, test, config, infra, docs, etc.)
    - If changes span 2+ unrelated concerns (e.g. a feature AND an infra fix), stop and tell the user which concerns were identified and suggest splitting into separate PRs. Do not create the PR until the user confirms to proceed as-is or asks you to split.
    - A PR is appropriately sized if a reviewer can understand it in one sitting. More than ~400 changed lines or 3+ unrelated concerns is a signal to split.
 3. If a PR template exists in the project, follow it
-4. Autonomously decide the PR title and body, then create it with `gh pr create --draft`
+4. Autonomously decide the PR title and body, then create it with
+   `gh pr create --draft --body-file <file>`
+5. Verify the created PR with
+   `gh pr view --json isDraft,title,body,baseRefName,headRefName,url`
 
 ## PR Format (if no template exists)