[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6BZ4J9EKEAC3NQ0MYMDXR6B":3,"skill-same:01M6BZ4J9EKEAC3NQ0MYMDXR6B":67},{"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":39,"linkOnly":40,"markdownContent":41,"markdownBody":42,"frontMatter":43,"refName":47,"commitSha":48,"skillDirectory":49,"forksCount":14,"repositoryHtmlUrl":50,"repositoryHomepageUrl":6,"ownerHtmlUrl":51,"ownerBlogUrl":52,"ownerDescription":6,"updatedAt":53,"install":54,"resources":66},"01M6BZ4J9EKEAC3NQ0MYMDXR6B","atomic-commits",null,"Split the current worktree (staged and unstaged) into a sequence of atomic commits whose messages match the repository's existing conventions, guarding the process with a snapshot so no change is lost or introduced. Invoke explicitly when you want pending work committed as clean, logically separated commits. Pass `--fix` to commit the plan without waiting for approval.","hareki\u002Fdotfiles","hareki","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F81374684?v=4","01M6BZ3YB4KETETCGKZEVQ9J5N","Tu Nguyen","01M6BZ3YEQMMTMJ6E8TW6AV5RJ",0,"MIT","https:\u002F\u002Fgithub.com\u002Fhareki\u002Fdotfiles\u002Fblob\u002Fmain\u002Fagents\u002F.agents\u002Fskills\u002Fatomic-commits\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"atomic commits","atomic","commits","parse","write","log","reset","you","when","invoke","clean","fix","work","plan","commit","Bash","repository","messages","worktree","change","2026-11-10 10:12:30",false,"---\nname: atomic-commits\ndescription: Split the current worktree (staged and unstaged) into a sequence of atomic commits whose messages match the repository's existing conventions, guarding the process with a snapshot so no change is lost or introduced. Invoke explicitly when you want pending work committed as clean, logically separated commits. Pass `--fix` to commit the plan without waiting for approval.\ndisable-model-invocation: true\nargument-hint: \"[--fix]\"\nallowed-tools: Bash(git status:*), Bash(git diff:*), Bash(git log:*), Bash(git add:*), Bash(git commit:*), Bash(git reset:*), Bash(git write-tree:*), Bash(git rev-parse:*)\n---\n\n# Atomic Commits\n\nSplit everything currently in the worktree into a sequence of small, self-contained commits, ordered sensibly, with messages that match how this repo already writes commits. Whether a change is staged or unstaged does not matter: it all gets regrouped here.\n\nTwo things must hold when you finish: every pending change ends up committed (nothing lost), and nothing new is committed that was not already in the worktree (nothing invented). The snapshot in step 1 is what lets you prove both at the end, so do not skip it.\n\n## 1. Snapshot the worktree, and capture the full diff in one view\n\nBefore grouping anything, record the complete state so you can verify it later and roll back if needed:\n\n```bash\ngit rev-parse HEAD          # ORIG_HEAD: rollback anchor and end-of-run base\ngit add -A                  # stage everything: edits, new files, deletions, untracked (ignored files stay out, as they should)\ngit write-tree              # SNAPSHOT_TREE: the printed SHA is the ground-truth content\ngit diff --staged HEAD      # the COMPLETE set of pending changes, tracked + untracked, in one place\ngit reset                   # unstage; this is a mixed reset, it moves only the index and leaves every file untouched\n```\n\nKeep `ORIG_HEAD` and `SNAPSHOT_TREE` for step 5. The `git diff --staged HEAD` output above is your full inventory of what needs to be committed, so read it carefully before planning.\n\n## 2. Learn the repo's commit style\n\n```bash\ngit log -30 --format='%s'                       # subject-line conventions\ngit log -10 --format='%s%n%n%b%n--------'       # whether\u002Fhow bodies are used\n```\n\nInfer and follow what the repo actually does, not a generic default: Conventional Commits prefixes (`feat`, `fix`, `chore`, `refactor`, `docs`, etc.) and scope notation if present, capitalization, imperative vs. past tense, typical subject length, and whether a body is usually included.\n\n## 3. Plan the commits\n\nGroup the changes into the smallest set of commits that each represent one coherent concern (one feature, fix, refactor, or cleanup), and order them so each builds on the last (prerequisites and refactors before the features that depend on them).\n\nPresent the plan to the user before committing anything: the ordered list of commits, the proposed message for each, and which files (or hunks) go into each. What happens next depends on the arguments:\n\n- **Without `--fix`**: wait for the user to sign off on the grouping and the order before committing. If they want changes, revise and re-present.\n- **With `--fix`**: the plan is pre-approved. Present it, then continue straight to step 4 in the same turn.\n\nIf some changes are too entangled to separate cleanly, say so in the plan and go with the best grouping rather than forcing artificial splits.\n\n## 4. Stage and commit each group, in order\n\nFor each planned commit:\n\n- Whole files: `git add \u003Cfile>...`\n- A file that spans multiple logical changes: `git add -p \u003Cfile>` to stage only the relevant hunks. This only ever stages content; it cannot discard it.\n- Verify what you are about to commit with `git diff --staged`, then commit with its planned message.\n\nWrite the message exactly as planned. For a body, pass it as additional `-m` arguments. Add nothing else (see Guardrails on attribution).\n\n## 5. Verify nothing was lost or added\n\nAfter the final commit:\n\n```bash\ngit status --short              # must be empty: a clean worktree means everything was committed\ngit diff \u003CSNAPSHOT_TREE> HEAD   # must print nothing: the committed tree equals the snapshot\n```\n\nIf `git status` is not clean, a change was missed: stage and commit the remainder (re-running step 1's snapshot view helps you see what is left). If `git diff \u003CSNAPSHOT_TREE> HEAD` shows anything, the committed content diverges from what you started with, so stop and report it rather than papering over it. Both checks passing is the proof that the new commits reproduce exactly the worktree you began with.\n\nIf something goes wrong at any point, recover with `git reset --soft \u003CORIG_HEAD>`: it un-commits everything back into the index without touching a single file, so you can regroup and try again.\n\n## Guardrails\n\n- **No attribution.** Never add a `Co-Authored-By` trailer or any Claude\u002FAI attribution. The message is exactly the planned content, with nothing appended.\n- **Commit only what is already there.** Never edit, create, reformat, or delete file contents to make a commit look cleaner. Introduce nothing new into the worktree; the snapshot check in step 5 exists to catch exactly this.\n- **Never run change-destroying commands.** `git reset --hard`, `git checkout -- \u003Cpath>`, `git restore`, `git clean`, and `git stash` can all wipe uncommitted work and are not part of this workflow. The only resets used here are the mixed `git reset` (unstage) and `git reset --soft` (rollback), both of which preserve file content.\n- Do not `git push`, `git rebase`, or amend existing commits unless explicitly asked.\n- If the worktree is already clean when you start, report that and stop.\n","# Atomic Commits\n\nSplit everything currently in the worktree into a sequence of small, self-contained commits, ordered sensibly, with messages that match how this repo already writes commits. Whether a change is staged or unstaged does not matter: it all gets regrouped here.\n\nTwo things must hold when you finish: every pending change ends up committed (nothing lost), and nothing new is committed that was not already in the worktree (nothing invented). The snapshot in step 1 is what lets you prove both at the end, so do not skip it.\n\n## 1. Snapshot the worktree, and capture the full diff in one view\n\nBefore grouping anything, record the complete state so you can verify it later and roll back if needed:\n\n```bash\ngit rev-parse HEAD          # ORIG_HEAD: rollback anchor and end-of-run base\ngit add -A                  # stage everything: edits, new files, deletions, untracked (ignored files stay out, as they should)\ngit write-tree              # SNAPSHOT_TREE: the printed SHA is the ground-truth content\ngit diff --staged HEAD      # the COMPLETE set of pending changes, tracked + untracked, in one place\ngit reset                   # unstage; this is a mixed reset, it moves only the index and leaves every file untouched\n```\n\nKeep `ORIG_HEAD` and `SNAPSHOT_TREE` for step 5. The `git diff --staged HEAD` output above is your full inventory of what needs to be committed, so read it carefully before planning.\n\n## 2. Learn the repo's commit style\n\n```bash\ngit log -30 --format='%s'                       # subject-line conventions\ngit log -10 --format='%s%n%n%b%n--------'       # whether\u002Fhow bodies are used\n```\n\nInfer and follow what the repo actually does, not a generic default: Conventional Commits prefixes (`feat`, `fix`, `chore`, `refactor`, `docs`, etc.) and scope notation if present, capitalization, imperative vs. past tense, typical subject length, and whether a body is usually included.\n\n## 3. Plan the commits\n\nGroup the changes into the smallest set of commits that each represent one coherent concern (one feature, fix, refactor, or cleanup), and order them so each builds on the last (prerequisites and refactors before the features that depend on them).\n\nPresent the plan to the user before committing anything: the ordered list of commits, the proposed message for each, and which files (or hunks) go into each. What happens next depends on the arguments:\n\n- **Without `--fix`**: wait for the user to sign off on the grouping and the order before committing. If they want changes, revise and re-present.\n- **With `--fix`**: the plan is pre-approved. Present it, then continue straight to step 4 in the same turn.\n\nIf some changes are too entangled to separate cleanly, say so in the plan and go with the best grouping rather than forcing artificial splits.\n\n## 4. Stage and commit each group, in order\n\nFor each planned commit:\n\n- Whole files: `git add \u003Cfile>...`\n- A file that spans multiple logical changes: `git add -p \u003Cfile>` to stage only the relevant hunks. This only ever stages content; it cannot discard it.\n- Verify what you are about to commit with `git diff --staged`, then commit with its planned message.\n\nWrite the message exactly as planned. For a body, pass it as additional `-m` arguments. Add nothing else (see Guardrails on attribution).\n\n## 5. Verify nothing was lost or added\n\nAfter the final commit:\n\n```bash\ngit status --short              # must be empty: a clean worktree means everything was committed\ngit diff \u003CSNAPSHOT_TREE> HEAD   # must print nothing: the committed tree equals the snapshot\n```\n\nIf `git status` is not clean, a change was missed: stage and commit the remainder (re-running step 1's snapshot view helps you see what is left). If `git diff \u003CSNAPSHOT_TREE> HEAD` shows anything, the committed content diverges from what you started with, so stop and report it rather than papering over it. Both checks passing is the proof that the new commits reproduce exactly the worktree you began with.\n\nIf something goes wrong at any point, recover with `git reset --soft \u003CORIG_HEAD>`: it un-commits everything back into the index without touching a single file, so you can regroup and try again.\n\n## Guardrails\n\n- **No attribution.** Never add a `Co-Authored-By` trailer or any Claude\u002FAI attribution. The message is exactly the planned content, with nothing appended.\n- **Commit only what is already there.** Never edit, create, reformat, or delete file contents to make a commit look cleaner. Introduce nothing new into the worktree; the snapshot check in step 5 exists to catch exactly this.\n- **Never run change-destroying commands.** `git reset --hard`, `git checkout -- \u003Cpath>`, `git restore`, `git clean`, and `git stash` can all wipe uncommitted work and are not part of this workflow. The only resets used here are the mixed `git reset` (unstage) and `git reset --soft` (rollback), both of which preserve file content.\n- Do not `git push`, `git rebase`, or amend existing commits unless explicitly asked.\n- If the worktree is already clean when you start, report that and stop.\n",{"name":5,"description":7,"allowed-tools":44,"argument-hint":45,"disable-model-invocation":46},"Bash(git status:*), Bash(git diff:*), Bash(git log:*), Bash(git add:*), Bash(git commit:*), Bash(git reset:*), Bash(git write-tree:*), Bash(git rev-parse:*)","[--fix]",true,"main","78af07be4f8f78af052e3bf7f9ba34499674b76e","agents\u002F.agents\u002Fskills\u002Fatomic-commits","https:\u002F\u002Fgithub.com\u002Fhareki\u002Fdotfiles","https:\u002F\u002Fgithub.com\u002Fhareki","https:\u002F\u002Fhareki.dev","2026-11-11 17:32:25",{"source":8,"skillName":5,"commands":55,"prompt":65,"zipAvailable":46},[56,59,62],{"tool":57,"command":58},"npx","npx skills add hareki\u002Fdotfiles --skill atomic-commits",{"tool":60,"command":61},"bunx","bunx skills add hareki\u002Fdotfiles --skill atomic-commits",{"tool":63,"command":64},"pnpm","pnpm dlx skills add hareki\u002Fdotfiles --skill atomic-commits","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fhareki\u002Fdotfiles\u002Fblob\u002Fmain\u002Fagents\u002F.agents\u002Fskills\u002Fatomic-commits\u002FSKILL.md",[],[68,91,114,137,153,171],{"skillNo":69,"name":70,"nameZh":6,"description":71,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":72,"categories":73,"keywords":84,"publishedAt":39},"01M6BZ6B9Q73RKDJE34FRCKHX3","writing-for-agents","Writing documents for agents. Use when creating or editing skills, or modifying AGENTS.md or CLAUDE.md.","https:\u002F\u002Fgithub.com\u002Fhareki\u002Fdotfiles\u002Fblob\u002Fmain\u002Fagents\u002F.agents\u002Fskills\u002Fwriting-for-agents\u002FSKILL.md",[74,79],{"categoryNo":75,"categoryName":76,"taxonomyType":77,"taxonomyTypeDesc":78},"01JBSEEDCAT000000000000018","写作与文案","SCENARIO","使用场景",{"categoryNo":80,"categoryName":81,"taxonomyType":82,"taxonomyTypeDesc":83},"01JBSEEDCAT000000000000036","内容创作者","PROFESSION","适用职业",[85,86,87,27,88,89,90],"writing","for","writing for agents","use","editing","documents",{"skillNo":92,"name":93,"nameZh":6,"description":94,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":95,"categories":96,"keywords":97,"publishedAt":39},"01M6BZ697R108MDV5YDSRJK978","wizard","Generate an interactive bash wizard that walks a human through steps only they can perform. Use when provisioning infrastructure, setting up credentials or CI secrets, walking an unfamiliar third-party dashboard, or running a one-off migration or cutover. Don't invoke this for steps the agent can perform itself.","https:\u002F\u002Fgithub.com\u002Fhareki\u002Fdotfiles\u002Fblob\u002Fmain\u002Fagents\u002F.agents\u002Fskills\u002Fwizard\u002FSKILL.md",[],[93,98,99,100,101,102,103,104,27,28,105,86,106,107,108,109,110,111,88,112,34,113],"provisioning","ci","generate","infrastructure","dashboard","can","running","party","credentials","human","provisioning infrastructure","migration","up","only","interactive","secrets",{"skillNo":115,"name":116,"nameZh":6,"description":117,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":118,"categories":119,"keywords":120,"publishedAt":39},"01M6BZ67ZGZ4CPZSXVMYWWFS5P","wayfinder","Plan a huge chunk of work (more than one agent session can hold) as a shared map of decision tickets on your issue tracker, and resolve them one at a time until the way to the destination is clear.","https:\u002F\u002Fgithub.com\u002Fhareki\u002Fdotfiles\u002Fblob\u002Fmain\u002Fagents\u002F.agents\u002Fskills\u002Fwayfinder\u002FSKILL.md",[],[116,121,122,123,103,124,125,126,127,128,129,130,131,132,133,31,134,32,135,136],"at","map","agent session","time","true","shared","more","tickets","as","clear","issue","session","one at a time","decision","chunk","tracker",{"skillNo":138,"name":139,"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":143,"publishedAt":39},"01M6BZ66S9SVKE0K845NT5EGVR","wait-what","Stop. That last message did not land: re-pitch it.","https:\u002F\u002Fgithub.com\u002Fhareki\u002Fdotfiles\u002Fblob\u002Fmain\u002Fagents\u002F.agents\u002Fskills\u002Fwait-what\u002FSKILL.md",[],[144,145,146,125,147,148,149,150,151,152],"wait what","wait","re","last","it","pitch","message","stop","land",{"skillNo":154,"name":155,"nameZh":6,"description":156,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":157,"categories":158,"keywords":159,"publishedAt":39},"01M6BZ63THJCZ9FNCR7CWDGCJZ","triage","Move issues and external PRs through a state machine of triage roles, categorise, verify, grill if needed, and write agent-ready briefs.","https:\u002F\u002Fgithub.com\u002Fhareki\u002Fdotfiles\u002Fblob\u002Fmain\u002Fagents\u002F.agents\u002Fskills\u002Ftriage\u002FSKILL.md",[],[155,160,161,162,163,23,164,165,166,167,168,169,125,170],"machine","roles","grill","ready","verify","issues","state","move","prs","state machine","briefs",{"skillNo":172,"name":173,"nameZh":6,"description":174,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":175,"categories":176,"keywords":177,"publishedAt":39},"01M6BZ627X8Y85ASTMA4F5WBN9","to-tickets","Break a plan, spec, or the current conversation into a set of tracer-bullet tickets, each declaring its blocking edges, published to the configured tracker (edges as text in one file per ticket locally, or native blocking links on a real tracker).","https:\u002F\u002Fgithub.com\u002Fhareki\u002Fdotfiles\u002Fblob\u002Fmain\u002Fagents\u002F.agents\u002Fskills\u002Fto-tickets\u002FSKILL.md",[],[178,128,179,180,181,125,182,183,129,184,136,185,32,186,187],"to tickets","spec","links","break","native","ticket","conversation","text","SET","file"]