[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71FW8W5AN739WQSCX649X9S":3,"skill-same:01M71FW8W5AN739WQSCX649X9S":70},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":17,"publishedAt":38,"linkOnly":39,"markdownContent":40,"markdownBody":41,"frontMatter":42,"refName":43,"commitSha":44,"skillDirectory":45,"forksCount":46,"repositoryHtmlUrl":47,"repositoryHomepageUrl":6,"ownerHtmlUrl":48,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":49,"install":50,"resources":63},"01M71FW8W5AN739WQSCX649X9S","git-change-conventions",null,"Use when creating or naming branches, pull requests, or commits in this repository. Follow the repo's required type prefixes for branch and PR titles, and write detailed commit messages.","Andy-CH-BO-AN\u002FAI-running-coach","Andy-CH-BO-AN","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F58759761?v=4","01M71FSKGT9TWBMY2SFP4V2JR8","01M71FSKHQAN25HG2TRY5WVCMG",2,"MIT","https:\u002F\u002Fgithub.com\u002FAndy-CH-BO-AN\u002FAI-running-coach\u002Fblob\u002Fmain\u002Fai\u002Fskills\u002Fgit-change-conventions\u002FSKILL.md",[],[18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37],"change","git change conventions","conventions","git","pr","pull","messages","commits","branch","repo","use","branches","commit","type","naming","requests","for","when","titles","pull requests","2026-11-10 10:12:30",false,"---\nname: git-change-conventions\ndescription: Use when creating or naming branches, pull requests, or commits in this repository. Follow the repo's required type prefixes for branch and PR titles, and write detailed commit messages.\n---\n\n# Git Change Conventions\n\nUse this skill whenever the task includes:\n\n- creating a branch\n- updating the readme\n- naming a pull request\n- writing commit messages\n- proposing branch, PR, or commit naming conventions\n\n## PR title format\n\nPull request titles must use this exact format:\n\n- `\u003CTYPE>: \u003Csummary>`\n\nThe allowed `\u003CTYPE>` values are:\n\n- `FEATURE:` new feature\n- `FIX:` bug fix\n- `REFACTOR:` code refactor with no behavior change\n- `DOCS:` documentation only\n- `TEST:` tests only\n- `STYLE:` formatting-only changes such as linting or layout cleanup\n- `PERF:` performance improvement\n- `CHORE:` maintenance or miscellaneous housekeeping\n- `CI:` continuous integration configuration or scripts\n\n## Branch format\n\nGit branch names cannot contain `:` or spaces, so branches must use this\ncompatible format instead:\n\n- `\u003Ctype>\u002F\u003Csummary-in-kebab-case>`\n\nExamples:\n\n- `feat\u002Fadd-weekly-fatigue-summary`\n- `fix\u002Fhandle-empty-garmin-heart-rate-payload`\n\n## Required usage rules\n\n1. Use the same logical type for the branch and PR title unless there\n   is a clear reason not to.\n2. Branch `type` uses the short lowercase prefix (e.g. `feat`), while\n   the PR title uses the full allowed `TYPE` name (e.g. `FEATURE:`).\n   See the mapping table in the PR creation section.\n3. Keep the text after the prefix specific to the actual change.\n4. Do not invent additional top-level prefixes unless the user\n   explicitly changes the convention.\n5. If a change spans multiple categories, choose the prefix that best\n   describes the primary user-facing outcome.\n6. Convert branch summaries to lowercase kebab-case.\n7. PR descriptions should contain summary, why the change was needed, what was changed, and any important\n   implementation or validation notes.\n\n## Commit message rules\n\n- Commit messages must be detailed, not terse.\n- The subject line should clearly describe the intent and affected area.\n- Prefer a multi-line commit message when the change is non-trivial.\n- The body should summarize:\n  - what changed\n  - why the change was needed\n  - any important implementation or validation notes\n\n## Examples\n\n- Branch: `feat\u002Fadd-weekly-fatigue-summary`\n- PR title: `FEATURE: add weekly fatigue summary to coach report`\n- Branch: `fix\u002Fhandle-empty-garmin-heart-rate-payload`\n- PR title: `FIX: handle empty Garmin heart rate payload`\n- Branch: `docs\u002Fadd-shared-git-naming-conventions`\n- PR title: `DOCS: add shared Git naming conventions for branch, PR, and commits`\n\n## GitHub CLI environment\n\n- Run all `gh` commands in the local host environment, using its credential\n  store and GitHub configuration.\n- Do not use sandboxed `gh` credentials or fall back to them. If local-host\n  `gh` authentication fails, stop and report the authentication blocker.\n\n## PR creation with GitHub CLI\n\nWhen creating a pull request via `gh`, apply the conventions above:\n\n```bash\ngh pr create \\\n  --title \"TYPE: summary\" \\\n  --body \"## Summary\n\u003Cwhat this PR does>\n\n## Why\n\u003Cwhy the change was needed>\n\n## Changes\n- \u003Cfile\u002Farea>: \u003Cdescription>\n\n## Validation\n- \u003Ctests run, manual checks, or screenshots>\" \\\n  --base main\n```\n\n- Do not use `--draft`. Every pull request must be created ready for review.\n- Add `--reviewer \u003Chandle>` when the team requires explicit reviewer\n  assignment.\n- Add `--label \u003Clabel>` to categorise the PR when project labels exist.\n- The PR title `TYPE` must use the allowed name from the PR title\n  format section, not a literal uppercase of the branch prefix. Use the\n  mapping below:\n\n| Branch prefix | PR title TYPE |\n|---------------|---------------|\n| `feat`        | `FEATURE`     |\n| `fix`         | `FIX`         |\n| `refactor`    | `REFACTOR`    |\n| `docs`        | `DOCS`        |\n| `test`        | `TEST`        |\n| `style`       | `STYLE`       |\n| `perf`        | `PERF`        |\n| `chore`       | `CHORE`       |\n| `ci`          | `CI`          |\n\n## PR review follow-ups\n\nWhen completing requested PR review changes, commit and push the fix, then use\nthe PR's **Add a comment** action to post `@codex review`. This requests a new\nautomatic Codex reviewer pass for the updated changes.\n\n## Output expectations\n\n- When asked to create names, provide branch and PR title that follow\n  this convention exactly.\n- When asked to commit, write a detailed commit message that matches the\n  change scope instead of a one-line shorthand.\n","# Git Change Conventions\n\nUse this skill whenever the task includes:\n\n- creating a branch\n- updating the readme\n- naming a pull request\n- writing commit messages\n- proposing branch, PR, or commit naming conventions\n\n## PR title format\n\nPull request titles must use this exact format:\n\n- `\u003CTYPE>: \u003Csummary>`\n\nThe allowed `\u003CTYPE>` values are:\n\n- `FEATURE:` new feature\n- `FIX:` bug fix\n- `REFACTOR:` code refactor with no behavior change\n- `DOCS:` documentation only\n- `TEST:` tests only\n- `STYLE:` formatting-only changes such as linting or layout cleanup\n- `PERF:` performance improvement\n- `CHORE:` maintenance or miscellaneous housekeeping\n- `CI:` continuous integration configuration or scripts\n\n## Branch format\n\nGit branch names cannot contain `:` or spaces, so branches must use this\ncompatible format instead:\n\n- `\u003Ctype>\u002F\u003Csummary-in-kebab-case>`\n\nExamples:\n\n- `feat\u002Fadd-weekly-fatigue-summary`\n- `fix\u002Fhandle-empty-garmin-heart-rate-payload`\n\n## Required usage rules\n\n1. Use the same logical type for the branch and PR title unless there\n   is a clear reason not to.\n2. Branch `type` uses the short lowercase prefix (e.g. `feat`), while\n   the PR title uses the full allowed `TYPE` name (e.g. `FEATURE:`).\n   See the mapping table in the PR creation section.\n3. Keep the text after the prefix specific to the actual change.\n4. Do not invent additional top-level prefixes unless the user\n   explicitly changes the convention.\n5. If a change spans multiple categories, choose the prefix that best\n   describes the primary user-facing outcome.\n6. Convert branch summaries to lowercase kebab-case.\n7. PR descriptions should contain summary, why the change was needed, what was changed, and any important\n   implementation or validation notes.\n\n## Commit message rules\n\n- Commit messages must be detailed, not terse.\n- The subject line should clearly describe the intent and affected area.\n- Prefer a multi-line commit message when the change is non-trivial.\n- The body should summarize:\n  - what changed\n  - why the change was needed\n  - any important implementation or validation notes\n\n## Examples\n\n- Branch: `feat\u002Fadd-weekly-fatigue-summary`\n- PR title: `FEATURE: add weekly fatigue summary to coach report`\n- Branch: `fix\u002Fhandle-empty-garmin-heart-rate-payload`\n- PR title: `FIX: handle empty Garmin heart rate payload`\n- Branch: `docs\u002Fadd-shared-git-naming-conventions`\n- PR title: `DOCS: add shared Git naming conventions for branch, PR, and commits`\n\n## GitHub CLI environment\n\n- Run all `gh` commands in the local host environment, using its credential\n  store and GitHub configuration.\n- Do not use sandboxed `gh` credentials or fall back to them. If local-host\n  `gh` authentication fails, stop and report the authentication blocker.\n\n## PR creation with GitHub CLI\n\nWhen creating a pull request via `gh`, apply the conventions above:\n\n```bash\ngh pr create \\\n  --title \"TYPE: summary\" \\\n  --body \"## Summary\n\u003Cwhat this PR does>\n\n## Why\n\u003Cwhy the change was needed>\n\n## Changes\n- \u003Cfile\u002Farea>: \u003Cdescription>\n\n## Validation\n- \u003Ctests run, manual checks, or screenshots>\" \\\n  --base main\n```\n\n- Do not use `--draft`. Every pull request must be created ready for review.\n- Add `--reviewer \u003Chandle>` when the team requires explicit reviewer\n  assignment.\n- Add `--label \u003Clabel>` to categorise the PR when project labels exist.\n- The PR title `TYPE` must use the allowed name from the PR title\n  format section, not a literal uppercase of the branch prefix. Use the\n  mapping below:\n\n| Branch prefix | PR title TYPE |\n|---------------|---------------|\n| `feat`        | `FEATURE`     |\n| `fix`         | `FIX`         |\n| `refactor`    | `REFACTOR`    |\n| `docs`        | `DOCS`        |\n| `test`        | `TEST`        |\n| `style`       | `STYLE`       |\n| `perf`        | `PERF`        |\n| `chore`       | `CHORE`       |\n| `ci`          | `CI`          |\n\n## PR review follow-ups\n\nWhen completing requested PR review changes, commit and push the fix, then use\nthe PR's **Add a comment** action to post `@codex review`. This requests a new\nautomatic Codex reviewer pass for the updated changes.\n\n## Output expectations\n\n- When asked to create names, provide branch and PR title that follow\n  this convention exactly.\n- When asked to commit, write a detailed commit message that matches the\n  change scope instead of a one-line shorthand.\n",{"name":5,"description":7},"main","c8423dc370076b0251f5c049b7c3ea3bc4d17d75","ai\u002Fskills\u002Fgit-change-conventions",0,"https:\u002F\u002Fgithub.com\u002FAndy-CH-BO-AN\u002FAI-running-coach","https:\u002F\u002Fgithub.com\u002FAndy-CH-BO-AN","2026-10-23 22:13:05",{"source":8,"skillName":5,"commands":51,"prompt":61,"zipAvailable":62},[52,55,58],{"tool":53,"command":54},"npx","npx skills add Andy-CH-BO-AN\u002FAI-running-coach --skill git-change-conventions",{"tool":56,"command":57},"bunx","bunx skills add Andy-CH-BO-AN\u002FAI-running-coach --skill git-change-conventions",{"tool":59,"command":60},"pnpm","pnpm dlx skills add Andy-CH-BO-AN\u002FAI-running-coach --skill git-change-conventions","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FAndy-CH-BO-AN\u002FAI-running-coach\u002Fblob\u002Fmain\u002Fai\u002Fskills\u002Fgit-change-conventions\u002FSKILL.md",true,[64],{"path":65,"resourceType":66,"resourceTypeDesc":67,"sizeBytes":68,"sourceHtmlUrl":69},"agents\u002Fopenai.yaml","REFERENCE","参考文档",294,"https:\u002F\u002Fgithub.com\u002FAndy-CH-BO-AN\u002FAI-running-coach\u002Fblob\u002Fmain\u002Fai\u002Fskills\u002Fgit-change-conventions\u002Fagents\u002Fopenai.yaml",[71,96,120,143,167,184],{"skillNo":72,"name":73,"nameZh":6,"description":74,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":75,"categories":76,"keywords":77,"publishedAt":38},"01M71FWKE76AC8TMK2CQ19YAY6","token-decrease","Ultra-compressed communication mode. Cuts token usage ~75% by speaking like caveman while keeping full technical accuracy. Supports intensity levels: lite, full (default), ultra, wenyan-lite, wenyan-full, wenyan-ultra. Use when user says \"caveman mode\", \"talk like caveman\", \"use caveman\", \"less tokens\", \"be brief\", \"token decrease\", or invokes \u002Fcaveman. Also auto-triggers when token efficiency is requested.","https:\u002F\u002Fgithub.com\u002FAndy-CH-BO-AN\u002FAI-running-coach\u002Fblob\u002Fmain\u002Fai\u002Fskills\u002Ftoken-decrease\u002FSKILL.md",[],[78,79,80,81,82,83,84,85,86,87,88,89,90,28,35,91,92,93,94,95],"token decrease","token","brief","token efficiency","usage","tokens","mode","default","accuracy","triggers","intensity","auto","technical","efficiency","Caveman Mode","communication","lite","ultra",{"skillNo":97,"name":98,"nameZh":6,"description":99,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":100,"categories":101,"keywords":102,"publishedAt":38},"01M71FWHPQQBZWZ9ZHTV2SED9Y","readme-pm-review","Use only when the user explicitly asks for a product-manager style review of a repository README. Read only the README first, do not infer undocumented features, and provide readability feedback, rewrite suggestions, and product-priority recommendations.","https:\u002F\u002Fgithub.com\u002FAndy-CH-BO-AN\u002FAI-running-coach\u002Fblob\u002Fmain\u002Fai\u002Fskills\u002Freadme-pm-review\u002FSKILL.md",[],[103,104,105,106,107,108,109,34,110,28,35,111,112,113,114,115,116,117,118,119],"README","readme pm review","pm","review","do","feedback","infer","only","rewrite","first","style","product","recommendations","read","repository","features","manager",{"skillNo":121,"name":122,"nameZh":6,"description":123,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":124,"categories":125,"keywords":126,"publishedAt":38},"01M71FWFE09MTZVFZS2CY8Y939","python-review-qa-loop","Use when working on Python code changes that should follow this repo's shared review and QA loop. Read the shared workflow docs, make the smallest viable patch, run relevant tests, capture results, and route DB, credentials, secrets, or Garmin password related changes through the shared security guidance.","https:\u002F\u002Fgithub.com\u002FAndy-CH-BO-AN\u002FAI-running-coach\u002Fblob\u002Fmain\u002Fai\u002Fskills\u002Fpython-review-qa-loop\u002FSKILL.md",[],[127,128,129,130,106,131,132,133,27,134,135,28,136,35,137,138,139,140,141,142],"python review qa loop","python","qa","loop","shared","relevant","db","security guidance","tests","password","workflow","patch","code","route","python code","credentials",{"skillNo":144,"name":145,"nameZh":6,"description":146,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":147,"categories":148,"keywords":149,"publishedAt":38},"01M71FWDWPXVWR0GBB4SSWXPJK","improve-codebase-architecture","Scan a codebase for deepening opportunities, present them as a visual HTML report, then grill through whichever one you pick.","https:\u002F\u002Fgithub.com\u002FAndy-CH-BO-AN\u002FAI-running-coach\u002Fblob\u002Fmain\u002Fai\u002Fskills\u002Fimprove-codebase-architecture\u002FSKILL.md",[],[150,151,152,153,154,155,34,156,157,158,159,160,161,162,163,164,165,166],"improve codebase architecture","codebase","improve","architecture","as","grill","scan","report","pick","html report","true","deepening","present","you","visual","one","html",{"skillNo":168,"name":169,"nameZh":6,"description":170,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":171,"categories":172,"keywords":173,"publishedAt":38},"01M71FWCMB41PC4XCKG0HTMEFK","grilling","Grill the user relentlessly about a plan, decision, or idea. Use when the user wants to stress-test their thinking, or uses any 'grill' trigger phrases.","https:\u002F\u002Fgithub.com\u002FAndy-CH-BO-AN\u002FAI-running-coach\u002Fblob\u002Fmain\u002Fai\u002Fskills\u002Fgrilling\u002FSKILL.md",[],[169,174,175,176,155,177,178,179,180,28,35,181,182,183],"test","thinking","plan","about","trigger","decision","stress-test","stress","user","idea",{"skillNo":185,"name":186,"nameZh":6,"description":187,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":188,"categories":189,"keywords":190,"publishedAt":38},"01M71FWBE9N70PWAY8HF7RR4HY","grill-with-docs","A relentless interview to sharpen a plan or design, which also creates docs (ADR's and glossary) as we go.","https:\u002F\u002Fgithub.com\u002FAndy-CH-BO-AN\u002FAI-running-coach\u002Fblob\u002Fmain\u002Fai\u002Fskills\u002Fgrill-with-docs\u002FSKILL.md",[],[191,155,192,193,194,154,195,176,196,160,197,198,199,200],"with","docs","grill with docs","interview","adr","which","design","go","glossary","sharpen"]