[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M72XZGSVY72DN0RY62NFGV1B":3,"skill-same:01M72XZGSVY72DN0RY62NFGV1B":50},{"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":19,"linkOnly":20,"markdownContent":21,"markdownBody":22,"frontMatter":23,"refName":24,"commitSha":25,"skillDirectory":26,"forksCount":14,"repositoryHtmlUrl":27,"repositoryHomepageUrl":6,"ownerHtmlUrl":28,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":29,"install":30,"resources":43},"01M72XZGSVY72DN0RY62NFGV1B","create-pr",null,"Create a draft or ready-for-review PR for the current branch. Use when asked to draft, create, open, or prepare a PR, or to write a PR description.","lithammer\u002Fai","lithammer","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F177685?v=4","01M72XZ1CBM905458R0T7AGP87","Peter Lithammer","01M72XZ1CYWE22YVYQ43NJQZQB",0,"MIT","https:\u002F\u002Fgithub.com\u002Flithammer\u002Fai\u002Fblob\u002Fmain\u002Fskills\u002Fcreate-pr\u002FSKILL.md",[],[],"2026-11-10 22:39:42",false,"---\nname: create-pr\ndescription: Create a draft or ready-for-review PR for the current branch. Use when asked to draft, create, open, or prepare a PR, or to write a PR description.\n---\n\n# Create PR\n\n1. Identify the current branch and an appropriate base branch. Inspect the\n   intended changes, including uncommitted work, and use the conversation context\n   already available. Check claims against the actual branch rather than relying\n   on memory. Preserve file contents, unrelated changes, and unrelated staging.\n2. Write the title and description in the current session using the guidance\n   below.\n3. Read the description as a teammate about to review the diff. Keep the outcome\n   and useful heads-ups; cut implementation narration and explanations already\n   present in the changed code or documents.\n4. If asked only for a description, return the title and body without changing\n   Git state or creating a PR. Otherwise, prepare the PR branch locally, creating\n   one if needed. Commit only the intended changes if needed, then push that\n   branch. Keep the local checkout on the PR branch.\n5. Create the PR as a draft unless explicitly requested ready for review.\n   Confirm the published body matches the intended text. Return the URL, or the\n   title, body, and blocker if preparation or creation fails.\n\n## Description\n\nWrite from the PR author's perspective, not as an assistant reporting on their\nwork.\n\nTell a teammate what this makes possible, and why now if they'd ask. Assume\nthey'll read the diff. Most PRs need only a short sentence describing the\noutcome. Then name only what a reviewer must decide or do before merging, such\nas a merge or deploy order. Keep discussion tied to a particular line in an\ninline comment rather than the description.\n\nAnswer what a reviewer, or someone tracing this change later, would ask\nfirst: how do you know it works? Show what you would show a teammate at\nyour desk, beside the claim it backs, and let it replace the explanation\nwhere possible. Reuse it from the session or capture it now; `gh pr create\n--help` covers `--attach`. Tests and CI show that logic meets a contract,\nnot that the change works in practice; leave out that they pass.\n\nFold every other note into one `\u003Cdetails>` block after the evidence, with a\n`\u003Csummary>` that says what it holds and a blank line after `\u003C\u002Fsummary>`.\n\nEnd the body with a line for each issue the PR references. Read its open\nacceptance criteria: write `Closes #N` when this PR meets the last of them,\nand `Refs #N` otherwise.\n","# Create PR\n\n1. Identify the current branch and an appropriate base branch. Inspect the\n   intended changes, including uncommitted work, and use the conversation context\n   already available. Check claims against the actual branch rather than relying\n   on memory. Preserve file contents, unrelated changes, and unrelated staging.\n2. Write the title and description in the current session using the guidance\n   below.\n3. Read the description as a teammate about to review the diff. Keep the outcome\n   and useful heads-ups; cut implementation narration and explanations already\n   present in the changed code or documents.\n4. If asked only for a description, return the title and body without changing\n   Git state or creating a PR. Otherwise, prepare the PR branch locally, creating\n   one if needed. Commit only the intended changes if needed, then push that\n   branch. Keep the local checkout on the PR branch.\n5. Create the PR as a draft unless explicitly requested ready for review.\n   Confirm the published body matches the intended text. Return the URL, or the\n   title, body, and blocker if preparation or creation fails.\n\n## Description\n\nWrite from the PR author's perspective, not as an assistant reporting on their\nwork.\n\nTell a teammate what this makes possible, and why now if they'd ask. Assume\nthey'll read the diff. Most PRs need only a short sentence describing the\noutcome. Then name only what a reviewer must decide or do before merging, such\nas a merge or deploy order. Keep discussion tied to a particular line in an\ninline comment rather than the description.\n\nAnswer what a reviewer, or someone tracing this change later, would ask\nfirst: how do you know it works? Show what you would show a teammate at\nyour desk, beside the claim it backs, and let it replace the explanation\nwhere possible. Reuse it from the session or capture it now; `gh pr create\n--help` covers `--attach`. Tests and CI show that logic meets a contract,\nnot that the change works in practice; leave out that they pass.\n\nFold every other note into one `\u003Cdetails>` block after the evidence, with a\n`\u003Csummary>` that says what it holds and a blank line after `\u003C\u002Fsummary>`.\n\nEnd the body with a line for each issue the PR references. Read its open\nacceptance criteria: write `Closes #N` when this PR meets the last of them,\nand `Refs #N` otherwise.\n",{"name":5,"description":7},"main","b782240b7d6c97cfd42c899ed2b118e5b165797e","skills\u002Fcreate-pr","https:\u002F\u002Fgithub.com\u002Flithammer\u002Fai","https:\u002F\u002Fgithub.com\u002Flithammer","2026-11-13 19:30:46",{"source":8,"skillName":5,"commands":31,"prompt":41,"zipAvailable":42},[32,35,38],{"tool":33,"command":34},"npx","npx skills add lithammer\u002Fai --skill create-pr",{"tool":36,"command":37},"bunx","bunx skills add lithammer\u002Fai --skill create-pr",{"tool":39,"command":40},"pnpm","pnpm dlx skills add lithammer\u002Fai --skill create-pr","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Flithammer\u002Fai\u002Fblob\u002Fmain\u002Fskills\u002Fcreate-pr\u002FSKILL.md",true,[44],{"path":45,"resourceType":46,"resourceTypeDesc":47,"sizeBytes":48,"sourceHtmlUrl":49},"agents\u002Fopenai.yaml","REFERENCE","参考文档",111,"https:\u002F\u002Fgithub.com\u002Flithammer\u002Fai\u002Fblob\u002Fmain\u002Fskills\u002Fcreate-pr\u002Fagents\u002Fopenai.yaml",[51,59,66,73,80,87],{"skillNo":52,"name":53,"nameZh":6,"description":54,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":55,"categories":56,"keywords":57,"publishedAt":58},"01M74AAAPNY933TSRZHM4PSKZ3","shape","Review a working change for its shape (cause, ownership, states, names, size, reuse, cost), then apply what you accept.","https:\u002F\u002Fgithub.com\u002Flithammer\u002Fai\u002Fblob\u002Fmain\u002Fskills\u002Fshape\u002FSKILL.md",[],[],"2026-11-11 15:11:14",{"skillNo":60,"name":61,"nameZh":6,"description":62,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":63,"categories":64,"keywords":65,"publishedAt":58},"01M74AA65VBXVA11AA8JPBNYW6","correctness","Review a working change for defects (logic, state, lifecycle, concurrency, regression) and for drift from its ticket, docs, and rules, then apply what you accept.","https:\u002F\u002Fgithub.com\u002Flithammer\u002Fai\u002Fblob\u002Fmain\u002Fskills\u002Fcorrectness\u002FSKILL.md",[],[],{"skillNo":67,"name":68,"nameZh":6,"description":69,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":70,"categories":71,"keywords":72,"publishedAt":19},"01M72Y19CBNJ6SDBY29A9JZ0GV","zero-tech-debt","Rework a change as if the intended UX and architecture existed from day one, deleting compatibility cruft and accidental complexity.","https:\u002F\u002Fgithub.com\u002Flithammer\u002Fai\u002Fblob\u002Fmain\u002Fskills\u002Fzero-tech-debt\u002FSKILL.md",[],[],{"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":79,"publishedAt":19},"01M72Y1441P3HZAT87MT4MWMQQ","waterfall-review","Review a code change by dispatching specialized review subagents in parallel — each focused on a single dimension (correctness, security, architecture, etc.) — then triaging their findings into a unified report. Works standalone on a branch or as part of the waterfall flow after implementation. Invoke when the user explicitly asks to review a branch or diff, or as a step inside waterfall-implement; avoid auto-triggering on casual mentions of \"review\".","https:\u002F\u002Fgithub.com\u002Flithammer\u002Fai\u002Fblob\u002Fmain\u002Fskills\u002Fwaterfall\u002Fwaterfall-review\u002FSKILL.md",[],[],{"skillNo":81,"name":82,"nameZh":6,"description":83,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":84,"categories":85,"keywords":86,"publishedAt":19},"01M72Y0ZGMWP5EZHRD5DB3SHKM","waterfall-refactor","Identify refactoring opportunities in code that a feature will touch. Runs at strategic level during design (looking for structural moves that could change which approach is chosen) or tactical level before implementation (looking for pre-work that gives the feature a better foundation). Primarily invoked by waterfall-design or waterfall-implement; avoid auto-triggering on casual mentions of \"refactor\".","https:\u002F\u002Fgithub.com\u002Flithammer\u002Fai\u002Fblob\u002Fmain\u002Fskills\u002Fwaterfall\u002Fwaterfall-refactor\u002FSKILL.md",[],[],{"skillNo":88,"name":89,"nameZh":6,"description":90,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":91,"categories":92,"keywords":93,"publishedAt":19},"01M72Y0X02J7VCBG9S3AJV7W16","waterfall-plan","Detail a chosen design approach into an implementation plan (objective, file manifest, execution order, test strategy), then auto-proceed to waterfall-challenge. Convergent phase of the waterfall flow.","https:\u002F\u002Fgithub.com\u002Flithammer\u002Fai\u002Fblob\u002Fmain\u002Fskills\u002Fwaterfall\u002Fwaterfall-plan\u002FSKILL.md",[],[]]