[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6C67CY2K89W8F8DMGM8APFQ":3,"skill-same:01M6C67CY2K89W8F8DMGM8APFQ":72},{"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":35,"linkOnly":36,"markdownContent":37,"markdownBody":38,"frontMatter":39,"refName":40,"commitSha":41,"skillDirectory":42,"forksCount":43,"repositoryHtmlUrl":44,"repositoryHomepageUrl":6,"ownerHtmlUrl":45,"ownerBlogUrl":46,"ownerDescription":6,"updatedAt":47,"install":48,"resources":61},"01M6C67CY2K89W8F8DMGM8APFQ","pr",null,"The full pipeline from \"code is ready\" to \"ready to merge\" — pre-push verification, three-way self-review, opening the PR, watching CI and review threads. Read BEFORE committing, opening a PR, or checking on an open one.","clice-io\u002Fkotatsu","clice-io","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F176553789?v=4","01M6BZEJH3SKDZ3SMSS1V6CKKB","clice","01M6C671678X7BC9NX3E1SEWW5",26,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fclice-io\u002Fkotatsu\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fpr\u002FSKILL.md",[],[5,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34],"open","full pipeline","threads","full","self","three","opening a pr","ready","read","review","pipeline","ci","push","verification","code","merge","2026-11-10 10:12:30",false,"---\nname: pr\ndescription: The full pipeline from \"code is ready\" to \"ready to merge\" — pre-push verification, three-way self-review, opening the PR, watching CI and review threads. Read BEFORE committing, opening a PR, or checking on an open one.\n---\n\n# PR Pipeline\n\nThe development flow is: branch off `main` → write code (discussing requirements with the maintainer) → self-review and fix → open the PR → watch CI and reviews until everything is handled → report that it is ready. **The maintainer merges — never merge yourself.**\n\n## Branch\n\n- Always branch from freshly fetched `origin\u002Fmain` — `git fetch origin && git checkout -b \u003Ctype>\u002F\u003Cshort-topic> origin\u002Fmain` — never from the local `main`. `\u003Ctype>` uses the conventional-commit types, e.g. `fix\u002Fqueue-cancel`, `refactor\u002Fcodec-macros`.\n\n## Pre-push verification (every push, not just the first)\n\nNever push anything unverified — \"it compiles\" is not verified, and CI is not a debugger.\n\n1. `pixi run format`.\n2. The tests pass locally (the test skill): `pixi run test` builds the `debug` preset and runs every ctest stage, `unit_tests`, `system_tests` and the integration tests included; ctest handles the snapshot dir and the drivers' paths. Every failure on the branch is yours to fix now — even if it looks pre-existing (main is green), and never by skipping, disabling, or weakening the test.\n3. Read results from a full log, not a pipe: `cmd > \u002Ftmp\u002Fx.log 2>&1`, then the exit code and the log tail (`ninja: build stopped`, `FAILED`, the suite summary). `| tail` reports tail's exit code (a failed build looks green), `pipefail` + `| grep error` fails when there is nothing to find. Before running a suite, check the test binary is newer than your last source edit — a \"1362 passed\" on a stale binary verifies nothing.\n4. Long local runs (build, suites) go through Bash `run_in_background`, which notifies on exit — not a detached script polled by timed wake-ups.\n5. A platform failure you can reproduce locally is fixed locally. With a Windows checkout reachable from WSL, build and run the failing suite there before pushing; CI is not a debugger.\n\n## Pushing\n\n`git status -sb` immediately before every push, then push with no arguments (upstream) or the branch name you just read. Never take the branch name from the session's start-of-conversation snapshot — it is stale after compaction, and a stale explicit name once resurrected a merged PR's deleted head branch (`git push origin :\u003Cbranch>` undoes that).\n\n## Self-review (before opening)\n\nCommit all work first — the review diff only sees commits, so a dirty worktree means the reviewer inspects an incomplete patch (`git status` must be clean). Then review the full diff (`git diff origin\u002Fmain...HEAD` — never the local `main`, which goes stale) and fix everything confirmed before opening:\n\nReview with 3 parallel Opus subagents, each reviewing the diff independently and told to read `.claude\u002FCLAUDE.md` and the relevant skills (cpp-style, test-style) first — correctness (logic errors, edge cases, undefined behavior; coroutine lifetime and cancellation paths deserve extra suspicion), style (naming, redundancy, the skills' rules), tests (new functionality covered, no existing tests broken or weakened). Do not use codex for reviews. Treat findings as hypotheses: verify each concrete claim before fixing it.\n\n## Opening\n\n- Confirm with the maintainer before creating the PR.\n- One PR is one complete, user-perceivable capability. Implementation stages order the work and isolate risk; they are commit layering, not PR boundaries — the maintainer reviews one capability at a time, not a chain of partial PRs.\n- Title follows the conventional commit format — CI checks it, and it becomes the squash-merge commit on `main`.\n- Body: a concise summary of what changed and why. Never reference local file paths, private notes, or other material a reader without this machine cannot see.\n- After `gh pr edit --body-file`, read the body back and check its length: an API timeout in a `gh pr view | gh pr edit` chain writes an empty body. Never pipe the two in one command.\n- An external contributor's PR gets its title and body rewritten before merge — the title is the squash commit, and the body must describe the post-review state, including fixes made on their behalf.\n\n## Watching\n\nThis is a sustained loop, not a single check — reviews and CI both take time, and a PR typically needs 5-6 rounds of check-and-fix before it is truly settled. Do not stop at the first green check.\n\n- Cadence: one check every ~20 minutes by default, via timed wake-ups — never background shell loops. Tune to the situation: CI runs take their own time, and agent reviewers need a while to post after each push. Decide the total number of rounds yourself based on elapsed time and remaining activity.\n- Every check covers all three: CI status, unresolved review threads, and the formal review decision. A green pipeline with open review comments is not done — **review threads must be at zero before the maintainer merges**. `python3 .claude\u002Fskills\u002Fpr\u002Fscripts\u002Finfo.py [N]` prints the PR's state, merge status, review decision, check buckets (failing ones with links) and review load on one screen; `comments.py` prints the findings themselves.\n- Bots also post findings in review bodies — the codex connector puts P2 findings there with blob permalinks, not as inline threads. `comments.py` lists both channels; when the maintainer reports a comment you cannot see as a thread, it is in a review body.\n- Threads go through the resolve-comments skill: it pulls unresolved threads (by `isResolved`, never timestamps), applies root-cause fixes in the worktree, resolves the threads, and returns a compact summary — the GraphQL plumbing and comment bodies stay out of the main conversation. Threads are settled by resolving, not replying, and none stay open waiting for the maintainer: debatable points get the most defensible solution applied and recorded, batched into the final report.\n- If resolve-comments left changes in the worktree: run the pre-push verification, then push an ordinary commit — never `--amend`, never force push. History rewrites destroy review anchors and reviewers' incremental diffs.\n- Force push has essentially no legitimate use on a PR branch. The usual temptation — amending fixes into the previous commit to keep the branch \"one tidy commit\" — buys nothing: the squash merge flattens the branch anyway and only the PR title lands in `main` history. The single real case is rebasing onto a newer `main` (e.g. to resolve a conflict), and that requires asking the maintainer first.\n- CI failure: reproduce and fix locally, verify, then push. Digest CI logs via a subagent; don't pull raw logs into the main conversation.\n- Keep API calls sparse — one batch per check, `sleep 1` between `gh` calls.\n\n## Done\n\n- CI fully green, zero unresolved review threads, and no blocking review decision (`reviewDecision` must not be `CHANGES_REQUESTED` — a top-level \"changes requested\" review blocks the merge even after every inline thread is resolved; address its feedback and request a re-review) → report to the maintainer that the PR is ready to merge: a one-paragraph summary of what review found and how it was addressed, plus every design decision taken while resolving threads (chosen vs. alternative), so the maintainer can accept or overturn them in one pass. Then stop — merging is the maintainer's call.\n- The default bar stays high: elegant code, edge cases considered. \"Merge now, clean up in a dedicated refactor PR later\" is a real move in this project, but that trade-off is the maintainer's call, made case by case — never the agent's default.\n","# PR Pipeline\n\nThe development flow is: branch off `main` → write code (discussing requirements with the maintainer) → self-review and fix → open the PR → watch CI and reviews until everything is handled → report that it is ready. **The maintainer merges — never merge yourself.**\n\n## Branch\n\n- Always branch from freshly fetched `origin\u002Fmain` — `git fetch origin && git checkout -b \u003Ctype>\u002F\u003Cshort-topic> origin\u002Fmain` — never from the local `main`. `\u003Ctype>` uses the conventional-commit types, e.g. `fix\u002Fqueue-cancel`, `refactor\u002Fcodec-macros`.\n\n## Pre-push verification (every push, not just the first)\n\nNever push anything unverified — \"it compiles\" is not verified, and CI is not a debugger.\n\n1. `pixi run format`.\n2. The tests pass locally (the test skill): `pixi run test` builds the `debug` preset and runs every ctest stage, `unit_tests`, `system_tests` and the integration tests included; ctest handles the snapshot dir and the drivers' paths. Every failure on the branch is yours to fix now — even if it looks pre-existing (main is green), and never by skipping, disabling, or weakening the test.\n3. Read results from a full log, not a pipe: `cmd > \u002Ftmp\u002Fx.log 2>&1`, then the exit code and the log tail (`ninja: build stopped`, `FAILED`, the suite summary). `| tail` reports tail's exit code (a failed build looks green), `pipefail` + `| grep error` fails when there is nothing to find. Before running a suite, check the test binary is newer than your last source edit — a \"1362 passed\" on a stale binary verifies nothing.\n4. Long local runs (build, suites) go through Bash `run_in_background`, which notifies on exit — not a detached script polled by timed wake-ups.\n5. A platform failure you can reproduce locally is fixed locally. With a Windows checkout reachable from WSL, build and run the failing suite there before pushing; CI is not a debugger.\n\n## Pushing\n\n`git status -sb` immediately before every push, then push with no arguments (upstream) or the branch name you just read. Never take the branch name from the session's start-of-conversation snapshot — it is stale after compaction, and a stale explicit name once resurrected a merged PR's deleted head branch (`git push origin :\u003Cbranch>` undoes that).\n\n## Self-review (before opening)\n\nCommit all work first — the review diff only sees commits, so a dirty worktree means the reviewer inspects an incomplete patch (`git status` must be clean). Then review the full diff (`git diff origin\u002Fmain...HEAD` — never the local `main`, which goes stale) and fix everything confirmed before opening:\n\nReview with 3 parallel Opus subagents, each reviewing the diff independently and told to read `.claude\u002FCLAUDE.md` and the relevant skills (cpp-style, test-style) first — correctness (logic errors, edge cases, undefined behavior; coroutine lifetime and cancellation paths deserve extra suspicion), style (naming, redundancy, the skills' rules), tests (new functionality covered, no existing tests broken or weakened). Do not use codex for reviews. Treat findings as hypotheses: verify each concrete claim before fixing it.\n\n## Opening\n\n- Confirm with the maintainer before creating the PR.\n- One PR is one complete, user-perceivable capability. Implementation stages order the work and isolate risk; they are commit layering, not PR boundaries — the maintainer reviews one capability at a time, not a chain of partial PRs.\n- Title follows the conventional commit format — CI checks it, and it becomes the squash-merge commit on `main`.\n- Body: a concise summary of what changed and why. Never reference local file paths, private notes, or other material a reader without this machine cannot see.\n- After `gh pr edit --body-file`, read the body back and check its length: an API timeout in a `gh pr view | gh pr edit` chain writes an empty body. Never pipe the two in one command.\n- An external contributor's PR gets its title and body rewritten before merge — the title is the squash commit, and the body must describe the post-review state, including fixes made on their behalf.\n\n## Watching\n\nThis is a sustained loop, not a single check — reviews and CI both take time, and a PR typically needs 5-6 rounds of check-and-fix before it is truly settled. Do not stop at the first green check.\n\n- Cadence: one check every ~20 minutes by default, via timed wake-ups — never background shell loops. Tune to the situation: CI runs take their own time, and agent reviewers need a while to post after each push. Decide the total number of rounds yourself based on elapsed time and remaining activity.\n- Every check covers all three: CI status, unresolved review threads, and the formal review decision. A green pipeline with open review comments is not done — **review threads must be at zero before the maintainer merges**. `python3 .claude\u002Fskills\u002Fpr\u002Fscripts\u002Finfo.py [N]` prints the PR's state, merge status, review decision, check buckets (failing ones with links) and review load on one screen; `comments.py` prints the findings themselves.\n- Bots also post findings in review bodies — the codex connector puts P2 findings there with blob permalinks, not as inline threads. `comments.py` lists both channels; when the maintainer reports a comment you cannot see as a thread, it is in a review body.\n- Threads go through the resolve-comments skill: it pulls unresolved threads (by `isResolved`, never timestamps), applies root-cause fixes in the worktree, resolves the threads, and returns a compact summary — the GraphQL plumbing and comment bodies stay out of the main conversation. Threads are settled by resolving, not replying, and none stay open waiting for the maintainer: debatable points get the most defensible solution applied and recorded, batched into the final report.\n- If resolve-comments left changes in the worktree: run the pre-push verification, then push an ordinary commit — never `--amend`, never force push. History rewrites destroy review anchors and reviewers' incremental diffs.\n- Force push has essentially no legitimate use on a PR branch. The usual temptation — amending fixes into the previous commit to keep the branch \"one tidy commit\" — buys nothing: the squash merge flattens the branch anyway and only the PR title lands in `main` history. The single real case is rebasing onto a newer `main` (e.g. to resolve a conflict), and that requires asking the maintainer first.\n- CI failure: reproduce and fix locally, verify, then push. Digest CI logs via a subagent; don't pull raw logs into the main conversation.\n- Keep API calls sparse — one batch per check, `sleep 1` between `gh` calls.\n\n## Done\n\n- CI fully green, zero unresolved review threads, and no blocking review decision (`reviewDecision` must not be `CHANGES_REQUESTED` — a top-level \"changes requested\" review blocks the merge even after every inline thread is resolved; address its feedback and request a re-review) → report to the maintainer that the PR is ready to merge: a one-paragraph summary of what review found and how it was addressed, plus every design decision taken while resolving threads (chosen vs. alternative), so the maintainer can accept or overturn them in one pass. Then stop — merging is the maintainer's call.\n- The default bar stays high: elegant code, edge cases considered. \"Merge now, clean up in a dedicated refactor PR later\" is a real move in this project, but that trade-off is the maintainer's call, made case by case — never the agent's default.\n",{"name":5,"description":7},"main","a0e2560ba22a1b28ac1b42fd7796c50e90f5b384",".claude\u002Fskills\u002Fpr",4,"https:\u002F\u002Fgithub.com\u002Fclice-io\u002Fkotatsu","https:\u002F\u002Fgithub.com\u002Fclice-io","https:\u002F\u002Fclice.io\u002F","2026-11-13 10:27:45",{"source":8,"skillName":5,"commands":49,"prompt":59,"zipAvailable":60},[50,53,56],{"tool":51,"command":52},"npx","npx skills add clice-io\u002Fkotatsu --skill pr",{"tool":54,"command":55},"bunx","bunx skills add clice-io\u002Fkotatsu --skill pr",{"tool":57,"command":58},"pnpm","pnpm dlx skills add clice-io\u002Fkotatsu --skill pr","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fclice-io\u002Fkotatsu\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fpr\u002FSKILL.md",true,[62,68],{"path":63,"resourceType":64,"resourceTypeDesc":65,"sizeBytes":66,"sourceHtmlUrl":67},"scripts\u002Fcomments.py","SCRIPT","脚本",10999,"https:\u002F\u002Fgithub.com\u002Fclice-io\u002Fkotatsu\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fpr\u002Fscripts\u002Fcomments.py",{"path":69,"resourceType":64,"resourceTypeDesc":65,"sizeBytes":70,"sourceHtmlUrl":71},"scripts\u002Finfo.py",3303,"https:\u002F\u002Fgithub.com\u002Fclice-io\u002Fkotatsu\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fpr\u002Fscripts\u002Finfo.py",[73,101,123,142,160,181],{"skillNo":74,"name":75,"nameZh":6,"description":76,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":77,"categories":78,"keywords":84,"publishedAt":35},"01M6C67NK9F2XEEW9VK03YW5G2","test","Run kotatsu test suites. Optional args = suite (ctest | integration | all, default all) and cmake preset for the ctest suites (default `debug`). Runs in a forked context — test output stays out of the main conversation; only a digest returns.","https:\u002F\u002Fgithub.com\u002Fclice-io\u002Fkotatsu\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Ftest\u002FSKILL.md",[79],{"categoryNo":80,"categoryName":81,"taxonomyType":82,"taxonomyTypeDesc":83},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",[75,85,86,87,88,89,90,91,92,93,94,95,96,40,97,98,99,100],"preset","run","integration","only","cmake","ctest","debug","context","returns","conversation","for","default","output","fork","digest","suite",{"skillNo":102,"name":103,"nameZh":6,"description":104,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":105,"categories":106,"keywords":108,"publishedAt":35},"01M6C67JHMEH8Y4TQB9TH7C9QJ","test-style","How kotatsu's tests are organized and written — levels (unit, system, integration), the module-first layout, dependency and trust rules, naming, zest checks, determinism. Read BEFORE writing, moving or reviewing any test.","https:\u002F\u002Fgithub.com\u002Fclice-io\u002Fkotatsu\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Ftest-style\u002FSKILL.md",[107],{"categoryNo":80,"categoryName":81,"taxonomyType":82,"taxonomyTypeDesc":83},[109,75,110,111,112,113,114,27,87,115,116,117,118,119,120,121,122],"test style","style","first","how","dependency","system","writing","Rules","unit","trust","tests","module","naming","layout",{"skillNo":124,"name":125,"nameZh":6,"description":126,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":127,"categories":128,"keywords":129,"publishedAt":35},"01M6C67FJ1SC6CJH3F7KJ6J9FY","resolve-comments","Pull unresolved review threads of the current PR, apply the fixes in the worktree, resolve the threads, and return a compact summary. Runs inline; the digest script keeps the bot boilerplate out of the conversation.","https:\u002F\u002Fgithub.com\u002Fclice-io\u002Fkotatsu\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fresolve-comments\u002FSKILL.md",[],[130,131,132,5,133,134,28,94,135,136,137,138,21,99,139,140,141],"resolve comments","comments","pull","worktree","bot","fixes","compact","apply","inline","script","boilerplate","summary",{"skillNo":143,"name":144,"nameZh":6,"description":145,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":146,"categories":147,"keywords":148,"publishedAt":35},"01M6C67AC5ABFCX4GN4MVXK89D","format","Format all project source files (C++, Python, JS\u002FTS, Markdown, JSON, TOML, YAML). Run before every commit.","https:\u002F\u002Fgithub.com\u002Fclice-io\u002Fkotatsu\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fformat\u002FSKILL.md",[],[144,149,86,150,151,152,153,154,155,156,157,158,159],"markdown","json","yaml","python","js","commit","c++","project","toml","files","source",{"skillNo":161,"name":162,"nameZh":6,"description":163,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":164,"categories":165,"keywords":166,"publishedAt":35},"01M6C677FJ70HR4KG0N92G527M","cpp-style","kotatsu C++ coding conventions — redundancy elimination (the rule we care most about), file organization, macro.h isolation, dual-mode exception policy, template deduction and type-trait rules, naming, modern C++ preferences. Read BEFORE writing or modifying any C++ code.","https:\u002F\u002Fgithub.com\u002Fclice-io\u002Fkotatsu\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fcpp-style\u002FSKILL.md",[],[167,168,110,169,170,115,116,171,33,172,27,173,174,175,176,177,178,155,179,180],"cpp","cpp style","policy","preferences","file","template","macro","coding","mode","coding conventions","organization","isolation","file organization","type",{"skillNo":182,"name":183,"nameZh":6,"description":184,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":185,"categories":186,"keywords":187,"publishedAt":35},"01M6C673Z8W2VYG5CGPE7CY1W1","codex","Drive the codex CLI (GPT-6 astra) as a delegate — debugging, test writing, scoped implementation. Not for reviews, which go to Opus subagents. Read BEFORE invoking codex.","https:\u002F\u002Fgithub.com\u002Fclice-io\u002Fkotatsu\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fcodex\u002FSKILL.md",[],[183,188,189,115,190,75,191,27,192,193,194,195,196,197,198,199,95,200,201,202],"codex cli","delegate","debugging","cli","implementation","go","gpt","drive","subagents","as","reviews","which","scoped","gpt-6","opus"]