[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71SNT6W8V2DZVCX67CE44B5":3,"skill-same:01M71SNT6W8V2DZVCX67CE44B5":77},{"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":37,"linkOnly":38,"markdownContent":39,"markdownBody":40,"frontMatter":41,"refName":43,"commitSha":44,"skillDirectory":45,"forksCount":46,"repositoryHtmlUrl":47,"repositoryHomepageUrl":48,"ownerHtmlUrl":49,"ownerBlogUrl":50,"ownerDescription":51,"updatedAt":52,"install":53,"resources":66},"01M71SNT6W8V2DZVCX67CE44B5","caveman-pr",null,"Ultra-compressed, signal-only pull request descriptions","HigorAlves\u002Forc","HigorAlves","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F11262976?v=4","01M71S79EZEMHZ8PQSV0XQJHYY","Higor Alves","01M71S79FKKTCHCN1EDR8DSTWQ",7,"MIT","https:\u002F\u002Fgithub.com\u002FHigorAlves\u002Forc\u002Fblob\u002Fmain\u002Forc\u002Fskills\u002Fcaveman-pr\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36],"pr","caveman pr","caveman","pull request","pr description","pull","write","user","use","only","opening a pr","draft","ultra","pr body","request","signal","body","when","2026-11-10 13:02:02",false,"---\nname: caveman-pr\ndescription: Ultra-compressed, signal-only pull request descriptions\nwhen_to_use: Use when opening a PR or when the user says \"write a PR description\", \"PR body\", \"draft the PR\", or invokes \u002Fcaveman-pr.\n---\n\nWrite PR descriptions terse and exact. Reviewers don't need a tour of your diff — they need a *why*, a *how-tested*, and (if relevant) a heads-up.\n\n## Rules\n\n**Title:**\n\n- Same shape as the squash-merge commit subject — Conventional Commits if the project uses them (`feat(scope): ...`, `fix(scope): ...`).\n- ≤ 72 chars; ≤ 50 if possible.\n- Imperative mood (\"add\", \"fix\", \"remove\" — not \"added\").\n- No `[WIP]` — use a draft PR instead.\n- No emoji unless the project already does it.\n\n**Body — at most 4 sections, in this order. Omit any that don't add signal.**\n\n### Why (almost always mandatory)\n- 1–3 sentences. Link the plan \u002F RFC \u002F ADR \u002F Jira ticket \u002F issue if that's the why.\n- Skip ONLY when the title is genuinely self-explanatory (e.g. `fix(billing): guard against zero-cap users` — title says everything).\n\n### What changed (often skippable)\n- ONLY include if the diff isn't obvious from a 30-second skim.\n- Bullets of structural changes. Don't restate file paths the reviewer will see anyway.\n- Drop \"Refactored\", \"Cleaned up\" — say what *behavior* changed.\n- When the *shape* is the point, one small visual beats bullets: a `diff`-sketch of a call tree, component tree, or file tree, pseudocode of the new control flow, or a short mermaid sequence. One visual, never a gallery.\n\n### How tested (mandatory)\n- One or two lines. Command run + result. Or a link to QA artifacts.\n- Web change: link to `.orc\u002F\u003Cbranch>\u002Ffiles\u002Fqa\u002Fsteps.md` (or wherever orc's QA evidence lives).\n- \"Tests: 47 pass, 0 fail.\" beats \"Wrote tests for the new branch and they all pass.\"\n- Evidence tiers: a screenshot or recording (S) when the change is visual and the environment allows it; execution output (A) — the exact test that failed before and passes now, command + result; prose on its own never counts.\n\n### Notes (only if there's something real)\n- **Merge danger** — required for anything beyond a trivial fix, one line: `Door: one-way | two-way · Blast radius: \u003Cone or two words>`. Two-way doors revert cleanly; one-way doors (migrations, deletions, published API changes, anything a revert won't undo) say what makes them hard to walk back.\n- Breaking changes — call out, including the migration step.\n- Risks the reviewer must look at twice.\n- Follow-up issues filed.\n- Skip platitudes (\"clean code\", \"all tests pass\" — already covered).\n\n### Trailers (footer, not a section)\n- `Closes #42`, `Refs #17`, `Fixes ENG-712` — one per line at the very bottom.\n- No AI attribution. No `Co-Authored-By: Claude`. No `Generated with…`.\n\n## What NEVER goes in\n\n- \"This PR does X\" — the title and diff already say it.\n- \"Please review carefully\" \u002F \"Let me know what you think\" — reviewer knows their job.\n- Line-by-line restatement of the diff.\n- Marketing voice (\"This game-changing refactor unlocks…\").\n- Emoji-stuffed checklists if the repo's PR template doesn't require them.\n- AI attribution of any kind.\n- A \"Screenshots\" section with placeholder text — either include real screenshots\u002Flinks or omit.\n\n## GitHub markdown craft\n\nTerse ≠ plain. Read [GITHUB-MARKDOWN.md](references\u002FGITHUB-MARKDOWN.md) when the body carries evidence bulk, code locations, or callouts — auto-links, permalinks, `\u003Cdetails>`, tables, task lists.\n\n## Examples\n\nRead [EXAMPLES.md](references\u002FEXAMPLES.md) for three shaped bodies — title-only bug fix, feature with Why + QA link, refactor with breaking change + merge-danger line — when unsure how terse the result reads.\n\n## Auto-Clarity\n\nAlways include a `## Why` section for: ADR-driven refactors, security fixes, data migrations, breaking changes. Never compress those into title-only — future debuggers need the context.\n\nThe Merge-danger line is mandatory for every one-way door: a migration, a deletion, a published API change, a config cutover. A reviewer deciding how carefully to read needs the door and the blast radius before the diff.\n\nFor **web changes**, `## How tested` MUST link to the QA artifact directory (per orc's web-QA evidence rule) or explicitly state \"no UI surface touched\". A bare \"tested manually\" is not acceptable.\n\n## Boundaries\n\nOnly generates the PR description (title + body) as a code block ready to paste into `gh pr create --title ... --body ...` or the GitHub UI. Does NOT:\n\n- open the PR (that's `\u002Forc:ship` or a manual `gh pr create`)\n- push commits\n- modify the diff\n- amend a previous PR\n\nThis skill is `\u002Forc:ship`'s **default** body composer (Phase 4); `\u002Forc:ship --verbose` opts out into the long-form template.\n\n## When to revert to verbose\n\nUser says \"verbose PR\", \"long-form description\", \"explain in detail\", \"this PR needs context\" — drop the compression and write a longer description with full reasoning, alternatives considered, risk model, etc. Caveman is the default, not a mandate.\n","Write PR descriptions terse and exact. Reviewers don't need a tour of your diff — they need a *why*, a *how-tested*, and (if relevant) a heads-up.\n\n## Rules\n\n**Title:**\n\n- Same shape as the squash-merge commit subject — Conventional Commits if the project uses them (`feat(scope): ...`, `fix(scope): ...`).\n- ≤ 72 chars; ≤ 50 if possible.\n- Imperative mood (\"add\", \"fix\", \"remove\" — not \"added\").\n- No `[WIP]` — use a draft PR instead.\n- No emoji unless the project already does it.\n\n**Body — at most 4 sections, in this order. Omit any that don't add signal.**\n\n### Why (almost always mandatory)\n- 1–3 sentences. Link the plan \u002F RFC \u002F ADR \u002F Jira ticket \u002F issue if that's the why.\n- Skip ONLY when the title is genuinely self-explanatory (e.g. `fix(billing): guard against zero-cap users` — title says everything).\n\n### What changed (often skippable)\n- ONLY include if the diff isn't obvious from a 30-second skim.\n- Bullets of structural changes. Don't restate file paths the reviewer will see anyway.\n- Drop \"Refactored\", \"Cleaned up\" — say what *behavior* changed.\n- When the *shape* is the point, one small visual beats bullets: a `diff`-sketch of a call tree, component tree, or file tree, pseudocode of the new control flow, or a short mermaid sequence. One visual, never a gallery.\n\n### How tested (mandatory)\n- One or two lines. Command run + result. Or a link to QA artifacts.\n- Web change: link to `.orc\u002F\u003Cbranch>\u002Ffiles\u002Fqa\u002Fsteps.md` (or wherever orc's QA evidence lives).\n- \"Tests: 47 pass, 0 fail.\" beats \"Wrote tests for the new branch and they all pass.\"\n- Evidence tiers: a screenshot or recording (S) when the change is visual and the environment allows it; execution output (A) — the exact test that failed before and passes now, command + result; prose on its own never counts.\n\n### Notes (only if there's something real)\n- **Merge danger** — required for anything beyond a trivial fix, one line: `Door: one-way | two-way · Blast radius: \u003Cone or two words>`. Two-way doors revert cleanly; one-way doors (migrations, deletions, published API changes, anything a revert won't undo) say what makes them hard to walk back.\n- Breaking changes — call out, including the migration step.\n- Risks the reviewer must look at twice.\n- Follow-up issues filed.\n- Skip platitudes (\"clean code\", \"all tests pass\" — already covered).\n\n### Trailers (footer, not a section)\n- `Closes #42`, `Refs #17`, `Fixes ENG-712` — one per line at the very bottom.\n- No AI attribution. No `Co-Authored-By: Claude`. No `Generated with…`.\n\n## What NEVER goes in\n\n- \"This PR does X\" — the title and diff already say it.\n- \"Please review carefully\" \u002F \"Let me know what you think\" — reviewer knows their job.\n- Line-by-line restatement of the diff.\n- Marketing voice (\"This game-changing refactor unlocks…\").\n- Emoji-stuffed checklists if the repo's PR template doesn't require them.\n- AI attribution of any kind.\n- A \"Screenshots\" section with placeholder text — either include real screenshots\u002Flinks or omit.\n\n## GitHub markdown craft\n\nTerse ≠ plain. Read [GITHUB-MARKDOWN.md](references\u002FGITHUB-MARKDOWN.md) when the body carries evidence bulk, code locations, or callouts — auto-links, permalinks, `\u003Cdetails>`, tables, task lists.\n\n## Examples\n\nRead [EXAMPLES.md](references\u002FEXAMPLES.md) for three shaped bodies — title-only bug fix, feature with Why + QA link, refactor with breaking change + merge-danger line — when unsure how terse the result reads.\n\n## Auto-Clarity\n\nAlways include a `## Why` section for: ADR-driven refactors, security fixes, data migrations, breaking changes. Never compress those into title-only — future debuggers need the context.\n\nThe Merge-danger line is mandatory for every one-way door: a migration, a deletion, a published API change, a config cutover. A reviewer deciding how carefully to read needs the door and the blast radius before the diff.\n\nFor **web changes**, `## How tested` MUST link to the QA artifact directory (per orc's web-QA evidence rule) or explicitly state \"no UI surface touched\". A bare \"tested manually\" is not acceptable.\n\n## Boundaries\n\nOnly generates the PR description (title + body) as a code block ready to paste into `gh pr create --title ... --body ...` or the GitHub UI. Does NOT:\n\n- open the PR (that's `\u002Forc:ship` or a manual `gh pr create`)\n- push commits\n- modify the diff\n- amend a previous PR\n\nThis skill is `\u002Forc:ship`'s **default** body composer (Phase 4); `\u002Forc:ship --verbose` opts out into the long-form template.\n\n## When to revert to verbose\n\nUser says \"verbose PR\", \"long-form description\", \"explain in detail\", \"this PR needs context\" — drop the compression and write a longer description with full reasoning, alternatives considered, risk model, etc. Caveman is the default, not a mandate.\n",{"name":5,"description":7,"when_to_use":42},"Use when opening a PR or when the user says \"write a PR description\", \"PR body\", \"draft the PR\", or invokes \u002Fcaveman-pr.","main","7522fd7266944e30052204c2f6df287d8b5516be","orc\u002Fskills\u002Fcaveman-pr",0,"https:\u002F\u002Fgithub.com\u002FHigorAlves\u002Forc","https:\u002F\u002Forc.novacstack.com\u002F","https:\u002F\u002Fgithub.com\u002FHigorAlves","higoralves.dev","Software Engineering","2026-11-07 07:26:38",{"source":8,"skillName":5,"commands":54,"prompt":64,"zipAvailable":65},[55,58,61],{"tool":56,"command":57},"npx","npx skills add HigorAlves\u002Forc --skill caveman-pr",{"tool":59,"command":60},"bunx","bunx skills add HigorAlves\u002Forc --skill caveman-pr",{"tool":62,"command":63},"pnpm","pnpm dlx skills add HigorAlves\u002Forc --skill caveman-pr","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FHigorAlves\u002Forc\u002Fblob\u002Fmain\u002Forc\u002Fskills\u002Fcaveman-pr\u002FSKILL.md",true,[67,73],{"path":68,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":71,"sourceHtmlUrl":72},"references\u002FEXAMPLES.md","REFERENCE","参考文档",1584,"https:\u002F\u002Fgithub.com\u002FHigorAlves\u002Forc\u002Fblob\u002Fmain\u002Forc\u002Fskills\u002Fcaveman-pr\u002Freferences\u002FEXAMPLES.md",{"path":74,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":75,"sourceHtmlUrl":76},"references\u002FGITHUB-MARKDOWN.md",1112,"https:\u002F\u002Fgithub.com\u002FHigorAlves\u002Forc\u002Fblob\u002Fmain\u002Forc\u002Fskills\u002Fcaveman-pr\u002Freferences\u002FGITHUB-MARKDOWN.md",[78,115,141,161,182,202],{"skillNo":79,"name":80,"nameZh":6,"description":81,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":82,"categories":83,"keywords":97,"publishedAt":37},"01M71SW40F9TAAEDKBYYBCM814","writing-plans","Write a comprehensive implementation plan of bite-sized TDD tasks that an engineer with zero codebase context could execute — exact files, code, tests, and verification steps","https:\u002F\u002Fgithub.com\u002FHigorAlves\u002Forc\u002Fblob\u002Fmain\u002Forc\u002Fskills\u002Fwriting-plans\u002FSKILL.md",[84,89,94],{"categoryNo":85,"categoryName":86,"taxonomyType":87,"taxonomyTypeDesc":88},"01JBSEEDCAT000000000000018","写作与文案","SCENARIO","使用场景",{"categoryNo":90,"categoryName":91,"taxonomyType":92,"taxonomyTypeDesc":93},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",{"categoryNo":95,"categoryName":96,"taxonomyType":92,"taxonomyTypeDesc":93},"01JBSEEDCAT000000000000036","内容创作者",[98,99,100,101,102,103,104,36,105,106,107,108,109,25,110,111,112,113,114,27],"writing","writing plans","plans","engineer","superpowers","implementation plan","files","you","code","tasks","verification","plan","steps","context","ZeRO","for","tests",{"skillNo":116,"name":117,"nameZh":6,"description":118,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":119,"categories":120,"keywords":126,"publishedAt":37},"01M71SW15KHE4MHJW9NEXV65X2","writing-for-agents","orc's doctrine layer for writing any document an agent consumes — skills, AGENTS.md\u002FCLAUDE.md, reference docs","https:\u002F\u002Fgithub.com\u002FHigorAlves\u002Forc\u002Fblob\u002Fmain\u002Forc\u002Fskills\u002Fwriting-for-agents\u002FSKILL.md",[121,122,125],{"categoryNo":85,"categoryName":86,"taxonomyType":87,"taxonomyTypeDesc":88},{"categoryNo":123,"categoryName":124,"taxonomyType":87,"taxonomyTypeDesc":88},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":95,"categoryName":96,"taxonomyType":92,"taxonomyTypeDesc":93},[127,98,113,128,36,129,130,131,132,133,134,135,27,136,137,138,139,140],"writing for agents","matt pocock","inline","tuning","a skill","layer","doctrine","push","editing","document","github","https","reference","docs",{"skillNo":142,"name":143,"nameZh":6,"description":144,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":145,"categories":146,"keywords":148,"publishedAt":37},"01M71SVYQKXT743HHHWGHT3G13","workspace-mode","Use when cwd is a parent dir holding multiple sibling git repos — defines repo auto-detection, --repos\u002F--repo\u002F--all-repos\u002F--this-repo precedence, per-repo dispatch, and linked-PR mechanics.","https:\u002F\u002Fgithub.com\u002FHigorAlves\u002Forc\u002Fblob\u002Fmain\u002Forc\u002Fskills\u002Fworkspace-mode\u002FSKILL.md",[147],{"categoryNo":123,"categoryName":124,"taxonomyType":87,"taxonomyTypeDesc":88},[149,150,151,152,153,36,154,155,19,156,27,157,158,159,160],"workspace mode","mode","workspace","mechanics","auto","repos","git","repo","dispatch","auto-detection","detection","parent",{"skillNo":162,"name":163,"nameZh":6,"description":164,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":165,"categories":166,"keywords":168,"publishedAt":37},"01M71SVVP3BXS06G9395P2K0RH","wizard","Generate an interactive bash wizard walking a human through work only they can perform — credentials, secrets, one-off migrations","https:\u002F\u002Fgithub.com\u002FHigorAlves\u002Forc\u002Fblob\u002Fmain\u002Forc\u002Fskills\u002Fwizard\u002FSKILL.md",[167],{"categoryNo":123,"categoryName":124,"taxonomyType":87,"taxonomyTypeDesc":88},[163,169,170,171,28,128,36,172,173,174,175,176,177,110,178,179,113,27,180,181],"condition","never","provisioning infrastructure","Bash","work","credentials","generate","human","secrets","infrastructure","do","one","interactive",{"skillNo":183,"name":184,"nameZh":6,"description":185,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":186,"categories":187,"keywords":188,"publishedAt":37},"01M71SVT4AR6NKAM5B077E7QSJ","wait-what","Stop and re-pitch — the last message did not land; say it again simply, in the project's own vocabulary.","https:\u002F\u002Fgithub.com\u002FHigorAlves\u002Forc\u002Fblob\u002Fmain\u002Forc\u002Fskills\u002Fwait-what\u002FSKILL.md",[],[189,190,191,192,193,128,194,195,196,197,137,138,198,199,200,201],"wait what","wait","project","re","true","pitch","last","say","message","land","it","stop","vocabulary",{"skillNo":203,"name":204,"nameZh":6,"description":205,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":206,"categories":207,"keywords":212,"publishedAt":37},"01M71SVQVYRA9QBQ6G8MWR8G6F","vitest","Vitest fast unit testing framework powered by Vite with Jest-compatible API","https:\u002F\u002Fgithub.com\u002FHigorAlves\u002Forc\u002Fblob\u002Fmain\u002Forc\u002Fskills\u002Fvitest\u002FSKILL.md",[208,211],{"categoryNo":209,"categoryName":210,"taxonomyType":87,"taxonomyTypeDesc":88},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":90,"categoryName":91,"taxonomyType":92,"taxonomyTypeDesc":93},[204,213,214,215,216,217,98,36,218,219,220,221,222,223,224,225,226,227,114,228],"coverage","unit","testing","testing framework","generated","api","jest","2026","at","scripts","unit testing","antfu","framework","vite","mocking","dev"]