[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6BVHZNFQBVQPV3NA8DA373N":3,"skill-same:01M6BVHZNFQBVQPV3NA8DA373N":78},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":46,"linkOnly":47,"markdownContent":48,"markdownBody":49,"frontMatter":50,"refName":51,"commitSha":52,"skillDirectory":53,"forksCount":54,"repositoryHtmlUrl":55,"repositoryHomepageUrl":6,"ownerHtmlUrl":56,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":57,"install":58,"resources":71},"01M6BVHZNFQBVQPV3NA8DA373N","pr-review-coach",null,"Japanese-only PR understanding coach. Use when the user wants to prepare their own review, understand a branch diff, identify questions to ask, or build review judgment before running a merge gate. Requires an explicit --base \u003Cref-or-commit> for the first turn, then resumes from local state on answer turns. Asks at most one question at a time and stores resumable local state outside the target worktree. Single-agent only; does not spawn specialist reviewers, does not produce Critical\u002FImportant\u002FSuggestions gate findings, and does not decide merge readiness.","toku345\u002Fdotfiles","toku345","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F3142849?v=4","01M6BVHFC948X4EGTFPQF53G6Q","Fumitaka Tokumitsu","01M6BVHFGV7PA8A2QHR2H8YWMX",1,"MIT","https:\u002F\u002Fgithub.com\u002Ftoku345\u002Fdotfiles\u002Fblob\u002Fmain\u002Fprivate_dot_codex\u002Fskills\u002Fpr-review-coach\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45],"pr review","pr","pr review coach","coach","review","decide","running","single","for","answer","critical","local","time","japanese","only","diff","use","question","branch","merge gate","first","worktree","produce","state","prepare","merge","commit","2026-11-10 10:12:30",false,"---\nname: pr-review-coach\ndescription: Japanese-only PR understanding coach. Use when the user wants to prepare their own review, understand a branch diff, identify questions to ask, or build review judgment before running a merge gate. Requires an explicit --base \u003Cref-or-commit> for the first turn, then resumes from local state on answer turns. Asks at most one question at a time and stores resumable local state outside the target worktree. Single-agent only; does not spawn specialist reviewers, does not produce Critical\u002FImportant\u002FSuggestions gate findings, and does not decide merge readiness.\n---\n\n# pr-review-coach\n\n## Goal\n\nHelp the user understand the committed branch diff before a gate review. Run a one-question-at-a-time coaching loop with a local state file, so the conversation can resume without turning into a fix queue.\n\nThis skill is intentionally separate from `$pr-review`:\n- `$pr-review-coach` builds the user's review judgment.\n- `$pr-review` is the merge gate \u002F audit workflow.\n\n## Hard Boundaries\n\n- Respond in Japanese.\n- Require an explicit `--base \u003Cref-or-commit>` on the first turn. If `--base` is missing, continue only when exactly one state file for the current repo and HEAD can be resolved.\n- Treat `\u003Cbase>` as an already available local ref or commit. Do not run `git fetch`, `gh`, or network commands.\n- Review only committed changes in `\u003Cbase>...HEAD`.\n- Do not edit project files, apply patches, run formatters, or dirty tracked files.\n- The only permitted writes are under `STATE_ROOT`: creating\u002Fupdating the current coach state file and pruning stale coach state via `scripts\u002Fcleanup-state.sh`. `STATE_ROOT` defaults to `${XDG_STATE_HOME:-$HOME\u002F.local\u002Fstate}\u002Fcodex\u002Fpr-review-coach\u002F` and must not be inside the target worktree.\n- Do not spawn subagents or specialist reviewers.\n- Do not read unrelated memory files, previous session logs, or review history. Use only the current user prompt, this skill file, the local coach state file, and the git context collected below unless the user explicitly supplies extra context.\n- Do not use the merge-gate taxonomy `Critical`, `Important`, or `Suggestions`.\n- Do not decide whether the PR can merge.\n- Do not create a fix queue. Phrase observations as questions, reading focus, assumptions to verify, or learning notes.\n- Ask at most one question per response unless the user explicitly asks for a summary or the coaching loop is complete.\n- On answer turns, respond to the user's answer before moving on. Say directly whether the answer is correct, partly correct, or off target, and explain the smallest concrete reason from the diff.\n- Do not advance to the next candidate question until the current answer is good enough to record as answered, or the user explicitly asks to skip it.\n\n## Preconditions\n\nRun these checks before reading the diff:\n\n1. **Clean worktree** — Run `git status --porcelain --untracked-files=normal`.\n   - If the command fails, abort with the command output.\n   - If output is non-empty, abort and explain that the coach covers committed branch diff only, so uncommitted changes would be silently excluded.\n\n2. **State location and HEAD pinning** — Run:\n   - `REPO_ROOT=$(git rev-parse --show-toplevel)`\n   - Resolve `REPO_ROOT` to its canonical physical path (for example with `pwd -P` \u002F `realpath` semantics) and compute `REPO_KEY` as the SHA-256 of that canonical path.\n   - `STATE_ROOT=${CODEX_PR_REVIEW_COACH_STATE_ROOT:-${XDG_STATE_HOME:-$HOME\u002F.local\u002Fstate}\u002Fcodex\u002Fpr-review-coach}`\n   - Resolve `STATE_ROOT` to a canonical physical path before creating it, canonicalizing the nearest existing parent and appending any missing path components. If the canonical `STATE_ROOT` is equal to canonical `REPO_ROOT` or inside canonical `REPO_ROOT`, abort before creating any state directory; the coach must never write state into the target worktree through lexical paths, symlinks, or `..` traversal.\n   - `STATE_DIR=$STATE_ROOT\u002Frepos\u002F$REPO_KEY`\n   - `HEAD_REF=$(git rev-parse HEAD)`\n   - `HEAD_SHORT=$(git rev-parse --short=12 HEAD)`\n   If any command fails, abort with the command output.\n\n3. **Base or continuation resolution** — Extract optional `--base \u003Cref-or-commit>` from the user prompt.\n   - Reject base values that start with `-` or `+`, contain `:`, or contain whitespace.\n   - If `--base` is present, set `BASE` to that value, run `BASE_COMMIT=$(git rev-parse --verify \"$BASE^{commit}\")`, `BASE_SHORT=$(git rev-parse --short=12 \"$BASE_COMMIT\")`, and `STATE_FILE=$STATE_DIR\u002F$BASE_SHORT-$HEAD_SHORT.md`. If either command fails, abort with the command output and ask the user to provide a valid local base ref or commit.\n   - If `--base` is missing, treat the prompt as an answer continuation. Find state files matching `$STATE_DIR\u002F*-$HEAD_SHORT.md`.\n   - If no matching state file exists, stop with: `--base \u003Cref-or-commit> を指定してください。例: $pr-review-coach --base main`\n   - If multiple matching state files exist, stop and ask the user to rerun with `--base` because the continuation base is ambiguous.\n   - If exactly one matching state file exists, set `STATE_FILE` to it, load `status`, `base`, `base_commit`, and `head_ref` from the file, set `BASE` and `BASE_COMMIT` from those fields, and compute `BASE_SHORT=$(git rev-parse --short=12 \"$BASE_COMMIT\")`.\n   - For any existing `STATE_FILE`, whether it was selected by explicit `--base` or continuation lookup, validate it before reuse. If `status` is `complete`, produce the final summary from that state or ask the user to start a new coaching run with a different base\u002FHEAD; do not resume it as an active question. Otherwise, abort if `status` is not `active`, if `head_ref` differs from `HEAD_REF`, if `base_commit` differs from `BASE_COMMIT`, if `BASE_COMMIT` does not resolve to a commit, or if the state file lacks `current_question`.\n\n## Procedure\n\nAfter preconditions pass:\n\n1. Collect only read-only context:\n   - `git status --short`\n   - `git log --no-decorate \"$BASE_COMMIT..$HEAD_REF\"`\n   - `git diff --name-only \"$BASE_COMMIT\"...\"$HEAD_REF\"`\n   - `git diff \"$BASE_COMMIT\"...\"$HEAD_REF\"`\n   - Run each command independently. If any command fails, abort with the command output and do not continue with partial context.\n\n2. If the diff is empty, run the final guard and say there are no committed changes relative to the base.\n\n3. Prepare or load the local coach state:\n   - Use the `STATE_ROOT`, `STATE_DIR`, and `STATE_FILE` resolved in Preconditions.\n   - Create the state directory with `mkdir -p`; if creation or a temporary write+rename preflight fails, abort instead of falling back to the target worktree.\n   - Resolve `SKILL_DIR` as this skill's directory and run `bash \"$SKILL_DIR\u002Fscripts\u002Fcleanup-state.sh\" --state-root \"$STATE_ROOT\" --current \"$STATE_FILE\"` before creating or updating state. If cleanup fails, warn and continue; cleanup failure must not alter the coaching result.\n   - The state file is outside the target worktree and must not be committed.\n   - If the state file does not exist, create it after reading the diff.\n   - If it exists and passed the existing-state validation from Preconditions, load it and resume from its `current_question`.\n   - If `base_commit` or `head_ref` in the state file differs from the pinned values, do not reuse it. Create or use the state file derived from the current `$BASE_SHORT-$HEAD_SHORT` pair.\n   - Cleanup policy is centralized in `scripts\u002Fcleanup-state.sh`: delete state files older than 30 days, keep the 20 newest files per repo, and always preserve `$STATE_FILE` even when that exceeds the cap.\n\n4. State file contents should be compact Markdown:\n   - `status`: `active` or `complete`\n   - `base`: the user-provided base string\n   - `base_commit`: pinned base commit\n   - `head_ref`: pinned HEAD\n   - `snapshot`: 2-3 bullets about the diff\n   - `questions`: numbered candidate questions, maximum 5\n   - `answered`: prior accepted question\u002Fanswer pairs\n   - `answer_attempts`: current-question attempts and coach reactions that were not yet accepted, if any\n   - `skipped_answer_attempts`: skipped or moved-on question attempts and coach reactions that are no longer tied to `current_question`, if any\n   - `current_question`: the single question to ask next\n   - `review_focus`: up to 3 reading focus bullets\n   - `learning_hook`: 1-2 learning notes\n   - `ledger_draft`: notes the user can carry into their review\n\n5. Read the diff for understanding, not triage:\n   - What changed?\n   - Which files should the user read first?\n   - What intent or assumption is visible from the diff?\n   - What is still unclear from code alone?\n   - What review habit would help on this PR?\n\n6. Keep output bounded:\n   - Generate at most 5 candidate questions in the state file.\n   - Output at most 1 question in the response.\n   - At most 3 review focus bullets.\n   - At most 2 learning hooks.\n   - Prefer one strong question over several weak ones.\n\n7. Continuing a coaching loop:\n   - If the user answers the current question, first write a `Response To Your Answer` section. Use direct language: `合っています`, `一部合っています`, or `そこは違います`.\n   - If the answer is correct enough for the review habit being practiced, update `answered`, advance `current_question`, and ask the next candidate question.\n   - If the answer is incomplete, ambiguous, or off target, update `answer_attempts`, keep the same `current_question`, and ask one narrower follow-up about the same question. Do not advance yet.\n   - If the user sends an additional response for the same question, respond to that attempt with the same direct judgment, then either accept and advance or keep the current question with one narrower follow-up.\n   - If the user explicitly asks to skip or move on, record the attempt in `skipped_answer_attempts`, advance `current_question`, and note what remains unverified. Keep `answer_attempts` reserved for the active `current_question`; do not carry skipped attempts into the next question's current-attempt state.\n   - If the user invokes the skill again without an answer, repeat the current question with shorter context.\n   - If all questions are answered, produce the final summary, set `status: complete`, and clear `current_question` so the state cannot be resumed as an active answer continuation.\n   - If the user asks for a summary early, produce a summary from answered items and leave the state resumable.\n\n8. Final guard:\n   - Run `git status --porcelain --untracked-files=normal` again.\n   - Run `git rev-parse HEAD` again and compare with `HEAD_REF`.\n   - If any final guard command fails, abort with the command output.\n   - If any worktree content or HEAD changed, abort and explain that the coaching output may not match the current branch state.\n\n## Output Format\n\nFor an active coaching turn, use this section structure:\n\n```markdown\n# Review Coach\n\n## State\n- 状態ファイル:\n- 進捗:\n\n## Response To Your Answer\n- （回答継続ターンのみ。合っています \u002F 一部合っています \u002F そこは違います、のいずれかを明示する）\n\n## Snapshot\n- 何が変わったか:\n- 最初に読むべき場所:\n\n## Next Question\n1. ...\n\n## Why This Question\n- ...\n```\n\nFor the final summary, use this section structure:\n\n```markdown\n# Review Coach Summary\n\n## What You Clarified\n- ...\n\n## Review Focus\n- ...\n\n## Learning Hook\n- この PR から学べること:\n- 練習するレビュー習慣:\n\n## Review Ledger Draft\n- 迷った点:\n- 見落としやすい理由:\n- 次のチェックリスト項目:\n- 自動化候補:\n```\n\n## Style\n\n- Be concrete and grounded in the committed diff.\n- If a conclusion depends on missing information, state what to verify instead of guessing.\n- Use plain Japanese. Keep each bullet short enough to act on.\n- Keep the coaching loop one-question-at-a-time. Do not list the remaining questions unless the user asks.\n- Avoid praise, scoring, severity labels, and merge advice.\n","# pr-review-coach\n\n## Goal\n\nHelp the user understand the committed branch diff before a gate review. Run a one-question-at-a-time coaching loop with a local state file, so the conversation can resume without turning into a fix queue.\n\nThis skill is intentionally separate from `$pr-review`:\n- `$pr-review-coach` builds the user's review judgment.\n- `$pr-review` is the merge gate \u002F audit workflow.\n\n## Hard Boundaries\n\n- Respond in Japanese.\n- Require an explicit `--base \u003Cref-or-commit>` on the first turn. If `--base` is missing, continue only when exactly one state file for the current repo and HEAD can be resolved.\n- Treat `\u003Cbase>` as an already available local ref or commit. Do not run `git fetch`, `gh`, or network commands.\n- Review only committed changes in `\u003Cbase>...HEAD`.\n- Do not edit project files, apply patches, run formatters, or dirty tracked files.\n- The only permitted writes are under `STATE_ROOT`: creating\u002Fupdating the current coach state file and pruning stale coach state via `scripts\u002Fcleanup-state.sh`. `STATE_ROOT` defaults to `${XDG_STATE_HOME:-$HOME\u002F.local\u002Fstate}\u002Fcodex\u002Fpr-review-coach\u002F` and must not be inside the target worktree.\n- Do not spawn subagents or specialist reviewers.\n- Do not read unrelated memory files, previous session logs, or review history. Use only the current user prompt, this skill file, the local coach state file, and the git context collected below unless the user explicitly supplies extra context.\n- Do not use the merge-gate taxonomy `Critical`, `Important`, or `Suggestions`.\n- Do not decide whether the PR can merge.\n- Do not create a fix queue. Phrase observations as questions, reading focus, assumptions to verify, or learning notes.\n- Ask at most one question per response unless the user explicitly asks for a summary or the coaching loop is complete.\n- On answer turns, respond to the user's answer before moving on. Say directly whether the answer is correct, partly correct, or off target, and explain the smallest concrete reason from the diff.\n- Do not advance to the next candidate question until the current answer is good enough to record as answered, or the user explicitly asks to skip it.\n\n## Preconditions\n\nRun these checks before reading the diff:\n\n1. **Clean worktree** — Run `git status --porcelain --untracked-files=normal`.\n   - If the command fails, abort with the command output.\n   - If output is non-empty, abort and explain that the coach covers committed branch diff only, so uncommitted changes would be silently excluded.\n\n2. **State location and HEAD pinning** — Run:\n   - `REPO_ROOT=$(git rev-parse --show-toplevel)`\n   - Resolve `REPO_ROOT` to its canonical physical path (for example with `pwd -P` \u002F `realpath` semantics) and compute `REPO_KEY` as the SHA-256 of that canonical path.\n   - `STATE_ROOT=${CODEX_PR_REVIEW_COACH_STATE_ROOT:-${XDG_STATE_HOME:-$HOME\u002F.local\u002Fstate}\u002Fcodex\u002Fpr-review-coach}`\n   - Resolve `STATE_ROOT` to a canonical physical path before creating it, canonicalizing the nearest existing parent and appending any missing path components. If the canonical `STATE_ROOT` is equal to canonical `REPO_ROOT` or inside canonical `REPO_ROOT`, abort before creating any state directory; the coach must never write state into the target worktree through lexical paths, symlinks, or `..` traversal.\n   - `STATE_DIR=$STATE_ROOT\u002Frepos\u002F$REPO_KEY`\n   - `HEAD_REF=$(git rev-parse HEAD)`\n   - `HEAD_SHORT=$(git rev-parse --short=12 HEAD)`\n   If any command fails, abort with the command output.\n\n3. **Base or continuation resolution** — Extract optional `--base \u003Cref-or-commit>` from the user prompt.\n   - Reject base values that start with `-` or `+`, contain `:`, or contain whitespace.\n   - If `--base` is present, set `BASE` to that value, run `BASE_COMMIT=$(git rev-parse --verify \"$BASE^{commit}\")`, `BASE_SHORT=$(git rev-parse --short=12 \"$BASE_COMMIT\")`, and `STATE_FILE=$STATE_DIR\u002F$BASE_SHORT-$HEAD_SHORT.md`. If either command fails, abort with the command output and ask the user to provide a valid local base ref or commit.\n   - If `--base` is missing, treat the prompt as an answer continuation. Find state files matching `$STATE_DIR\u002F*-$HEAD_SHORT.md`.\n   - If no matching state file exists, stop with: `--base \u003Cref-or-commit> を指定してください。例: $pr-review-coach --base main`\n   - If multiple matching state files exist, stop and ask the user to rerun with `--base` because the continuation base is ambiguous.\n   - If exactly one matching state file exists, set `STATE_FILE` to it, load `status`, `base`, `base_commit`, and `head_ref` from the file, set `BASE` and `BASE_COMMIT` from those fields, and compute `BASE_SHORT=$(git rev-parse --short=12 \"$BASE_COMMIT\")`.\n   - For any existing `STATE_FILE`, whether it was selected by explicit `--base` or continuation lookup, validate it before reuse. If `status` is `complete`, produce the final summary from that state or ask the user to start a new coaching run with a different base\u002FHEAD; do not resume it as an active question. Otherwise, abort if `status` is not `active`, if `head_ref` differs from `HEAD_REF`, if `base_commit` differs from `BASE_COMMIT`, if `BASE_COMMIT` does not resolve to a commit, or if the state file lacks `current_question`.\n\n## Procedure\n\nAfter preconditions pass:\n\n1. Collect only read-only context:\n   - `git status --short`\n   - `git log --no-decorate \"$BASE_COMMIT..$HEAD_REF\"`\n   - `git diff --name-only \"$BASE_COMMIT\"...\"$HEAD_REF\"`\n   - `git diff \"$BASE_COMMIT\"...\"$HEAD_REF\"`\n   - Run each command independently. If any command fails, abort with the command output and do not continue with partial context.\n\n2. If the diff is empty, run the final guard and say there are no committed changes relative to the base.\n\n3. Prepare or load the local coach state:\n   - Use the `STATE_ROOT`, `STATE_DIR`, and `STATE_FILE` resolved in Preconditions.\n   - Create the state directory with `mkdir -p`; if creation or a temporary write+rename preflight fails, abort instead of falling back to the target worktree.\n   - Resolve `SKILL_DIR` as this skill's directory and run `bash \"$SKILL_DIR\u002Fscripts\u002Fcleanup-state.sh\" --state-root \"$STATE_ROOT\" --current \"$STATE_FILE\"` before creating or updating state. If cleanup fails, warn and continue; cleanup failure must not alter the coaching result.\n   - The state file is outside the target worktree and must not be committed.\n   - If the state file does not exist, create it after reading the diff.\n   - If it exists and passed the existing-state validation from Preconditions, load it and resume from its `current_question`.\n   - If `base_commit` or `head_ref` in the state file differs from the pinned values, do not reuse it. Create or use the state file derived from the current `$BASE_SHORT-$HEAD_SHORT` pair.\n   - Cleanup policy is centralized in `scripts\u002Fcleanup-state.sh`: delete state files older than 30 days, keep the 20 newest files per repo, and always preserve `$STATE_FILE` even when that exceeds the cap.\n\n4. State file contents should be compact Markdown:\n   - `status`: `active` or `complete`\n   - `base`: the user-provided base string\n   - `base_commit`: pinned base commit\n   - `head_ref`: pinned HEAD\n   - `snapshot`: 2-3 bullets about the diff\n   - `questions`: numbered candidate questions, maximum 5\n   - `answered`: prior accepted question\u002Fanswer pairs\n   - `answer_attempts`: current-question attempts and coach reactions that were not yet accepted, if any\n   - `skipped_answer_attempts`: skipped or moved-on question attempts and coach reactions that are no longer tied to `current_question`, if any\n   - `current_question`: the single question to ask next\n   - `review_focus`: up to 3 reading focus bullets\n   - `learning_hook`: 1-2 learning notes\n   - `ledger_draft`: notes the user can carry into their review\n\n5. Read the diff for understanding, not triage:\n   - What changed?\n   - Which files should the user read first?\n   - What intent or assumption is visible from the diff?\n   - What is still unclear from code alone?\n   - What review habit would help on this PR?\n\n6. Keep output bounded:\n   - Generate at most 5 candidate questions in the state file.\n   - Output at most 1 question in the response.\n   - At most 3 review focus bullets.\n   - At most 2 learning hooks.\n   - Prefer one strong question over several weak ones.\n\n7. Continuing a coaching loop:\n   - If the user answers the current question, first write a `Response To Your Answer` section. Use direct language: `合っています`, `一部合っています`, or `そこは違います`.\n   - If the answer is correct enough for the review habit being practiced, update `answered`, advance `current_question`, and ask the next candidate question.\n   - If the answer is incomplete, ambiguous, or off target, update `answer_attempts`, keep the same `current_question`, and ask one narrower follow-up about the same question. Do not advance yet.\n   - If the user sends an additional response for the same question, respond to that attempt with the same direct judgment, then either accept and advance or keep the current question with one narrower follow-up.\n   - If the user explicitly asks to skip or move on, record the attempt in `skipped_answer_attempts`, advance `current_question`, and note what remains unverified. Keep `answer_attempts` reserved for the active `current_question`; do not carry skipped attempts into the next question's current-attempt state.\n   - If the user invokes the skill again without an answer, repeat the current question with shorter context.\n   - If all questions are answered, produce the final summary, set `status: complete`, and clear `current_question` so the state cannot be resumed as an active answer continuation.\n   - If the user asks for a summary early, produce a summary from answered items and leave the state resumable.\n\n8. Final guard:\n   - Run `git status --porcelain --untracked-files=normal` again.\n   - Run `git rev-parse HEAD` again and compare with `HEAD_REF`.\n   - If any final guard command fails, abort with the command output.\n   - If any worktree content or HEAD changed, abort and explain that the coaching output may not match the current branch state.\n\n## Output Format\n\nFor an active coaching turn, use this section structure:\n\n```markdown\n# Review Coach\n\n## State\n- 状態ファイル:\n- 進捗:\n\n## Response To Your Answer\n- （回答継続ターンのみ。合っています \u002F 一部合っています \u002F そこは違います、のいずれかを明示する）\n\n## Snapshot\n- 何が変わったか:\n- 最初に読むべき場所:\n\n## Next Question\n1. ...\n\n## Why This Question\n- ...\n```\n\nFor the final summary, use this section structure:\n\n```markdown\n# Review Coach Summary\n\n## What You Clarified\n- ...\n\n## Review Focus\n- ...\n\n## Learning Hook\n- この PR から学べること:\n- 練習するレビュー習慣:\n\n## Review Ledger Draft\n- 迷った点:\n- 見落としやすい理由:\n- 次のチェックリスト項目:\n- 自動化候補:\n```\n\n## Style\n\n- Be concrete and grounded in the committed diff.\n- If a conclusion depends on missing information, state what to verify instead of guessing.\n- Use plain Japanese. Keep each bullet short enough to act on.\n- Keep the coaching loop one-question-at-a-time. Do not list the remaining questions unless the user asks.\n- Avoid praise, scoring, severity labels, and merge advice.\n",{"name":5,"description":7},"main","dad20ea2a4096fe9379fdbee5efcec3ef838ab9e","private_dot_codex\u002Fskills\u002Fpr-review-coach",0,"https:\u002F\u002Fgithub.com\u002Ftoku345\u002Fdotfiles","https:\u002F\u002Fgithub.com\u002Ftoku345","2026-11-13 17:02:22",{"source":8,"skillName":5,"commands":59,"prompt":69,"zipAvailable":70},[60,63,66],{"tool":61,"command":62},"npx","npx skills add toku345\u002Fdotfiles --skill pr-review-coach",{"tool":64,"command":65},"bunx","bunx skills add toku345\u002Fdotfiles --skill pr-review-coach",{"tool":67,"command":68},"pnpm","pnpm dlx skills add toku345\u002Fdotfiles --skill pr-review-coach","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Ftoku345\u002Fdotfiles\u002Fblob\u002Fmain\u002Fprivate_dot_codex\u002Fskills\u002Fpr-review-coach\u002FSKILL.md",true,[72],{"path":73,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":76,"sourceHtmlUrl":77},"scripts\u002Fcleanup-state.sh","SCRIPT","脚本",6237,"https:\u002F\u002Fgithub.com\u002Ftoku345\u002Fdotfiles\u002Fblob\u002Fmain\u002Fprivate_dot_codex\u002Fskills\u002Fpr-review-coach\u002Fscripts\u002Fcleanup-state.sh",[79,98,118,138,163,175],{"skillNo":80,"name":81,"nameZh":6,"description":82,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":83,"sourceHtmlUrl":84,"categories":85,"keywords":91,"publishedAt":46},"01M6BVHMWSZMNVE2HDN10GFDQ8","teach","Explain code, changes, and subsystems by investigating how they work and why they were designed that way, then teach at the user's pace. Use for explicit teach requests, teach me this, help me understand this implementation, この実装を教えて, 仕組みと設計背景を知りたい, and understanding before review or modification. Do not trigger for every factual question or primarily implementation requests.","https:\u002F\u002Fgithub.com\u002Ftoku345\u002Fdotfiles\u002Fblob\u002Fmain\u002Fdot_agents\u002Fskills\u002Fteach\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Ftoku345\u002Fdotfiles\u002Fblob\u002Fmain\u002Fdot_agents\u002Fskills\u002Fteach\u002FSKILL.md",[86],{"categoryNo":87,"categoryName":88,"taxonomyType":89,"taxonomyTypeDesc":90},"01JBSEEDCAT000000000000039","教师与教育","PROFESSION","适用职业",[81,23,92,93,94,95,96,97],"teach me","why","how","explain code","help","code",{"skillNo":99,"name":100,"nameZh":6,"description":101,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":102,"categories":103,"keywords":104,"publishedAt":46},"01M6BVJ23D24K530S7WK257HHK","pr-review","Comprehensive pre-PR review orchestrator. Runs named specialist subagents on the current branch's committed diff, conditionally checks simplification, verifies each normalized Critical\u002FImportant candidate with a dedicated finding-verifier, then synthesizes Critical \u002F Important \u002F Suggestions \u002F Strengths using the bundled `references\u002Freview-criteria.md` gate policy. Use before creating a pull request as a heavy quality gate. Intended successor to the legacy bash `triple-review` orchestrator.","https:\u002F\u002Fgithub.com\u002Ftoku345\u002Fdotfiles\u002Fblob\u002Fmain\u002Fprivate_dot_codex\u002Fskills\u002Fpr-review\u002FSKILL.md",[],[23,19,20,105,106,107,29,108,109,110,111,112,113,34,35,114,115,116,117,37],"candidate","with","verifier","orchestrator","as","simplification","references","Legacy","policy","quality gate","pull request","pull","Bash",{"skillNo":119,"name":120,"nameZh":6,"description":121,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":122,"categories":123,"keywords":132,"publishedAt":46},"01M6BVHXZYDT858V8GQEJHKMPC","writing-proofreader","日本語ブログ・技術記事の校正スキル。Fumitakaの文体ガイドラインに基づいて表現・構成・トーンをチェックし、改善提案を行う。「校正して」「レビューして」「文章チェックして」「書いた記事を見て」「ブログ見てもらえる？」「おかしいところない？」「公開前に確認して」「この記事どう思う？」など、記事やブログの品質チェックに関するリクエスト全般で使う。Markdownやテキストの文章校正を依頼されたら必ずこのスキルを参照する。記事の「推敲」「添削」「赤入れ」といった表現でも発動すること。","https:\u002F\u002Fgithub.com\u002Ftoku345\u002Fdotfiles\u002Fblob\u002Fmain\u002Fprivate_dot_claude\u002Fskills\u002Fwriting-proofreader\u002FSKILL.md",[124,129],{"categoryNo":125,"categoryName":126,"taxonomyType":127,"taxonomyTypeDesc":128},"01JBSEEDCAT000000000000018","写作与文案","SCENARIO","使用场景",{"categoryNo":130,"categoryName":131,"taxonomyType":89,"taxonomyTypeDesc":90},"01JBSEEDCAT000000000000036","内容创作者",[133,134,135,136,137],"writing","writing proofreader","proofreader","提案","文章",{"skillNo":139,"name":100,"nameZh":6,"description":140,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":141,"categories":142,"keywords":146,"publishedAt":46},"01M6BVHTTDAY7CYFMFR0HZX1YJ","Claude-side pre-PR review gate. Resolves the branch's base ref (gh PR view or explicit --base), pins an authoritative diff packet, then launches the pr-review dynamic workflow (~\u002F.claude\u002Fworkflows\u002Fpr-review.js) which fans out up to 8 review specialists (code-reviewer, security-reviewer, adversarial-reviewer, pr-test-analyzer, comment-analyzer, silent-failure-hunter, type-design-analyzer, code-simplifier), fails closed on coverage, and verifies Critical\u002FImportant findings. Use before creating a pull request as a quality gate for thick changes — especially where the Codex CLI `$pr-review` skill is unavailable. Triggers: \"pre-PR review\", \"PR 前レビュー\", \"レビュー gate を回して\", \"run the pr-review gate\".","https:\u002F\u002Fgithub.com\u002Ftoku345\u002Fdotfiles\u002Fblob\u002Fmain\u002Fprivate_dot_claude\u002Fskills\u002Fpr-review\u002FSKILL.md",[143],{"categoryNo":144,"categoryName":145,"taxonomyType":127,"taxonomyTypeDesc":128},"01JBSEEDCAT000000000000023","Skill与智能体开发",[20,19,23,147,148,149,37,150,151,29,100,152,153,154,97,155,115,114,156,157,158,159,116,160,161,162],"js","gh pr","reviewer","coverage","up","which","request","security","run","codex cli","workflows","test","workflow","codex","cli","design",{"skillNo":164,"name":165,"nameZh":6,"description":166,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":167,"categories":168,"keywords":169,"publishedAt":46},"01M6BVHRPQ77P9BF94T0VQ871E","codex-usage","Codex CLI による実装計画レビューの条件と手順、および `\u002Fcodex:adversarial-review` \u002F `\u002Fcodex:rescue` の使い分け。厚い変更の計画完成時や、調査委譲・別案試行・バックグラウンド実行を検討するときに参照する。","https:\u002F\u002Fgithub.com\u002Ftoku345\u002Fdotfiles\u002Fblob\u002Fmain\u002Fprivate_dot_claude\u002Fskills\u002Fcodex-usage\u002FSKILL.md",[],[170,171,160,23,172,173,174,156,161],"usage","codex usage","adversarial","adversarial-review","rescue",{"skillNo":176,"name":177,"nameZh":6,"description":178,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":179,"sourceHtmlUrl":180,"categories":181,"keywords":182,"publishedAt":46},"01M6BVHQ1QDEZJN8FFZ62X5PSV","brainstorming","ソクラテス式対話で要件と設計を詰めてから実装方針を固めるブレインストーミングスキル。「ブレスト」「設計を考えたい」「どう実装すべきか」「アーキテクチャを相談したい」「設計相談」「実装の前に整理したい」「方針を決めたい」などのリクエストで発動する。Triggers Socratic-dialogue design refinement before implementation; surfaces 2-3 approaches and records key decisions as ADRs.","https:\u002F\u002Fgithub.com\u002Ftoku345\u002Fdotfiles\u002Fblob\u002Fmain\u002Fprivate_dot_claude\u002Fskills\u002Fbrainstorming\u002FLICENSE.superpowers","https:\u002F\u002Fgithub.com\u002Ftoku345\u002Fdotfiles\u002Fblob\u002Fmain\u002Fprivate_dot_claude\u002Fskills\u002Fbrainstorming\u002FSKILL.md",[],[177,183,184,185,186,187,109,188,189,190,191,162],"implementation","socratic","refinement","整理","records","triggers","dialogue","surfaces","decisions"]