[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71FSYZSK2K3Y72FH60MSD73":3,"skill-same:01M71FSYZSK2K3Y72FH60MSD73":73},{"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":44,"linkOnly":45,"markdownContent":46,"markdownBody":47,"frontMatter":48,"refName":51,"commitSha":52,"skillDirectory":53,"forksCount":14,"repositoryHtmlUrl":54,"repositoryHomepageUrl":6,"ownerHtmlUrl":55,"ownerBlogUrl":56,"ownerDescription":57,"updatedAt":58,"install":59,"resources":72},"01M71FSYZSK2K3Y72FH60MSD73","manage-upstream-issue",null,"ALWAYS invoke this skill when continuing an open issue in a repository the operator does not control — answering a maintainer, adding evidence, or reporting the thread's current state. NEVER comment on or close an issue in such a repository 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-issue\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,43],"manage upstream issue","upstream","manage","issue","evidence","target","when","invoke","thread","number","current state","issue comment","issue close","never","use","view","gh","tool","open","gh issue","2026-11-10 10:12:30",false,"---\nname: manage-upstream-issue\ndescription: >-\n  ALWAYS invoke this skill when continuing an open issue in a repository the operator does not control — answering a maintainer, adding evidence, or reporting the thread's current state.\n  NEVER comment on or close an issue in such a repository without this skill.\nargument-hint: \"[issue 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(gh issue view:*), Bash(gh issue comment:*), Bash(gh issue close:*), Bash(gh api user:*)\n---\n\n\u003Cobjective>\nThe maintainer's question answered with evidence in one comment on the open issue, or that thread's state reported when it asked nothing.\n\u003C\u002Fobjective>\n\n\u003Cworkflow>\n\n**Step 1 — Load the standards and resolve the issue.** {!% require_skill 'contribute:contribution-standards' %!}\n\n`$ARGUMENTS` is an issue number or URL. A bare number is the number; a URL's trailing path segment is the number. An empty `$ARGUMENTS` stops the flow, because this skill continues an identified thread and never picks one. The URL check needs the resolved base, so Step 2 settles it.\n\n**Step 2 — Establish the target, then check the number.** Read the live `\u003CUPSTREAM_TARGET>` marker; invoke `\u002Fupstream` when none is live. `upstream-contribution`, `head-ambiguous`, and `fork-absent` all continue — a thread needs no head repository. `controlled` and `blocked` stop, reporting the classification and `detail` verbatim.\n\nWith `base` resolved, a URL's `owner\u002Fname` segments must equal it; a mismatch stops the flow rather than being reconciled.\n\n**Step 3 — Read the thread once.**\n\n```bash\ngh issue view \"\u003Cnumber>\" --repo \"\u003Cbase>\" --json state,title,body,comments,labels,author,url\n```\n\nRead it one time and report `state` and the last maintainer comment verbatim. `\u002Fcontribution-standards` forbids polling, watching, and sleeping on the artifact; a maintainer answers on their own schedule.\n\n**STOP when `state` is `CLOSED`.** Report that outcome and return. This gate precedes every later step: a comment posted afterwards notifies every watcher of a thread whose decision is already made, and Step 7 has nothing left to close.\n\n**Step 4 — Answer what was asked.** Identify the maintainer's actual question. Gather the evidence it needs before drafting anything, under `\u002Fcontribution-standards` `\u003Cinvariants>` \"Carry reproducible evidence\" — versions, the base commit observed against, the exact command, and a negative control where the answer makes a defect claim. Those probes belong to the subject tool rather than to this skill, so they run per `\u002Fcontribution-standards` `\u003Ccapability_scope>`.\n\nWhen the answer requires a condition that cannot be reproduced in the real surface, say the claim is unverified and say why. A synthesized approximation reported as an observation is worse than no answer, because the maintainer cannot tell which they received.\n\n**Step 5 — GATE: Establish whose thread this is, before writing to it.** Read the authenticated login, which is the only side of this comparison Step 3 does not already supply:\n\n```bash\ngh api user --jq '.login'\n```\n\nCompare it against `author.login` from the Step 3 read; that field is the only evidence of who filed the issue.\n\nAn issue the operator filed is the artifact they already authorized, and a reply continues it. An issue anyone else filed is an unrelated thread: `\u002Fcontribution-standards` `\u003Cinvariants>` \"Authorization covers the artifact and its revisions\" gives a comment there its own in-turn authorization, so present through the runtime's structured-question tool the resolved `base`, the issue number and title, and the choice to reply there or to stop. Post nothing until the operator authorizes it in this turn.\n\nThis gate precedes Step 6's write. A comment notifies every watcher of a repository the operator does not control, and that cannot be taken back by deciding afterwards that the thread was someone else's.\n\n**Step 6 — GATE: Review the reply, then post it.** A reply is posted only when the thread asked for one. An invocation that reports the thread's current state, and a thread where the maintainer has asked nothing since the last reply, both skip this step and continue to Step 7: a comment that answers no question is a notification the maintainer did not ask for, on a repository the operator does not control. Step 7 still runs, because closing depends on Step 5's author comparison and never on a comment having been posted — a thread that asks nothing is exactly the thread an operator may want closed.\n\nWith a question to answer, draft per `\u003Creply_shape>` and review — the prose plugin's `{{! subagent_name('prose', 'prose-auditor') !}}` thin agent where installed, `\u002Fcontribution-standards` `\u003Coutward_text>` unassisted where not, stated as such.\n\nThe reply 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 issue, 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 issue comment \"\u003Cnumber>\" --repo \"\u003Cbase>\" --body-file \"\u003Ccomment-file>\"\n```\n\n`--body-file \"\u003Ccomment-file>\"` delivers the reply 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\n**Step 7 — GATE: Close only what the operator opened, and only when authorized.** Step 5 already established the author. An issue anyone else filed is the maintainer's to close; stop there. For an issue the operator filed, closing is a new outward action rather than a revision of the authorized one, so present through the runtime's structured-question tool the resolved `base`, the issue number and title, and the choice to close it or leave it open. Close only after the operator authorizes it in this turn:\n\n```bash\ngh issue close \"\u003Cnumber>\" --repo \"\u003Cbase>\"\n```\n\n**Step 8 — Return.** Report the issue URL, the state read in Step 3, and what was answered — or that the thread asked nothing this pass. Do not wait for a response.\n\n\u003C\u002Fworkflow>\n\n\u003Creply_shape>\n\n- Open by answering the question that was asked, before anything else.\n- Quote the evidence rather than describing it.\n- Mark inference as inference and an unreproduced condition as unverified.\n- Cut every sentence about the reply's own process.\n- Add a new observation only when it bears on the question; otherwise it belongs in its own issue through `\u002Fopen-upstream-issue`.\n\n\u003C\u002Freply_shape>\n\n\u003Cworked_example>\n\nOne reply on a fictional `acme\u002Fparser` issue reporting that `--strict` is ignored when the config file sets `strict: false`, to compare a draft against.\n\nThe maintainer's comment, which is the question Step 4 identifies:\n\n```text\nDoes this reproduce without a config file present?\n```\n\nThe reply:\n\n```text\nNo — with no config file the flag takes effect.\n\n$ rm parser.yml\n$ parser --strict sample.txt; echo \"exit $?\"\nsample.txt:1:5: unexpected '='\nexit 1\n\nparser 4.2.0, acme\u002Fparser at 4f9c2a1, the same sample.txt as the report.\n\nThat reads as the file's value overriding the flag rather than the reverse —\nan inference from these two runs, not something I confirmed in the source.\n```\n\nThe first sentence answers the question asked, before anything else. The command output stands quoted rather than summarized as \"it worked\". The precedence claim carries its own inference marker, because the run compared two exit codes and never read the merge. The reply thanks nobody, describes none of its own process, and proposes no fix.\n\n\u003C\u002Fworked_example>\n\n\u003Cconstraints>\n\n- MUST read the thread exactly once per invocation and return without waiting.\n- NEVER comment on or close an issue whose `state` is `CLOSED`. Report that outcome and return; the decision is already made, and a comment notifies every watcher of it.\n- MUST name the base repository with `--repo` on every `gh` write.\n- MUST answer the maintainer's question before adding anything else.\n- NEVER post a comment when the thread asked nothing — a state-only invocation returns what it read and writes nothing.\n- MUST establish the issue's author before the first write, and obtain authorization in the same turn before commenting on a thread the operator did not open.\n- MUST obtain authorization in the same turn before closing an issue.\n- MUST read `gh api user` only for the Step 5 authorship comparison. `\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 an `-X` method flag to `gh api user`. The `Bash(gh api user:*)` grant matches by prefix, so it admits every verb against the operator's own GitHub account — `-X PATCH` and `-X DELETE` among them; this constraint is the whole containment for all of them. Read only.\n- NEVER pass `--edit-last` or `--delete-last` to `gh issue comment`. The `Bash(gh issue comment:*)` grant matches by prefix and admits both, and either one rewrites or removes a comment a maintainer 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 close, label, or reassign an issue the operator did not open.\n- NEVER present a synthesized approximation of the condition as an observation.\n\n\u003C\u002Fconstraints>\n\n\u003Cfailure_modes>\n\n**A reply was posted before the thread's owner was known.** Claude read the issue, drafted an answer, and commented — then compared the author against the authenticated account, which is where the authorization gate sat. On a thread the operator had not opened, the comment had already notified every watcher of a repository the operator does not control, and GitHub keeps that notification whatever happens to the comment. Establish the author in Step 5, before any write.\n\n\u003C\u002Ffailure_modes>\n\n\u003Csuccess_criteria>\n\n- The `\u003CUPSTREAM_TARGET>` marker read for this pass carries `classification=\"upstream-contribution\"`, `\"head-ambiguous\"`, or `\"fork-absent\"`, established before any write.\n- The thread was read once, and `state` plus the last maintainer comment appear verbatim.\n- A `state` of `CLOSED` returned that outcome and wrote nothing; every criterion below covers a pass on an open thread.\n- The issue's `author.login` was compared against the authenticated login before the comment was posted, and a thread the operator did not open was authorized in that turn.\n- Where the thread asked a question, the reply's opening sentence answers the one Step 4 identified and every claim after it is followed by quoted evidence rather than a description of that evidence; where it asked none, no comment was posted; a posted reply arrived from a scratch file through `--body-file`.\n- Inference is marked as inference; an unreproduced condition is marked unverified.\n- The reply passed a prose review, reported as unassisted where the prose plugin is absent.\n- Any close was authorized in the same turn and applied only to an issue whose `author.login` equals the login `gh api user` reported.\n- The pass returned without polling, watching, or sleeping.\n\n\u003C\u002Fsuccess_criteria>\n","\u003Cobjective>\nThe maintainer's question answered with evidence in one comment on the open issue, or that thread's state reported when it asked nothing.\n\u003C\u002Fobjective>\n\n\u003Cworkflow>\n\n**Step 1 — Load the standards and resolve the issue.** {!% require_skill 'contribute:contribution-standards' %!}\n\n`$ARGUMENTS` is an issue number or URL. A bare number is the number; a URL's trailing path segment is the number. An empty `$ARGUMENTS` stops the flow, because this skill continues an identified thread and never picks one. The URL check needs the resolved base, so Step 2 settles it.\n\n**Step 2 — Establish the target, then check the number.** Read the live `\u003CUPSTREAM_TARGET>` marker; invoke `\u002Fupstream` when none is live. `upstream-contribution`, `head-ambiguous`, and `fork-absent` all continue — a thread needs no head repository. `controlled` and `blocked` stop, reporting the classification and `detail` verbatim.\n\nWith `base` resolved, a URL's `owner\u002Fname` segments must equal it; a mismatch stops the flow rather than being reconciled.\n\n**Step 3 — Read the thread once.**\n\n```bash\ngh issue view \"\u003Cnumber>\" --repo \"\u003Cbase>\" --json state,title,body,comments,labels,author,url\n```\n\nRead it one time and report `state` and the last maintainer comment verbatim. `\u002Fcontribution-standards` forbids polling, watching, and sleeping on the artifact; a maintainer answers on their own schedule.\n\n**STOP when `state` is `CLOSED`.** Report that outcome and return. This gate precedes every later step: a comment posted afterwards notifies every watcher of a thread whose decision is already made, and Step 7 has nothing left to close.\n\n**Step 4 — Answer what was asked.** Identify the maintainer's actual question. Gather the evidence it needs before drafting anything, under `\u002Fcontribution-standards` `\u003Cinvariants>` \"Carry reproducible evidence\" — versions, the base commit observed against, the exact command, and a negative control where the answer makes a defect claim. Those probes belong to the subject tool rather than to this skill, so they run per `\u002Fcontribution-standards` `\u003Ccapability_scope>`.\n\nWhen the answer requires a condition that cannot be reproduced in the real surface, say the claim is unverified and say why. A synthesized approximation reported as an observation is worse than no answer, because the maintainer cannot tell which they received.\n\n**Step 5 — GATE: Establish whose thread this is, before writing to it.** Read the authenticated login, which is the only side of this comparison Step 3 does not already supply:\n\n```bash\ngh api user --jq '.login'\n```\n\nCompare it against `author.login` from the Step 3 read; that field is the only evidence of who filed the issue.\n\nAn issue the operator filed is the artifact they already authorized, and a reply continues it. An issue anyone else filed is an unrelated thread: `\u002Fcontribution-standards` `\u003Cinvariants>` \"Authorization covers the artifact and its revisions\" gives a comment there its own in-turn authorization, so present through the runtime's structured-question tool the resolved `base`, the issue number and title, and the choice to reply there or to stop. Post nothing until the operator authorizes it in this turn.\n\nThis gate precedes Step 6's write. A comment notifies every watcher of a repository the operator does not control, and that cannot be taken back by deciding afterwards that the thread was someone else's.\n\n**Step 6 — GATE: Review the reply, then post it.** A reply is posted only when the thread asked for one. An invocation that reports the thread's current state, and a thread where the maintainer has asked nothing since the last reply, both skip this step and continue to Step 7: a comment that answers no question is a notification the maintainer did not ask for, on a repository the operator does not control. Step 7 still runs, because closing depends on Step 5's author comparison and never on a comment having been posted — a thread that asks nothing is exactly the thread an operator may want closed.\n\nWith a question to answer, draft per `\u003Creply_shape>` and review — the prose plugin's `{{! subagent_name('prose', 'prose-auditor') !}}` thin agent where installed, `\u002Fcontribution-standards` `\u003Coutward_text>` unassisted where not, stated as such.\n\nThe reply 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 issue, 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 issue comment \"\u003Cnumber>\" --repo \"\u003Cbase>\" --body-file \"\u003Ccomment-file>\"\n```\n\n`--body-file \"\u003Ccomment-file>\"` delivers the reply 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\n**Step 7 — GATE: Close only what the operator opened, and only when authorized.** Step 5 already established the author. An issue anyone else filed is the maintainer's to close; stop there. For an issue the operator filed, closing is a new outward action rather than a revision of the authorized one, so present through the runtime's structured-question tool the resolved `base`, the issue number and title, and the choice to close it or leave it open. Close only after the operator authorizes it in this turn:\n\n```bash\ngh issue close \"\u003Cnumber>\" --repo \"\u003Cbase>\"\n```\n\n**Step 8 — Return.** Report the issue URL, the state read in Step 3, and what was answered — or that the thread asked nothing this pass. Do not wait for a response.\n\n\u003C\u002Fworkflow>\n\n\u003Creply_shape>\n\n- Open by answering the question that was asked, before anything else.\n- Quote the evidence rather than describing it.\n- Mark inference as inference and an unreproduced condition as unverified.\n- Cut every sentence about the reply's own process.\n- Add a new observation only when it bears on the question; otherwise it belongs in its own issue through `\u002Fopen-upstream-issue`.\n\n\u003C\u002Freply_shape>\n\n\u003Cworked_example>\n\nOne reply on a fictional `acme\u002Fparser` issue reporting that `--strict` is ignored when the config file sets `strict: false`, to compare a draft against.\n\nThe maintainer's comment, which is the question Step 4 identifies:\n\n```text\nDoes this reproduce without a config file present?\n```\n\nThe reply:\n\n```text\nNo — with no config file the flag takes effect.\n\n$ rm parser.yml\n$ parser --strict sample.txt; echo \"exit $?\"\nsample.txt:1:5: unexpected '='\nexit 1\n\nparser 4.2.0, acme\u002Fparser at 4f9c2a1, the same sample.txt as the report.\n\nThat reads as the file's value overriding the flag rather than the reverse —\nan inference from these two runs, not something I confirmed in the source.\n```\n\nThe first sentence answers the question asked, before anything else. The command output stands quoted rather than summarized as \"it worked\". The precedence claim carries its own inference marker, because the run compared two exit codes and never read the merge. The reply thanks nobody, describes none of its own process, and proposes no fix.\n\n\u003C\u002Fworked_example>\n\n\u003Cconstraints>\n\n- MUST read the thread exactly once per invocation and return without waiting.\n- NEVER comment on or close an issue whose `state` is `CLOSED`. Report that outcome and return; the decision is already made, and a comment notifies every watcher of it.\n- MUST name the base repository with `--repo` on every `gh` write.\n- MUST answer the maintainer's question before adding anything else.\n- NEVER post a comment when the thread asked nothing — a state-only invocation returns what it read and writes nothing.\n- MUST establish the issue's author before the first write, and obtain authorization in the same turn before commenting on a thread the operator did not open.\n- MUST obtain authorization in the same turn before closing an issue.\n- MUST read `gh api user` only for the Step 5 authorship comparison. `\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 an `-X` method flag to `gh api user`. The `Bash(gh api user:*)` grant matches by prefix, so it admits every verb against the operator's own GitHub account — `-X PATCH` and `-X DELETE` among them; this constraint is the whole containment for all of them. Read only.\n- NEVER pass `--edit-last` or `--delete-last` to `gh issue comment`. The `Bash(gh issue comment:*)` grant matches by prefix and admits both, and either one rewrites or removes a comment a maintainer 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 close, label, or reassign an issue the operator did not open.\n- NEVER present a synthesized approximation of the condition as an observation.\n\n\u003C\u002Fconstraints>\n\n\u003Cfailure_modes>\n\n**A reply was posted before the thread's owner was known.** Claude read the issue, drafted an answer, and commented — then compared the author against the authenticated account, which is where the authorization gate sat. On a thread the operator had not opened, the comment had already notified every watcher of a repository the operator does not control, and GitHub keeps that notification whatever happens to the comment. Establish the author in Step 5, before any write.\n\n\u003C\u002Ffailure_modes>\n\n\u003Csuccess_criteria>\n\n- The `\u003CUPSTREAM_TARGET>` marker read for this pass carries `classification=\"upstream-contribution\"`, `\"head-ambiguous\"`, or `\"fork-absent\"`, established before any write.\n- The thread was read once, and `state` plus the last maintainer comment appear verbatim.\n- A `state` of `CLOSED` returned that outcome and wrote nothing; every criterion below covers a pass on an open thread.\n- The issue's `author.login` was compared against the authenticated login before the comment was posted, and a thread the operator did not open was authorized in that turn.\n- Where the thread asked a question, the reply's opening sentence answers the one Step 4 identified and every claim after it is followed by quoted evidence rather than a description of that evidence; where it asked none, no comment was posted; a posted reply arrived from a scratch file through `--body-file`.\n- Inference is marked as inference; an unreproduced condition is marked unverified.\n- The reply passed a prose review, reported as unassisted where the prose plugin is absent.\n- Any close was authorized in the same turn and applied only to an issue whose `author.login` equals the login `gh api user` reported.\n- The pass returned without polling, watching, or sleeping.\n\n\u003C\u002Fsuccess_criteria>\n",{"name":5,"description":7,"allowed-tools":49,"argument-hint":50},"Read, Write, {{! tool('use_skill') !}},{!% if target == 'claude' %!} Agent,{!% else %!} {{! tool('spawn_agent') !}}, {{! tool('wait_agent') !}},{!% endif %!} {{! tool('ask_user') !}}, Bash(gh issue view:*), Bash(gh issue comment:*), Bash(gh issue close:*), Bash(gh api user:*)","[issue number or URL]","main","978d51c51d68c99cffb2ba48f7cad9d2f07e5738","src\u002Fplugins\u002Fcontribute\u002Fskills\u002Fmanage-upstream-issue","https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins","https:\u002F\u002Fgithub.com\u002Foutcomeeng","https:\u002F\u002Foutcome.engineering","Spec-driven development for AI-assisted engineering","2026-11-13 22:49:15",{"source":8,"skillName":5,"commands":60,"prompt":70,"zipAvailable":71},[61,64,67],{"tool":62,"command":63},"npx","npx skills add outcomeeng\u002Fplugins --skill manage-upstream-issue",{"tool":65,"command":66},"bunx","bunx skills add outcomeeng\u002Fplugins --skill manage-upstream-issue",{"tool":68,"command":69},"pnpm","pnpm dlx skills add outcomeeng\u002Fplugins --skill manage-upstream-issue","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Fcontribute\u002Fskills\u002Fmanage-upstream-issue\u002FSKILL.md",true,[],[74,80,112,128,145,158],{"skillNo":75,"name":76,"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":77,"categories":78,"keywords":79,"publishedAt":44},"01M71G25RZTPQG9KJ00JCHC1F7","plugin","https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Ftemplates\u002Fplugin\u002FSKILL.md",[],[76],{"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":94,"publishedAt":44},"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",[86,89],{"categoryNo":87,"categoryName":88,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000003","演示文稿",{"categoryNo":90,"categoryName":91,"taxonomyType":92,"taxonomyTypeDesc":93},"01JBSEEDCAT000000000000034","行政与办公人员","PROFESSION","适用职业",[95,96,97,98,99,100,101,37,102,103,104,105,106,107,108,109,110,111,31,30],"sanitize powerpoint","powerpoint","sanitize","fonts","type","cleaning","structure","attributes","theme","pptx","naming","layout","deck","up","edit","xml","master",{"skillNo":113,"name":114,"nameZh":6,"description":115,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":116,"categories":117,"keywords":118,"publishedAt":44},"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",[],[119,120,121,122,123,37,31,124,125,30,126,127],"draw excalidraw","excalidraw","draw","diagrams","architectures","generate","workflows","concepts","json",{"skillNo":129,"name":130,"nameZh":6,"description":131,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":132,"categories":133,"keywords":137,"publishedAt":44},"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",[134],{"categoryNo":135,"categoryName":136,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",[138,139,140,141,142,143,144],"typescript","typescript test standards","test","standards","false","read","across",{"skillNo":146,"name":147,"nameZh":6,"description":148,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":149,"categories":150,"keywords":154,"publishedAt":44},"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",[151],{"categoryNo":152,"categoryName":153,"taxonomyType":92,"taxonomyTypeDesc":93},"01JBSEEDCAT000000000000030","开发工程师",[138,155,156,157,141,142,143,144],"code","typescript code standards","code standards",{"skillNo":159,"name":160,"nameZh":6,"description":161,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":162,"categories":163,"keywords":164,"publishedAt":44},"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",[],[165,141,166,167,138,168,169,144,143,170,142,171],"architecture standards","typescript architecture standards","architecture","adr","architect","auditor","conventions"]