[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6R34S9C8N0HHT2WXZ985CBH":3,"skill-same:01M6R34S9C8N0HHT2WXZ985CBH":75},{"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":23,"publishedAt":43,"linkOnly":44,"markdownContent":45,"markdownBody":46,"frontMatter":47,"refName":48,"commitSha":49,"skillDirectory":50,"forksCount":14,"repositoryHtmlUrl":51,"repositoryHomepageUrl":52,"ownerHtmlUrl":53,"ownerBlogUrl":52,"ownerDescription":6,"updatedAt":54,"install":55,"resources":68},"01M6R34S9C8N0HHT2WXZ985CBH","github-workflow",null,"Handles the repository's GitHub delivery workflow end to end: issue creation, issue-number-linked branch creation, validation, conventional commit, push, and pull request creation.","jaeunda\u002Fjaeunda.github.io","jaeunda","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F130204907?v=4","01M6R348G0CWC8A2CHP7PJTXP4","daeun","01M6R348N2HXYAW14TCCVT94HN",0,"MIT","https:\u002F\u002Fgithub.com\u002Fjaeunda\u002Fjaeunda.github.io\u002Fblob\u002Fmain\u002F.agent\u002Fskills\u002Fgithub-workflow\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42],"workflow","github workflow","github","issue","request","issue creation","number","false","end","creation","delivery","commit","branch","conventional commit","repository","push","pull","validation","pull request","2026-11-10 10:12:30",false,"---\nname: github-workflow\ndescription: \"Handles the repository's GitHub delivery workflow end to end: issue creation, issue-number-linked branch creation, validation, conventional commit, push, and pull request creation.\"\nuser-invocable: false\n---\n\n# GitHub Workflow\n\nUse this skill when the user wants the repository change wrapped up into GitHub artifacts, especially requests like:\n\n- \"이슈 생성\u002F브랜치\u002F커밋\u002Fpr까지 진행\"\n- \"브랜치 이름 바꾸고 PR 열어줘\"\n- \"이 작업 이슈랑 커밋까지 정리해줘\"\n\nKeep the flow non-interactive and repository-safe.\n\n## Preconditions\n\n1. Check local state first.\n   - `git status --short --branch`\n   - `git remote -v`\n   - `git log --oneline -5`\n2. If there are unrelated staged or modified files, do not revert them. Scope the workflow only to the user-requested change.\n3. Check GitHub CLI auth before remote work.\n   - `gh auth status`\n4. If network access or auth blocks the workflow, continue as far as possible locally, then surface the exact blocker.\n5. Run all `gh` commands outside the sandbox (with escalation in this environment).\n\n## Required Validation\n\nBefore committing non-trivial work, choose validation commands that match the\nchanged surface. This repository uses `npm` scripts, not `pnpm` or Biome.\n\n- Always run `git diff --check` for whitespace and patch hygiene.\n- For TypeScript, component, config, Sass, or formatting-sensitive changes, run\n  `npm run check`.\n- For logic or utility changes covered by tests, run `npm test`.\n- For content, layout, Quartz config, build pipeline, or broad UI changes, run\n  `npm run quartz -- build`.\n\nReport pass\u002Ffail status in the final handoff and include the same validation\nlist in the PR body. If a validation command is skipped because it is not\nrelevant, say why.\n\n## Workflow\n\n1. Summarize the change in one line and identify the conventional commit type.\n   - Use `feat(\u003Cdomain>): ...`, `fix(\u003Cdomain>): ...`, or `chore: ...`\n2. Create the GitHub issue (required for full workflow).\n   - Use a conventional title matching the eventual commit and PR title.\n   - Example: `chore(agents): unify shared skill workflow`\n   - Use a body with `Summary` and `Validation` sections.\n   - Capture issue number from the creation result.\n3. Create issue-numbered branch name and check out branch.\n   - Branch format: `prefix\u003Cissue_num>\u002F\u003Cshort-kebab-summary>`\n   - `prefix` should be the conventional commit type, such as `feat`, `fix`,\n     `docs`, `style`, `refactor`, `test`, or `chore`.\n   - Example: `feat123\u002Fteam-po-fourth-deck`\n   - Command: `git checkout -b \u003Cbranch-name>`\n4. Stage only intended files.\n   - `git add \u003Cpaths...>`\n5. Commit with a conventional message.\n   - `git commit -m \"\u003Ctype(scope): summary>\"`\n6. Push branch.\n   - `git push -u origin \u003Cbranch-name>`\n7. Create the PR.\n   - Base branch is usually `main` unless local context says otherwise.\n   - Use the same conventional title style as the issue and commit.\n   - PR body should contain:\n     - `Summary`\n     - `Validation`\n     - `Closes #\u003Cissue-number>`\n\n## Naming Guidance\n\n- Issue, commit, and PR title: conventional, short, outcome-oriented, and\n  consistent with each other\n  - `feat(\u003Cdomain>): ...`\n  - `fix(\u003Cdomain>): ...`\n  - `chore(\u003Cdomain>): ...`\n- Branch name: lowercase kebab-case summary with a type prefix immediately\n  followed by the required issue number (`issue_num`), then a slash\n  - `feat123\u002Fshort-summary`\n  - `fix456\u002Fshort-summary`\n  - `chore789\u002Fshort-summary`\n- Good branch examples:\n  - `fix123\u002Fbranding-svg-refresh`\n  - `feat456\u002Fauth-profile-page`\n  - `chore789\u002Fupdate-mock-handlers`\n\nPrefer branch names that match the commit intent and always include issue number.\n\n## Command Patterns\n\nUse non-interactive `gh` commands.\n\n```bash\ngh issue create --repo \u003Cowner\u002Frepo> --title \"\u003Ctitle>\" --body \"\u003Cbody>\"\n# Capture issue URL from stdout, then derive issue number for branch naming:\nissue_url=\"$(gh issue create --repo \u003Cowner\u002Frepo> --title \"\u003Ctitle>\" --body \"\u003Cbody>\")\"\nissue_number=\"${issue_url##*\u002F}\"\ngh pr create --repo \u003Cowner\u002Frepo> --base main --head \u003Cbranch> --title \"\u003Ctitle>\" --body \"\u003Cbody>\"\n```\n\nWhen body text is multi-line, quote it safely. Avoid shell interpolation bugs from backticks inside double quotes.\n\n## Branch Rename Notes\n\nWhen the user explicitly asks to rename a branch:\n\n1. Rename locally with `git branch -m`.\n2. Push the renamed branch with `git push -u origin \u003Cnew-branch-name>`.\n3. Only delete the old remote branch if the user explicitly asks for it.\n\nDo not delete remote branches as part of the default flow.\n\n## Final Handoff\n\nReturn:\n\n- issue number and URL, if created\n- branch name\n- commit SHA and message\n- PR number and URL, if created\n- validation results\n\nIf any GitHub step failed, clearly separate:\n\n- completed local steps\n- blocked remote steps\n- exact reason, such as invalid `gh` auth or network restrictions\n","# GitHub Workflow\n\nUse this skill when the user wants the repository change wrapped up into GitHub artifacts, especially requests like:\n\n- \"이슈 생성\u002F브랜치\u002F커밋\u002Fpr까지 진행\"\n- \"브랜치 이름 바꾸고 PR 열어줘\"\n- \"이 작업 이슈랑 커밋까지 정리해줘\"\n\nKeep the flow non-interactive and repository-safe.\n\n## Preconditions\n\n1. Check local state first.\n   - `git status --short --branch`\n   - `git remote -v`\n   - `git log --oneline -5`\n2. If there are unrelated staged or modified files, do not revert them. Scope the workflow only to the user-requested change.\n3. Check GitHub CLI auth before remote work.\n   - `gh auth status`\n4. If network access or auth blocks the workflow, continue as far as possible locally, then surface the exact blocker.\n5. Run all `gh` commands outside the sandbox (with escalation in this environment).\n\n## Required Validation\n\nBefore committing non-trivial work, choose validation commands that match the\nchanged surface. This repository uses `npm` scripts, not `pnpm` or Biome.\n\n- Always run `git diff --check` for whitespace and patch hygiene.\n- For TypeScript, component, config, Sass, or formatting-sensitive changes, run\n  `npm run check`.\n- For logic or utility changes covered by tests, run `npm test`.\n- For content, layout, Quartz config, build pipeline, or broad UI changes, run\n  `npm run quartz -- build`.\n\nReport pass\u002Ffail status in the final handoff and include the same validation\nlist in the PR body. If a validation command is skipped because it is not\nrelevant, say why.\n\n## Workflow\n\n1. Summarize the change in one line and identify the conventional commit type.\n   - Use `feat(\u003Cdomain>): ...`, `fix(\u003Cdomain>): ...`, or `chore: ...`\n2. Create the GitHub issue (required for full workflow).\n   - Use a conventional title matching the eventual commit and PR title.\n   - Example: `chore(agents): unify shared skill workflow`\n   - Use a body with `Summary` and `Validation` sections.\n   - Capture issue number from the creation result.\n3. Create issue-numbered branch name and check out branch.\n   - Branch format: `prefix\u003Cissue_num>\u002F\u003Cshort-kebab-summary>`\n   - `prefix` should be the conventional commit type, such as `feat`, `fix`,\n     `docs`, `style`, `refactor`, `test`, or `chore`.\n   - Example: `feat123\u002Fteam-po-fourth-deck`\n   - Command: `git checkout -b \u003Cbranch-name>`\n4. Stage only intended files.\n   - `git add \u003Cpaths...>`\n5. Commit with a conventional message.\n   - `git commit -m \"\u003Ctype(scope): summary>\"`\n6. Push branch.\n   - `git push -u origin \u003Cbranch-name>`\n7. Create the PR.\n   - Base branch is usually `main` unless local context says otherwise.\n   - Use the same conventional title style as the issue and commit.\n   - PR body should contain:\n     - `Summary`\n     - `Validation`\n     - `Closes #\u003Cissue-number>`\n\n## Naming Guidance\n\n- Issue, commit, and PR title: conventional, short, outcome-oriented, and\n  consistent with each other\n  - `feat(\u003Cdomain>): ...`\n  - `fix(\u003Cdomain>): ...`\n  - `chore(\u003Cdomain>): ...`\n- Branch name: lowercase kebab-case summary with a type prefix immediately\n  followed by the required issue number (`issue_num`), then a slash\n  - `feat123\u002Fshort-summary`\n  - `fix456\u002Fshort-summary`\n  - `chore789\u002Fshort-summary`\n- Good branch examples:\n  - `fix123\u002Fbranding-svg-refresh`\n  - `feat456\u002Fauth-profile-page`\n  - `chore789\u002Fupdate-mock-handlers`\n\nPrefer branch names that match the commit intent and always include issue number.\n\n## Command Patterns\n\nUse non-interactive `gh` commands.\n\n```bash\ngh issue create --repo \u003Cowner\u002Frepo> --title \"\u003Ctitle>\" --body \"\u003Cbody>\"\n# Capture issue URL from stdout, then derive issue number for branch naming:\nissue_url=\"$(gh issue create --repo \u003Cowner\u002Frepo> --title \"\u003Ctitle>\" --body \"\u003Cbody>\")\"\nissue_number=\"${issue_url##*\u002F}\"\ngh pr create --repo \u003Cowner\u002Frepo> --base main --head \u003Cbranch> --title \"\u003Ctitle>\" --body \"\u003Cbody>\"\n```\n\nWhen body text is multi-line, quote it safely. Avoid shell interpolation bugs from backticks inside double quotes.\n\n## Branch Rename Notes\n\nWhen the user explicitly asks to rename a branch:\n\n1. Rename locally with `git branch -m`.\n2. Push the renamed branch with `git push -u origin \u003Cnew-branch-name>`.\n3. Only delete the old remote branch if the user explicitly asks for it.\n\nDo not delete remote branches as part of the default flow.\n\n## Final Handoff\n\nReturn:\n\n- issue number and URL, if created\n- branch name\n- commit SHA and message\n- PR number and URL, if created\n- validation results\n\nIf any GitHub step failed, clearly separate:\n\n- completed local steps\n- blocked remote steps\n- exact reason, such as invalid `gh` auth or network restrictions\n",{"name":5,"description":7,"user-invocable":44},"main","a7481b1c06fafc4cc38ffdd8d045ea378adbcce1",".agent\u002Fskills\u002Fgithub-workflow","https:\u002F\u002Fgithub.com\u002Fjaeunda\u002Fjaeunda.github.io","https:\u002F\u002Fjaeunda.github.io\u002F","https:\u002F\u002Fgithub.com\u002Fjaeunda","2026-10-24 19:45:07",{"source":8,"skillName":5,"commands":56,"prompt":66,"zipAvailable":67},[57,60,63],{"tool":58,"command":59},"npx","npx skills add jaeunda\u002Fjaeunda.github.io --skill github-workflow",{"tool":61,"command":62},"bunx","bunx skills add jaeunda\u002Fjaeunda.github.io --skill github-workflow",{"tool":64,"command":65},"pnpm","pnpm dlx skills add jaeunda\u002Fjaeunda.github.io --skill github-workflow","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fjaeunda\u002Fjaeunda.github.io\u002Fblob\u002Fmain\u002F.agent\u002Fskills\u002Fgithub-workflow\u002FSKILL.md",true,[69],{"path":70,"resourceType":71,"resourceTypeDesc":72,"sizeBytes":73,"sourceHtmlUrl":74},"agents\u002Fopenai.yml","REFERENCE","参考文档",166,"https:\u002F\u002Fgithub.com\u002Fjaeunda\u002Fjaeunda.github.io\u002Fblob\u002Fmain\u002F.agent\u002Fskills\u002Fgithub-workflow\u002Fagents\u002Fopenai.yml",[76,81,98],{"skillNo":77,"name":5,"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":78,"categories":79,"keywords":80,"publishedAt":43},"01M6R351JJ5H06YW2Y019GVAFS","https:\u002F\u002Fgithub.com\u002Fjaeunda\u002Fjaeunda.github.io\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fgithub-workflow\u002FSKILL.md",[],[25,24,26],{"skillNo":82,"name":83,"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":84,"categories":85,"keywords":94,"publishedAt":43},"01M6R34YJFEX4TVF5PD47Y3YT2","design-system","https:\u002F\u002Fgithub.com\u002Fjaeunda\u002Fjaeunda.github.io\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fdesign-system\u002FSKILL.md",[86,89],{"categoryNo":87,"categoryName":88,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":90,"categoryName":91,"taxonomyType":92,"taxonomyTypeDesc":93},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",[95,96,97],"system","design system","design",{"skillNo":99,"name":83,"nameZh":6,"description":100,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":101,"categories":102,"keywords":105,"publishedAt":43},"01M6R34FE3BQX6YMG3T96CEYKZ","Use when changing jaeunda.log visual design, Quartz layout, typography, colors, responsive behavior, home-page components, article styling, tag\u002Flist pages, or UI polish. Ensures every agent follows the repository's actual design system and produces consistent output from the same input.","https:\u002F\u002Fgithub.com\u002Fjaeunda\u002Fjaeunda.github.io\u002Fblob\u002Fmain\u002F.agent\u002Fskills\u002Fdesign-system\u002FSKILL.md",[103,104],{"categoryNo":87,"categoryName":88,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":90,"categoryName":91,"taxonomyType":92,"taxonomyTypeDesc":93},[96,95,97,106,107,108,109,110,111,112,113,114,115,116,117,118,119,120,38,121],"layout","when","true","output","input","pages","article","visual","visual design","log","use","behavior","page","ui polish","polish","components"]