[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71FT5VKZNVSSAGPK2BAMQCY":3,"skill-same:01M71FT5VKZNVSSAGPK2BAMQCY":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},"01M71FT5VKZNVSSAGPK2BAMQCY","open-upstream-issue",null,"ALWAYS invoke this skill when filing an issue in a repository the operator does not control — a fork's upstream, or any base whose permission is READ, TRIAGE, or NONE. NEVER open an issue against 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\u002Fopen-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],"open","open upstream issue","issue","upstream","control","create","Bash","ask","when","invoke","use","issue create","gh","issues","filing","tool","search","never","target","gh issue","2026-11-10 10:12:30",false,"---\nname: open-upstream-issue\ndescription: >-\n  ALWAYS invoke this skill when filing an issue in a repository the operator does not control — a fork's upstream, or any base whose permission is READ, TRIAGE, or NONE.\n  NEVER open an issue against such a repository without this skill.\nargument-hint: \"[what was observed]\"\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 create:*), Bash(gh search issues:*)\n---\n\n\u003Cobjective>\nOne issue open in a repository the operator does not control, carrying an observation its maintainer can reproduce without access to the operator's machine — or the existing issue that already reports it, named instead of duplicated.\n\u003C\u002Fobjective>\n\n\u003Cworkflow>\n\n**Step 1 — Load the standards and read the invocation input.** {!% require_skill 'contribute:contribution-standards' %!}\n\n`$ARGUMENTS`, when non-empty, is the observation this report is built around: it supplies Step 3's distinguishing search terms, Step 4's claim to gather evidence for, and Step 5's one-sentence summary. When it is empty, present, through the runtime's structured-question tool, the request for what was observed, before Step 3, because a report has no subject without it.\n\n**Step 2 — GATE: Establish the target.** Read the live `\u003CUPSTREAM_TARGET>` marker; invoke `\u002Fupstream` when none is live. Report `base` and `permission` verbatim.\n\nAn issue needs no head repository, so `upstream-contribution`, `head-ambiguous`, and `fork-absent` all continue here — an absent or ambiguous head blocks a pull request, never a report. `controlled` stops: an issue in a repository the operator controls belongs to that repository's own workflow. `blocked` stops with the resolver's `detail` verbatim.\n\n**Step 3 — Search before filing.** Search the base repository for an existing issue describing the same observation:\n\n```bash\ngh search issues --repo \"\u003Cbase>\" --state open --limit 100 \"\u003Cdistinguishing terms>\"\ngh search issues --repo \"\u003Cbase>\" --state closed --limit 100 \"\u003Cdistinguishing terms>\"\n```\n\nEach search is bounded at 100 results. A search that returns 100 results fills its bound and cannot show whether more match, so stop and report the blocked search with the bound `100 results per search`. NEVER conclude that no duplicate exists from a result that fills its bound. Narrow the distinguishing terms and search again only on the operator's instruction.\n\nBoth states are searched because `gh search issues --state` accepts only `open` or `closed`; passing `all` fails the command and would stop the flow before duplicate detection runs. A closed issue matters as much as an open one — it may record that the maintainer already rejected this report.\n\nReport what both searches returned.\n\n**STOP when either search matched this observation.** Surface that issue's URL and return; Steps 4 through 8 do not run. An existing issue takes a comment through `\u002Fmanage-upstream-issue`, never a duplicate, and a duplicate filed into a repository the operator does not control cannot be taken back by deciding afterwards that the search had already answered.\n\n**Step 4 — Assemble the evidence.** Per `\u002Fcontribution-standards` `\u003Cinvariants>` \"Carry reproducible evidence\", collect: the versions of every tool involved, the base repository commit the observation was made against, the exact command or interaction that produced it, and a negative control showing the same method reporting the opposite result. Those probes belong to the subject tool rather than to this skill, so they run per `\u002Fcontribution-standards` `\u003Ccapability_scope>`.\n\nA claim without a negative control cannot distinguish a defect from a broken measurement, and a maintainer has no way to tell which they received. When the condition cannot be reproduced in the real surface, say so and say why; never substitute a lookalike and report it as observed.\n\n**Step 5 — GATE: Obtain authorization.** Present, through the runtime's structured-question tool, the resolved `base`, the issue title, the observation in one sentence, and the choice to file it against that base or to stop and inspect. Create nothing until the operator authorizes it in this turn.\n\n**Step 6 — GATE: Review the outward text.** Draft the title and body per `\u003Creport_shape>`, then review them — the prose plugin's `{{! subagent_name('prose', 'prose-auditor') !}}` thin agent where installed, `\u002Fcontribution-standards` `\u003Coutward_text>` unassisted where not, stated as such in the report.\n\n**Step 7 — File it.** The body 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. The file holds:\n\n```text\n\u003Cwhat was observed>\n\n## Reproduction\n\n\u003Cversions, base commit, exact command>\n\n## Negative control\n\n\u003Cthe same method reporting the opposite result>\n```\n\n```bash\ngh issue create --repo \"\u003Cbase>\" --title \"\u003Ctitle>\" --body-file \"\u003Cbody-file>\"\n```\n\n`--body-file \"\u003Cbody-file>\"` delivers the body 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 8 — Hand off.** Surface the URL of the issue this pass filed. `\u002Fmanage-upstream-issue` owns every later pass on the thread, including the first one on an issue Step 3 found rather than filed.\n\n\u003C\u002Fworkflow>\n\n\u003Creport_shape>\n\nThe title names the observed behavior, not the suspected cause.\n\nThe body opens with what was observed, in the surface a maintainer recognizes. Then:\n\n- **Reproduction** — tool versions, the base repository commit observed against, and the exact command or interaction. Quote output rather than describing it.\n- **Negative control** — the same method reporting the opposite result, which is what separates a defect from a broken measurement.\n- What was inferred rather than observed, marked as inference. An unreproduced condition is stated as unverified.\n\nLeave the fix to the maintainer unless they asked for one. A report that prescribes an implementation constrains a decision that is theirs.\n\n\u003C\u002Freport_shape>\n\n\u003Cworked_example>\n\nOne report against a fictional base `acme\u002Fparser`, to compare a draft against.\n\nTitle: `--strict is ignored when the config file sets strict: false`\n\nBody:\n\n```text\n`parser --strict` exits 0 on input that `strict: true` in the config file\nrejects. The flag is accepted and changes nothing.\n\n## Reproduction\n\nparser 4.2.0, Python 3.13.2, macOS 15.3\nacme\u002Fparser at 4f9c2a1\n\n$ printf 'strict: false\\n' > parser.yml\n$ printf 'a = = 1\\n' > sample.txt\n$ parser --strict sample.txt; echo \"exit $?\"\nexit 0\n\n## Negative control\n\nThe same input with the flag's effect present:\n\n$ printf 'strict: true\\n' > parser.yml\n$ parser sample.txt; echo \"exit $?\"\nsample.txt:1:5: unexpected '='\nexit 1\n\nThe parse error exists and the config file surfaces it, so the exit 0 above is\nthe flag failing rather than the input parsing cleanly.\n```\n\nThe title names what the run observed rather than the precedence bug it suspects. The negative control is the same command and the same input with one value changed, so it separates a defect from a broken measurement. The report proposes no fix and names no line of source, because where the flag and the file merge is the maintainer's to decide.\n\n\u003C\u002Fworked_example>\n\n\u003Cconstraints>\n\n- MUST read the resolved target from a live `\u003CUPSTREAM_TARGET>` marker before the first write, invoking `\u002Fupstream` when none is live.\n- MUST search the base repository for an existing issue before filing a new one.\n- MUST obtain authorization naming the resolved base in the same turn.\n- MUST name the base repository with `--repo` on `gh issue create`.\n- MUST carry a negative control with every defect claim.\n- NEVER file against a base whose classification is `controlled` or `blocked`.\n- NEVER present a synthesized approximation of the condition as an observation.\n\n\u003C\u002Fconstraints>\n\n\u003Csuccess_criteria>\n\n- The `\u003CUPSTREAM_TARGET>` marker read for this pass carries `classification=\"upstream-contribution\"`, `\"head-ambiguous\"`, or `\"fork-absent\"`, and its `base` and `permission` values appear verbatim.\n- A search for an existing issue ran and its result is reported.\n- A search that returned 100 results reported the blocked search with the bound `100 results per search` and filed nothing.\n- A search that matched surfaced that issue's URL and filed nothing; every criterion below covers a pass that filed.\n- The operator authorized this issue against the resolved base in the turn it was filed.\n- The body carries tool versions, the base commit observed against, the exact command, and a negative control.\n- Every inference is marked as inference and every unreproduced condition as unverified.\n- The title and body passed a prose review, reported as unassisted where the prose plugin is absent.\n- `gh issue create` named the base with `--repo` and the body arrived from a scratch file through `--body-file`.\n- The issue URL is surfaced.\n\n\u003C\u002Fsuccess_criteria>\n","\u003Cobjective>\nOne issue open in a repository the operator does not control, carrying an observation its maintainer can reproduce without access to the operator's machine — or the existing issue that already reports it, named instead of duplicated.\n\u003C\u002Fobjective>\n\n\u003Cworkflow>\n\n**Step 1 — Load the standards and read the invocation input.** {!% require_skill 'contribute:contribution-standards' %!}\n\n`$ARGUMENTS`, when non-empty, is the observation this report is built around: it supplies Step 3's distinguishing search terms, Step 4's claim to gather evidence for, and Step 5's one-sentence summary. When it is empty, present, through the runtime's structured-question tool, the request for what was observed, before Step 3, because a report has no subject without it.\n\n**Step 2 — GATE: Establish the target.** Read the live `\u003CUPSTREAM_TARGET>` marker; invoke `\u002Fupstream` when none is live. Report `base` and `permission` verbatim.\n\nAn issue needs no head repository, so `upstream-contribution`, `head-ambiguous`, and `fork-absent` all continue here — an absent or ambiguous head blocks a pull request, never a report. `controlled` stops: an issue in a repository the operator controls belongs to that repository's own workflow. `blocked` stops with the resolver's `detail` verbatim.\n\n**Step 3 — Search before filing.** Search the base repository for an existing issue describing the same observation:\n\n```bash\ngh search issues --repo \"\u003Cbase>\" --state open --limit 100 \"\u003Cdistinguishing terms>\"\ngh search issues --repo \"\u003Cbase>\" --state closed --limit 100 \"\u003Cdistinguishing terms>\"\n```\n\nEach search is bounded at 100 results. A search that returns 100 results fills its bound and cannot show whether more match, so stop and report the blocked search with the bound `100 results per search`. NEVER conclude that no duplicate exists from a result that fills its bound. Narrow the distinguishing terms and search again only on the operator's instruction.\n\nBoth states are searched because `gh search issues --state` accepts only `open` or `closed`; passing `all` fails the command and would stop the flow before duplicate detection runs. A closed issue matters as much as an open one — it may record that the maintainer already rejected this report.\n\nReport what both searches returned.\n\n**STOP when either search matched this observation.** Surface that issue's URL and return; Steps 4 through 8 do not run. An existing issue takes a comment through `\u002Fmanage-upstream-issue`, never a duplicate, and a duplicate filed into a repository the operator does not control cannot be taken back by deciding afterwards that the search had already answered.\n\n**Step 4 — Assemble the evidence.** Per `\u002Fcontribution-standards` `\u003Cinvariants>` \"Carry reproducible evidence\", collect: the versions of every tool involved, the base repository commit the observation was made against, the exact command or interaction that produced it, and a negative control showing the same method reporting the opposite result. Those probes belong to the subject tool rather than to this skill, so they run per `\u002Fcontribution-standards` `\u003Ccapability_scope>`.\n\nA claim without a negative control cannot distinguish a defect from a broken measurement, and a maintainer has no way to tell which they received. When the condition cannot be reproduced in the real surface, say so and say why; never substitute a lookalike and report it as observed.\n\n**Step 5 — GATE: Obtain authorization.** Present, through the runtime's structured-question tool, the resolved `base`, the issue title, the observation in one sentence, and the choice to file it against that base or to stop and inspect. Create nothing until the operator authorizes it in this turn.\n\n**Step 6 — GATE: Review the outward text.** Draft the title and body per `\u003Creport_shape>`, then review them — the prose plugin's `{{! subagent_name('prose', 'prose-auditor') !}}` thin agent where installed, `\u002Fcontribution-standards` `\u003Coutward_text>` unassisted where not, stated as such in the report.\n\n**Step 7 — File it.** The body 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. The file holds:\n\n```text\n\u003Cwhat was observed>\n\n## Reproduction\n\n\u003Cversions, base commit, exact command>\n\n## Negative control\n\n\u003Cthe same method reporting the opposite result>\n```\n\n```bash\ngh issue create --repo \"\u003Cbase>\" --title \"\u003Ctitle>\" --body-file \"\u003Cbody-file>\"\n```\n\n`--body-file \"\u003Cbody-file>\"` delivers the body 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 8 — Hand off.** Surface the URL of the issue this pass filed. `\u002Fmanage-upstream-issue` owns every later pass on the thread, including the first one on an issue Step 3 found rather than filed.\n\n\u003C\u002Fworkflow>\n\n\u003Creport_shape>\n\nThe title names the observed behavior, not the suspected cause.\n\nThe body opens with what was observed, in the surface a maintainer recognizes. Then:\n\n- **Reproduction** — tool versions, the base repository commit observed against, and the exact command or interaction. Quote output rather than describing it.\n- **Negative control** — the same method reporting the opposite result, which is what separates a defect from a broken measurement.\n- What was inferred rather than observed, marked as inference. An unreproduced condition is stated as unverified.\n\nLeave the fix to the maintainer unless they asked for one. A report that prescribes an implementation constrains a decision that is theirs.\n\n\u003C\u002Freport_shape>\n\n\u003Cworked_example>\n\nOne report against a fictional base `acme\u002Fparser`, to compare a draft against.\n\nTitle: `--strict is ignored when the config file sets strict: false`\n\nBody:\n\n```text\n`parser --strict` exits 0 on input that `strict: true` in the config file\nrejects. The flag is accepted and changes nothing.\n\n## Reproduction\n\nparser 4.2.0, Python 3.13.2, macOS 15.3\nacme\u002Fparser at 4f9c2a1\n\n$ printf 'strict: false\\n' > parser.yml\n$ printf 'a = = 1\\n' > sample.txt\n$ parser --strict sample.txt; echo \"exit $?\"\nexit 0\n\n## Negative control\n\nThe same input with the flag's effect present:\n\n$ printf 'strict: true\\n' > parser.yml\n$ parser sample.txt; echo \"exit $?\"\nsample.txt:1:5: unexpected '='\nexit 1\n\nThe parse error exists and the config file surfaces it, so the exit 0 above is\nthe flag failing rather than the input parsing cleanly.\n```\n\nThe title names what the run observed rather than the precedence bug it suspects. The negative control is the same command and the same input with one value changed, so it separates a defect from a broken measurement. The report proposes no fix and names no line of source, because where the flag and the file merge is the maintainer's to decide.\n\n\u003C\u002Fworked_example>\n\n\u003Cconstraints>\n\n- MUST read the resolved target from a live `\u003CUPSTREAM_TARGET>` marker before the first write, invoking `\u002Fupstream` when none is live.\n- MUST search the base repository for an existing issue before filing a new one.\n- MUST obtain authorization naming the resolved base in the same turn.\n- MUST name the base repository with `--repo` on `gh issue create`.\n- MUST carry a negative control with every defect claim.\n- NEVER file against a base whose classification is `controlled` or `blocked`.\n- NEVER present a synthesized approximation of the condition as an observation.\n\n\u003C\u002Fconstraints>\n\n\u003Csuccess_criteria>\n\n- The `\u003CUPSTREAM_TARGET>` marker read for this pass carries `classification=\"upstream-contribution\"`, `\"head-ambiguous\"`, or `\"fork-absent\"`, and its `base` and `permission` values appear verbatim.\n- A search for an existing issue ran and its result is reported.\n- A search that returned 100 results reported the blocked search with the bound `100 results per search` and filed nothing.\n- A search that matched surfaced that issue's URL and filed nothing; every criterion below covers a pass that filed.\n- The operator authorized this issue against the resolved base in the turn it was filed.\n- The body carries tool versions, the base commit observed against, the exact command, and a negative control.\n- Every inference is marked as inference and every unreproduced condition as unverified.\n- The title and body passed a prose review, reported as unassisted where the prose plugin is absent.\n- `gh issue create` named the base with `--repo` and the body arrived from a scratch file through `--body-file`.\n- The issue URL is surfaced.\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 create:*), Bash(gh search issues:*)","[what was observed]","main","978d51c51d68c99cffb2ba48f7cad9d2f07e5738","src\u002Fplugins\u002Fcontribute\u002Fskills\u002Fopen-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 open-upstream-issue",{"tool":65,"command":66},"bunx","bunx skills add outcomeeng\u002Fplugins --skill open-upstream-issue",{"tool":68,"command":69},"pnpm","pnpm dlx skills add outcomeeng\u002Fplugins --skill open-upstream-issue","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Fcontribute\u002Fskills\u002Fopen-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,41,102,103,104,105,106,107,108,109,110,111,33,32],"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,41,33,124,125,32,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"]