[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6ACGDJBHVT4P5M3EV93MQAR":3,"skill-same:01M6ACGDJBHVT4P5M3EV93MQAR":322},{"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},"01M6ACGDJBHVT4P5M3EV93MQAR","tinker-review",null,"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.","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-review\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000011","运维与部署",[27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,9,50],"review","tinker review","Tinker","html","source code","source","network","node","knowledge graph","beads","analysis","number","when","access","knowledge","structural","graph","code","package","git","docker","pr review","pr","tinkerpop","2026-11-10 10:12:30",false,"---\nname: tinker-review\ndescription: >\n  Graph-based PR review for Apache TinkerPop. Builds a knowledge graph from\n  PR source code, enriches it with semantic relationships guided by domain\n  playbooks, runs structural analysis, and produces an HTML evidence package.\n  Use when asked to review a TinkerPop PR by number.\nlicense: Apache-2.0\ncompatibility: Requires Docker, Node.js 20+, git and beads (bd). Network access for fetching PR refs.\nmetadata:\n  version: \"0.1.0\"\n  project: Apache TinkerPop\n---\n\n# Graph Review Skill\n\n## Prerequisites\n\n- Docker running (for Gremlin Server)\n- `upstream` remote pointing to `git@github.com:apache\u002Ftinkerpop.git` (fetch only)\n- Node.js 20+ with dependencies installed in `.skills\u002Ftinker-review\u002F`\n- Beads (`bd`) installed, with the repo's beads database available (`bin\u002Fagent-setup.sh --contributor`).\n  The review stops before fetching the PR when `bd` is missing. It runs `bd dolt pull` first and\n  falls back to local state if the pull fails; it never writes to beads.\n\n\n## References (load on demand)\n\n- Read [references\u002Fschema.md](references\u002Fschema.md) when you need to understand what vertices, edges, or properties exist in the knowledge graph (typically during enrichment or when writing raw Gremlin)\n- Read [references\u002Finterfaces.md](references\u002Finterfaces.md) when you need the exact function signatures or data type definitions for a module\n- Read [references\u002Fenrichment-cli.md](references\u002Fenrichment-cli.md) when you need to know what an enrichment CLI command *does* and when to reach for it (the command names below are terse; this is where their meaning lives)\n- Read [references\u002Ffunctional-testing.md](references\u002Ffunctional-testing.md) when you run the optional functional test (step 4) — what `functional\u002Fcli.js` does, how the built server is configured, and how to drive it from the subagent\n- Read [references\u002Fblind-design.md](references\u002Fblind-design.md) when you run the blind design pass (step 3) — picking high-impact surfaces, building the subagent's bundle, its return shape, and reconciling its objections against the beads\n\n## Execution Sequence\n\nWhen invoked with `\u002Freview \u003Cpr-number>`:\n\nThe run has two phases (see [DESIGN.md](DESIGN.md)). **Phase 1** (step 1) is\ndeterministic and builds the graph. **Phase 2** (steps 3–5) is agent-driven —\nenrichment with a blind design pass, an optional functional test, then the\nreport. Step 2 chooses the\nplaybooks that guide Phase 2; step 6 tears down.\n\n### 1. Setup + Phase 1 (deterministic)\n\nRun the review script. This handles everything mechanical:\n\n```bash\nnpm install --prefix .skills\u002Ftinker-review  # only needed once\nnode .skills\u002Ftinker-review\u002Fscripts\u002Freview.js \u003Cpr-number> \u003Crepo-path>\n```\n\nThis performs: check for beads and pull it → fetch PR → create worktree → start\nGremlin Server → extract structure via Tree-sitter → populate knowledge graph →\ndiscover discussions (JIRA, dev list, proposals, PR comments) → discover the PR's\nbeads (records naming the PR or those discussions, their roots and subtrees) →\nrun pattern checks (completeness,\ncoverage gaps, centrality, blast radius, cluster analysis) → write evidence JSON.\n\n**Output:** `\u002Ftmp\u002Fpr-review-\u003Cpr>\u002Fevidence.json`\n**Server:** remains running (the agent needs it for enrichment)\n**Worktree:** available at `\u002Ftmp\u002Fpr-review-\u003Cpr>\u002Fsrc\u002F`\n\nIf re-running, the script clears the earlier run first (container, functional\nserver, worktrees, and the work dir with its old evidence and report).\n\n### 2. Choose the playbooks\n\nPlaybooks carry the domain judgment for Phase 2. `general.md` always applies;\nselect the domain playbooks in two passes:\n\n1. **Orient** — from the changed file paths, gather the candidates:\n   - `gremlin-dart\u002F`, `gremlin-go\u002F`, `gremlin-python\u002F`, `gremlin-dotnet\u002F`, `gremlin-js\u002F`, `gremlin-javascript\u002F` → `playbooks\u002Fglv.md`\n   - `gremlin-core\u002F` with new step patterns → `playbooks\u002Fnew-step.md`\n   - `gremlin-driver\u002F`, `gremlin-server\u002F`, `gremlin-util\u002F` → `playbooks\u002Fdriver-server.md`\n   - `tinkergraph-gremlin\u002F` on a `master` base branch → `playbooks\u002Ftinkergraph.md`\n   - Small change set with linked issue → `playbooks\u002Fbug-fix.md`\n   - `gremlin-language\u002F` or `*.g4` → `playbooks\u002Fgrammar.md`\n   - Deletion-heavy change set (removes a feature\u002Fmodule\u002Fdependency; `listDeleted` returns entries) → `playbooks\u002Fremoval.md`\n2. **Confirm** — read each candidate's **Context** and keep only the ones that\n   truly fit this PR. A path can match a playbook that doesn't apply: a\n   `gremlin-core\u002F` change that adds no step, or a `gremlin-driver\u002F` fix that's\n   really a bug-fix.\n\nThen apply each kept playbook's sections at the point each is used:\n\nThe three working sections (**Enrich**, **Inspect**, **Interpret**) are bullet\nchecklists — one item per action.\n\n| Section | Used when | What you do |\n|---------|-----------|-------------|\n| **Context** | choosing playbooks (above) | Confirm the path-matched playbook fits this PR; set aside the ones that don't. |\n| **Enrich** | improving the graph (step 3) | Run each command bullet to add or re-grade semantic edges. Graph mutation only. |\n| **Inspect** | reading the changed source (step 3) | Check each bullet against the source; record what you find as a *candidate finding* for Interpret. |\n| **Verify** | functional testing (step 4) | Apply the gate, then shape the blind subagent's test battery. `general.md` holds the shared gate\u002Fframework; domains specialize it. |\n| **Interpret** | writing the report (step 5) | Weigh the named `evidence.json` fields together with the Inspect and Verify candidates into `findings` \u002F `openQuestions`. |\n| **Escape** | any time | Honor its stop\u002Fescalate gates; halt or flag when one holds. |\n\nThe working sections split by data flow: **Enrich** writes to the graph,\n**Inspect** reads the changed source into candidate findings, **Verify** exercises\nthe built feature as a user would, and **Interpret** reads the computed\n`evidence.json` checks and weighs the Inspect and Verify candidates into the\nreport. `findings` is an ordered list — Interpret ranks it most-severe-first,\ngrading each entry blocking \u002F high \u002F low.\n\nPhase 1 already computes every structural check — completeness, coverageGaps,\ncentrality, blastRadius, clusters, confidence, externals, orphans — into\n`evidence.json`. Playbooks' Interpret sections reference those results **by field\nname** (e.g. `checks.blastRadius`); they do not re-run checks. The shape and\nmeaning of every field is documented in\n[references\u002Finterfaces.md](references\u002Finterfaces.md) (`Evidence`), which points\nto the per-check `@typedef`s in `scripts\u002Fpatterns\u002F*.js`.\n\n### 3. Phase 2 — Enrichment\n\nThe Gremlin Server is still running. Use `scripts\u002Fenrichment\u002Fcli.js` to\nread from and write to the knowledge graph. Do NOT write your own connection\ncode or import gremlin-js directly — the CLI handles connections for you. For\nwhat each command does and when to use it, see\n[references\u002Fenrichment-cli.md](references\u002Fenrichment-cli.md).\n\nEvery command takes `--workDir \u002Ftmp\u002Fpr-review-\u003Cpr>`, connects using that dir's\n`session.json`, prints its JSON result to stdout, and disconnects:\n```bash\nnode scripts\u002Fenrichment\u002Fcli.js \u003Ccommand> --workDir \u002Ftmp\u002Fpr-review-\u003Cpr> [--options...]\n```\n\nThe command catalog — what each does and when to reach for it — lives in\n[references\u002Fenrichment-cli.md](references\u002Fenrichment-cli.md); run\n`node scripts\u002Fenrichment\u002Fcli.js --help` for exact flags. In brief: **read\ncommands** (`listFunctions`, `listDeleted`, `listExternalRefs`, …) orient you and\nfeed the playbooks; **write commands** (`mapStep`, `addReference`,\n`setEdgeConfidence`, …) add the semantic edges. Edges you create default to\n`INFERRED` — pass `--confidence AMBIGUOUS` for a flagged guess or `EXTRACTED`\nwhen the source states it directly.\n\nThe confidence loop is the backbone of enrichment: `auditConfidence` →\n`listInferred` (your verification worklist) → read the source → `setEdgeConfidence`\nto promote or downgrade, then re-run `auditConfidence` and reflect anything still\n`AMBIGUOUS` in `openQuestions`. It is defined once in `general.md`'s **Enrich**\nsection and inherited by every playbook.\n\n**Read source files:** worktree at `\u002Ftmp\u002Fpr-review-\u003Cpr>\u002Fsrc\u002F`\n\nFollow the playbook's Enrich section (graph writes) and its Inspect section (read\nthe changed source, recording concerns as candidate findings for Interpret to\nweigh at report time). Check Escape conditions.\n\n**Blind design pass (subagent, mandatory when gated).** Decision beads are\ntrusted by default, so the review only fact-checks most of them. A decision that\ngoverns a **high-impact surface** — public API, configuration or protocol;\nuser-visible behaviour; a one-way door such as grammar syntax or a serialization\nformat — is also challenged, and the challenge draws on an agent that has not\nread the beads. `general.md`'s Inspect (*High-impact design*) holds the gate and\nthe challenge questions; [references\u002Fblind-design.md](references\u002Fblind-design.md)\nholds the mechanics:\n\n- **Gate** — pick the high-impact surfaces from the diff (not from the beads).\n  If there are none, skip the pass and record the reason in\n  `appendixBlindDesign.skipped`.\n- **Bundle** — write each surface's contract after and before the change, its\n  release status, the JIRA text and any named standards to\n  `\u002Ftmp\u002Fpr-review-\u003Cpr>\u002Fblind\u002F`.\n- **Isolation** — the subagent reads only that directory. It does NOT get the\n  beads, the PR description, PR or JIRA comment threads, the knowledge graph,\n  `evidence.json`, your Inspect notes, the functional test or implementation\n  code. Brief it as an experienced committer who also implements a provider.\n- **Return** — per surface, what it commits the project to and at most three\n  typed objections (`premise`, `counterargument`, `alternative`), or none.\n- **Reconcile** — you, having read the beads, sort each objection against them:\n  confirmed false premise, unaddressed counterargument, missing alternative,\n  already answered (dropped) or ungoverned surface. Interpret grades the\n  outcomes; at most three challenges reach the report.\n\nThe pass produces candidates, not report entries. It can run in parallel with\nthe functional test (step 4): the two subagents share nothing.\n\n### 4. Phase 2 — Functional Testing (optional, subagent)\n\n**IMPORTANT: Functional testing is NOT running the project's unit tests.**\nDO NOT use `mvn test`. DO NOT run TreeTest, DO NOT run any existing test class.\nThe project's own tests are the author's responsibility — running them tells\nthe reviewer nothing new.\n\nFunctional testing means: test the feature AS A USER WOULD. Connect to a\nGremlin Server built from the PR and submit traversals. Try to use the feature\nbased only on what the documentation says. Try to break it with adversarial\ninputs.\n\n**Gate — decide whether to run it.** Consult the applicable playbooks' **Verify**\nsections. `general.md`'s Verify holds the shared gate: skip functional testing\nwhen the change has no user-facing runtime surface (tests-only, docs-only, a pure\ninternal refactor, build\u002FCI plumbing) and either omit `functionalTest` or record\nthe skip reason. Otherwise continue.\n\n**Build the PR and start the server (mechanical).** The `functional\u002Fcli.js`\ncommand builds the full reactor, locates the assembly, and launches a Gremlin\nServer from the built artifacts on a fresh port (distinct from the knowledge\ngraph server). It reads `pr`\u002F`repoPath` from `session.json` and writes the\nhandle to `functional.json` so teardown can find it:\n\n```bash\nnode .skills\u002Ftinker-review\u002Fscripts\u002Ffunctional\u002Fcli.js start --workDir \u002Ftmp\u002Fpr-review-\u003Cpr>\n```\n\nThis prints `{ url, port, pid, assemblyDir, logFile, ... }`. The build is slow\n(full reactor); on failure, the error names the server log to inspect. See\n[references\u002Ffunctional-testing.md](references\u002Ffunctional-testing.md) for what the\ncommand does and how to drive it.\n\n**Test from the outside.** Spawn a subagent that receives ONLY:\n- PR title\u002Fdescription (what the change claims to do)\n- Relevant documentation sections\n- Relevant Gherkin test features (for expected behavior reference)\n- The Gremlin Server URL (the `url` from the command above), or for Layer 1 the built\n  console's `gremlin.sh`\n\nThe subagent does NOT get: source code, the knowledge graph, the PR's beads, code\nreview findings, or access to the analysis worktree. Brief it as a **minimally experienced\nTinkerPop user** who has only the docs — it tests blind, and its stumbles are\nsignal about how usable the feature is.\n\n**The subagent tests by submitting Gremlin traversals** via the Gremlin Console\nor a GLV client. It devises its own test plan from the docs, executes traversals,\nand attempts adversarial edge cases. The **shape** of the battery comes from the\napplicable playbooks' Verify sections — which languages\u002Flayers to exercise and\nwhat adversarial cases matter for this class of change.\n\n**Layer decision** (the Verify sections say which applies to this PR):\n- **Layer 1 (embedded):** Gremlin Console with TinkerGraph. For core logic changes. Use the\n  console `start` built; [references\u002Ffunctional-testing.md](references\u002Ffunctional-testing.md)\n  gives its path and the script gotchas to pass to the subagent.\n- **Layer 2 (per-GLV wire):** Connect from each GLV to the server. For\n  serialization\u002Ftype changes. Skip if purely computational.\n\n**Label every scenario in the code (required).** Instruct the subagent to keep\nthe test code as the single source of truth for *what* was tested, and to label\neach scenario with a comment carrying a stable id and a one-line intent, e.g.:\n\n```groovy\n\u002F\u002F Scenario A1: group().by(T.id) — validates the id key survives when its reduction is productive\ng.V().group().by(id).by(out().count())\n```\n\nThe subagent returns:\n- **Complete, unabbreviated test code**, every scenario labeled as above — this is\n  `appendixFunctional.testCode` (raw text; the renderer wraps it — do NOT add\n  `\u003Cpre>`\u002F`\u003Ccode>`). No `...`, no \"(abbrev)\"; if the battery is large, that is\n  what the appendix is for.\n- **Themes, not a scenario dump** — group the scenarios into a handful of themes,\n  each citing the labels it spans (e.g. \"Barrier family (A4–A12): …\").\n- Results, adversarial findings, and observations keyed to those labels.\n\nFold these into the `functionalTest` \u002F `appendixFunctional` report fields (step 5)\nand weigh them in Interpret. The count and granularity of `functionalTest.results`\nrows must match the themes, not inflate to imply more tests than the appendix\nactually lists.\n\n### 5. Phase 2 — Produce Report\n\nWrite the narrative JSON, then render.\n\n**Step A:** Read `\u002Ftmp\u002Fpr-review-\u003Cpr>\u002Fevidence.json`. Add narrative fields to\nproduce a complete evidence-with-narrative JSON file. Write it to\n`\u002Ftmp\u002Fpr-review-\u003Cpr>\u002Freport.json`. The narrative fields you must provide:\n\n- `summary` — HTML paragraph describing the PR\n- `clusters.assessment` — HTML prose about what the connected-component clusters mean\n  (`evidence.json` carries `clusters: { assessment: null }` for it; the computed result is\n  `checks.clusters`)\n- `communityAssessment` — HTML, **light by default**: usually one or two sentences on\n  whether the change is coherent\u002Flocalized and what its dominant theme is. Expand *only*\n  when the community **structure itself** shows something non-obvious that no other section\n  captures — e.g. disconnected communities hinting at bundled unrelated changes, a community\n  bridging subsystems that shouldn't be coupled, a changed file stranded in a community about\n  an unrelated concern, or diffuse modularity on a supposedly focused change. Absent such a\n  structural surprise, keep it short and instead use the communities as *supporting evidence*\n  cited in other sections (Guided Walk, Findings, Change Coherence). Do NOT restate the graph\n  literally (vertices\u002Fedges\u002Flabels\u002Fcounts), do NOT re-narrate what Removal References,\n  Coverage, or Blast Radius already report, and do NOT pad. The renderer draws the diagram\n  and the appendix lists membership; you supply only the judgment.\n- `communityNames` — object mapping each community's `id` (from\n  `checks.communities.communities`) to a short name for what it is about, e.g.\n  `{ \"0\": \"Barrier step reduction\", \"1\": \"GraphBinary type IO\" }`. Derive each name\n  from the community's `keyMembers` and `files`; if those leave it unclear, query its\n  members with `g.V().has(\"community\", id)`. Aim for 2–5 words and at most 40\n  characters; the box truncates anything longer. Name the concern, not the structure:\n  the renderer already shows the kind (`implementation`, `test code`, `type hierarchy`,\n  `file group`) next to the name. Any community left unnamed renders as \"Community N\".\n- `guidedWalk` — array of `{ title, badge, badgeText, intro, questions, refs }` objects, one\n  per area of the change, that **orient a reviewer who does not know the code**. Write for a\n  first-time reader: say what the area does in plain terms, not as a tour of class and method\n  names.\n  - `intro` — HTML, one or two plain sentences on what this part of the PR does and why.\n  - `questions` — `[{ text, refs }]`, the questions a reviewer should hold while reading this\n    part. Each `text` (HTML) asks something the reviewer can check or judge (*\"Can two graphs\n    ever write to the same directory?\"*, *\"Is keeping index definitions outside the log\n    reasonable?\"*) and may cite what you found (a finding, a functional-test label). Invite\n    judgment of trade-offs rather than asserting them.\n  - `refs` on a question — the code that answers it, as `{ file, symbol?, lines?, label? }`:\n    `file` is a repo path or unique suffix (`\"TinkerTransaction.java\"`); `symbol` a function,\n    type or field name, or `\"Type.member\"` for a method or field of that type\n    (`\"TinkerStorageGraph.TinkerStorageGraph\"` is the constructor; bare `\"TinkerStorageGraph\"`\n    the class); `label` the chip text. Name\n    the code — **never write line numbers or URLs**: the renderer resolves each ref against\n    `evidence.codeIndex` and links to the file pinned at the reviewed commit with the\n    symbol's lines highlighted. Two or three\n    refs per question is plenty.\n  - `refs` on the item — optional \"Also see\" chips for code that belongs to the whole area.\n  - A ref can cite a bead instead of code: `{ bead: \"tp-abc.3\", label? }` links to that bead\n    in the report's Project Memory. Use it where a question or finding rests on a recorded\n    decision or task; it must be a bead in `discussions.beads.beads`.\n\n  `render.js` prints any ref it cannot resolve; fix the `file`\u002F`symbol` and re-render. An\n  item with only an HTML `body` still renders (older reports).\n- `findings` — array of `{ title, snippet, body, refs? }` objects, ordered most-severe-first (Interpret grades each blocking \u002F high \u002F low); `refs` take the same code or bead refs as `guidedWalk`\n- `openQuestions` — array of `{ title, body, meta, refs? }` objects\n- `functionalTest` — `{ plan, results: [{name, pass, output}], observations }` (if testing was done).\n  `plan` is HTML and `observations` is an array of HTML strings (one per insight); both and surface **themes and insights** — what\n  families of behavior were exercised and what was learned — not a per-scenario\n  list. `results` rows are **theme-level**: each `name` names a theme and the\n  scenario labels it spans (e.g. `\"Barrier family (A4–A12)\"`), so the PASS\u002FFAIL\n  grid stays scannable and every row is backed by labeled code in the appendix.\n  Do not enumerate every scenario here and do not let the row count imply more\n  tests than the appendix lists.\n- `appendixFunctional` — `{ environment, testCode, fullOutput }` (if testing was done).\n  `environment` is HTML. `testCode` and `fullOutput` are **raw text** — the\n  renderer wraps them in `\u003Cpre>\u003Ccode>`, so do NOT add `\u003Cpre>`\u002F`\u003Ccode>`\u002F`\u003Cp>`\n  yourself. `testCode` is the **complete, unabbreviated** labeled battery from the\n  subagent (see step 4); it is the source of truth the Functional Test section\n  summarizes by label.\n- `appendixBlindDesign` — the blind design pass (step 3): either\n  `{ skipped }`, the gate reason as HTML, or `{ surfaces, objections }`.\n  `surfaces` is `[{ id, kind, name, commitment }]`; `objections` is\n  `[{ id, surface, type, claim, outcome, note }]`, one per objection the\n  subagent returned, with `outcome` one of `finding`, `openQuestion` or\n  `dropped` and `note` (HTML) saying which decision answers or fails to answer\n  it. Every entry in `findings` or `openQuestions` that came from the pass names\n  its objection id, so a reader can trace it back.\n\nAll `body`, `intro` and question `text` fields (and `functionalTest.plan`\u002F`observations`, `appendixFunctional.environment`,\n`appendixBlindDesign.skipped` and each objection's `note`)\nare HTML — use `\u003Ccode>`, `\u003Cstrong>`, `\u003Cul>`, `\u003Cp>` as needed. The raw-text fields\nnoted above are the exception. The renderer handles all layout, CSS, and structure.\n\n**Step B:** Render the report:\n\n```bash\nnode .skills\u002Ftinker-review\u002Fscripts\u002Frenderer\u002Frender.js \u002Ftmp\u002Fpr-review-\u003Cpr>\u002Freport.json \u002Ftmp\u002Fpr-review-\u003Cpr>\u002Freport.html\n```\n\nThe renderer produces a complete HTML report with consistent structure.\nEvery section is always present — if you didn't provide a field, it shows\n\"Section not provided\" in red. DO NOT write HTML yourself.\n\n### 6. Teardown\n\n```bash\nnode -e \"import { teardown } from '.\u002Fscripts\u002Freview.js'; await teardown('\u002Ftmp\u002Fpr-review-\u003Cpr>');\"\n```\n\nThis stops the knowledge graph server, removes the `src\u002F` worktree and deletes\nthe `pr-review\u002F\u003Cpr>` branch. If a functional test ran (step 4), teardown also\nstops that server (via its `pid` in `functional.json`) and removes the `build\u002F`\nworktree. Call this ONLY after all phases are complete.\n\nTeardown **keeps** `\u002Ftmp\u002Fpr-review-\u003Cpr>\u002F`: it holds `report.html`, `report.json`\nand `evidence.json`. Delete it yourself once the report is no longer needed\n(`rm -rf \u002Ftmp\u002Fpr-review-\u003Cpr>`). Re-running the review on the same PR clears it,\nalong with anything the earlier run left running.\n\n## Important Notes\n\n- NEVER push to the `upstream` remote. It is fetch-only.\n- ALL output goes to `\u002Ftmp\u002Fpr-review-\u003Cpr>\u002F` — never write inside the git repo.\n- The Gremlin Server stays alive until teardown. Don't kill it early.\n- If re-running, the script clears the earlier run first: its container, functional\n  server, worktrees and the whole work dir, including any old report.\n- The agent populates JSON narrative fields; the renderer produces HTML. No agent writes raw HTML.\n","# Graph Review Skill\n\n## Prerequisites\n\n- Docker running (for Gremlin Server)\n- `upstream` remote pointing to `git@github.com:apache\u002Ftinkerpop.git` (fetch only)\n- Node.js 20+ with dependencies installed in `.skills\u002Ftinker-review\u002F`\n- Beads (`bd`) installed, with the repo's beads database available (`bin\u002Fagent-setup.sh --contributor`).\n  The review stops before fetching the PR when `bd` is missing. It runs `bd dolt pull` first and\n  falls back to local state if the pull fails; it never writes to beads.\n\n\n## References (load on demand)\n\n- Read [references\u002Fschema.md](references\u002Fschema.md) when you need to understand what vertices, edges, or properties exist in the knowledge graph (typically during enrichment or when writing raw Gremlin)\n- Read [references\u002Finterfaces.md](references\u002Finterfaces.md) when you need the exact function signatures or data type definitions for a module\n- Read [references\u002Fenrichment-cli.md](references\u002Fenrichment-cli.md) when you need to know what an enrichment CLI command *does* and when to reach for it (the command names below are terse; this is where their meaning lives)\n- Read [references\u002Ffunctional-testing.md](references\u002Ffunctional-testing.md) when you run the optional functional test (step 4) — what `functional\u002Fcli.js` does, how the built server is configured, and how to drive it from the subagent\n- Read [references\u002Fblind-design.md](references\u002Fblind-design.md) when you run the blind design pass (step 3) — picking high-impact surfaces, building the subagent's bundle, its return shape, and reconciling its objections against the beads\n\n## Execution Sequence\n\nWhen invoked with `\u002Freview \u003Cpr-number>`:\n\nThe run has two phases (see [DESIGN.md](DESIGN.md)). **Phase 1** (step 1) is\ndeterministic and builds the graph. **Phase 2** (steps 3–5) is agent-driven —\nenrichment with a blind design pass, an optional functional test, then the\nreport. Step 2 chooses the\nplaybooks that guide Phase 2; step 6 tears down.\n\n### 1. Setup + Phase 1 (deterministic)\n\nRun the review script. This handles everything mechanical:\n\n```bash\nnpm install --prefix .skills\u002Ftinker-review  # only needed once\nnode .skills\u002Ftinker-review\u002Fscripts\u002Freview.js \u003Cpr-number> \u003Crepo-path>\n```\n\nThis performs: check for beads and pull it → fetch PR → create worktree → start\nGremlin Server → extract structure via Tree-sitter → populate knowledge graph →\ndiscover discussions (JIRA, dev list, proposals, PR comments) → discover the PR's\nbeads (records naming the PR or those discussions, their roots and subtrees) →\nrun pattern checks (completeness,\ncoverage gaps, centrality, blast radius, cluster analysis) → write evidence JSON.\n\n**Output:** `\u002Ftmp\u002Fpr-review-\u003Cpr>\u002Fevidence.json`\n**Server:** remains running (the agent needs it for enrichment)\n**Worktree:** available at `\u002Ftmp\u002Fpr-review-\u003Cpr>\u002Fsrc\u002F`\n\nIf re-running, the script clears the earlier run first (container, functional\nserver, worktrees, and the work dir with its old evidence and report).\n\n### 2. Choose the playbooks\n\nPlaybooks carry the domain judgment for Phase 2. `general.md` always applies;\nselect the domain playbooks in two passes:\n\n1. **Orient** — from the changed file paths, gather the candidates:\n   - `gremlin-dart\u002F`, `gremlin-go\u002F`, `gremlin-python\u002F`, `gremlin-dotnet\u002F`, `gremlin-js\u002F`, `gremlin-javascript\u002F` → `playbooks\u002Fglv.md`\n   - `gremlin-core\u002F` with new step patterns → `playbooks\u002Fnew-step.md`\n   - `gremlin-driver\u002F`, `gremlin-server\u002F`, `gremlin-util\u002F` → `playbooks\u002Fdriver-server.md`\n   - `tinkergraph-gremlin\u002F` on a `master` base branch → `playbooks\u002Ftinkergraph.md`\n   - Small change set with linked issue → `playbooks\u002Fbug-fix.md`\n   - `gremlin-language\u002F` or `*.g4` → `playbooks\u002Fgrammar.md`\n   - Deletion-heavy change set (removes a feature\u002Fmodule\u002Fdependency; `listDeleted` returns entries) → `playbooks\u002Fremoval.md`\n2. **Confirm** — read each candidate's **Context** and keep only the ones that\n   truly fit this PR. A path can match a playbook that doesn't apply: a\n   `gremlin-core\u002F` change that adds no step, or a `gremlin-driver\u002F` fix that's\n   really a bug-fix.\n\nThen apply each kept playbook's sections at the point each is used:\n\nThe three working sections (**Enrich**, **Inspect**, **Interpret**) are bullet\nchecklists — one item per action.\n\n| Section | Used when | What you do |\n|---------|-----------|-------------|\n| **Context** | choosing playbooks (above) | Confirm the path-matched playbook fits this PR; set aside the ones that don't. |\n| **Enrich** | improving the graph (step 3) | Run each command bullet to add or re-grade semantic edges. Graph mutation only. |\n| **Inspect** | reading the changed source (step 3) | Check each bullet against the source; record what you find as a *candidate finding* for Interpret. |\n| **Verify** | functional testing (step 4) | Apply the gate, then shape the blind subagent's test battery. `general.md` holds the shared gate\u002Fframework; domains specialize it. |\n| **Interpret** | writing the report (step 5) | Weigh the named `evidence.json` fields together with the Inspect and Verify candidates into `findings` \u002F `openQuestions`. |\n| **Escape** | any time | Honor its stop\u002Fescalate gates; halt or flag when one holds. |\n\nThe working sections split by data flow: **Enrich** writes to the graph,\n**Inspect** reads the changed source into candidate findings, **Verify** exercises\nthe built feature as a user would, and **Interpret** reads the computed\n`evidence.json` checks and weighs the Inspect and Verify candidates into the\nreport. `findings` is an ordered list — Interpret ranks it most-severe-first,\ngrading each entry blocking \u002F high \u002F low.\n\nPhase 1 already computes every structural check — completeness, coverageGaps,\ncentrality, blastRadius, clusters, confidence, externals, orphans — into\n`evidence.json`. Playbooks' Interpret sections reference those results **by field\nname** (e.g. `checks.blastRadius`); they do not re-run checks. The shape and\nmeaning of every field is documented in\n[references\u002Finterfaces.md](references\u002Finterfaces.md) (`Evidence`), which points\nto the per-check `@typedef`s in `scripts\u002Fpatterns\u002F*.js`.\n\n### 3. Phase 2 — Enrichment\n\nThe Gremlin Server is still running. Use `scripts\u002Fenrichment\u002Fcli.js` to\nread from and write to the knowledge graph. Do NOT write your own connection\ncode or import gremlin-js directly — the CLI handles connections for you. For\nwhat each command does and when to use it, see\n[references\u002Fenrichment-cli.md](references\u002Fenrichment-cli.md).\n\nEvery command takes `--workDir \u002Ftmp\u002Fpr-review-\u003Cpr>`, connects using that dir's\n`session.json`, prints its JSON result to stdout, and disconnects:\n```bash\nnode scripts\u002Fenrichment\u002Fcli.js \u003Ccommand> --workDir \u002Ftmp\u002Fpr-review-\u003Cpr> [--options...]\n```\n\nThe command catalog — what each does and when to reach for it — lives in\n[references\u002Fenrichment-cli.md](references\u002Fenrichment-cli.md); run\n`node scripts\u002Fenrichment\u002Fcli.js --help` for exact flags. In brief: **read\ncommands** (`listFunctions`, `listDeleted`, `listExternalRefs`, …) orient you and\nfeed the playbooks; **write commands** (`mapStep`, `addReference`,\n`setEdgeConfidence`, …) add the semantic edges. Edges you create default to\n`INFERRED` — pass `--confidence AMBIGUOUS` for a flagged guess or `EXTRACTED`\nwhen the source states it directly.\n\nThe confidence loop is the backbone of enrichment: `auditConfidence` →\n`listInferred` (your verification worklist) → read the source → `setEdgeConfidence`\nto promote or downgrade, then re-run `auditConfidence` and reflect anything still\n`AMBIGUOUS` in `openQuestions`. It is defined once in `general.md`'s **Enrich**\nsection and inherited by every playbook.\n\n**Read source files:** worktree at `\u002Ftmp\u002Fpr-review-\u003Cpr>\u002Fsrc\u002F`\n\nFollow the playbook's Enrich section (graph writes) and its Inspect section (read\nthe changed source, recording concerns as candidate findings for Interpret to\nweigh at report time). Check Escape conditions.\n\n**Blind design pass (subagent, mandatory when gated).** Decision beads are\ntrusted by default, so the review only fact-checks most of them. A decision that\ngoverns a **high-impact surface** — public API, configuration or protocol;\nuser-visible behaviour; a one-way door such as grammar syntax or a serialization\nformat — is also challenged, and the challenge draws on an agent that has not\nread the beads. `general.md`'s Inspect (*High-impact design*) holds the gate and\nthe challenge questions; [references\u002Fblind-design.md](references\u002Fblind-design.md)\nholds the mechanics:\n\n- **Gate** — pick the high-impact surfaces from the diff (not from the beads).\n  If there are none, skip the pass and record the reason in\n  `appendixBlindDesign.skipped`.\n- **Bundle** — write each surface's contract after and before the change, its\n  release status, the JIRA text and any named standards to\n  `\u002Ftmp\u002Fpr-review-\u003Cpr>\u002Fblind\u002F`.\n- **Isolation** — the subagent reads only that directory. It does NOT get the\n  beads, the PR description, PR or JIRA comment threads, the knowledge graph,\n  `evidence.json`, your Inspect notes, the functional test or implementation\n  code. Brief it as an experienced committer who also implements a provider.\n- **Return** — per surface, what it commits the project to and at most three\n  typed objections (`premise`, `counterargument`, `alternative`), or none.\n- **Reconcile** — you, having read the beads, sort each objection against them:\n  confirmed false premise, unaddressed counterargument, missing alternative,\n  already answered (dropped) or ungoverned surface. Interpret grades the\n  outcomes; at most three challenges reach the report.\n\nThe pass produces candidates, not report entries. It can run in parallel with\nthe functional test (step 4): the two subagents share nothing.\n\n### 4. Phase 2 — Functional Testing (optional, subagent)\n\n**IMPORTANT: Functional testing is NOT running the project's unit tests.**\nDO NOT use `mvn test`. DO NOT run TreeTest, DO NOT run any existing test class.\nThe project's own tests are the author's responsibility — running them tells\nthe reviewer nothing new.\n\nFunctional testing means: test the feature AS A USER WOULD. Connect to a\nGremlin Server built from the PR and submit traversals. Try to use the feature\nbased only on what the documentation says. Try to break it with adversarial\ninputs.\n\n**Gate — decide whether to run it.** Consult the applicable playbooks' **Verify**\nsections. `general.md`'s Verify holds the shared gate: skip functional testing\nwhen the change has no user-facing runtime surface (tests-only, docs-only, a pure\ninternal refactor, build\u002FCI plumbing) and either omit `functionalTest` or record\nthe skip reason. Otherwise continue.\n\n**Build the PR and start the server (mechanical).** The `functional\u002Fcli.js`\ncommand builds the full reactor, locates the assembly, and launches a Gremlin\nServer from the built artifacts on a fresh port (distinct from the knowledge\ngraph server). It reads `pr`\u002F`repoPath` from `session.json` and writes the\nhandle to `functional.json` so teardown can find it:\n\n```bash\nnode .skills\u002Ftinker-review\u002Fscripts\u002Ffunctional\u002Fcli.js start --workDir \u002Ftmp\u002Fpr-review-\u003Cpr>\n```\n\nThis prints `{ url, port, pid, assemblyDir, logFile, ... }`. The build is slow\n(full reactor); on failure, the error names the server log to inspect. See\n[references\u002Ffunctional-testing.md](references\u002Ffunctional-testing.md) for what the\ncommand does and how to drive it.\n\n**Test from the outside.** Spawn a subagent that receives ONLY:\n- PR title\u002Fdescription (what the change claims to do)\n- Relevant documentation sections\n- Relevant Gherkin test features (for expected behavior reference)\n- The Gremlin Server URL (the `url` from the command above), or for Layer 1 the built\n  console's `gremlin.sh`\n\nThe subagent does NOT get: source code, the knowledge graph, the PR's beads, code\nreview findings, or access to the analysis worktree. Brief it as a **minimally experienced\nTinkerPop user** who has only the docs — it tests blind, and its stumbles are\nsignal about how usable the feature is.\n\n**The subagent tests by submitting Gremlin traversals** via the Gremlin Console\nor a GLV client. It devises its own test plan from the docs, executes traversals,\nand attempts adversarial edge cases. The **shape** of the battery comes from the\napplicable playbooks' Verify sections — which languages\u002Flayers to exercise and\nwhat adversarial cases matter for this class of change.\n\n**Layer decision** (the Verify sections say which applies to this PR):\n- **Layer 1 (embedded):** Gremlin Console with TinkerGraph. For core logic changes. Use the\n  console `start` built; [references\u002Ffunctional-testing.md](references\u002Ffunctional-testing.md)\n  gives its path and the script gotchas to pass to the subagent.\n- **Layer 2 (per-GLV wire):** Connect from each GLV to the server. For\n  serialization\u002Ftype changes. Skip if purely computational.\n\n**Label every scenario in the code (required).** Instruct the subagent to keep\nthe test code as the single source of truth for *what* was tested, and to label\neach scenario with a comment carrying a stable id and a one-line intent, e.g.:\n\n```groovy\n\u002F\u002F Scenario A1: group().by(T.id) — validates the id key survives when its reduction is productive\ng.V().group().by(id).by(out().count())\n```\n\nThe subagent returns:\n- **Complete, unabbreviated test code**, every scenario labeled as above — this is\n  `appendixFunctional.testCode` (raw text; the renderer wraps it — do NOT add\n  `\u003Cpre>`\u002F`\u003Ccode>`). No `...`, no \"(abbrev)\"; if the battery is large, that is\n  what the appendix is for.\n- **Themes, not a scenario dump** — group the scenarios into a handful of themes,\n  each citing the labels it spans (e.g. \"Barrier family (A4–A12): …\").\n- Results, adversarial findings, and observations keyed to those labels.\n\nFold these into the `functionalTest` \u002F `appendixFunctional` report fields (step 5)\nand weigh them in Interpret. The count and granularity of `functionalTest.results`\nrows must match the themes, not inflate to imply more tests than the appendix\nactually lists.\n\n### 5. Phase 2 — Produce Report\n\nWrite the narrative JSON, then render.\n\n**Step A:** Read `\u002Ftmp\u002Fpr-review-\u003Cpr>\u002Fevidence.json`. Add narrative fields to\nproduce a complete evidence-with-narrative JSON file. Write it to\n`\u002Ftmp\u002Fpr-review-\u003Cpr>\u002Freport.json`. The narrative fields you must provide:\n\n- `summary` — HTML paragraph describing the PR\n- `clusters.assessment` — HTML prose about what the connected-component clusters mean\n  (`evidence.json` carries `clusters: { assessment: null }` for it; the computed result is\n  `checks.clusters`)\n- `communityAssessment` — HTML, **light by default**: usually one or two sentences on\n  whether the change is coherent\u002Flocalized and what its dominant theme is. Expand *only*\n  when the community **structure itself** shows something non-obvious that no other section\n  captures — e.g. disconnected communities hinting at bundled unrelated changes, a community\n  bridging subsystems that shouldn't be coupled, a changed file stranded in a community about\n  an unrelated concern, or diffuse modularity on a supposedly focused change. Absent such a\n  structural surprise, keep it short and instead use the communities as *supporting evidence*\n  cited in other sections (Guided Walk, Findings, Change Coherence). Do NOT restate the graph\n  literally (vertices\u002Fedges\u002Flabels\u002Fcounts), do NOT re-narrate what Removal References,\n  Coverage, or Blast Radius already report, and do NOT pad. The renderer draws the diagram\n  and the appendix lists membership; you supply only the judgment.\n- `communityNames` — object mapping each community's `id` (from\n  `checks.communities.communities`) to a short name for what it is about, e.g.\n  `{ \"0\": \"Barrier step reduction\", \"1\": \"GraphBinary type IO\" }`. Derive each name\n  from the community's `keyMembers` and `files`; if those leave it unclear, query its\n  members with `g.V().has(\"community\", id)`. Aim for 2–5 words and at most 40\n  characters; the box truncates anything longer. Name the concern, not the structure:\n  the renderer already shows the kind (`implementation`, `test code`, `type hierarchy`,\n  `file group`) next to the name. Any community left unnamed renders as \"Community N\".\n- `guidedWalk` — array of `{ title, badge, badgeText, intro, questions, refs }` objects, one\n  per area of the change, that **orient a reviewer who does not know the code**. Write for a\n  first-time reader: say what the area does in plain terms, not as a tour of class and method\n  names.\n  - `intro` — HTML, one or two plain sentences on what this part of the PR does and why.\n  - `questions` — `[{ text, refs }]`, the questions a reviewer should hold while reading this\n    part. Each `text` (HTML) asks something the reviewer can check or judge (*\"Can two graphs\n    ever write to the same directory?\"*, *\"Is keeping index definitions outside the log\n    reasonable?\"*) and may cite what you found (a finding, a functional-test label). Invite\n    judgment of trade-offs rather than asserting them.\n  - `refs` on a question — the code that answers it, as `{ file, symbol?, lines?, label? }`:\n    `file` is a repo path or unique suffix (`\"TinkerTransaction.java\"`); `symbol` a function,\n    type or field name, or `\"Type.member\"` for a method or field of that type\n    (`\"TinkerStorageGraph.TinkerStorageGraph\"` is the constructor; bare `\"TinkerStorageGraph\"`\n    the class); `label` the chip text. Name\n    the code — **never write line numbers or URLs**: the renderer resolves each ref against\n    `evidence.codeIndex` and links to the file pinned at the reviewed commit with the\n    symbol's lines highlighted. Two or three\n    refs per question is plenty.\n  - `refs` on the item — optional \"Also see\" chips for code that belongs to the whole area.\n  - A ref can cite a bead instead of code: `{ bead: \"tp-abc.3\", label? }` links to that bead\n    in the report's Project Memory. Use it where a question or finding rests on a recorded\n    decision or task; it must be a bead in `discussions.beads.beads`.\n\n  `render.js` prints any ref it cannot resolve; fix the `file`\u002F`symbol` and re-render. An\n  item with only an HTML `body` still renders (older reports).\n- `findings` — array of `{ title, snippet, body, refs? }` objects, ordered most-severe-first (Interpret grades each blocking \u002F high \u002F low); `refs` take the same code or bead refs as `guidedWalk`\n- `openQuestions` — array of `{ title, body, meta, refs? }` objects\n- `functionalTest` — `{ plan, results: [{name, pass, output}], observations }` (if testing was done).\n  `plan` is HTML and `observations` is an array of HTML strings (one per insight); both and surface **themes and insights** — what\n  families of behavior were exercised and what was learned — not a per-scenario\n  list. `results` rows are **theme-level**: each `name` names a theme and the\n  scenario labels it spans (e.g. `\"Barrier family (A4–A12)\"`), so the PASS\u002FFAIL\n  grid stays scannable and every row is backed by labeled code in the appendix.\n  Do not enumerate every scenario here and do not let the row count imply more\n  tests than the appendix lists.\n- `appendixFunctional` — `{ environment, testCode, fullOutput }` (if testing was done).\n  `environment` is HTML. `testCode` and `fullOutput` are **raw text** — the\n  renderer wraps them in `\u003Cpre>\u003Ccode>`, so do NOT add `\u003Cpre>`\u002F`\u003Ccode>`\u002F`\u003Cp>`\n  yourself. `testCode` is the **complete, unabbreviated** labeled battery from the\n  subagent (see step 4); it is the source of truth the Functional Test section\n  summarizes by label.\n- `appendixBlindDesign` — the blind design pass (step 3): either\n  `{ skipped }`, the gate reason as HTML, or `{ surfaces, objections }`.\n  `surfaces` is `[{ id, kind, name, commitment }]`; `objections` is\n  `[{ id, surface, type, claim, outcome, note }]`, one per objection the\n  subagent returned, with `outcome` one of `finding`, `openQuestion` or\n  `dropped` and `note` (HTML) saying which decision answers or fails to answer\n  it. Every entry in `findings` or `openQuestions` that came from the pass names\n  its objection id, so a reader can trace it back.\n\nAll `body`, `intro` and question `text` fields (and `functionalTest.plan`\u002F`observations`, `appendixFunctional.environment`,\n`appendixBlindDesign.skipped` and each objection's `note`)\nare HTML — use `\u003Ccode>`, `\u003Cstrong>`, `\u003Cul>`, `\u003Cp>` as needed. The raw-text fields\nnoted above are the exception. The renderer handles all layout, CSS, and structure.\n\n**Step B:** Render the report:\n\n```bash\nnode .skills\u002Ftinker-review\u002Fscripts\u002Frenderer\u002Frender.js \u002Ftmp\u002Fpr-review-\u003Cpr>\u002Freport.json \u002Ftmp\u002Fpr-review-\u003Cpr>\u002Freport.html\n```\n\nThe renderer produces a complete HTML report with consistent structure.\nEvery section is always present — if you didn't provide a field, it shows\n\"Section not provided\" in red. DO NOT write HTML yourself.\n\n### 6. Teardown\n\n```bash\nnode -e \"import { teardown } from '.\u002Fscripts\u002Freview.js'; await teardown('\u002Ftmp\u002Fpr-review-\u003Cpr>');\"\n```\n\nThis stops the knowledge graph server, removes the `src\u002F` worktree and deletes\nthe `pr-review\u002F\u003Cpr>` branch. If a functional test ran (step 4), teardown also\nstops that server (via its `pid` in `functional.json`) and removes the `build\u002F`\nworktree. Call this ONLY after all phases are complete.\n\nTeardown **keeps** `\u002Ftmp\u002Fpr-review-\u003Cpr>\u002F`: it holds `report.html`, `report.json`\nand `evidence.json`. Delete it yourself once the report is no longer needed\n(`rm -rf \u002Ftmp\u002Fpr-review-\u003Cpr>`). Re-running the review on the same PR clears it,\nalong with anything the earlier run left running.\n\n## Important Notes\n\n- NEVER push to the `upstream` remote. It is fetch-only.\n- ALL output goes to `\u002Ftmp\u002Fpr-review-\u003Cpr>\u002F` — never write inside the git repo.\n- The Gremlin Server stays alive until teardown. Don't kill it early.\n- If re-running, the script clears the earlier run first: its container, functional\n  server, worktrees and the whole work dir, including any old report.\n- The agent populates JSON narrative fields; the renderer produces HTML. No agent writes raw HTML.\n",{"name":5,"license":15,"metadata":56,"description":59,"compatibility":60},{"project":57,"version":58},"Apache TinkerPop","0.1.0","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.\n","Requires Docker, Node.js 20+, git and beads (bd). Network access for fetching PR refs.","master","3b0fdf96c122ddf4049ab60358188ad1e1824a76",".skills\u002Ftinker-review",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-14 08:48:41",{"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-review",{"tool":76,"command":77},"bunx","bunx skills add apache\u002Ftinkerpop --skill tinker-review",{"tool":79,"command":80},"pnpm","pnpm dlx skills add apache\u002Ftinkerpop --skill tinker-review","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fapache\u002Ftinkerpop\u002Fblob\u002Fmaster\u002F.skills\u002Ftinker-review\u002FSKILL.md",true,[84,90,96,100,104,108,112,116,120,124,128,132,136,140,144,148,152,156,162,166,170,174,178,182,186,190,194,198,202,206,210,214,218,222,226,230,234,238,242,246,250,254,258,262,266,270,274,278,282,286,290,294,298,302,306,310,314,318],{"path":85,"resourceType":86,"resourceTypeDesc":87,"sizeBytes":88,"sourceHtmlUrl":89},".gitignore","OTHER","其他",34,"https:\u002F\u002Fgithub.com\u002Fapache\u002Ftinkerpop\u002Fblob\u002Fmaster\u002F.skills\u002Ftinker-review\u002F.gitignore",{"path":91,"resourceType":92,"resourceTypeDesc":93,"sizeBytes":94,"sourceHtmlUrl":95},"DESIGN.md","REFERENCE","参考文档",9802,"https:\u002F\u002Fgithub.com\u002Fapache\u002Ftinkerpop\u002Fblob\u002Fmaster\u002F.skills\u002Ftinker-review\u002FDESIGN.md",{"path":97,"resourceType":92,"resourceTypeDesc":93,"sizeBytes":98,"sourceHtmlUrl":99},"package-lock.json",11440,"https:\u002F\u002Fgithub.com\u002Fapache\u002Ftinkerpop\u002Fblob\u002Fmaster\u002F.skills\u002Ftinker-review\u002Fpackage-lock.json",{"path":101,"resourceType":92,"resourceTypeDesc":93,"sizeBytes":102,"sourceHtmlUrl":103},"package.json",509,"https:\u002F\u002Fgithub.com\u002Fapache\u002Ftinkerpop\u002Fblob\u002Fmaster\u002F.skills\u002Ftinker-review\u002Fpackage.json",{"path":105,"resourceType":92,"resourceTypeDesc":93,"sizeBytes":106,"sourceHtmlUrl":107},"playbooks\u002Fbug-fix.md",2367,"https:\u002F\u002Fgithub.com\u002Fapache\u002Ftinkerpop\u002Fblob\u002Fmaster\u002F.skills\u002Ftinker-review\u002Fplaybooks\u002Fbug-fix.md",{"path":109,"resourceType":92,"resourceTypeDesc":93,"sizeBytes":110,"sourceHtmlUrl":111},"playbooks\u002Fdriver-server.md",3835,"https:\u002F\u002Fgithub.com\u002Fapache\u002Ftinkerpop\u002Fblob\u002Fmaster\u002F.skills\u002Ftinker-review\u002Fplaybooks\u002Fdriver-server.md",{"path":113,"resourceType":92,"resourceTypeDesc":93,"sizeBytes":114,"sourceHtmlUrl":115},"playbooks\u002Fgeneral.md",11604,"https:\u002F\u002Fgithub.com\u002Fapache\u002Ftinkerpop\u002Fblob\u002Fmaster\u002F.skills\u002Ftinker-review\u002Fplaybooks\u002Fgeneral.md",{"path":117,"resourceType":92,"resourceTypeDesc":93,"sizeBytes":118,"sourceHtmlUrl":119},"playbooks\u002Fglv.md",2874,"https:\u002F\u002Fgithub.com\u002Fapache\u002Ftinkerpop\u002Fblob\u002Fmaster\u002F.skills\u002Ftinker-review\u002Fplaybooks\u002Fglv.md",{"path":121,"resourceType":92,"resourceTypeDesc":93,"sizeBytes":122,"sourceHtmlUrl":123},"playbooks\u002Fgrammar.md",2283,"https:\u002F\u002Fgithub.com\u002Fapache\u002Ftinkerpop\u002Fblob\u002Fmaster\u002F.skills\u002Ftinker-review\u002Fplaybooks\u002Fgrammar.md",{"path":125,"resourceType":92,"resourceTypeDesc":93,"sizeBytes":126,"sourceHtmlUrl":127},"playbooks\u002Fnew-step.md",3076,"https:\u002F\u002Fgithub.com\u002Fapache\u002Ftinkerpop\u002Fblob\u002Fmaster\u002F.skills\u002Ftinker-review\u002Fplaybooks\u002Fnew-step.md",{"path":129,"resourceType":92,"resourceTypeDesc":93,"sizeBytes":130,"sourceHtmlUrl":131},"playbooks\u002Fremoval.md",3260,"https:\u002F\u002Fgithub.com\u002Fapache\u002Ftinkerpop\u002Fblob\u002Fmaster\u002F.skills\u002Ftinker-review\u002Fplaybooks\u002Fremoval.md",{"path":133,"resourceType":92,"resourceTypeDesc":93,"sizeBytes":134,"sourceHtmlUrl":135},"playbooks\u002Ftinkergraph.md",6621,"https:\u002F\u002Fgithub.com\u002Fapache\u002Ftinkerpop\u002Fblob\u002Fmaster\u002F.skills\u002Ftinker-review\u002Fplaybooks\u002Ftinkergraph.md",{"path":137,"resourceType":92,"resourceTypeDesc":93,"sizeBytes":138,"sourceHtmlUrl":139},"references\u002Fblind-design.md",9556,"https:\u002F\u002Fgithub.com\u002Fapache\u002Ftinkerpop\u002Fblob\u002Fmaster\u002F.skills\u002Ftinker-review\u002Freferences\u002Fblind-design.md",{"path":141,"resourceType":92,"resourceTypeDesc":93,"sizeBytes":142,"sourceHtmlUrl":143},"references\u002Fenrichment-cli.md",10027,"https:\u002F\u002Fgithub.com\u002Fapache\u002Ftinkerpop\u002Fblob\u002Fmaster\u002F.skills\u002Ftinker-review\u002Freferences\u002Fenrichment-cli.md",{"path":145,"resourceType":92,"resourceTypeDesc":93,"sizeBytes":146,"sourceHtmlUrl":147},"references\u002Ffunctional-testing.md",7037,"https:\u002F\u002Fgithub.com\u002Fapache\u002Ftinkerpop\u002Fblob\u002Fmaster\u002F.skills\u002Ftinker-review\u002Freferences\u002Ffunctional-testing.md",{"path":149,"resourceType":92,"resourceTypeDesc":93,"sizeBytes":150,"sourceHtmlUrl":151},"references\u002Finterfaces.md",17025,"https:\u002F\u002Fgithub.com\u002Fapache\u002Ftinkerpop\u002Fblob\u002Fmaster\u002F.skills\u002Ftinker-review\u002Freferences\u002Finterfaces.md",{"path":153,"resourceType":92,"resourceTypeDesc":93,"sizeBytes":154,"sourceHtmlUrl":155},"references\u002Fschema.md",13445,"https:\u002F\u002Fgithub.com\u002Fapache\u002Ftinkerpop\u002Fblob\u002Fmaster\u002F.skills\u002Ftinker-review\u002Freferences\u002Fschema.md",{"path":157,"resourceType":158,"resourceTypeDesc":159,"sizeBytes":160,"sourceHtmlUrl":161},"scripts\u002Fdiscovery\u002Fbeads.js","SCRIPT","脚本",13653,"https:\u002F\u002Fgithub.com\u002Fapache\u002Ftinkerpop\u002Fblob\u002Fmaster\u002F.skills\u002Ftinker-review\u002Fscripts\u002Fdiscovery\u002Fbeads.js",{"path":163,"resourceType":158,"resourceTypeDesc":159,"sizeBytes":164,"sourceHtmlUrl":165},"scripts\u002Fdiscovery\u002Fdiscussions.js",16668,"https:\u002F\u002Fgithub.com\u002Fapache\u002Ftinkerpop\u002Fblob\u002Fmaster\u002F.skills\u002Ftinker-review\u002Fscripts\u002Fdiscovery\u002Fdiscussions.js",{"path":167,"resourceType":158,"resourceTypeDesc":159,"sizeBytes":168,"sourceHtmlUrl":169},"scripts\u002Fenrichment\u002Fapi.js",25741,"https:\u002F\u002Fgithub.com\u002Fapache\u002Ftinkerpop\u002Fblob\u002Fmaster\u002F.skills\u002Ftinker-review\u002Fscripts\u002Fenrichment\u002Fapi.js",{"path":171,"resourceType":158,"resourceTypeDesc":159,"sizeBytes":172,"sourceHtmlUrl":173},"scripts\u002Fenrichment\u002Fcli.js",11043,"https:\u002F\u002Fgithub.com\u002Fapache\u002Ftinkerpop\u002Fblob\u002Fmaster\u002F.skills\u002Ftinker-review\u002Fscripts\u002Fenrichment\u002Fcli.js",{"path":175,"resourceType":158,"resourceTypeDesc":159,"sizeBytes":176,"sourceHtmlUrl":177},"scripts\u002Fextraction\u002Fcode-index.js",4118,"https:\u002F\u002Fgithub.com\u002Fapache\u002Ftinkerpop\u002Fblob\u002Fmaster\u002F.skills\u002Ftinker-review\u002Fscripts\u002Fextraction\u002Fcode-index.js",{"path":179,"resourceType":158,"resourceTypeDesc":159,"sizeBytes":180,"sourceHtmlUrl":181},"scripts\u002Fextraction\u002Ftree-sitter.js",37295,"https:\u002F\u002Fgithub.com\u002Fapache\u002Ftinkerpop\u002Fblob\u002Fmaster\u002F.skills\u002Ftinker-review\u002Fscripts\u002Fextraction\u002Ftree-sitter.js",{"path":183,"resourceType":158,"resourceTypeDesc":159,"sizeBytes":184,"sourceHtmlUrl":185},"scripts\u002Ffunctional\u002Fcli.js",3569,"https:\u002F\u002Fgithub.com\u002Fapache\u002Ftinkerpop\u002Fblob\u002Fmaster\u002F.skills\u002Ftinker-review\u002Fscripts\u002Ffunctional\u002Fcli.js",{"path":187,"resourceType":158,"resourceTypeDesc":159,"sizeBytes":188,"sourceHtmlUrl":189},"scripts\u002Ffunctional\u002Fsetup.js",12943,"https:\u002F\u002Fgithub.com\u002Fapache\u002Ftinkerpop\u002Fblob\u002Fmaster\u002F.skills\u002Ftinker-review\u002Fscripts\u002Ffunctional\u002Fsetup.js",{"path":191,"resourceType":158,"resourceTypeDesc":159,"sizeBytes":192,"sourceHtmlUrl":193},"scripts\u002Fgraph\u002Fchange-levels.js",6599,"https:\u002F\u002Fgithub.com\u002Fapache\u002Ftinkerpop\u002Fblob\u002Fmaster\u002F.skills\u002Ftinker-review\u002Fscripts\u002Fgraph\u002Fchange-levels.js",{"path":195,"resourceType":158,"resourceTypeDesc":159,"sizeBytes":196,"sourceHtmlUrl":197},"scripts\u002Fgraph\u002Fconfidence.js",3077,"https:\u002F\u002Fgithub.com\u002Fapache\u002Ftinkerpop\u002Fblob\u002Fmaster\u002F.skills\u002Ftinker-review\u002Fscripts\u002Fgraph\u002Fconfidence.js",{"path":199,"resourceType":158,"resourceTypeDesc":159,"sizeBytes":200,"sourceHtmlUrl":201},"scripts\u002Fgraph\u002Fexternals.js",3777,"https:\u002F\u002Fgithub.com\u002Fapache\u002Ftinkerpop\u002Fblob\u002Fmaster\u002F.skills\u002Ftinker-review\u002Fscripts\u002Fgraph\u002Fexternals.js",{"path":203,"resourceType":158,"resourceTypeDesc":159,"sizeBytes":204,"sourceHtmlUrl":205},"scripts\u002Fgraph\u002Fpopulate-beads.js",5256,"https:\u002F\u002Fgithub.com\u002Fapache\u002Ftinkerpop\u002Fblob\u002Fmaster\u002F.skills\u002Ftinker-review\u002Fscripts\u002Fgraph\u002Fpopulate-beads.js",{"path":207,"resourceType":158,"resourceTypeDesc":159,"sizeBytes":208,"sourceHtmlUrl":209},"scripts\u002Fgraph\u002Fpopulate-discussions.js",11385,"https:\u002F\u002Fgithub.com\u002Fapache\u002Ftinkerpop\u002Fblob\u002Fmaster\u002F.skills\u002Ftinker-review\u002Fscripts\u002Fgraph\u002Fpopulate-discussions.js",{"path":211,"resourceType":158,"resourceTypeDesc":159,"sizeBytes":212,"sourceHtmlUrl":213},"scripts\u002Fgraph\u002Fpopulate.js",15397,"https:\u002F\u002Fgithub.com\u002Fapache\u002Ftinkerpop\u002Fblob\u002Fmaster\u002F.skills\u002Ftinker-review\u002Fscripts\u002Fgraph\u002Fpopulate.js",{"path":215,"resourceType":158,"resourceTypeDesc":159,"sizeBytes":216,"sourceHtmlUrl":217},"scripts\u002Fgraph\u002Freferences.js",3148,"https:\u002F\u002Fgithub.com\u002Fapache\u002Ftinkerpop\u002Fblob\u002Fmaster\u002F.skills\u002Ftinker-review\u002Fscripts\u002Fgraph\u002Freferences.js",{"path":219,"resourceType":158,"resourceTypeDesc":159,"sizeBytes":220,"sourceHtmlUrl":221},"scripts\u002Finfrastructure\u002Fdocker.js",3275,"https:\u002F\u002Fgithub.com\u002Fapache\u002Ftinkerpop\u002Fblob\u002Fmaster\u002F.skills\u002Ftinker-review\u002Fscripts\u002Finfrastructure\u002Fdocker.js",{"path":223,"resourceType":158,"resourceTypeDesc":159,"sizeBytes":224,"sourceHtmlUrl":225},"scripts\u002Finfrastructure\u002Fnet.js",2654,"https:\u002F\u002Fgithub.com\u002Fapache\u002Ftinkerpop\u002Fblob\u002Fmaster\u002F.skills\u002Ftinker-review\u002Fscripts\u002Finfrastructure\u002Fnet.js",{"path":227,"resourceType":158,"resourceTypeDesc":159,"sizeBytes":228,"sourceHtmlUrl":229},"scripts\u002Fpatterns\u002Farchitecture.js",5602,"https:\u002F\u002Fgithub.com\u002Fapache\u002Ftinkerpop\u002Fblob\u002Fmaster\u002F.skills\u002Ftinker-review\u002Fscripts\u002Fpatterns\u002Farchitecture.js",{"path":231,"resourceType":158,"resourceTypeDesc":159,"sizeBytes":232,"sourceHtmlUrl":233},"scripts\u002Fpatterns\u002Fblast-radius.js",7021,"https:\u002F\u002Fgithub.com\u002Fapache\u002Ftinkerpop\u002Fblob\u002Fmaster\u002F.skills\u002Ftinker-review\u002Fscripts\u002Fpatterns\u002Fblast-radius.js",{"path":235,"resourceType":158,"resourceTypeDesc":159,"sizeBytes":236,"sourceHtmlUrl":237},"scripts\u002Fpatterns\u002Fcentrality.js",6199,"https:\u002F\u002Fgithub.com\u002Fapache\u002Ftinkerpop\u002Fblob\u002Fmaster\u002F.skills\u002Ftinker-review\u002Fscripts\u002Fpatterns\u002Fcentrality.js",{"path":239,"resourceType":158,"resourceTypeDesc":159,"sizeBytes":240,"sourceHtmlUrl":241},"scripts\u002Fpatterns\u002Fclassify-externals.js",3495,"https:\u002F\u002Fgithub.com\u002Fapache\u002Ftinkerpop\u002Fblob\u002Fmaster\u002F.skills\u002Ftinker-review\u002Fscripts\u002Fpatterns\u002Fclassify-externals.js",{"path":243,"resourceType":158,"resourceTypeDesc":159,"sizeBytes":244,"sourceHtmlUrl":245},"scripts\u002Fpatterns\u002Fcluster-analysis.js",3039,"https:\u002F\u002Fgithub.com\u002Fapache\u002Ftinkerpop\u002Fblob\u002Fmaster\u002F.skills\u002Ftinker-review\u002Fscripts\u002Fpatterns\u002Fcluster-analysis.js",{"path":247,"resourceType":158,"resourceTypeDesc":159,"sizeBytes":248,"sourceHtmlUrl":249},"scripts\u002Fpatterns\u002Fcommunity-detection.js",20146,"https:\u002F\u002Fgithub.com\u002Fapache\u002Ftinkerpop\u002Fblob\u002Fmaster\u002F.skills\u002Ftinker-review\u002Fscripts\u002Fpatterns\u002Fcommunity-detection.js",{"path":251,"resourceType":158,"resourceTypeDesc":159,"sizeBytes":252,"sourceHtmlUrl":253},"scripts\u002Fpatterns\u002Fcompleteness.js",3331,"https:\u002F\u002Fgithub.com\u002Fapache\u002Ftinkerpop\u002Fblob\u002Fmaster\u002F.skills\u002Ftinker-review\u002Fscripts\u002Fpatterns\u002Fcompleteness.js",{"path":255,"resourceType":158,"resourceTypeDesc":159,"sizeBytes":256,"sourceHtmlUrl":257},"scripts\u002Fpatterns\u002Fconfidence-audit.js",7008,"https:\u002F\u002Fgithub.com\u002Fapache\u002Ftinkerpop\u002Fblob\u002Fmaster\u002F.skills\u002Ftinker-review\u002Fscripts\u002Fpatterns\u002Fconfidence-audit.js",{"path":259,"resourceType":158,"resourceTypeDesc":159,"sizeBytes":260,"sourceHtmlUrl":261},"scripts\u002Fpatterns\u002Fcoverage-gaps.js",3384,"https:\u002F\u002Fgithub.com\u002Fapache\u002Ftinkerpop\u002Fblob\u002Fmaster\u002F.skills\u002Ftinker-review\u002Fscripts\u002Fpatterns\u002Fcoverage-gaps.js",{"path":263,"resourceType":158,"resourceTypeDesc":159,"sizeBytes":264,"sourceHtmlUrl":265},"scripts\u002Fpatterns\u002Forphans.js",3376,"https:\u002F\u002Fgithub.com\u002Fapache\u002Ftinkerpop\u002Fblob\u002Fmaster\u002F.skills\u002Ftinker-review\u002Fscripts\u002Fpatterns\u002Forphans.js",{"path":267,"resourceType":158,"resourceTypeDesc":159,"sizeBytes":268,"sourceHtmlUrl":269},"scripts\u002Fpatterns\u002Fremoval-refs.js",4615,"https:\u002F\u002Fgithub.com\u002Fapache\u002Ftinkerpop\u002Fblob\u002Fmaster\u002F.skills\u002Ftinker-review\u002Fscripts\u002Fpatterns\u002Fremoval-refs.js",{"path":271,"resourceType":158,"resourceTypeDesc":159,"sizeBytes":272,"sourceHtmlUrl":273},"scripts\u002Frenderer\u002Fcode-links.js",5798,"https:\u002F\u002Fgithub.com\u002Fapache\u002Ftinkerpop\u002Fblob\u002Fmaster\u002F.skills\u002Ftinker-review\u002Fscripts\u002Frenderer\u002Fcode-links.js",{"path":275,"resourceType":158,"resourceTypeDesc":159,"sizeBytes":276,"sourceHtmlUrl":277},"scripts\u002Frenderer\u002Frender.js",45890,"https:\u002F\u002Fgithub.com\u002Fapache\u002Ftinkerpop\u002Fblob\u002Fmaster\u002F.skills\u002Ftinker-review\u002Fscripts\u002Frenderer\u002Frender.js",{"path":279,"resourceType":158,"resourceTypeDesc":159,"sizeBytes":280,"sourceHtmlUrl":281},"scripts\u002Frenderer\u002Ftemplate.html",8214,"https:\u002F\u002Fgithub.com\u002Fapache\u002Ftinkerpop\u002Fblob\u002Fmaster\u002F.skills\u002Ftinker-review\u002Fscripts\u002Frenderer\u002Ftemplate.html",{"path":283,"resourceType":158,"resourceTypeDesc":159,"sizeBytes":284,"sourceHtmlUrl":285},"scripts\u002Freview.js",31457,"https:\u002F\u002Fgithub.com\u002Fapache\u002Ftinkerpop\u002Fblob\u002Fmaster\u002F.skills\u002Ftinker-review\u002Fscripts\u002Freview.js",{"path":287,"resourceType":158,"resourceTypeDesc":159,"sizeBytes":288,"sourceHtmlUrl":289},"test\u002Fbeads.test.js",15189,"https:\u002F\u002Fgithub.com\u002Fapache\u002Ftinkerpop\u002Fblob\u002Fmaster\u002F.skills\u002Ftinker-review\u002Ftest\u002Fbeads.test.js",{"path":291,"resourceType":158,"resourceTypeDesc":159,"sizeBytes":292,"sourceHtmlUrl":293},"test\u002Fblind-design.test.js",3315,"https:\u002F\u002Fgithub.com\u002Fapache\u002Ftinkerpop\u002Fblob\u002Fmaster\u002F.skills\u002Ftinker-review\u002Ftest\u002Fblind-design.test.js",{"path":295,"resourceType":158,"resourceTypeDesc":159,"sizeBytes":296,"sourceHtmlUrl":297},"test\u002Fcli-docs.test.js",4514,"https:\u002F\u002Fgithub.com\u002Fapache\u002Ftinkerpop\u002Fblob\u002Fmaster\u002F.skills\u002Ftinker-review\u002Ftest\u002Fcli-docs.test.js",{"path":299,"resourceType":158,"resourceTypeDesc":159,"sizeBytes":300,"sourceHtmlUrl":301},"test\u002Fcode-links.test.js",8222,"https:\u002F\u002Fgithub.com\u002Fapache\u002Ftinkerpop\u002Fblob\u002Fmaster\u002F.skills\u002Ftinker-review\u002Ftest\u002Fcode-links.test.js",{"path":303,"resourceType":158,"resourceTypeDesc":159,"sizeBytes":304,"sourceHtmlUrl":305},"test\u002Fcommunity-detection.test.js",8805,"https:\u002F\u002Fgithub.com\u002Fapache\u002Ftinkerpop\u002Fblob\u002Fmaster\u002F.skills\u002Ftinker-review\u002Ftest\u002Fcommunity-detection.test.js",{"path":307,"resourceType":158,"resourceTypeDesc":159,"sizeBytes":308,"sourceHtmlUrl":309},"test\u002Fdiscovery.test.js",10375,"https:\u002F\u002Fgithub.com\u002Fapache\u002Ftinkerpop\u002Fblob\u002Fmaster\u002F.skills\u002Ftinker-review\u002Ftest\u002Fdiscovery.test.js",{"path":311,"resourceType":158,"resourceTypeDesc":159,"sizeBytes":312,"sourceHtmlUrl":313},"test\u002Fextraction.test.js",8314,"https:\u002F\u002Fgithub.com\u002Fapache\u002Ftinkerpop\u002Fblob\u002Fmaster\u002F.skills\u002Ftinker-review\u002Ftest\u002Fextraction.test.js",{"path":315,"resourceType":158,"resourceTypeDesc":159,"sizeBytes":316,"sourceHtmlUrl":317},"test\u002Ffingerprint.test.js",6792,"https:\u002F\u002Fgithub.com\u002Fapache\u002Ftinkerpop\u002Fblob\u002Fmaster\u002F.skills\u002Ftinker-review\u002Ftest\u002Ffingerprint.test.js",{"path":319,"resourceType":158,"resourceTypeDesc":159,"sizeBytes":320,"sourceHtmlUrl":321},"test\u002Fplaybook-sections.test.js",4102,"https:\u002F\u002Fgithub.com\u002Fapache\u002Ftinkerpop\u002Fblob\u002Fmaster\u002F.skills\u002Ftinker-review\u002Ftest\u002Fplaybook-sections.test.js",[323,352,385],{"skillNo":324,"name":325,"nameZh":6,"description":326,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":327,"categories":328,"keywords":333,"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",[329,332],{"categoryNo":330,"categoryName":331,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000007","代码审查",{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[334,335,29,50,336,39,337,338,339,340,341,342,343,9,344,345,346,46,347,348,349,350,351],"merge","tinker merge","work","use","pull","commits","gh","push","only","cli","pull request","release","testing","dev","branches","branch","maven","feature",{"skillNo":353,"name":354,"nameZh":6,"description":355,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":356,"categories":357,"keywords":366,"publishedAt":51},"01M6ACG7R07AC5ABZ472F0B3MF","tinker-doc","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.","https:\u002F\u002Fgithub.com\u002Fapache\u002Ftinkerpop\u002Fblob\u002Fmaster\u002F.skills\u002Ftinker-doc\u002FSKILL.md",[358,363],{"categoryNo":359,"categoryName":360,"taxonomyType":361,"taxonomyTypeDesc":362},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",{"categoryNo":364,"categoryName":365,"taxonomyType":361,"taxonomyTypeDesc":362},"01JBSEEDCAT000000000000036","内容创作者",[29,367,368,369,370,371,372,39,373,374,375,376,377,378,379,380,50,381,9,345,347,382,383,384,44],"doc","tinker doc","never","project","pipeline","upgrade","guides","markdown","src","authoring","content","gremlin","documentation","notes","changelog","release notes","writing","docs",{"skillNo":386,"name":387,"nameZh":6,"description":388,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":389,"categories":390,"keywords":395,"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",[391,392],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":393,"categoryName":394,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[347,29,396,397,346,398,399,379,9,400,401,402,403,404,405,406,34,407,408,43,409,39],"tinker dev","coding","MCP","mcp server","contributing","go","framework","ecosystem","monorepo","coding conventions","server","Evaluation","recipes","development environment"]