[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6ACG7R07AC5ABZ472F0B3MF":3,"skill-same:01M6ACG7R07AC5ABZ472F0B3MF":102},{"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":51,"linkOnly":52,"markdownContent":53,"markdownBody":54,"frontMatter":55,"refName":61,"commitSha":62,"skillDirectory":63,"forksCount":64,"repositoryHtmlUrl":65,"repositoryHomepageUrl":66,"ownerHtmlUrl":67,"ownerBlogUrl":68,"ownerDescription":6,"updatedAt":69,"install":70,"resources":83},"01M6ACG7R07AC5ABZ472F0B3MF","tinker-doc",null,"Writing, editing and reviewing documentation for the Apache TinkerPop project. Use  when  authoring or revising any content under docs\u002Fsrc\u002F — reference docs, recipes, tutorials, upgrade\u002Frelease notes, provider and developer guides — or the CHANGELOG. Covers the TinkerPop documentation voice and the per-book style expectations, the executable Gremlin code-block pipeline, and AsciiDoc conventions. For building and validating code changes, see tinker-dev.","apache\u002Ftinkerpop","apache","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F47359?v=4","01M6AC83E6K4FDKK7HZ8WNMQKE","The Apache Software Foundation","01M6ACG106047V1J755TAB62T9",2155,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fapache\u002Ftinkerpop\u002Fblob\u002Fmaster\u002F.skills\u002Ftinker-doc\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000036","内容创作者",[27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,9,43,44,45,46,47,48,49,50],"Tinker","doc","tinker doc","tinkerpop","when","guides","authoring","project","upgrade","never","src","markdown","pipeline","writing","gremlin","content","changelog","dev","release","code","release notes","notes","documentation","docs","2026-11-10 10:12:30",false,"---\nname: tinker-doc\ndescription: >\n  Writing, editing and reviewing documentation for the Apache TinkerPop project. Use \n  when  authoring or revising any content under docs\u002Fsrc\u002F — reference docs, recipes,\n  tutorials, upgrade\u002Frelease notes, provider and developer guides — or the\n  CHANGELOG. Covers the TinkerPop documentation voice and the per-book style\n  expectations, the executable Gremlin code-block pipeline, and AsciiDoc\n  conventions. For building and validating code changes, see tinker-dev.\nlicense: Apache-2.0\ncompatibility: Documentation is AsciiDoc under docs\u002Fsrc\u002F, never Markdown.\nmetadata:\n  version: 1.0.0\n  project: Apache TinkerPop\n---\n\n# TinkerPop Documentation Skill\n\nThis skill is about the **craft** of TinkerPop documentation: getting the voice,\naudience, and shape of each kind of document right. The mechanics that keep the\nbuild green (executable code blocks, AsciiDoc wiring) are covered in the\nreferences and matter, but they serve the writing, not the other way around.\n\nAll project documentation lives under `docs\u002Fsrc\u002F` and is **AsciiDoc, never\nMarkdown**. It is organized into several books, each with its own audience and\npurpose. The four directories under `docs\u002Fsrc\u002Fdev\u002F` are themselves separate\nbooks, not one:\n\n| Book | Path | Audience | Purpose |\n|---|---|---|---|\n| Reference | `docs\u002Fsrc\u002Freference\u002F` | Users | The complete, authoritative description of every feature and step |\n| Recipes | `docs\u002Fsrc\u002Frecipes\u002F` | Users | Reusable problem→solution patterns for real tasks |\n| Tutorials | `docs\u002Fsrc\u002Ftutorials\u002F` | Users (learning) | Story-driven walkthroughs of a focused topic |\n| Upgrade | `docs\u002Fsrc\u002Fupgrade\u002F` | Users (upgrading) | Announces what changed in a release and how to adapt |\n| Provider | `docs\u002Fsrc\u002Fdev\u002Fprovider\u002F` | Graph providers | Implementation guidance, provider policies, and the canonical Gremlin semantics |\n| IO | `docs\u002Fsrc\u002Fdev\u002Fio\u002F` | Providers and advanced users | The serialization formats (GraphBinary, GraphSON, GraphML, Gryo) |\n| Developer | `docs\u002Fsrc\u002Fdev\u002Fdeveloper\u002F` | Contributors | Contributing, development environment, committer and release process |\n| Future | `docs\u002Fsrc\u002Fdev\u002Ffuture\u002F` | Contributors | Design proposals for planned or possible changes |\n\nThe full per-book voice guide, with grounded examples from the real docs, is in\n[references\u002Fbooks-and-voice.md](references\u002Fbooks-and-voice.md). Read it before\nwriting in any book you have not written in before. The short version of each\nbook's character:\n\n- **Upgrade** announces. It tells a feature's story — what changed and why it\n  matters — and defers exhaustive detail to the reference docs via `See:` rather\n  than cataloging every edge case itself. A typical entry is short: a paragraph or\n  two and one example. It frames past shortcomings positively and treats breaking\n  changes as a priority.\n- **Reference and Recipes** instruct. They are the focal point for correct\n  usage and established patterns: complete, user-friendly, and formal.\n- **Tutorials** teach through a story but otherwise follow the Reference\u002FRecipes\n  style.\n- **Provider** documents internals in the Reference\u002FRecipes style. The\n  `gremlin-semantics.asciidoc` file is special and load-bearing (see below).\n- **IO** specifies the serialization formats in the same formal, complete style\n  as Provider.\n- **Developer** docs are internal notes, instructions and standard processes for contributors.\n- **Future** holds design proposals for changes under consideration.\n\n## House style (applies to every book)\n\nThese rules hold across all documentation. Existing prose does not always obey\nthem; write to the standard, not to the weakest nearby example.\n\n1. **No em-dash or semicolon to break a sentence.** Prefer two separate\n   sentences, or find a transition word that lets the thought flow. (This is a\n   prose rule. Semicolons inside code, such as the `;[]` output-suppression\n   idiom, are unaffected.)\n2. **Formal means no first or second person.** Do not address the reader as\n   \"you\" or speak as \"I\" or \"we.\" Write about the subject, not about the author\n   or audience. \"The `coalesce()`-step evaluates...\" not \"You can use\n   `coalesce()` to...\".\n3. **Prefer flowing paragraphs over lists.** Use a bulleted or numbered list\n   only when it itemizes something clearly quantifiable, such as the members of\n   an enumeration or a fixed set of options, each needing description. Do not use\n   a list for open-ended or subjective points (for example, \"the benefits of a\n   traversal pattern\"). Those belong in prose.\n4. **Avoid hype and marketing language.** Describe what something does and why it\n   matters in plain, positive terms. Let the capability speak for itself.\n\n### The `llms-summary` attribute\n\nEvery top-level section carries an `[llms-summary=\"...\"]` attribute above its\ntitle. Its value is the one-line description that appears in the `llms.txt`\ndiscovery index, and it is what an AI agent reads to decide whether to open the\npage. Write it for that reader: one or two sentences, no more, self-contained\nand concrete about what the section covers so its scope is clear without opening\nit. Match the book's character — a recipe summary names the problem it solves, a\nreference summary names the feature it describes — and keep it factual, like the\nprose around it. The mechanics (how a summary makes a section its own Markdown\npage, the per-page size budget, `allow-oversize`) live in the Developer docs\nunder Agent-Friendly Documentation, not here.\n\n## Examples must be real and runnable\n\nTinkerPop documentation is unusual: most Gremlin examples are **executed at build\ntime** against a real graph, and their output is inlined automatically. A block\nmarked `[gremlin-groovy,modern]` is run against the modern toy graph and its\noutput is filled in for you. Never invent or hand-write the `==>` output of such\na block.\n\nThe two graphs available to executable blocks are `modern` and `existing`. Use\na bare `[gremlin-groovy]` block for setup that should run without a graph. When\nan example is purely illustrative and must *not* be executed (a hypothetical, an\nerror case, console session text), use `[source,text]` or `[source,groovy]`\ninstead.\n\n**Exception — upgrade documentation is always static.** Every example in\n`docs\u002Fsrc\u002Fupgrade\u002F` is a hand-written `[source,groovy]` or `[source,text]` block,\n**never** an executable `[gremlin-groovy]` block, because an upgrade entry is a\nsnapshot of behavior at a fixed point in history (often an old-vs-new\ncomparison). This reverses the general rule above: in upgrade docs you **do**\nwrite the `==>` output by hand. \"Static\" does not mean \"no output\" — a static\nupgrade example should still show its results so the reader sees the payoff. If an\nupgrade example is missing its output, the fix is to write the output in, **not**\nto convert the block to executable. Do not be talked out of this by the rest of\nthe docs being executable, and do not assume the upgrade book contains executable\nblocks — it does not.\n\nThe authoring details — graph choice, output suppression, `\u003C1>` callouts, and\nthe multi-language story — are in\n[references\u002Fexecutable-blocks.md](references\u002Fexecutable-blocks.md). AsciiDoc\nstructure (anchors, cross-references, section-title length limits for the TOC,\nthe `x.y.z` version placeholder, per-book `index.asciidoc` wiring, admonitions,\nimages) is in\n[references\u002Fasciidoc-and-wiring.md](references\u002Fasciidoc-and-wiring.md).\n\n## The semantics document is load-bearing\n\n`docs\u002Fsrc\u002Fdev\u002Fprovider\u002Fgremlin-semantics.asciidoc` is the canonical description\nof Gremlin's semantics. **It must be updated whenever Gremlin steps, the Gremlin\ngrammar (`Gremlin.g4`), or the semantics code change in any way.** When adding to\nit, follow the patterns already established there for how a concept or step is\ndocumented rather than inventing a new structure. See\n[references\u002Fbooks-and-voice.md](references\u002Fbooks-and-voice.md#provider-documentation)\nfor what those patterns are.\n\n## Don't forget the changelog and upgrade docs\n\nBehavioral and API changes usually need more than reference updates:\n\n- **`CHANGELOG.asciidoc`** (repo root) gets a concise entry in the correct\n  version section. One short clause, written for what the user will see on\n  release day — the net user-facing change, from a usage perspective — not the\n  implementation detail. Do not invent version numbers or release names.\n  - The changelog is not a commit log. Not every commit earns an entry, and a\n    feature built over many commits should have **one** entry, not one per\n    increment. When extending an unreleased feature, fold the change into its\n    existing entry rather than appending a new line; if a change has no\n    user-visible effect, it needs no entry at all.\n- **Upgrade docs** get an entry for user-visible features and especially for\n  breaking changes to public APIs or Gremlin semantics. A breaking change\n  without clear migration guidance in the upgrade docs is incomplete.\n","# TinkerPop Documentation Skill\n\nThis skill is about the **craft** of TinkerPop documentation: getting the voice,\naudience, and shape of each kind of document right. The mechanics that keep the\nbuild green (executable code blocks, AsciiDoc wiring) are covered in the\nreferences and matter, but they serve the writing, not the other way around.\n\nAll project documentation lives under `docs\u002Fsrc\u002F` and is **AsciiDoc, never\nMarkdown**. It is organized into several books, each with its own audience and\npurpose. The four directories under `docs\u002Fsrc\u002Fdev\u002F` are themselves separate\nbooks, not one:\n\n| Book | Path | Audience | Purpose |\n|---|---|---|---|\n| Reference | `docs\u002Fsrc\u002Freference\u002F` | Users | The complete, authoritative description of every feature and step |\n| Recipes | `docs\u002Fsrc\u002Frecipes\u002F` | Users | Reusable problem→solution patterns for real tasks |\n| Tutorials | `docs\u002Fsrc\u002Ftutorials\u002F` | Users (learning) | Story-driven walkthroughs of a focused topic |\n| Upgrade | `docs\u002Fsrc\u002Fupgrade\u002F` | Users (upgrading) | Announces what changed in a release and how to adapt |\n| Provider | `docs\u002Fsrc\u002Fdev\u002Fprovider\u002F` | Graph providers | Implementation guidance, provider policies, and the canonical Gremlin semantics |\n| IO | `docs\u002Fsrc\u002Fdev\u002Fio\u002F` | Providers and advanced users | The serialization formats (GraphBinary, GraphSON, GraphML, Gryo) |\n| Developer | `docs\u002Fsrc\u002Fdev\u002Fdeveloper\u002F` | Contributors | Contributing, development environment, committer and release process |\n| Future | `docs\u002Fsrc\u002Fdev\u002Ffuture\u002F` | Contributors | Design proposals for planned or possible changes |\n\nThe full per-book voice guide, with grounded examples from the real docs, is in\n[references\u002Fbooks-and-voice.md](references\u002Fbooks-and-voice.md). Read it before\nwriting in any book you have not written in before. The short version of each\nbook's character:\n\n- **Upgrade** announces. It tells a feature's story — what changed and why it\n  matters — and defers exhaustive detail to the reference docs via `See:` rather\n  than cataloging every edge case itself. A typical entry is short: a paragraph or\n  two and one example. It frames past shortcomings positively and treats breaking\n  changes as a priority.\n- **Reference and Recipes** instruct. They are the focal point for correct\n  usage and established patterns: complete, user-friendly, and formal.\n- **Tutorials** teach through a story but otherwise follow the Reference\u002FRecipes\n  style.\n- **Provider** documents internals in the Reference\u002FRecipes style. The\n  `gremlin-semantics.asciidoc` file is special and load-bearing (see below).\n- **IO** specifies the serialization formats in the same formal, complete style\n  as Provider.\n- **Developer** docs are internal notes, instructions and standard processes for contributors.\n- **Future** holds design proposals for changes under consideration.\n\n## House style (applies to every book)\n\nThese rules hold across all documentation. Existing prose does not always obey\nthem; write to the standard, not to the weakest nearby example.\n\n1. **No em-dash or semicolon to break a sentence.** Prefer two separate\n   sentences, or find a transition word that lets the thought flow. (This is a\n   prose rule. Semicolons inside code, such as the `;[]` output-suppression\n   idiom, are unaffected.)\n2. **Formal means no first or second person.** Do not address the reader as\n   \"you\" or speak as \"I\" or \"we.\" Write about the subject, not about the author\n   or audience. \"The `coalesce()`-step evaluates...\" not \"You can use\n   `coalesce()` to...\".\n3. **Prefer flowing paragraphs over lists.** Use a bulleted or numbered list\n   only when it itemizes something clearly quantifiable, such as the members of\n   an enumeration or a fixed set of options, each needing description. Do not use\n   a list for open-ended or subjective points (for example, \"the benefits of a\n   traversal pattern\"). Those belong in prose.\n4. **Avoid hype and marketing language.** Describe what something does and why it\n   matters in plain, positive terms. Let the capability speak for itself.\n\n### The `llms-summary` attribute\n\nEvery top-level section carries an `[llms-summary=\"...\"]` attribute above its\ntitle. Its value is the one-line description that appears in the `llms.txt`\ndiscovery index, and it is what an AI agent reads to decide whether to open the\npage. Write it for that reader: one or two sentences, no more, self-contained\nand concrete about what the section covers so its scope is clear without opening\nit. Match the book's character — a recipe summary names the problem it solves, a\nreference summary names the feature it describes — and keep it factual, like the\nprose around it. The mechanics (how a summary makes a section its own Markdown\npage, the per-page size budget, `allow-oversize`) live in the Developer docs\nunder Agent-Friendly Documentation, not here.\n\n## Examples must be real and runnable\n\nTinkerPop documentation is unusual: most Gremlin examples are **executed at build\ntime** against a real graph, and their output is inlined automatically. A block\nmarked `[gremlin-groovy,modern]` is run against the modern toy graph and its\noutput is filled in for you. Never invent or hand-write the `==>` output of such\na block.\n\nThe two graphs available to executable blocks are `modern` and `existing`. Use\na bare `[gremlin-groovy]` block for setup that should run without a graph. When\nan example is purely illustrative and must *not* be executed (a hypothetical, an\nerror case, console session text), use `[source,text]` or `[source,groovy]`\ninstead.\n\n**Exception — upgrade documentation is always static.** Every example in\n`docs\u002Fsrc\u002Fupgrade\u002F` is a hand-written `[source,groovy]` or `[source,text]` block,\n**never** an executable `[gremlin-groovy]` block, because an upgrade entry is a\nsnapshot of behavior at a fixed point in history (often an old-vs-new\ncomparison). This reverses the general rule above: in upgrade docs you **do**\nwrite the `==>` output by hand. \"Static\" does not mean \"no output\" — a static\nupgrade example should still show its results so the reader sees the payoff. If an\nupgrade example is missing its output, the fix is to write the output in, **not**\nto convert the block to executable. Do not be talked out of this by the rest of\nthe docs being executable, and do not assume the upgrade book contains executable\nblocks — it does not.\n\nThe authoring details — graph choice, output suppression, `\u003C1>` callouts, and\nthe multi-language story — are in\n[references\u002Fexecutable-blocks.md](references\u002Fexecutable-blocks.md). AsciiDoc\nstructure (anchors, cross-references, section-title length limits for the TOC,\nthe `x.y.z` version placeholder, per-book `index.asciidoc` wiring, admonitions,\nimages) is in\n[references\u002Fasciidoc-and-wiring.md](references\u002Fasciidoc-and-wiring.md).\n\n## The semantics document is load-bearing\n\n`docs\u002Fsrc\u002Fdev\u002Fprovider\u002Fgremlin-semantics.asciidoc` is the canonical description\nof Gremlin's semantics. **It must be updated whenever Gremlin steps, the Gremlin\ngrammar (`Gremlin.g4`), or the semantics code change in any way.** When adding to\nit, follow the patterns already established there for how a concept or step is\ndocumented rather than inventing a new structure. See\n[references\u002Fbooks-and-voice.md](references\u002Fbooks-and-voice.md#provider-documentation)\nfor what those patterns are.\n\n## Don't forget the changelog and upgrade docs\n\nBehavioral and API changes usually need more than reference updates:\n\n- **`CHANGELOG.asciidoc`** (repo root) gets a concise entry in the correct\n  version section. One short clause, written for what the user will see on\n  release day — the net user-facing change, from a usage perspective — not the\n  implementation detail. Do not invent version numbers or release names.\n  - The changelog is not a commit log. Not every commit earns an entry, and a\n    feature built over many commits should have **one** entry, not one per\n    increment. When extending an unreleased feature, fold the change into its\n    existing entry rather than appending a new line; if a change has no\n    user-visible effect, it needs no entry at all.\n- **Upgrade docs** get an entry for user-visible features and especially for\n  breaking changes to public APIs or Gremlin semantics. A breaking change\n  without clear migration guidance in the upgrade docs is incomplete.\n",{"name":5,"license":15,"metadata":56,"description":59,"compatibility":60},{"project":57,"version":58},"Apache TinkerPop","1.0.0","Writing, editing and reviewing documentation for the Apache TinkerPop project. Use  when  authoring or revising any content under docs\u002Fsrc\u002F — reference docs, recipes, tutorials, upgrade\u002Frelease notes, provider and developer guides — or the CHANGELOG. Covers the TinkerPop documentation voice and the per-book style expectations, the executable Gremlin code-block pipeline, and AsciiDoc conventions. For building and validating code changes, see tinker-dev.\n","Documentation is AsciiDoc under docs\u002Fsrc\u002F, never Markdown.","master","6909f4b34ff2a7f485ad67355b72ca41804513db",".skills\u002Ftinker-doc",864,"https:\u002F\u002Fgithub.com\u002Fapache\u002Ftinkerpop","https:\u002F\u002Ftinkerpop.apache.org\u002F","https:\u002F\u002Fgithub.com\u002Fapache","https:\u002F\u002Fwww.apache.org\u002F","2026-11-13 02:24:34",{"source":8,"skillName":5,"commands":71,"prompt":81,"zipAvailable":82},[72,75,78],{"tool":73,"command":74},"npx","npx skills add apache\u002Ftinkerpop --skill tinker-doc",{"tool":76,"command":77},"bunx","bunx skills add apache\u002Ftinkerpop --skill tinker-doc",{"tool":79,"command":80},"pnpm","pnpm dlx skills add apache\u002Ftinkerpop --skill tinker-doc","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fapache\u002Ftinkerpop\u002Fblob\u002Fmaster\u002F.skills\u002Ftinker-doc\u002FSKILL.md",true,[84,90,94,98],{"path":85,"resourceType":86,"resourceTypeDesc":87,"sizeBytes":88,"sourceHtmlUrl":89},"DESIGN.md","REFERENCE","参考文档",1395,"https:\u002F\u002Fgithub.com\u002Fapache\u002Ftinkerpop\u002Fblob\u002Fmaster\u002F.skills\u002Ftinker-doc\u002FDESIGN.md",{"path":91,"resourceType":86,"resourceTypeDesc":87,"sizeBytes":92,"sourceHtmlUrl":93},"references\u002Fasciidoc-and-wiring.md",7281,"https:\u002F\u002Fgithub.com\u002Fapache\u002Ftinkerpop\u002Fblob\u002Fmaster\u002F.skills\u002Ftinker-doc\u002Freferences\u002Fasciidoc-and-wiring.md",{"path":95,"resourceType":86,"resourceTypeDesc":87,"sizeBytes":96,"sourceHtmlUrl":97},"references\u002Fbooks-and-voice.md",17833,"https:\u002F\u002Fgithub.com\u002Fapache\u002Ftinkerpop\u002Fblob\u002Fmaster\u002F.skills\u002Ftinker-doc\u002Freferences\u002Fbooks-and-voice.md",{"path":99,"resourceType":86,"resourceTypeDesc":87,"sizeBytes":100,"sourceHtmlUrl":101},"references\u002Fexecutable-blocks.md",4422,"https:\u002F\u002Fgithub.com\u002Fapache\u002Ftinkerpop\u002Fblob\u002Fmaster\u002F.skills\u002Ftinker-doc\u002Freferences\u002Fexecutable-blocks.md",[103,138,165],{"skillNo":104,"name":105,"nameZh":6,"description":106,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":107,"categories":108,"keywords":117,"publishedAt":51},"01M6ACGDJBHVT4P5M3EV93MQAR","tinker-review","Graph-based PR review for Apache TinkerPop. Builds a knowledge graph from PR source code, enriches it with semantic relationships guided by domain playbooks, runs structural analysis, and produces an HTML evidence package. Use when asked to review a TinkerPop PR by number.","https:\u002F\u002Fgithub.com\u002Fapache\u002Ftinkerpop\u002Fblob\u002Fmaster\u002F.skills\u002Ftinker-review\u002FSKILL.md",[109,114],{"categoryNo":110,"categoryName":111,"taxonomyType":112,"taxonomyTypeDesc":113},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",{"categoryNo":115,"categoryName":116,"taxonomyType":112,"taxonomyTypeDesc":113},"01JBSEEDCAT000000000000011","运维与部署",[27,118,119,30,9,120,121,122,31,123,124,125,126,127,128,129,130,131,132,133,134,135,46,136,137],"review","tinker review","pr","pr review","html","source code","source","network","node","knowledge graph","beads","analysis","number","docker","access","knowledge","structural","graph","package","git",{"skillNo":139,"name":140,"nameZh":6,"description":141,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":142,"categories":143,"keywords":148,"publishedAt":51},"01M6ACGAP25ER09HE3H2FJ9DJA","tinker-merge","Merge work forward through Apache TinkerPop's release branches toward master (e.g. 3.7-dev, then 3.8-dev, then master), testing each branch locally and stopping before the push. Use only when the operator explicitly asks to merge a pull request, a feature branch, or commits already on a release branch.","https:\u002F\u002Fgithub.com\u002Fapache\u002Ftinkerpop\u002Fblob\u002Fmaster\u002F.skills\u002Ftinker-merge\u002FSKILL.md",[144,147],{"categoryNo":145,"categoryName":146,"taxonomyType":112,"taxonomyTypeDesc":113},"01JBSEEDCAT000000000000007","代码审查",{"categoryNo":110,"categoryName":111,"taxonomyType":112,"taxonomyTypeDesc":113},[149,150,27,151,152,31,153,154,155,156,157,158,30,159,160,9,161,45,162,137,44,163,164],"merge","tinker merge","gh","use","work","only","branches","commits","feature","pull","push","cli","pull request","testing","branch","maven",{"skillNo":166,"name":167,"nameZh":6,"description":168,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":169,"categories":170,"keywords":175,"publishedAt":51},"01M6ACG48DAG4N1P036ZP8V8P5","tinker-dev","Development guidance for the Apache TinkerPop monorepo. Use when building, testing, or contributing to TinkerPop's graph computing framework and its multi-language Gremlin ecosystem (Java, Python, JavaScript, .NET, Go). Covers coding conventions, build recipes, test evaluation, documentation, development environment setup, and Gremlin MCP server usage.","https:\u002F\u002Fgithub.com\u002Fapache\u002Ftinkerpop\u002Fblob\u002Fmaster\u002F.skills\u002Ftinker-dev\u002FSKILL.md",[171,172],{"categoryNo":110,"categoryName":111,"taxonomyType":112,"taxonomyTypeDesc":113},{"categoryNo":173,"categoryName":174,"taxonomyType":112,"taxonomyTypeDesc":113},"01JBSEEDCAT000000000000023","Skill与智能体开发",[44,27,176,177,162,178,179,49,9,180,181,182,183,184,185,186,126,187,188,135,189,31],"tinker dev","coding","MCP","mcp server","contributing","go","framework","ecosystem","monorepo","coding conventions","server","Evaluation","recipes","development environment"]