[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6AC3117P8HTY7VRDJR0WHKJ":3,"skill-same:01M6AC3117P8HTY7VRDJR0WHKJ":70},{"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":24,"linkOnly":25,"markdownContent":26,"markdownBody":27,"frontMatter":28,"refName":29,"commitSha":30,"skillDirectory":31,"forksCount":32,"repositoryHtmlUrl":33,"repositoryHomepageUrl":34,"ownerHtmlUrl":35,"ownerBlogUrl":36,"ownerDescription":6,"updatedAt":37,"install":38,"resources":51},"01M6AC3117P8HTY7VRDJR0WHKJ","pull",null,"Pull latest origin\u002Fmain into the current local branch and resolve merge conflicts (aka update-branch). Use when Codex needs to sync a feature branch with origin, perform a merge-based update (not rebase), and guide conflict resolution best practices.","openai\u002Fsymphony","openai","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F14957082?v=4","01M6AC29YGCR4S2NTJFV0G8B81","OpenAI","01M6AC2S7WQ2QFC2KVMSGBVNVZ",28003,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fopenai\u002Fsymphony\u002Fblob\u002Fmain\u002F.codex\u002Fskills\u002Fpull\u002FSKILL.md",[],[5,19,20,21,22,23],"codex","merge","sync","update","best practices","2026-11-10 10:12:30",false,"---\nname: pull\ndescription:\n  Pull latest origin\u002Fmain into the current local branch and resolve merge\n  conflicts (aka update-branch). Use when Codex needs to sync a feature branch\n  with origin, perform a merge-based update (not rebase), and guide conflict\n  resolution best practices.\n---\n\n# Pull\n\n## Workflow\n\n1. Verify git status is clean or commit\u002Fstash changes before merging.\n2. Ensure rerere is enabled locally:\n   - `git config rerere.enabled true`\n   - `git config rerere.autoupdate true`\n3. Confirm remotes and branches:\n   - Ensure the `origin` remote exists.\n   - Ensure the current branch is the one to receive the merge.\n4. Fetch latest refs:\n   - `git fetch origin`\n5. Sync the remote feature branch first:\n   - `git pull --ff-only origin $(git branch --show-current)`\n   - This pulls branch updates made remotely (for example, a GitHub auto-commit)\n     before merging `origin\u002Fmain`.\n6. Merge in order:\n   - Prefer `git -c merge.conflictstyle=zdiff3 merge origin\u002Fmain` for clearer\n     conflict context.\n7. If conflicts appear, resolve them (see conflict guidance below), then:\n   - `git add \u003Cfiles>`\n   - `git commit` (or `git merge --continue` if the merge is paused)\n8. Verify with project checks (follow repo policy in `AGENTS.md`).\n9. Summarize the merge:\n   - Call out the most challenging conflicts\u002Ffiles and how they were resolved.\n   - Note any assumptions or follow-ups.\n\n## Conflict Resolution Guidance (Best Practices)\n\n- Inspect context before editing:\n  - Use `git status` to list conflicted files.\n  - Use `git diff` or `git diff --merge` to see conflict hunks.\n  - Use `git diff :1:path\u002Fto\u002Ffile :2:path\u002Fto\u002Ffile` and\n    `git diff :1:path\u002Fto\u002Ffile :3:path\u002Fto\u002Ffile` to compare base vs ours\u002Ftheirs\n    for a file-level view of intent.\n  - With `merge.conflictstyle=zdiff3`, conflict markers include:\n    - `\u003C\u003C\u003C\u003C\u003C\u003C\u003C` ours, `|||||||` base, `=======` split, `>>>>>>>` theirs.\n    - Matching lines near the start\u002Fend are trimmed out of the conflict region,\n      so focus on the differing core.\n  - Summarize the intent of both changes, decide the semantically correct\n    outcome, then edit:\n    - State what each side is trying to achieve (bug fix, refactor, rename,\n      behavior change).\n    - Identify the shared goal, if any, and whether one side supersedes the\n      other.\n    - Decide the final behavior first; only then craft the code to match that\n      decision.\n    - Prefer preserving invariants, API contracts, and user-visible behavior\n      unless the conflict clearly indicates a deliberate change.\n  - Open files and understand intent on both sides before choosing a resolution.\n- Prefer minimal, intention-preserving edits:\n  - Keep behavior consistent with the branch’s purpose.\n  - Avoid accidental deletions or silent behavior changes.\n- Resolve one file at a time and rerun tests after each logical batch.\n- Use `ours\u002Ftheirs` only when you are certain one side should win entirely.\n- For complex conflicts, search for related files or definitions to align with\n  the rest of the codebase.\n- For generated files, resolve non-generated conflicts first, then regenerate:\n  - Prefer resolving source files and handwritten logic before touching\n    generated artifacts.\n  - Run the CLI\u002Ftooling command that produced the generated file to recreate it\n    cleanly, then stage the regenerated output.\n- For import conflicts where intent is unclear, accept both sides first:\n  - Keep all candidate imports temporarily, finish the merge, then run lint\u002Ftype\n    checks to remove unused or incorrect imports safely.\n- After resolving, ensure no conflict markers remain:\n  - `git diff --check`\n- When unsure, note assumptions and ask for confirmation before finalizing the\n  merge.\n\n## When To Ask The User (Keep To A Minimum)\n\nDo not ask for input unless there is no safe, reversible alternative. Prefer\nmaking a best-effort decision, documenting the rationale, and proceeding.\n\nAsk the user only when:\n\n- The correct resolution depends on product intent or behavior not inferable\n  from code, tests, or nearby documentation.\n- The conflict crosses a user-visible contract, API surface, or migration where\n  choosing incorrectly could break external consumers.\n- A conflict requires selecting between two mutually exclusive designs with\n  equivalent technical merit and no clear local signal.\n- The merge introduces data loss, schema changes, or irreversible side effects\n  without an obvious safe default.\n- The branch is not the intended target, or the remote\u002Fbranch names do not exist\n  and cannot be determined locally.\n\nOtherwise, proceed with the merge, explain the decision briefly in notes, and\nleave a clear, reviewable commit history.\n","# Pull\n\n## Workflow\n\n1. Verify git status is clean or commit\u002Fstash changes before merging.\n2. Ensure rerere is enabled locally:\n   - `git config rerere.enabled true`\n   - `git config rerere.autoupdate true`\n3. Confirm remotes and branches:\n   - Ensure the `origin` remote exists.\n   - Ensure the current branch is the one to receive the merge.\n4. Fetch latest refs:\n   - `git fetch origin`\n5. Sync the remote feature branch first:\n   - `git pull --ff-only origin $(git branch --show-current)`\n   - This pulls branch updates made remotely (for example, a GitHub auto-commit)\n     before merging `origin\u002Fmain`.\n6. Merge in order:\n   - Prefer `git -c merge.conflictstyle=zdiff3 merge origin\u002Fmain` for clearer\n     conflict context.\n7. If conflicts appear, resolve them (see conflict guidance below), then:\n   - `git add \u003Cfiles>`\n   - `git commit` (or `git merge --continue` if the merge is paused)\n8. Verify with project checks (follow repo policy in `AGENTS.md`).\n9. Summarize the merge:\n   - Call out the most challenging conflicts\u002Ffiles and how they were resolved.\n   - Note any assumptions or follow-ups.\n\n## Conflict Resolution Guidance (Best Practices)\n\n- Inspect context before editing:\n  - Use `git status` to list conflicted files.\n  - Use `git diff` or `git diff --merge` to see conflict hunks.\n  - Use `git diff :1:path\u002Fto\u002Ffile :2:path\u002Fto\u002Ffile` and\n    `git diff :1:path\u002Fto\u002Ffile :3:path\u002Fto\u002Ffile` to compare base vs ours\u002Ftheirs\n    for a file-level view of intent.\n  - With `merge.conflictstyle=zdiff3`, conflict markers include:\n    - `\u003C\u003C\u003C\u003C\u003C\u003C\u003C` ours, `|||||||` base, `=======` split, `>>>>>>>` theirs.\n    - Matching lines near the start\u002Fend are trimmed out of the conflict region,\n      so focus on the differing core.\n  - Summarize the intent of both changes, decide the semantically correct\n    outcome, then edit:\n    - State what each side is trying to achieve (bug fix, refactor, rename,\n      behavior change).\n    - Identify the shared goal, if any, and whether one side supersedes the\n      other.\n    - Decide the final behavior first; only then craft the code to match that\n      decision.\n    - Prefer preserving invariants, API contracts, and user-visible behavior\n      unless the conflict clearly indicates a deliberate change.\n  - Open files and understand intent on both sides before choosing a resolution.\n- Prefer minimal, intention-preserving edits:\n  - Keep behavior consistent with the branch’s purpose.\n  - Avoid accidental deletions or silent behavior changes.\n- Resolve one file at a time and rerun tests after each logical batch.\n- Use `ours\u002Ftheirs` only when you are certain one side should win entirely.\n- For complex conflicts, search for related files or definitions to align with\n  the rest of the codebase.\n- For generated files, resolve non-generated conflicts first, then regenerate:\n  - Prefer resolving source files and handwritten logic before touching\n    generated artifacts.\n  - Run the CLI\u002Ftooling command that produced the generated file to recreate it\n    cleanly, then stage the regenerated output.\n- For import conflicts where intent is unclear, accept both sides first:\n  - Keep all candidate imports temporarily, finish the merge, then run lint\u002Ftype\n    checks to remove unused or incorrect imports safely.\n- After resolving, ensure no conflict markers remain:\n  - `git diff --check`\n- When unsure, note assumptions and ask for confirmation before finalizing the\n  merge.\n\n## When To Ask The User (Keep To A Minimum)\n\nDo not ask for input unless there is no safe, reversible alternative. Prefer\nmaking a best-effort decision, documenting the rationale, and proceeding.\n\nAsk the user only when:\n\n- The correct resolution depends on product intent or behavior not inferable\n  from code, tests, or nearby documentation.\n- The conflict crosses a user-visible contract, API surface, or migration where\n  choosing incorrectly could break external consumers.\n- A conflict requires selecting between two mutually exclusive designs with\n  equivalent technical merit and no clear local signal.\n- The merge introduces data loss, schema changes, or irreversible side effects\n  without an obvious safe default.\n- The branch is not the intended target, or the remote\u002Fbranch names do not exist\n  and cannot be determined locally.\n\nOtherwise, proceed with the merge, explain the decision briefly in notes, and\nleave a clear, reviewable commit history.\n",{"name":5,"description":7},"main","be10a1b79df723d6d7612b5651c8522704dafb2e",".codex\u002Fskills\u002Fpull",2889,"https:\u002F\u002Fgithub.com\u002Fopenai\u002Fsymphony","https:\u002F\u002Fopenai.com\u002Findex\u002Fopen-source-codex-orchestration-symphony\u002F","https:\u002F\u002Fgithub.com\u002Fopenai","https:\u002F\u002Fopenai.com\u002F","2026-09-16 06:14:59",{"source":8,"skillName":5,"commands":39,"prompt":49,"zipAvailable":50},[40,43,46],{"tool":41,"command":42},"npx","npx skills add openai\u002Fsymphony --skill pull",{"tool":44,"command":45},"bunx","bunx skills add openai\u002Fsymphony --skill pull",{"tool":47,"command":48},"pnpm","pnpm dlx skills add openai\u002Fsymphony --skill pull","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fopenai\u002Fsymphony\u002Fblob\u002Fmain\u002F.codex\u002Fskills\u002Fpull\u002FSKILL.md",true,[52,58,62,66],{"path":53,"resourceType":54,"resourceTypeDesc":55,"sizeBytes":56,"sourceHtmlUrl":57},"references\u002FDATAGRID.md","REFERENCE","参考文档",4692,"https:\u002F\u002Fgithub.com\u002Fgithub\u002Fawesome-copilot\u002Fblob\u002Fmain\u002Fskills\u002Ffluentui-blazor\u002Freferences\u002FDATAGRID.md",{"path":59,"resourceType":54,"resourceTypeDesc":55,"sizeBytes":60,"sourceHtmlUrl":61},"references\u002FLAYOUT-AND-NAVIGATION.md",5079,"https:\u002F\u002Fgithub.com\u002Fgithub\u002Fawesome-copilot\u002Fblob\u002Fmain\u002Fskills\u002Ffluentui-blazor\u002Freferences\u002FLAYOUT-AND-NAVIGATION.md",{"path":63,"resourceType":54,"resourceTypeDesc":55,"sizeBytes":64,"sourceHtmlUrl":65},"references\u002FSETUP.md",4982,"https:\u002F\u002Fgithub.com\u002Fgithub\u002Fawesome-copilot\u002Fblob\u002Fmain\u002Fskills\u002Ffluentui-blazor\u002Freferences\u002FSETUP.md",{"path":67,"resourceType":54,"resourceTypeDesc":55,"sizeBytes":68,"sourceHtmlUrl":69},"references\u002FTHEMING.md",3436,"https:\u002F\u002Fgithub.com\u002Fgithub\u002Fawesome-copilot\u002Fblob\u002Fmain\u002Fskills\u002Ffluentui-blazor\u002Freferences\u002FTHEMING.md",[71,80,90,97,105,117],{"skillNo":72,"name":73,"nameZh":6,"description":74,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":75,"categories":76,"keywords":77,"publishedAt":24},"01M6AC34AEWQ2BK7683S9X9TBG","release","Cut a Symphony release by bumping the committed version, landing it, tagging the merged commit, and verifying the Burrito release workflow. Use when asked to release, tag, or retag Symphony.","https:\u002F\u002Fgithub.com\u002Fopenai\u002Fsymphony\u002Fblob\u002Fmain\u002F.codex\u002Fskills\u002Frelease\u002FSKILL.md",[],[73,78,79],"workflow","commit",{"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":24},"01M6AC32PHM4E28BRWM03H61A3","push","Push current branch changes to origin and create or update the corresponding pull request; use when asked to push, publish updates, or create pull request.","https:\u002F\u002Fgithub.com\u002Fopenai\u002Fsymphony\u002Fblob\u002Fmain\u002F.codex\u002Fskills\u002Fpush\u002FSKILL.md",[],[82,87,88,89,22,5],"create pull request","pull request","create",{"skillNo":91,"name":92,"nameZh":6,"description":93,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":94,"categories":95,"keywords":96,"publishedAt":24},"01M6AC2ZANQQK8D1H01CB25BT4","linear","Use Symphony's `linear_graphql` client tool for raw Linear GraphQL\noperations such as comment editing and upload flows.","https:\u002F\u002Fgithub.com\u002Fopenai\u002Fsymphony\u002Fblob\u002Fmain\u002F.codex\u002Fskills\u002Flinear\u002FSKILL.md",[],[92],{"skillNo":98,"name":99,"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":103,"publishedAt":24},"01M6AC2XX3Z4NEEYM5S37JWEGN","land","Land a PR by monitoring conflicts, resolving them, waiting for checks, and squash-merging when green; use when asked to land, merge, or shepherd a PR to completion.","https:\u002F\u002Fgithub.com\u002Fopenai\u002Fsymphony\u002Fblob\u002Fmain\u002F.codex\u002Fskills\u002Fland\u002FSKILL.md",[],[99,20,104],"pr",{"skillNo":106,"name":107,"nameZh":6,"description":108,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":109,"categories":110,"keywords":116,"publishedAt":24},"01M6AC2WGC091TYSE940VNE3X1","debug","Investigate stuck runs and execution failures by tracing Symphony and Codex logs with issue\u002Fsession identifiers; use when runs stall, retry repeatedly, or fail unexpectedly.","https:\u002F\u002Fgithub.com\u002Fopenai\u002Fsymphony\u002Fblob\u002Fmain\u002F.codex\u002Fskills\u002Fdebug\u002FSKILL.md",[111],{"categoryNo":112,"categoryName":113,"taxonomyType":114,"taxonomyTypeDesc":115},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[107,19],{"skillNo":118,"name":79,"nameZh":6,"description":119,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":120,"categories":121,"keywords":122,"publishedAt":24},"01M6AC2V1NHHM48NEPKJPWG3GE","Create a well-formed git commit from current changes using session history for rationale and summary; use when asked to commit, prepare a commit message, or finalize staged work.","https:\u002F\u002Fgithub.com\u002Fopenai\u002Fsymphony\u002Fblob\u002Fmain\u002F.codex\u002Fskills\u002Fcommit\u002FSKILL.md",[],[79,123,124,89,125,126],"commit message","git","git commit","prepare"]