[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M718XCJQHXMFKSRRA4FTG7BP":3,"skill-same:01M718XCJQHXMFKSRRA4FTG7BP":65},{"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":44,"commitSha":45,"skillDirectory":46,"forksCount":47,"repositoryHtmlUrl":48,"repositoryHomepageUrl":6,"ownerHtmlUrl":49,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":50,"install":51,"resources":64},"01M718XCJQHXMFKSRRA4FTG7BP","git-commit",null,"Create a git commit with a clear, value-communicating message. Use when the user says \"commit\", \"commit this\", \"save my changes\", \"create a commit\", or wants to commit staged or unstaged work. Produces well-structured commit messages that follow repo conventions when they exist, and defaults to conventional commit format otherwise.","wangrenzhu-ola\u002FGaleHarnessCodingCLI","wangrenzhu-ola","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F113888128?v=4","01M718T5C0YYVP4Z7F4SH1MCHM","王韧竹(Bamboo Wang\u002F雪落)","01M718T5CN5T80VWXEWPK25PDQ",2,"MIT","https:\u002F\u002Fgithub.com\u002Fwangrenzhu-ola\u002FGaleHarnessCodingCLI\u002Fblob\u002Fmain\u002Fplugins\u002Fgaleharness-cli\u002Fskills\u002Fgit-commit\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"commit","git","git commit","my","conventions","staged","clear","communicating","format","conventional commit","message","changes","work","create","with","when","use","messages","repo","value","2026-11-10 10:12:30",false,"---\nname: git-commit\ndescription: Create a git commit with a clear, value-communicating message. Use when the user says \"commit\", \"commit this\", \"save my changes\", \"create a commit\", or wants to commit staged or unstaged work. Produces well-structured commit messages that follow repo conventions when they exist, and defaults to conventional commit format otherwise.\n---\n\n# Git Commit\n\nCreate a single, well-crafted git commit from the current working tree changes.\n\n## Context\n\n**If you are not Claude Code**, skip to the \"Context fallback\" section below and run the command there to gather context.\n\n**If you are Claude Code**, the five labeled sections below (Git status, Working tree diff, Current branch, Recent commits, Remote default branch) contain pre-populated data. Use them directly throughout this skill -- do not re-run these commands.\n\n**Git status:**\n!`git status`\n\n**Working tree diff:**\n!`git diff HEAD`\n\n**Current branch:**\n!`git branch --show-current`\n\n**Recent commits:**\n!`git log --oneline -10`\n\n**Remote default branch:**\n!`git rev-parse --abbrev-ref origin\u002FHEAD 2>\u002Fdev\u002Fnull || echo '__DEFAULT_BRANCH_UNRESOLVED__'`\n\n### Context fallback\n\n**If you are Claude Code, skip this section — the data above is already available.**\n\nRun this single command to gather all context:\n\n```bash\nprintf '=== STATUS ===\\n'; git status; printf '\\n=== DIFF ===\\n'; git diff HEAD; printf '\\n=== BRANCH ===\\n'; git branch --show-current; printf '\\n=== LOG ===\\n'; git log --oneline -10; printf '\\n=== DEFAULT_BRANCH ===\\n'; git rev-parse --abbrev-ref origin\u002FHEAD 2>\u002Fdev\u002Fnull || echo '__DEFAULT_BRANCH_UNRESOLVED__'\n```\n\n---\n\n## Workflow\n\n### Step 1: Gather context\n\nUse the context above (git status, working tree diff, current branch, recent commits, remote default branch). All data needed for this step is already available -- do not re-run those commands.\n\nThe remote default branch value returns something like `origin\u002Fmain`. Strip the `origin\u002F` prefix to get the branch name. If it returned `__DEFAULT_BRANCH_UNRESOLVED__` or a bare `HEAD`, try:\n\n```bash\ngh repo view --json defaultBranchRef --jq '.defaultBranchRef.name'\n```\n\nIf both fail, fall back to `main`.\n\nIf the git status from the context above shows a clean working tree (no staged, modified, or untracked files), report that there is nothing to commit and stop.\n\nIf the current branch from the context above is empty, the repository is in detached HEAD state. Explain that a branch is required before committing if the user wants this work attached to a branch. Ask whether to create a feature branch now. Use the platform's blocking question tool (`AskUserQuestion` in Claude Code, `request_user_input` in Codex, `ask_user` in Gemini, `ask_user` in Pi (requires the `pi-ask-user` extension)). If no question tool is available, present the options and wait for the user's reply before proceeding.\n\n- If the user chooses to create a branch, derive the name from the change content, create it with `git checkout -b \u003Cbranch-name>`, then run `git branch --show-current` again and use that result as the current branch name for the rest of the workflow.\n- If the user declines, continue with the detached HEAD commit.\n\n### Step 2: Determine commit message convention\n\nFollow this priority order:\n\n1. **Repo conventions already in context** -- If project instructions (AGENTS.md, CLAUDE.md, or similar) are already loaded and specify commit message conventions, follow those. Do not re-read these files; they are loaded at session start.\n2. **Recent commit history** -- If no explicit convention is documented, examine the 10 most recent commits from Step 1. If a clear pattern emerges (e.g., conventional commits, ticket prefixes, emoji prefixes), match that pattern.\n3. **Default: conventional commits** -- If neither source provides a pattern, use conventional commit format: `type(scope): description` where type is one of `feat`, `fix`, `docs`, `refactor`, `test`, `chore`, `perf`, `ci`, `style`, `build`.\n\nWhen using conventional commits, choose the type that most precisely describes the change (the type list above). Where `fix:` and `feat:` both seem to fit, default to `fix:`: a change that remedies broken or missing behavior is `fix:` even when implemented by adding code. Reserve `feat:` for capabilities the user could not previously accomplish. Other types remain primary when they fit better. The user may override for a specific change.\n\n### Step 3: Consider logical commits\n\nBefore staging everything together, scan the changed files for naturally distinct concerns. If modified files clearly group into separate logical changes (e.g., a refactor in one directory and a new feature in another, or test files for a different change than source files), create separate commits for each group.\n\nKeep this lightweight:\n- Group at the **file level only** -- do not use `git add -p` or try to split hunks within a file.\n- If the separation is obvious (different features, unrelated fixes), split. If it's ambiguous, one commit is fine.\n- Two or three logical commits is the sweet spot. Do not over-slice into many tiny commits.\n\n### Step 4: Stage and commit\n\nIf the current branch from the context above is `main`, `master`, or the resolved default branch from Step 1, warn the user and ask whether to continue committing here or create a feature branch first. Use the platform's blocking question tool (`AskUserQuestion` in Claude Code, `request_user_input` in Codex, `ask_user` in Gemini, `ask_user` in Pi (requires the `pi-ask-user` extension)). If no question tool is available, present the options and wait for the user's reply before proceeding. If the user chooses to create a branch, derive the name from the change content, create it with `git checkout -b \u003Cbranch-name>`, then continue.\n\nWrite the commit message:\n- **Subject line**: Concise, imperative mood, focused on *why* not *what*. Follow the convention determined in Step 2.\n- **Body** (when needed): Add a body separated by a blank line for non-trivial changes. Explain motivation, trade-offs, or anything a future reader would need. Omit the body for obvious single-purpose changes.\n\nFor each commit group, stage and commit in a single call. Prefer staging specific files by name over `git add -A` or `git add .` to avoid accidentally including sensitive files (.env, credentials) or unrelated changes. Use a heredoc to preserve formatting:\n\n```bash\ngit add file1 file2 file3 && git commit -m \"$(cat \u003C\u003C'EOF'\ntype(scope): subject line here\n\nOptional body explaining why this change was made,\nnot just what changed.\nEOF\n)\"\n```\n\n### Step 5: Confirm\n\nRun `git status` after the commit to verify success. Report the commit hash(es) and subject line(s).\n","# Git Commit\n\nCreate a single, well-crafted git commit from the current working tree changes.\n\n## Context\n\n**If you are not Claude Code**, skip to the \"Context fallback\" section below and run the command there to gather context.\n\n**If you are Claude Code**, the five labeled sections below (Git status, Working tree diff, Current branch, Recent commits, Remote default branch) contain pre-populated data. Use them directly throughout this skill -- do not re-run these commands.\n\n**Git status:**\n!`git status`\n\n**Working tree diff:**\n!`git diff HEAD`\n\n**Current branch:**\n!`git branch --show-current`\n\n**Recent commits:**\n!`git log --oneline -10`\n\n**Remote default branch:**\n!`git rev-parse --abbrev-ref origin\u002FHEAD 2>\u002Fdev\u002Fnull || echo '__DEFAULT_BRANCH_UNRESOLVED__'`\n\n### Context fallback\n\n**If you are Claude Code, skip this section — the data above is already available.**\n\nRun this single command to gather all context:\n\n```bash\nprintf '=== STATUS ===\\n'; git status; printf '\\n=== DIFF ===\\n'; git diff HEAD; printf '\\n=== BRANCH ===\\n'; git branch --show-current; printf '\\n=== LOG ===\\n'; git log --oneline -10; printf '\\n=== DEFAULT_BRANCH ===\\n'; git rev-parse --abbrev-ref origin\u002FHEAD 2>\u002Fdev\u002Fnull || echo '__DEFAULT_BRANCH_UNRESOLVED__'\n```\n\n---\n\n## Workflow\n\n### Step 1: Gather context\n\nUse the context above (git status, working tree diff, current branch, recent commits, remote default branch). All data needed for this step is already available -- do not re-run those commands.\n\nThe remote default branch value returns something like `origin\u002Fmain`. Strip the `origin\u002F` prefix to get the branch name. If it returned `__DEFAULT_BRANCH_UNRESOLVED__` or a bare `HEAD`, try:\n\n```bash\ngh repo view --json defaultBranchRef --jq '.defaultBranchRef.name'\n```\n\nIf both fail, fall back to `main`.\n\nIf the git status from the context above shows a clean working tree (no staged, modified, or untracked files), report that there is nothing to commit and stop.\n\nIf the current branch from the context above is empty, the repository is in detached HEAD state. Explain that a branch is required before committing if the user wants this work attached to a branch. Ask whether to create a feature branch now. Use the platform's blocking question tool (`AskUserQuestion` in Claude Code, `request_user_input` in Codex, `ask_user` in Gemini, `ask_user` in Pi (requires the `pi-ask-user` extension)). If no question tool is available, present the options and wait for the user's reply before proceeding.\n\n- If the user chooses to create a branch, derive the name from the change content, create it with `git checkout -b \u003Cbranch-name>`, then run `git branch --show-current` again and use that result as the current branch name for the rest of the workflow.\n- If the user declines, continue with the detached HEAD commit.\n\n### Step 2: Determine commit message convention\n\nFollow this priority order:\n\n1. **Repo conventions already in context** -- If project instructions (AGENTS.md, CLAUDE.md, or similar) are already loaded and specify commit message conventions, follow those. Do not re-read these files; they are loaded at session start.\n2. **Recent commit history** -- If no explicit convention is documented, examine the 10 most recent commits from Step 1. If a clear pattern emerges (e.g., conventional commits, ticket prefixes, emoji prefixes), match that pattern.\n3. **Default: conventional commits** -- If neither source provides a pattern, use conventional commit format: `type(scope): description` where type is one of `feat`, `fix`, `docs`, `refactor`, `test`, `chore`, `perf`, `ci`, `style`, `build`.\n\nWhen using conventional commits, choose the type that most precisely describes the change (the type list above). Where `fix:` and `feat:` both seem to fit, default to `fix:`: a change that remedies broken or missing behavior is `fix:` even when implemented by adding code. Reserve `feat:` for capabilities the user could not previously accomplish. Other types remain primary when they fit better. The user may override for a specific change.\n\n### Step 3: Consider logical commits\n\nBefore staging everything together, scan the changed files for naturally distinct concerns. If modified files clearly group into separate logical changes (e.g., a refactor in one directory and a new feature in another, or test files for a different change than source files), create separate commits for each group.\n\nKeep this lightweight:\n- Group at the **file level only** -- do not use `git add -p` or try to split hunks within a file.\n- If the separation is obvious (different features, unrelated fixes), split. If it's ambiguous, one commit is fine.\n- Two or three logical commits is the sweet spot. Do not over-slice into many tiny commits.\n\n### Step 4: Stage and commit\n\nIf the current branch from the context above is `main`, `master`, or the resolved default branch from Step 1, warn the user and ask whether to continue committing here or create a feature branch first. Use the platform's blocking question tool (`AskUserQuestion` in Claude Code, `request_user_input` in Codex, `ask_user` in Gemini, `ask_user` in Pi (requires the `pi-ask-user` extension)). If no question tool is available, present the options and wait for the user's reply before proceeding. If the user chooses to create a branch, derive the name from the change content, create it with `git checkout -b \u003Cbranch-name>`, then continue.\n\nWrite the commit message:\n- **Subject line**: Concise, imperative mood, focused on *why* not *what*. Follow the convention determined in Step 2.\n- **Body** (when needed): Add a body separated by a blank line for non-trivial changes. Explain motivation, trade-offs, or anything a future reader would need. Omit the body for obvious single-purpose changes.\n\nFor each commit group, stage and commit in a single call. Prefer staging specific files by name over `git add -A` or `git add .` to avoid accidentally including sensitive files (.env, credentials) or unrelated changes. Use a heredoc to preserve formatting:\n\n```bash\ngit add file1 file2 file3 && git commit -m \"$(cat \u003C\u003C'EOF'\ntype(scope): subject line here\n\nOptional body explaining why this change was made,\nnot just what changed.\nEOF\n)\"\n```\n\n### Step 5: Confirm\n\nRun `git status` after the commit to verify success. Report the commit hash(es) and subject line(s).\n",{"name":5,"description":7},"main","adde77e5116dc3a65ca3385f7d19d086cd10a74c","plugins\u002Fgaleharness-cli\u002Fskills\u002Fgit-commit",1,"https:\u002F\u002Fgithub.com\u002Fwangrenzhu-ola\u002FGaleHarnessCodingCLI","https:\u002F\u002Fgithub.com\u002Fwangrenzhu-ola","2026-06-13 09:21:37",{"source":8,"skillName":5,"commands":52,"prompt":62,"zipAvailable":63},[53,56,59],{"tool":54,"command":55},"npx","npx skills add wangrenzhu-ola\u002FGaleHarnessCodingCLI --skill git-commit",{"tool":57,"command":58},"bunx","bunx skills add wangrenzhu-ola\u002FGaleHarnessCodingCLI --skill git-commit",{"tool":60,"command":61},"pnpm","pnpm dlx skills add wangrenzhu-ola\u002FGaleHarnessCodingCLI --skill git-commit","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fwangrenzhu-ola\u002FGaleHarnessCodingCLI\u002Fblob\u002Fmain\u002Fplugins\u002Fgaleharness-cli\u002Fskills\u002Fgit-commit\u002FSKILL.md",true,[],[66,81,93,105,113,121],{"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":77,"publishedAt":39},"01M718XZ8QAQPM8BS5K9M2YQTJ","skill-one","Sample skill","https:\u002F\u002Fgithub.com\u002Fwangrenzhu-ola\u002FGaleHarnessCodingCLI\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fsample-plugin\u002Fskills\u002Fskill-one\u002FSKILL.md",[72],{"categoryNo":73,"categoryName":74,"taxonomyType":75,"taxonomyTypeDesc":76},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[78,79,80],"skill one","sample skill","sample",{"skillNo":82,"name":83,"nameZh":6,"description":84,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":85,"categories":86,"keywords":88,"publishedAt":39},"01M718XYEEENP5G592XVQ6MGVR","disabled-skill","A skill with model invocation disabled","https:\u002F\u002Fgithub.com\u002Fwangrenzhu-ola\u002FGaleHarnessCodingCLI\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fsample-plugin\u002Fskills\u002Fdisabled-skill\u002FSKILL.md",[87],{"categoryNo":73,"categoryName":74,"taxonomyType":75,"taxonomyTypeDesc":76},[89,33,90,91,92],"disabled skill","with model","true","model",{"skillNo":94,"name":95,"nameZh":6,"description":96,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":97,"categories":98,"keywords":100,"publishedAt":39},"01M718XXNH8T61H0EJE0BHE593","claude-only-skill","A skill restricted to Claude Code only","https:\u002F\u002Fgithub.com\u002Fwangrenzhu-ola\u002FGaleHarnessCodingCLI\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fsample-plugin\u002Fskills\u002Fclaude-only-skill\u002FSKILL.md",[99],{"categoryNo":73,"categoryName":74,"taxonomyType":75,"taxonomyTypeDesc":76},[101,102,103,104],"only","claude only skill","claude only","code",{"skillNo":106,"name":107,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":108,"categories":109,"keywords":110,"publishedAt":39},"01M718XWMPEPBWHC05JNGKSEF0","default-skill","https:\u002F\u002Fgithub.com\u002Fwangrenzhu-ola\u002FGaleHarnessCodingCLI\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fcustom-paths\u002Fskills\u002Fdefault-skill\u002FSKILL.md",[],[111,112],"default skill","default",{"skillNo":114,"name":115,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":116,"categories":117,"keywords":118,"publishedAt":39},"01M718XVZXW8CXYBNQZPJPNB6B","custom-skill","https:\u002F\u002Fgithub.com\u002Fwangrenzhu-ola\u002FGaleHarnessCodingCLI\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fcustom-paths\u002Fcustom-skills\u002Fcustom-skill\u002FSKILL.md",[],[119,120],"custom","custom skill",{"skillNo":122,"name":123,"nameZh":6,"description":124,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":125,"categories":126,"keywords":130,"publishedAt":39},"01M718XT6P96FVR69X0EEKK2N6","test-xcode","Build and test iOS apps on simulator using XcodeBuildMCP. Use after making iOS code changes, before creating a PR, or when verifying app behavior and checking for crashes on simulator.","https:\u002F\u002Fgithub.com\u002Fwangrenzhu-ola\u002FGaleHarnessCodingCLI\u002Fblob\u002Fmain\u002Fplugins\u002Fgaleharness-cli\u002Fskills\u002Ftest-xcode\u002FSKILL.md",[127],{"categoryNo":128,"categoryName":129,"taxonomyType":75,"taxonomyTypeDesc":76},"01JBSEEDCAT000000000000008","测试与质量",[131,132,133,134,135,136,137,138,112,91,139,35,140,34,104,30,141,142,143,144],"test","xcode","test xcode","apps","app","build and test","pr","for","xcodebuildmcp","scheme","build","ios","name","behavior"]