[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71FT22TQ1ACMP0Y2GEZFX8T":3,"skill-same:01M71FT22TQ1ACMP0Y2GEZFX8T":76},{"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":26,"publishedAt":47,"linkOnly":48,"markdownContent":49,"markdownBody":50,"frontMatter":51,"refName":54,"commitSha":55,"skillDirectory":56,"forksCount":14,"repositoryHtmlUrl":57,"repositoryHomepageUrl":6,"ownerHtmlUrl":58,"ownerBlogUrl":59,"ownerDescription":60,"updatedAt":61,"install":62,"resources":75},"01M71FT22TQ1ACMP0Y2GEZFX8T","manage-upstream-pr",null,"ALWAYS invoke this skill when continuing an open pull request against a repository the operator does not control — answering review, publishing a revision, or reporting its current state. NEVER comment on or push to such a pull request without this skill.","outcomeeng\u002Fplugins","outcomeeng","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F257335685?v=4","01M71FRVRF36XYR3HRSCGFHK2R","Outcome Engineering","01M71FRVS4BZG17DWANFJ7EPNY",1,"MIT","https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Fcontribute\u002Fskills\u002Fmanage-upstream-pr\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000007","代码审查","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46],"manage","manage upstream pr","upstream","pr","show","when","invoke","number","URL","remote","get","open pull request","open","commit","never","fetch","ask","branch","gh pr","Bash","2026-11-10 10:12:30",false,"---\nname: manage-upstream-pr\ndescription: >-\n  ALWAYS invoke this skill when continuing an open pull request against a repository the operator does not control — answering review, publishing a revision, or reporting its current state.\n  NEVER comment on or push to such a pull request without this skill.\nargument-hint: \"[pull request number or URL]\"\nallowed-tools: Read, Write, {{! tool('use_skill') !}},{!% if target == 'claude' %!} Agent,{!% else %!} {{! tool('spawn_agent') !}}, {{! tool('wait_agent') !}},{!% endif %!} {{! tool('ask_user') !}}, Bash(git remote get-url origin), Bash(gh repo view:*), Bash(git status --porcelain), Bash(gh pr view:*), Bash(gh pr list:*), Bash(gh pr comment:*), Bash(gh api repos\u002F*\u002Fpulls\u002F*\u002Fcomments:*), Bash(gh api user:*), Bash(git fetch:*), Bash(git switch:*), Bash(git rev-list:*), Bash(git branch --show-current), Bash(git add:*), Bash(git commit:*), Bash(git push origin HEAD:refs\u002Fheads\u002F*)\n---\n\n\u003Cobjective>\nEvery valid review finding answered in the head branch, and — when any finding needed a disposition — one comment on the open pull request stating what changed.\n\u003C\u002Fobjective>\n\n\u003Cworkflow>\n\n**Step 1 — Load the standards and resolve the pull request.** {!% require_skill 'contribute:contribution-standards' %!}\n\n`$ARGUMENTS` is a pull-request number or URL. A bare number is the number; a URL's trailing path segment is the number. Both the URL check and the empty-input lookup need the resolved base, so Step 2 settles them.\n\n**Step 2 — Establish the target, then the pull request.** Read the live `\u003CUPSTREAM_TARGET>` marker; invoke `\u002Fupstream` when none is live. A classification other than `upstream-contribution` means this pull request does not belong to this flow; stop and report the classification and `detail` verbatim.\n\nWith `base` resolved, settle the number. A URL's `owner\u002Fname` segments must equal that `base`; a mismatch stops the flow rather than being reconciled. When `$ARGUMENTS` is empty, look the pull request up for the current branch and stop when none exists:\n\n```bash\ngh pr list --repo \"\u003Cbase>\" --head \"$(git branch --show-current)\" --limit 100 --json number,headRefName,headRepository,headRepositoryOwner\n```\n\nThe list is bounded at 100 pull requests. When it returns 100 entries it fills its bound and cannot show whether more match, so stop and report the blocked lookup with the bound `100 pull requests` instead of selecting from a partial list.\n\n`--head` filters by branch name only — `gh` does not accept `\u003Cowner>:\u003Cbranch>` there — so two forks carrying the same branch name both match. Select the entry whose `headRepositoryOwner` and `headRepository` equal the resolved `head`, and stop when none does rather than taking the first.\n\n**Step 3 — Read current state once.** Substitute the resolved values literally per `\u002Fcontribution-standards` `\u003Cresolution>`:\n\n```bash\ngh pr view \"\u003Cnumber>\" --repo \"\u003Cbase>\" --json state,isDraft,reviewDecision,mergeStateStatus,statusCheckRollup,comments,reviews,author,title,headRefName,headRepository,headRepositoryOwner,url\n```\n\n`author` and `title` are read here because Step 4 gates on them, and this is the one read of the pull request this pass performs.\n\nRead review threads through the API when line-anchored comments matter, because `gh pr view` carries the PR-level conversation and not the comments tied to a file and line:\n\n```bash\ngh api repos\u002F\"\u003Cbase>\"\u002Fpulls\u002F\"\u003Cnumber>\"\u002Fcomments --method GET -F per_page=100 -F page=\u003Cpage> --jq '.[] | {user: .user.login, in_reply_to_id, path, line, body}'\n```\n\nRead page 1 to at most page 10 at 100 comments per page, and stop at the first page that returns fewer than 100. A tenth page that returns 100 comments fills its bound and cannot show whether more comments remain, so stop and report the blocked read with the bound `100 comments per page, 10 pages` instead of selecting findings from a partial read.\n\nThat endpoint returns every line-anchored comment on the pull request, not only a reviewer's. Keeping `user` and `in_reply_to_id` is what separates the three kinds it mixes: a maintainer's finding, a reply this flow posted on an earlier pass, and a line comment from anyone else. Dropping them leaves Step 5 rereading its own answers as new findings and re-fixing what it already fixed, pass after pass, on a repository the operator does not control. Read the authenticated login, which is the side of that comparison the pull request does not supply — Step 4 gates on it too, and this is the read both use:\n\n```bash\ngh api user --jq '.login'\n```\n\nTake as findings the comments carrying no `in_reply_to_id` from a login other than that one, and read the rest as the thread around them.\n\nRead the state one time — a maintainer answers on their own schedule, and `\u002Fcontribution-standards` forbids polling, watching, and sleeping on the artifact. The pages of the review-thread comments read, up to the bound above, are one read of that surface.\n\nReport `state`, `reviewDecision`, and each required check's conclusion verbatim. `reviewDecision` stays `CHANGES_REQUESTED` until the maintainer looks again; nothing on the contributor's side clears it, and that is not a defect to work around.\n\n**STOP when `state` is `CLOSED` or `MERGED`.** Report that outcome and return. This gate precedes every later step, because a management pass on a finished pull request would otherwise fix findings, push, and post a reply to a thread nobody is going to act on.\n\n**STOP when `headRepositoryOwner`\u002F`headRepository` do not equal the resolved `head`.** A number or URL names a pull request from any fork, and Step 6 pushes this checkout's `HEAD`; without this check a fix reaches an unrelated fork's branch while the reply claims this pull request was revised.\n\n**STOP when there is no finding to verify.** A state-only invocation, and a first pass on a pull request nobody has reviewed yet, both end here: report what Step 3 read and return. Every command from Step 4 onward moves this checkout's branch or writes to the base repository, and neither is something a request to read state asked for.\n\n**Step 4 — GATE: Establish that this artifact is the operator's, then take its branch.** Compare `author.login` from the Step 3 read against the login that read reported; those two fields are the whole comparison.\n\nA pull request the operator opened is the artifact they already authorized, and a revision continues it. One anyone else opened — a collaborator on the same organization fork reaches this flow through an explicit number or URL, and the head-repository check above passes for them — is an unrelated artifact: `\u002Fcontribution-standards` `\u003Cinvariants>` \"Authorization covers the artifact and its revisions\" gives it its own in-turn authorization, so present through the runtime's structured-question tool the resolved `base`, the pull-request number and title, its author, and the choice to revise it or to stop. Take no branch and write nothing until the operator authorizes it in this turn.\n\nThis gate precedes the checkout below, and not only Step 6's push. The checkout resets a local branch, and a reset performed for someone else's pull request is already a change to the operator's own worktree.\n\nWith that settled, check out `headRefName`, so the branch being fixed is the branch the pull request carries. That fetch reads through `origin`, so verify `origin` first per `\u002Fcontribution-standards` `\u003Cresolution>` \"Verify `origin` before pushing or fetching through it\" — a remote name is a local label, and an `origin` pointing elsewhere fetches a same-named branch from an unrelated repository:\n\n```bash\ngh repo view \"$(git remote get-url origin)\" --json nameWithOwner --jq '.nameWithOwner'\n```\n\n**STOP when that does not equal the resolved `head`.**\n\nTwo conditions must hold before the branch moves. The checkout must carry no uncommitted work, because the reset below takes those edits onto the pull request's branch, where Step 5 reproduces findings against them and Step 6 can commit one that overlaps a fixed path:\n\n```bash\ngit status --porcelain\ngit fetch origin \"\u003CheadRefName>\"\ngit rev-list --count FETCH_HEAD..refs\u002Fheads\u002F\"\u003CheadRefName>\"\n```\n\n**STOP when `git status --porcelain` prints anything.** Report the paths; committing or setting aside someone's in-progress work is theirs to decide, not this flow's.\n\nThe third command runs only when that branch already exists locally, and its count is the commits the local branch carries that the fetched pull-request tip does not. **STOP when the count is not zero**: those commits are work the pull request has never seen, and the next command discards them.\n\nWith a clean tree and nothing unpushed to lose, base the branch on the fetched tip:\n\n```bash\ngit switch -C \"\u003CheadRefName>\" FETCH_HEAD\n```\n\n`-C` is required. Plain `git switch` selects an existing local branch without moving it, so a branch left behind from an earlier pass verifies Step 5's findings against stale code and Step 6's push is rejected as non-fast-forward. An invocation already sitting on that branch still runs this, because Step 6 pushes `HEAD`.\n\n**Step 5 — GATE: Verify each finding before fixing it.** Reproduce the finding against the branch and report which findings confirmed. A finding the branch does not exhibit is answered with the evidence rather than with a change.\n\n**Step 6 — Fix, commit, verify, append.** Apply every confirmed finding as a defect class: fix the cited site and every parallel instance the same rule reaches. Re-run the base repository's declared checks per `\u002Fcontribution-standards`. Editing those files and running those checks are both discovered work rather than commands this skill can name, so they proceed per `\u002Fcontribution-standards` `\u003Ccapability_scope>`.\n\n**When no finding produced a change, skip to Step 7.** A pass where every finding failed reproduction reaches this step with nothing to commit. `git commit` with no staged change exits non-zero, which would strand the evidence Step 7 owes the maintainer for the findings that did not reproduce. There is nothing to push either — the pull request already carries what it carried.\n\nCommit the fixes before pushing. A push transfers commits, so an uncommitted fix leaves the pull request exactly as the maintainer left it while Step 7 posts a reply announcing a revision that is not there:\n\n```bash\ngit add \u003Cfixed-paths>\ngit commit -m \"\u003Cmessage in the base repository's commit style>\"\ngit push origin HEAD:refs\u002Fheads\u002F\"$(git branch --show-current)\"\n```\n\n`git commit` takes its message on the command line. Bare `git commit` opens an editor, and no step here runs on a terminal that can answer one.\n\nConfirm the pull request carries the pushed commit before continuing to Step 7. `git commit` reported the new commit and `git push` reports the ref update it performed; `Everything up-to-date` means it moved nothing. Then read what the pull request itself now points at:\n\n```bash\ngh pr view \"\u003Cnumber>\" --repo \"\u003Cbase>\" --json headRefOid --jq '.headRefOid'\n```\n\nStop when it does not equal the commit just pushed. Step 7 would otherwise announce a revision the pull request does not carry.\n\nThe push updates the open pull request in place and needs no fresh authorization beyond Step 4's, because it revises the artifact that gate established as the operator's. NEVER force-push a branch a reviewer has already read.\n\n**Step 7 — GATE: Review the reply, then post it.** A reply answers a review. A pass where every finding failed reproduction still reaches this step with a disposition to give, because the maintainer is owed the evidence for what did not reproduce.\n\nWith findings to answer, draft the comment per `\u003Creply_shape>` and review it per `\u002Fcontribution-standards` `\u003Cinvariants>` \"Outward-facing text is permanent\" — the prose plugin's `{{! subagent_name('prose', 'prose-auditor') !}}` thin agent where installed, `\u003Coutward_text>` unassisted where not.\n\nThe comment is a payload. Write it with the file-write tool to a file in the scratch directory the harness names for this session, under a file name unique to the agent and this pull request, then hand that file to `gh`. Where the harness names no scratch directory, use the one the environment designates, such as `$RUNNER_TEMP` on a hosted runner. Never remove it; the harness clears its scratch directory.\n\n```bash\ngh pr comment \"\u003Cnumber>\" --repo \"\u003Cbase>\" --body-file \"\u003Ccomment-file>\"\n```\n\n`--body-file \"\u003Ccomment-file>\"` delivers the comment with real newlines, whatever code spans, quotes, or shell text it carries; a heredoc, pipe, or inline argument is refused by the dangerous-command guard on such text.\n\nThat comment is the re-request. Requesting a reviewer is a maintainer-side action; `gh pr edit --add-reviewer` fails on a base the operator does not control, and the failure is the expected path.\n\n**Step 8 — Return.** Report the pull-request URL, the state read in Step 3, what changed, and what the maintainer has been asked to look at — or, on a pass Step 3 ended for having no finding to verify, what it read and that nothing needed a reply. Do not wait for the response.\n\n\u003C\u002Fworkflow>\n\n\u003Creply_shape>\n\nA reply answers the review. Structure it by finding:\n\n- Open with what was confirmed and, when a fix was pushed, what was pushed, in one line. A pass that changed nothing says what it verified, and claims no revision.\n- One section per finding, naming the finding and what changed. Quote the evidence rather than describing it.\n- A finding that did not reproduce gets the evidence that shows it did not, not an argument.\n- Close with what the maintainer is being asked to look at.\n\nCut every sentence about the contribution's own process — attempts made, time taken, lessons learned. Never characterize the maintainer's review as right or wrong; report what changed.\n\n\u003C\u002Freply_shape>\n\n\u003Cworked_example>\n\nOne reply on a fictional `acme\u002Fparser` pull request that makes the config file yield to `--strict`, to compare a draft against. Two line-anchored findings arrived, one confirmed and one did not:\n\n```text\nsrc\u002Fconfig.py:88  This still reads the flag before the file — same bug one level up.\nsrc\u002Fcli.py:12     --strict needs to be in the help text.\n```\n\nThe reply:\n\n```text\nConfirmed the precedence finding and pushed 9e1b330. The help-text finding did\nnot reproduce.\n\n**src\u002Fconfig.py:88 — flag read before file.** Confirmed. `merge_options` read\n`args.strict` ahead of `file_opts`, and `merge_flags` at src\u002Fconfig.py:141 had\nthe same order. Both read the file first now:\n\n$ printf 'strict: false\\n' > parser.yml\n$ parser --strict sample.txt; echo \"exit $?\"\nsample.txt:1:5: unexpected '='\nexit 1\n\n**src\u002Fcli.py:12 — --strict missing from help text.** Did not reproduce on this\nbranch:\n\n$ parser --help | grep -- --strict\n  --strict              Fail on any parse error\n\nThat line landed in 4f9c2a1, which this branch is based on.\n\nReady for another look at src\u002Fconfig.py.\n```\n\nThe opening line states what was confirmed and what was pushed, in that order, and claims one commit rather than \"the fixes\". The confirmed finding names the parallel instance at `src\u002Fconfig.py:141` that the same rule reached, because Step 6 fixes a finding as a defect class rather than at its cited line. The unconfirmed finding receives the command output that shows it did not reproduce, with no argument about whether the reviewer misread. The close names one file for the maintainer to look at.\n\n\u003C\u002Fworked_example>\n\n\u003Cconstraints>\n\n- MUST read the pull request's state exactly once per invocation, the pages of its review-thread comments counting as one read, and return without waiting.\n- NEVER fix, commit, push, or comment when `state` is `CLOSED` or `MERGED`. Report that outcome and return; nobody is going to act on a reply to a finished pull request.\n- NEVER move the branch or push when `headRepositoryOwner`\u002F`headRepository` do not equal the resolved `head`. A number or URL names a pull request from any fork, and Step 6 pushes this checkout's `HEAD`.\n- MUST end the pass at Step 3 when it has no finding to verify. Every command from Step 4 onward moves this checkout's branch or writes to the base repository, and a state-only invocation asked for neither.\n- MUST compare the pull request's `author.login` against the authenticated login before Step 4's checkout, and obtain authorization in the same turn for one the operator did not open. The head-repository check passes for every collaborator on that fork, so it is not evidence the artifact is the operator's.\n- MUST verify a finding against the branch before changing code for it.\n- MUST confirm `origin` resolves to the resolved head before the Step 4 fetch, not only before the Step 6 push. The fetch reads through `origin` too, and the reset that follows it moves the branch to whatever that fetch returned.\n- MUST require a clean working tree before the Step 4 reset, and commit nothing the operator left in progress.\n- NEVER commit or push when no confirmed finding produced a change; Step 7 still owes the maintainer the evidence for what did not reproduce.\n- NEVER post a comment when the pass had no finding to answer at all — a state-only invocation, or a handoff on a pull request nobody has reviewed yet, returns what Step 3 read and writes nothing.\n- MUST name the base repository with `--repo` on every `gh` write.\n- NEVER force-push the head branch. The `Bash(git push origin HEAD:refs\u002Fheads\u002F*)` grant matches by prefix, so it admits `--force` and `--force-with-lease` too; this constraint is the whole containment for those flags.\n- NEVER pass `--force` or `--discard-changes` to `git switch`. The `Bash(git switch:*)` grant matches by prefix and admits both, and either one drops uncommitted work in the invocation checkout. `-C` moves the branch pointer and is required by Step 4; neither of those flags is.\n- NEVER run the `-C` reset before the commit count proves the local branch carries nothing the fetched tip lacks. `-C` moves the branch to `FETCH_HEAD`, so a local commit the pull request has not seen is lost without that check.\n- NEVER stage by wildcard. The `Bash(git add:*)` grant matches by prefix, so it admits `-A` and `.`, either of which sweeps unrelated work in the invocation checkout into a commit destined for someone else's repository. Name the fixed paths.\n- NEVER pass `--no-verify` to `git commit`. The `Bash(git commit:*)` grant matches by prefix and admits it. Hooks run from this checkout's own configuration, which conforming to the base repository's conventions is what installs, so skipping them drops part of the verification `\u002Fcontribution-standards` requires. No hook being configured right now is not a reason to pass the flag.\n- MUST keep `user` and `in_reply_to_id` in the review-thread projection, and select findings from them. A projection that drops either one cannot tell a maintainer's finding from a reply this flow already posted, so Step 5 re-fixes what it fixed on the previous pass.\n- MUST read `gh api user` only for the reply-selection and Step 4 authorship comparisons. `\u002Fcontribution-standards` `\u003Cinvariants>` \"Establish permission from the API\" rules the authenticated account out as evidence of permission on the base; it is evidence of identity and nothing else.\n- NEVER pass `-X` or `--method` with any method other than `GET` to `gh api` — the `Bash(gh api repos\u002F*\u002Fpulls\u002F*\u002Fcomments:*)` and `Bash(gh api user:*)` grants exist to read review threads and the authenticated login, and matching by prefix they admit every verb: `-X POST` creates a review comment outside Step 7's flow, and `-X PATCH` and `-X DELETE` rewrite or remove a maintainer's comment and reach the operator's own GitHub account. The bounded review-thread read passes `--method GET` explicitly, because `gh api` sends a POST when `-F` parameters are present and no method is given. Read only.\n- NEVER pass `--edit-last` or `--delete-last` to `gh pr comment`. The `Bash(gh pr comment:*)` grant matches by prefix and admits both, and either one rewrites or removes a comment a reviewer may already have read. `\u002Fcontribution-standards` `\u003Cinvariants>` \"Iterate by appending\" is the rule; this constraint is its containment here.\n- NEVER pass the reply through a heredoc, a pipe, or an inline argument, and NEVER remove the comment file.\n- NEVER call `gh pr edit --add-reviewer`, `gh pr review`, or any maintainer-side action against a base the operator does not control.\n- NEVER treat `reviewDecision: CHANGES_REQUESTED` as a state the contributor can clear.\n\n\u003C\u002Fconstraints>\n\n\u003Cfailure_modes>\n\n**A structural permission failure was retried.** Claude ran `gh pr edit --add-reviewer` after pushing fixes, read `does not have the correct permissions to execute RequestReviewsByLogin`, and retried it. The call fails on every base the operator does not control. Post the comment stating what changed and stop.\n\n**A gate was described before it existed.** Claude fetched the pull request's head branch through `origin` because Step 3 said the remote had been \"confirmed above\". That confirmation sat two steps later, so the fetch and the reset that moved the branch to whatever it returned both ran on an unverified remote label. Place a gate before the command it protects, and state it there rather than asserting elsewhere that it already happened.\n\n**A request to read state moved the operator's branch.** Claude answered an invocation asking only what the pull request currently says by fetching, resetting a local branch to the fetched tip, and leaving the checkout on it — the head-branch checkout sat inside the state read. Nothing was written to the base repository and the pass still looked successful. Read state, then end the pass before the first command that moves the branch when there is no finding to verify.\n\n**A finding was fixed without being reproduced.** Claude read a review comment, changed the cited line, and pushed. The finding described a case the branch did not exhibit, so the change answered nothing and added a diff the maintainer had to review. Reproduce first, then fix what confirmed.\n\n\u003C\u002Ffailure_modes>\n\n\u003Csuccess_criteria>\n\n- The `\u003CUPSTREAM_TARGET>` marker read for this pass carries `classification=\"upstream-contribution\"`, established before any write.\n- The pull request's state was read once, its review-thread comments counting as one read across their pages, and `state`, `reviewDecision`, and each required check's conclusion appear verbatim.\n- A pull request list that returned 100 entries, or a tenth page of review-thread comments that returned 100 comments, ended the pass as the blocked lookup or read, naming the bound `100 pull requests` or `100 comments per page, 10 pages`, and selected nothing from the partial result.\n- A `state` of `CLOSED` or `MERGED`, a head repository other than the resolved `head`, and a pass with no finding to verify each returned what Step 3 read, left this checkout's branch where it was, and wrote nothing; every criterion below covers a pass that continued.\n- The pull request's `author.login` was compared against the authenticated login before the branch moved, and one the operator did not open was authorized in that turn.\n- The review-thread read kept each comment's author and reply parent, and the findings it selected exclude every reply this flow posted on an earlier pass.\n- Every confirmed finding is fixed as a defect class, and the Step 7 comment carries one disposition per finding Step 5 verified — what changed for a confirmed one, the evidence for an unconfirmed one — so re-reading the posted comment against the review accounts for every finding.\n- The base repository's declared checks ran on the revised branch and reported success.\n- `origin` was confirmed to be the resolved head and the working tree was clean before the head branch was reset to the fetched tip.\n- A revision reached the head branch by appending, never by force-push, and the pull request's `headRefOid` equals the commit that was pushed; a pass that changed nothing committed and pushed nothing.\n- A pass carrying findings posted one comment, after a prose review, stating what changed and standing as the re-request, which arrived from a scratch file through `--body-file`; a pass with no finding to answer posted none.\n- The pass returned without polling, watching, or sleeping.\n\n\u003C\u002Fsuccess_criteria>\n","\u003Cobjective>\nEvery valid review finding answered in the head branch, and — when any finding needed a disposition — one comment on the open pull request stating what changed.\n\u003C\u002Fobjective>\n\n\u003Cworkflow>\n\n**Step 1 — Load the standards and resolve the pull request.** {!% require_skill 'contribute:contribution-standards' %!}\n\n`$ARGUMENTS` is a pull-request number or URL. A bare number is the number; a URL's trailing path segment is the number. Both the URL check and the empty-input lookup need the resolved base, so Step 2 settles them.\n\n**Step 2 — Establish the target, then the pull request.** Read the live `\u003CUPSTREAM_TARGET>` marker; invoke `\u002Fupstream` when none is live. A classification other than `upstream-contribution` means this pull request does not belong to this flow; stop and report the classification and `detail` verbatim.\n\nWith `base` resolved, settle the number. A URL's `owner\u002Fname` segments must equal that `base`; a mismatch stops the flow rather than being reconciled. When `$ARGUMENTS` is empty, look the pull request up for the current branch and stop when none exists:\n\n```bash\ngh pr list --repo \"\u003Cbase>\" --head \"$(git branch --show-current)\" --limit 100 --json number,headRefName,headRepository,headRepositoryOwner\n```\n\nThe list is bounded at 100 pull requests. When it returns 100 entries it fills its bound and cannot show whether more match, so stop and report the blocked lookup with the bound `100 pull requests` instead of selecting from a partial list.\n\n`--head` filters by branch name only — `gh` does not accept `\u003Cowner>:\u003Cbranch>` there — so two forks carrying the same branch name both match. Select the entry whose `headRepositoryOwner` and `headRepository` equal the resolved `head`, and stop when none does rather than taking the first.\n\n**Step 3 — Read current state once.** Substitute the resolved values literally per `\u002Fcontribution-standards` `\u003Cresolution>`:\n\n```bash\ngh pr view \"\u003Cnumber>\" --repo \"\u003Cbase>\" --json state,isDraft,reviewDecision,mergeStateStatus,statusCheckRollup,comments,reviews,author,title,headRefName,headRepository,headRepositoryOwner,url\n```\n\n`author` and `title` are read here because Step 4 gates on them, and this is the one read of the pull request this pass performs.\n\nRead review threads through the API when line-anchored comments matter, because `gh pr view` carries the PR-level conversation and not the comments tied to a file and line:\n\n```bash\ngh api repos\u002F\"\u003Cbase>\"\u002Fpulls\u002F\"\u003Cnumber>\"\u002Fcomments --method GET -F per_page=100 -F page=\u003Cpage> --jq '.[] | {user: .user.login, in_reply_to_id, path, line, body}'\n```\n\nRead page 1 to at most page 10 at 100 comments per page, and stop at the first page that returns fewer than 100. A tenth page that returns 100 comments fills its bound and cannot show whether more comments remain, so stop and report the blocked read with the bound `100 comments per page, 10 pages` instead of selecting findings from a partial read.\n\nThat endpoint returns every line-anchored comment on the pull request, not only a reviewer's. Keeping `user` and `in_reply_to_id` is what separates the three kinds it mixes: a maintainer's finding, a reply this flow posted on an earlier pass, and a line comment from anyone else. Dropping them leaves Step 5 rereading its own answers as new findings and re-fixing what it already fixed, pass after pass, on a repository the operator does not control. Read the authenticated login, which is the side of that comparison the pull request does not supply — Step 4 gates on it too, and this is the read both use:\n\n```bash\ngh api user --jq '.login'\n```\n\nTake as findings the comments carrying no `in_reply_to_id` from a login other than that one, and read the rest as the thread around them.\n\nRead the state one time — a maintainer answers on their own schedule, and `\u002Fcontribution-standards` forbids polling, watching, and sleeping on the artifact. The pages of the review-thread comments read, up to the bound above, are one read of that surface.\n\nReport `state`, `reviewDecision`, and each required check's conclusion verbatim. `reviewDecision` stays `CHANGES_REQUESTED` until the maintainer looks again; nothing on the contributor's side clears it, and that is not a defect to work around.\n\n**STOP when `state` is `CLOSED` or `MERGED`.** Report that outcome and return. This gate precedes every later step, because a management pass on a finished pull request would otherwise fix findings, push, and post a reply to a thread nobody is going to act on.\n\n**STOP when `headRepositoryOwner`\u002F`headRepository` do not equal the resolved `head`.** A number or URL names a pull request from any fork, and Step 6 pushes this checkout's `HEAD`; without this check a fix reaches an unrelated fork's branch while the reply claims this pull request was revised.\n\n**STOP when there is no finding to verify.** A state-only invocation, and a first pass on a pull request nobody has reviewed yet, both end here: report what Step 3 read and return. Every command from Step 4 onward moves this checkout's branch or writes to the base repository, and neither is something a request to read state asked for.\n\n**Step 4 — GATE: Establish that this artifact is the operator's, then take its branch.** Compare `author.login` from the Step 3 read against the login that read reported; those two fields are the whole comparison.\n\nA pull request the operator opened is the artifact they already authorized, and a revision continues it. One anyone else opened — a collaborator on the same organization fork reaches this flow through an explicit number or URL, and the head-repository check above passes for them — is an unrelated artifact: `\u002Fcontribution-standards` `\u003Cinvariants>` \"Authorization covers the artifact and its revisions\" gives it its own in-turn authorization, so present through the runtime's structured-question tool the resolved `base`, the pull-request number and title, its author, and the choice to revise it or to stop. Take no branch and write nothing until the operator authorizes it in this turn.\n\nThis gate precedes the checkout below, and not only Step 6's push. The checkout resets a local branch, and a reset performed for someone else's pull request is already a change to the operator's own worktree.\n\nWith that settled, check out `headRefName`, so the branch being fixed is the branch the pull request carries. That fetch reads through `origin`, so verify `origin` first per `\u002Fcontribution-standards` `\u003Cresolution>` \"Verify `origin` before pushing or fetching through it\" — a remote name is a local label, and an `origin` pointing elsewhere fetches a same-named branch from an unrelated repository:\n\n```bash\ngh repo view \"$(git remote get-url origin)\" --json nameWithOwner --jq '.nameWithOwner'\n```\n\n**STOP when that does not equal the resolved `head`.**\n\nTwo conditions must hold before the branch moves. The checkout must carry no uncommitted work, because the reset below takes those edits onto the pull request's branch, where Step 5 reproduces findings against them and Step 6 can commit one that overlaps a fixed path:\n\n```bash\ngit status --porcelain\ngit fetch origin \"\u003CheadRefName>\"\ngit rev-list --count FETCH_HEAD..refs\u002Fheads\u002F\"\u003CheadRefName>\"\n```\n\n**STOP when `git status --porcelain` prints anything.** Report the paths; committing or setting aside someone's in-progress work is theirs to decide, not this flow's.\n\nThe third command runs only when that branch already exists locally, and its count is the commits the local branch carries that the fetched pull-request tip does not. **STOP when the count is not zero**: those commits are work the pull request has never seen, and the next command discards them.\n\nWith a clean tree and nothing unpushed to lose, base the branch on the fetched tip:\n\n```bash\ngit switch -C \"\u003CheadRefName>\" FETCH_HEAD\n```\n\n`-C` is required. Plain `git switch` selects an existing local branch without moving it, so a branch left behind from an earlier pass verifies Step 5's findings against stale code and Step 6's push is rejected as non-fast-forward. An invocation already sitting on that branch still runs this, because Step 6 pushes `HEAD`.\n\n**Step 5 — GATE: Verify each finding before fixing it.** Reproduce the finding against the branch and report which findings confirmed. A finding the branch does not exhibit is answered with the evidence rather than with a change.\n\n**Step 6 — Fix, commit, verify, append.** Apply every confirmed finding as a defect class: fix the cited site and every parallel instance the same rule reaches. Re-run the base repository's declared checks per `\u002Fcontribution-standards`. Editing those files and running those checks are both discovered work rather than commands this skill can name, so they proceed per `\u002Fcontribution-standards` `\u003Ccapability_scope>`.\n\n**When no finding produced a change, skip to Step 7.** A pass where every finding failed reproduction reaches this step with nothing to commit. `git commit` with no staged change exits non-zero, which would strand the evidence Step 7 owes the maintainer for the findings that did not reproduce. There is nothing to push either — the pull request already carries what it carried.\n\nCommit the fixes before pushing. A push transfers commits, so an uncommitted fix leaves the pull request exactly as the maintainer left it while Step 7 posts a reply announcing a revision that is not there:\n\n```bash\ngit add \u003Cfixed-paths>\ngit commit -m \"\u003Cmessage in the base repository's commit style>\"\ngit push origin HEAD:refs\u002Fheads\u002F\"$(git branch --show-current)\"\n```\n\n`git commit` takes its message on the command line. Bare `git commit` opens an editor, and no step here runs on a terminal that can answer one.\n\nConfirm the pull request carries the pushed commit before continuing to Step 7. `git commit` reported the new commit and `git push` reports the ref update it performed; `Everything up-to-date` means it moved nothing. Then read what the pull request itself now points at:\n\n```bash\ngh pr view \"\u003Cnumber>\" --repo \"\u003Cbase>\" --json headRefOid --jq '.headRefOid'\n```\n\nStop when it does not equal the commit just pushed. Step 7 would otherwise announce a revision the pull request does not carry.\n\nThe push updates the open pull request in place and needs no fresh authorization beyond Step 4's, because it revises the artifact that gate established as the operator's. NEVER force-push a branch a reviewer has already read.\n\n**Step 7 — GATE: Review the reply, then post it.** A reply answers a review. A pass where every finding failed reproduction still reaches this step with a disposition to give, because the maintainer is owed the evidence for what did not reproduce.\n\nWith findings to answer, draft the comment per `\u003Creply_shape>` and review it per `\u002Fcontribution-standards` `\u003Cinvariants>` \"Outward-facing text is permanent\" — the prose plugin's `{{! subagent_name('prose', 'prose-auditor') !}}` thin agent where installed, `\u003Coutward_text>` unassisted where not.\n\nThe comment is a payload. Write it with the file-write tool to a file in the scratch directory the harness names for this session, under a file name unique to the agent and this pull request, then hand that file to `gh`. Where the harness names no scratch directory, use the one the environment designates, such as `$RUNNER_TEMP` on a hosted runner. Never remove it; the harness clears its scratch directory.\n\n```bash\ngh pr comment \"\u003Cnumber>\" --repo \"\u003Cbase>\" --body-file \"\u003Ccomment-file>\"\n```\n\n`--body-file \"\u003Ccomment-file>\"` delivers the comment with real newlines, whatever code spans, quotes, or shell text it carries; a heredoc, pipe, or inline argument is refused by the dangerous-command guard on such text.\n\nThat comment is the re-request. Requesting a reviewer is a maintainer-side action; `gh pr edit --add-reviewer` fails on a base the operator does not control, and the failure is the expected path.\n\n**Step 8 — Return.** Report the pull-request URL, the state read in Step 3, what changed, and what the maintainer has been asked to look at — or, on a pass Step 3 ended for having no finding to verify, what it read and that nothing needed a reply. Do not wait for the response.\n\n\u003C\u002Fworkflow>\n\n\u003Creply_shape>\n\nA reply answers the review. Structure it by finding:\n\n- Open with what was confirmed and, when a fix was pushed, what was pushed, in one line. A pass that changed nothing says what it verified, and claims no revision.\n- One section per finding, naming the finding and what changed. Quote the evidence rather than describing it.\n- A finding that did not reproduce gets the evidence that shows it did not, not an argument.\n- Close with what the maintainer is being asked to look at.\n\nCut every sentence about the contribution's own process — attempts made, time taken, lessons learned. Never characterize the maintainer's review as right or wrong; report what changed.\n\n\u003C\u002Freply_shape>\n\n\u003Cworked_example>\n\nOne reply on a fictional `acme\u002Fparser` pull request that makes the config file yield to `--strict`, to compare a draft against. Two line-anchored findings arrived, one confirmed and one did not:\n\n```text\nsrc\u002Fconfig.py:88  This still reads the flag before the file — same bug one level up.\nsrc\u002Fcli.py:12     --strict needs to be in the help text.\n```\n\nThe reply:\n\n```text\nConfirmed the precedence finding and pushed 9e1b330. The help-text finding did\nnot reproduce.\n\n**src\u002Fconfig.py:88 — flag read before file.** Confirmed. `merge_options` read\n`args.strict` ahead of `file_opts`, and `merge_flags` at src\u002Fconfig.py:141 had\nthe same order. Both read the file first now:\n\n$ printf 'strict: false\\n' > parser.yml\n$ parser --strict sample.txt; echo \"exit $?\"\nsample.txt:1:5: unexpected '='\nexit 1\n\n**src\u002Fcli.py:12 — --strict missing from help text.** Did not reproduce on this\nbranch:\n\n$ parser --help | grep -- --strict\n  --strict              Fail on any parse error\n\nThat line landed in 4f9c2a1, which this branch is based on.\n\nReady for another look at src\u002Fconfig.py.\n```\n\nThe opening line states what was confirmed and what was pushed, in that order, and claims one commit rather than \"the fixes\". The confirmed finding names the parallel instance at `src\u002Fconfig.py:141` that the same rule reached, because Step 6 fixes a finding as a defect class rather than at its cited line. The unconfirmed finding receives the command output that shows it did not reproduce, with no argument about whether the reviewer misread. The close names one file for the maintainer to look at.\n\n\u003C\u002Fworked_example>\n\n\u003Cconstraints>\n\n- MUST read the pull request's state exactly once per invocation, the pages of its review-thread comments counting as one read, and return without waiting.\n- NEVER fix, commit, push, or comment when `state` is `CLOSED` or `MERGED`. Report that outcome and return; nobody is going to act on a reply to a finished pull request.\n- NEVER move the branch or push when `headRepositoryOwner`\u002F`headRepository` do not equal the resolved `head`. A number or URL names a pull request from any fork, and Step 6 pushes this checkout's `HEAD`.\n- MUST end the pass at Step 3 when it has no finding to verify. Every command from Step 4 onward moves this checkout's branch or writes to the base repository, and a state-only invocation asked for neither.\n- MUST compare the pull request's `author.login` against the authenticated login before Step 4's checkout, and obtain authorization in the same turn for one the operator did not open. The head-repository check passes for every collaborator on that fork, so it is not evidence the artifact is the operator's.\n- MUST verify a finding against the branch before changing code for it.\n- MUST confirm `origin` resolves to the resolved head before the Step 4 fetch, not only before the Step 6 push. The fetch reads through `origin` too, and the reset that follows it moves the branch to whatever that fetch returned.\n- MUST require a clean working tree before the Step 4 reset, and commit nothing the operator left in progress.\n- NEVER commit or push when no confirmed finding produced a change; Step 7 still owes the maintainer the evidence for what did not reproduce.\n- NEVER post a comment when the pass had no finding to answer at all — a state-only invocation, or a handoff on a pull request nobody has reviewed yet, returns what Step 3 read and writes nothing.\n- MUST name the base repository with `--repo` on every `gh` write.\n- NEVER force-push the head branch. The `Bash(git push origin HEAD:refs\u002Fheads\u002F*)` grant matches by prefix, so it admits `--force` and `--force-with-lease` too; this constraint is the whole containment for those flags.\n- NEVER pass `--force` or `--discard-changes` to `git switch`. The `Bash(git switch:*)` grant matches by prefix and admits both, and either one drops uncommitted work in the invocation checkout. `-C` moves the branch pointer and is required by Step 4; neither of those flags is.\n- NEVER run the `-C` reset before the commit count proves the local branch carries nothing the fetched tip lacks. `-C` moves the branch to `FETCH_HEAD`, so a local commit the pull request has not seen is lost without that check.\n- NEVER stage by wildcard. The `Bash(git add:*)` grant matches by prefix, so it admits `-A` and `.`, either of which sweeps unrelated work in the invocation checkout into a commit destined for someone else's repository. Name the fixed paths.\n- NEVER pass `--no-verify` to `git commit`. The `Bash(git commit:*)` grant matches by prefix and admits it. Hooks run from this checkout's own configuration, which conforming to the base repository's conventions is what installs, so skipping them drops part of the verification `\u002Fcontribution-standards` requires. No hook being configured right now is not a reason to pass the flag.\n- MUST keep `user` and `in_reply_to_id` in the review-thread projection, and select findings from them. A projection that drops either one cannot tell a maintainer's finding from a reply this flow already posted, so Step 5 re-fixes what it fixed on the previous pass.\n- MUST read `gh api user` only for the reply-selection and Step 4 authorship comparisons. `\u002Fcontribution-standards` `\u003Cinvariants>` \"Establish permission from the API\" rules the authenticated account out as evidence of permission on the base; it is evidence of identity and nothing else.\n- NEVER pass `-X` or `--method` with any method other than `GET` to `gh api` — the `Bash(gh api repos\u002F*\u002Fpulls\u002F*\u002Fcomments:*)` and `Bash(gh api user:*)` grants exist to read review threads and the authenticated login, and matching by prefix they admit every verb: `-X POST` creates a review comment outside Step 7's flow, and `-X PATCH` and `-X DELETE` rewrite or remove a maintainer's comment and reach the operator's own GitHub account. The bounded review-thread read passes `--method GET` explicitly, because `gh api` sends a POST when `-F` parameters are present and no method is given. Read only.\n- NEVER pass `--edit-last` or `--delete-last` to `gh pr comment`. The `Bash(gh pr comment:*)` grant matches by prefix and admits both, and either one rewrites or removes a comment a reviewer may already have read. `\u002Fcontribution-standards` `\u003Cinvariants>` \"Iterate by appending\" is the rule; this constraint is its containment here.\n- NEVER pass the reply through a heredoc, a pipe, or an inline argument, and NEVER remove the comment file.\n- NEVER call `gh pr edit --add-reviewer`, `gh pr review`, or any maintainer-side action against a base the operator does not control.\n- NEVER treat `reviewDecision: CHANGES_REQUESTED` as a state the contributor can clear.\n\n\u003C\u002Fconstraints>\n\n\u003Cfailure_modes>\n\n**A structural permission failure was retried.** Claude ran `gh pr edit --add-reviewer` after pushing fixes, read `does not have the correct permissions to execute RequestReviewsByLogin`, and retried it. The call fails on every base the operator does not control. Post the comment stating what changed and stop.\n\n**A gate was described before it existed.** Claude fetched the pull request's head branch through `origin` because Step 3 said the remote had been \"confirmed above\". That confirmation sat two steps later, so the fetch and the reset that moved the branch to whatever it returned both ran on an unverified remote label. Place a gate before the command it protects, and state it there rather than asserting elsewhere that it already happened.\n\n**A request to read state moved the operator's branch.** Claude answered an invocation asking only what the pull request currently says by fetching, resetting a local branch to the fetched tip, and leaving the checkout on it — the head-branch checkout sat inside the state read. Nothing was written to the base repository and the pass still looked successful. Read state, then end the pass before the first command that moves the branch when there is no finding to verify.\n\n**A finding was fixed without being reproduced.** Claude read a review comment, changed the cited line, and pushed. The finding described a case the branch did not exhibit, so the change answered nothing and added a diff the maintainer had to review. Reproduce first, then fix what confirmed.\n\n\u003C\u002Ffailure_modes>\n\n\u003Csuccess_criteria>\n\n- The `\u003CUPSTREAM_TARGET>` marker read for this pass carries `classification=\"upstream-contribution\"`, established before any write.\n- The pull request's state was read once, its review-thread comments counting as one read across their pages, and `state`, `reviewDecision`, and each required check's conclusion appear verbatim.\n- A pull request list that returned 100 entries, or a tenth page of review-thread comments that returned 100 comments, ended the pass as the blocked lookup or read, naming the bound `100 pull requests` or `100 comments per page, 10 pages`, and selected nothing from the partial result.\n- A `state` of `CLOSED` or `MERGED`, a head repository other than the resolved `head`, and a pass with no finding to verify each returned what Step 3 read, left this checkout's branch where it was, and wrote nothing; every criterion below covers a pass that continued.\n- The pull request's `author.login` was compared against the authenticated login before the branch moved, and one the operator did not open was authorized in that turn.\n- The review-thread read kept each comment's author and reply parent, and the findings it selected exclude every reply this flow posted on an earlier pass.\n- Every confirmed finding is fixed as a defect class, and the Step 7 comment carries one disposition per finding Step 5 verified — what changed for a confirmed one, the evidence for an unconfirmed one — so re-reading the posted comment against the review accounts for every finding.\n- The base repository's declared checks ran on the revised branch and reported success.\n- `origin` was confirmed to be the resolved head and the working tree was clean before the head branch was reset to the fetched tip.\n- A revision reached the head branch by appending, never by force-push, and the pull request's `headRefOid` equals the commit that was pushed; a pass that changed nothing committed and pushed nothing.\n- A pass carrying findings posted one comment, after a prose review, stating what changed and standing as the re-request, which arrived from a scratch file through `--body-file`; a pass with no finding to answer posted none.\n- The pass returned without polling, watching, or sleeping.\n\n\u003C\u002Fsuccess_criteria>\n",{"name":5,"description":7,"allowed-tools":52,"argument-hint":53},"Read, Write, {{! tool('use_skill') !}},{!% if target == 'claude' %!} Agent,{!% else %!} {{! tool('spawn_agent') !}}, {{! tool('wait_agent') !}},{!% endif %!} {{! tool('ask_user') !}}, Bash(git remote get-url origin), Bash(gh repo view:*), Bash(git status --porcelain), Bash(gh pr view:*), Bash(gh pr list:*), Bash(gh pr comment:*), Bash(gh api repos\u002F*\u002Fpulls\u002F*\u002Fcomments:*), Bash(gh api user:*), Bash(git fetch:*), Bash(git switch:*), Bash(git rev-list:*), Bash(git branch --show-current), Bash(git add:*), Bash(git commit:*), Bash(git push origin HEAD:refs\u002Fheads\u002F*)","[pull request number or URL]","main","978d51c51d68c99cffb2ba48f7cad9d2f07e5738","src\u002Fplugins\u002Fcontribute\u002Fskills\u002Fmanage-upstream-pr","https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins","https:\u002F\u002Fgithub.com\u002Foutcomeeng","https:\u002F\u002Foutcome.engineering","Spec-driven development for AI-assisted engineering","2026-11-11 22:17:26",{"source":8,"skillName":5,"commands":63,"prompt":73,"zipAvailable":74},[64,67,70],{"tool":65,"command":66},"npx","npx skills add outcomeeng\u002Fplugins --skill manage-upstream-pr",{"tool":68,"command":69},"bunx","bunx skills add outcomeeng\u002Fplugins --skill manage-upstream-pr",{"tool":71,"command":72},"pnpm","pnpm dlx skills add outcomeeng\u002Fplugins --skill manage-upstream-pr","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Fcontribute\u002Fskills\u002Fmanage-upstream-pr\u002FSKILL.md",true,[],[77,83,115,131,148,161],{"skillNo":78,"name":79,"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":80,"categories":81,"keywords":82,"publishedAt":47},"01M71G25RZTPQG9KJ00JCHC1F7","plugin","https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Ftemplates\u002Fplugin\u002FSKILL.md",[],[79],{"skillNo":84,"name":85,"nameZh":6,"description":86,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":87,"categories":88,"keywords":97,"publishedAt":47},"01M71G23DCX3SV60H63HBBKQ6J","sanitize-powerpoint","ALWAYS invoke this skill when sanitizing, cleaning up, auditing, or aligning a PowerPoint (.pptx) deck — slide-master and layout structure, layout type attributes, stray fonts, non-theme colors, or layout naming. NEVER hand-edit pptx XML without this skill.","https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Fwork\u002Fskills\u002Fsanitize-powerpoint\u002FSKILL.md",[89,92],{"categoryNo":90,"categoryName":91,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000003","演示文稿",{"categoryNo":93,"categoryName":94,"taxonomyType":95,"taxonomyTypeDesc":96},"01JBSEEDCAT000000000000034","行政与办公人员","PROFESSION","适用职业",[98,99,100,101,102,103,104,41,105,106,107,108,109,110,111,112,113,114,33,32],"sanitize powerpoint","powerpoint","sanitize","fonts","type","cleaning","structure","attributes","theme","pptx","naming","layout","deck","up","edit","xml","master",{"skillNo":116,"name":117,"nameZh":6,"description":118,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":119,"categories":120,"keywords":121,"publishedAt":47},"01M71G21PQKBCDECHGVYSKPJW5","draw-excalidraw","ALWAYS invoke this skill when creating Excalidraw diagrams, visualizing workflows, architectures, or concepts. NEVER generate Excalidraw JSON without this skill.","https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Fwork\u002Fskills\u002Fdraw-excalidraw\u002FSKILL.md",[],[122,123,124,125,126,41,33,127,128,32,129,130],"draw excalidraw","excalidraw","draw","diagrams","architectures","generate","workflows","concepts","json",{"skillNo":132,"name":133,"nameZh":6,"description":134,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":135,"categories":136,"keywords":140,"publishedAt":47},"01M71G1ZMNGFD37RZYM620XM2C","typescript-test-standards","TypeScript test standards enforced across all skills. Loaded by other skills, not invoked directly.","https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Ftypescript\u002Fskills\u002Ftypescript-test-standards\u002FSKILL.md",[137],{"categoryNo":138,"categoryName":139,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",[141,142,143,144,145,146,147],"typescript","typescript test standards","test","standards","false","read","across",{"skillNo":149,"name":150,"nameZh":6,"description":151,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":152,"categories":153,"keywords":157,"publishedAt":47},"01M71G1XBH0X1VCTR7269MDGSY","typescript-code-standards","TypeScript code standards enforced across all skills. Loaded by other skills, not invoked directly.","https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Ftypescript\u002Fskills\u002Ftypescript-code-standards\u002FSKILL.md",[154],{"categoryNo":155,"categoryName":156,"taxonomyType":95,"taxonomyTypeDesc":96},"01JBSEEDCAT000000000000030","开发工程师",[141,158,159,160,144,145,146,147],"code","typescript code standards","code standards",{"skillNo":162,"name":163,"nameZh":6,"description":164,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":165,"categories":166,"keywords":167,"publishedAt":47},"01M71G1TQ3VN45SJ75DFMJDB9W","typescript-architecture-standards","TypeScript ADR conventions enforced across architect and auditor skills. Loaded by other skills, not invoked directly.","https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Ftypescript\u002Fskills\u002Ftypescript-architecture-standards\u002FSKILL.md",[],[168,144,169,170,141,171,172,147,146,173,145,174],"architecture standards","typescript architecture standards","architecture","adr","architect","auditor","conventions"]