[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill-apache-doris-profile-reader":3,"mdc--5j79kw-key":39,"related-repo-apache-doris-profile-reader":866,"related-org-apache-doris-profile-reader":957},{"slug":4,"name":4,"fn":5,"description":6,"org":7,"tags":11,"stars":22,"repoUrl":23,"updatedAt":24,"license":25,"forks":26,"topics":27,"repo":34,"sourceUrl":37,"mdContent":38},"doris-profile-reader","analyze Apache Doris query profiles","Interpret Apache Doris query runtime profiles, especially profile bottleneck triage, misleading wait counters, per-operator metric priority, scan, join-order\u002Fruntime-filter analysis, and evidence-bounded performance explanations. Use when given a Doris profile, query id, profile URL\u002Ftext, or a request to explain Doris query performance.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},"apache","Apache Software Foundation","https:\u002F\u002Fpexgzepcugksgbtrxkhf.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Forg-logos\u002Fapache.png",[12,16,19],{"name":13,"slug":14,"type":15},"Performance","performance","tag",{"name":17,"slug":18,"type":15},"Analytics","analytics",{"name":20,"slug":21,"type":15},"Debugging","debugging",19,"https:\u002F\u002Fgithub.com\u002Fapache\u002Fdoris-skills","2026-07-12T08:35:36.788049",null,4,[28,29,30,31,32,33],"agent","cli","database","doris","mcp","skills",{"repoUrl":23,"stars":22,"forks":26,"topics":35,"description":36},[28,29,30,31,32,33],"Agent skills for Apache Doris","https:\u002F\u002Fgithub.com\u002Fapache\u002Fdoris-skills\u002Ftree\u002FHEAD\u002Fskills\u002Fdoris-profile-reader","---\nname: doris-profile-reader\ndescription: Interpret Apache Doris query runtime profiles, especially profile bottleneck triage, misleading wait counters, per-operator metric priority, scan, join-order\u002Fruntime-filter analysis, and evidence-bounded performance explanations. Use when given a Doris profile, query id, profile URL\u002Ftext, or a request to explain Doris query performance.\n---\n\n# Doris Profile Reader\n\n## Purpose\n\nUse this skill to identify the real bottleneck in an Apache Doris query runtime profile. The core rule is to separate active work from dependency, queue, and backpressure waits before naming an operator as expensive. When the plan contains joins, also separate the immediate runtime bottleneck from the plan-shape cause, especially bad join order and runtime-filter direction.\n\n## Required Reading Order\n\n1. Read `references\u002Freading-workflow.md` for the analysis workflow and output contract.\n2. Read `references\u002Fcounter-semantics.md` for counter meaning and priority, especially wait counters.\n3. Read `references\u002Foperator-guide.md` for the relevant operator family.\n4. Read `references\u002Ffailure-patterns.md` when the profile shows skew, bad join\u002Fdistribution choices, weak pruning, sort\u002Fspill\u002Fresource pressure, external scans\u002Fcatalogs, lifecycle waits, or when the user expects an issue-level root cause from profile-only evidence.\n5. Read `references\u002Fjoin-order-diagnosis.md` when the profile or plan has multiple joins, a large hash\u002Fnested-loop build, a large scan that might have been pruned by a join, paired fast\u002Fslow plans, hints\u002Freordered SQL, or a request about join shape\u002Freorder.\n6. Read `references\u002Fruntime-filters.md` when a profile or plan includes `RuntimeFilterInfo`, `RF... \u003C-`, `RF... ->`, `JRFs`, `WaitForRuntimeFilter`, or `AcquireRuntimeFilter`.\n7. Use `references\u002Fsource-profile-inventory.md` as the source-backed operator\u002Fcounter inventory. If a counter or operator is not in the narrative docs, do not ignore it; look it up in this inventory and classify it by the rules in `counter-semantics.md`.\n8. Read `references\u002Fsolution-playbook.md` when the user asks for a fix, workaround, mitigation, tuning, SQL rewrite, or when the requested output schema includes solution fields.\n9. Read `references\u002Fknown-issues-solutions.md` after the root-cause layer is established and a solution is requested. Use it as historical evidence, not as a replacement for profile diagnosis.\n\n## Non-Negotiable Interpretation Rules\n\n- Do not call `WaitForDependencyTime`, `WaitForDependency[...]Time`, `WaitForData0`, `WaitForDataN`, `WaitForRpcBufferQueue`, `WaitForBroadcastBuffer`, `PendingFinishDependency`, or pipeline blocked\u002Fwait counters direct operator compute cost. They are dependency, data-arrival, queue, memory, or backpressure signals.\n- Do not discard high `RpcMaxTime`\u002F`RpcAvgTime` on `DATA_STREAM_SINK_OPERATOR` as a generic wait counter. With non-zero `BytesSent` and `RpcCount`, it is exchange\u002FRPC-path evidence; if it is close to wall time or dominates local serialize\u002Fcompress\u002Fsend timers, keep it in the bottleneck conclusion and check channel, receiver, or BE outlier skew.\n- If a session variable, missing optimization, or large row count explains why data reached an exchange, do not make it the primary slow cause unless local scan\u002Fsort\u002Fwindow\u002Fjoin active timers dominate. When `DATA_STREAM_SINK_OPERATOR` RPC time dominates elapsed time, treat the plan\u002Fdata volume as an amplifier and keep RPC\u002FBE-to-BE transfer as the leading bottleneck candidate.\n- When multiple profiles are provided, their differences outrank single-profile wait symptoms. If the slow\u002Ffast profiles differ in join order, pruning, `instance_num`, exchange distribution, or bucket\u002Fsink layout, diagnose that plan\u002Fdata-layout difference before blaming generic RPC, scanner, or exchange backpressure.\n- If a join\u002Fprojection hotspot is dominated by wide JSON\u002FVARIANT\u002Fstring columns from one table and the work is single-instance or heavily skewed, do not stop at expression CPU. State the likely root layer as join order\u002Fdistribution or cost-model underweighting wide-column work, with expression CPU as the runtime symptom.\n- For INSERT\u002FSELECT profiles, visible massive-row `SPLIT_BY_STRING`\u002F`cardinality(split_by_string(...))` expressions are primary root-cause candidates. Do not demote them below generic scan\u002Fshuffle\u002Ftable-sink volume unless independent active sink\u002Fwrite timers dominate.\n- For INSERT skew, receiver or UNION\u002Flocal-exchange skew must be tied back to target bucket count, bucket key, write bucket parallelism, and hot values. If exact DDL is absent, conclude likely target bucket\u002Fkey design mismatch or insufficient write buckets rather than stopping at exchange skew.\n- Before concluding that a full scan or INSERT is slow only because of row volume, search the SQL\u002Fplan text for string-heavy expressions such as `SPLIT_BY_STRING`, regexp, trim\u002Freplace chains, `INSTR`, `COALESCE`, and `NULLIF`. On massive rows, those expressions remain root-cause candidates even when no `ProjectionTime` counter is visible.\n- For point or narrow queries with tiny output but many tablets\u002Fscanners, state the bucket\u002Ftablet-pruning verdict. High `ScannerWorkerWaitTime` is a fanout symptom unless workload-pressure evidence exists; if predicates and indexes are effective but many tablets are opened, prefer no bucket pruning\u002Ftable layout over scanner-pool contention.\n- Do not rank operators by the largest wait-like counter alone. First rank by `ExecTime`\u002Factive timers, direct custom timers, rows\u002Fbytes, memory\u002Fspill, and skew.\n- Before ranking a query bottleneck, verify the profile type. Async-profiler CPU flamegraphs, FE load-image\u002Fload-auth profiles, logs, or cached summaries are valid evidence for their own lifecycle hotspot, but they are not BE query runtime profiles. If the file type does not match the requested slow-query question, report the mismatch and ask for the matching runtime profile instead of forcing an unrelated Doris-query conclusion.\n- For OOM, timeout-after-spill, or memory-limit profiles, find the memory owner before choosing the root cause: check session\u002Fglobal memory settings, spill state, peak memory by operator, hash-join build\u002Fprobe memory, aggregation hash\u002Fstate memory, sort buffers, table-sink buffers, exchange buffers, and expression materialization. Do not call a large join the root until aggregation-state and expression-materialization costs have been ruled in or out.\n- Session\u002Fconfig evidence can outrank operator-shape speculation. Explicit non-default settings such as disabled parallel scan, very small `parallel_pipeline_task_num`, low memory percentage\u002Flimit, disabled two-phase read, or disabled local shuffle should be evaluated before concluding bad join order, scanner contention, or network outlier.\n- Analyze multiple profiles independently before summarizing. For each profile, name its dominant active\u002Fwait\u002Fresource signal and only then compare them. Do not collapse unrelated profiles into one generic fanout, scan, join, or RPC explanation.\n- Keep profile-visible bottlenecks separate from issue-level root causes. If a deeper cause requires schema, statistics, version, config, logs, comments, or a fast\u002Fslow comparison that is not present, say what the profile proves and list the exact missing check instead of overclaiming.\n- For solution fields, do not convert every plausible validation into a fix. First decide the solution source: profile-proven, exact historical pattern, code-backed but unproven next check, or no historical solution. Preserve exact historical parameter names, values, PR numbers, version numbers, and SQL rewrite shapes when they are in the known-pattern evidence.\n- If the diagnosis is uncertain or only profile-level, prefer an empty historical solution plus targeted `next_checks` over a concrete mitigation. A wrong concrete fix is worse than no fix.\n- When the requested schema has `historical_solution`, fill it only for `profile_proven` or exact `historical_pattern` actions. If the action still needs validation, or is inferred from a neighboring pattern family, leave `historical_solution` empty and move the action to `next_checks`.\n- Treat merged-profile `sum` timers as accumulated across parallel instances. A timer can exceed query elapsed time and still be normal when many scanners, drivers, or fragments run in parallel.\n- For scans, prioritize `RowsRead`, `ScanRows`, `ScanBytes`, `ScannerCpuTime`, `ScannerGetBlockTime`, `ScannerWorkerWaitTime`, I\u002FO\u002Fdecompression timers, predicate\u002Flazy-read timers, and row-filter counters. `ScannerWorkerWaitTime` is important, but it indicates scanner scheduling\u002Fthread-pool wait rather than scan CPU.\n- For runtime filters, distinguish source\u002Fbuild side from target\u002Fprobe scan side. In plan text, `RFxxx \u003C- expr` is produced from the build side; `RFxxx -> expr` is applied at a target scan. In profiles, `RuntimeFilterInfo` and scan-side wait\u002Ffilter counters decide whether the RF helped or just waited.\n- For joins, always identify build side and probe\u002Ftarget side before judging the order. A scan can be the immediate active bottleneck while the root cause is still bad join order if a selective join\u002FRF source is scheduled too late to prune that scan.\n- When a join\u002Fdistribution choice looks bad, check estimated versus actual rows, statistics\u002Fnull\u002Fhot-value evidence, join distribution, and RF direction if present. Do not stop at \"large scan\" or \"large build\" when the profile exposes a planner\u002Fstatistics symptom.\n- Do not require a paired fast profile before naming likely bad join order. A single slow profile can be enough when it proves large wasted build\u002Fscan work before an empty probe\u002Fresult, an RF source side that had to scan massively before it could emit an empty\u002Ftiny filter, or a huge intermediate later eliminated by a highly selective or contradictory join predicate.\n- Do not treat \"the current RF made other scans wait and then skip\" as proof that the join order is good. If producing that empty\u002Ftiny RF required the only expensive scan, the RF source\u002Ftarget choice is itself the join-order question.\n- When a large build\u002Fsource side is paid before an empty\u002Ftiny probe, preserved side, semi-join key set, or contradictory join can eliminate the result, call the build\u002Fprobe order likely bad unless the profile proves that ordering is semantically forced and no earlier pruning\u002Fshort-circuit is possible.\n- When `max` is far above `avg` on scan, join, aggregation, exchange, sort, or sink operators, run a skew pass: compare per-instance rows\u002Ftime\u002Fbytes, tablet or bucket assignment, local shuffle, distribution key, and global\u002Fsession parallelism before calling the cause generic data volume.\n- If a strong single-profile join-order pattern matches, do not hedge as \"suspicious\", \"close to likely bad\", or \"not proven\". Use `likely bad` when a better legal order still needs validation, and reserve `not proven` for the exact alternate shape, not for the join-order diagnosis itself.\n- When a join query has plan-shape evidence, the answer must explicitly judge join order\u002Fbuild-probe\u002FRF direction as good, suspicious, or bad. Do not replace that judgment with a vague \"predicate issue\" or \"plan shape issue\".\n- A long `InitTime`, `OpenTime`, `CloseTime`, or profile total can matter, but only after confirming it is not accumulated across many instances and not dominated by a known wait\u002Fdependency branch.\n\n## Standard Answer Shape\n\nWhen explaining a profile, answer in this order:\n\n1. `Conclusion`: one or two sentences naming the likely bottleneck and, when joins are involved, whether the plan shape\u002Fjoin order is likely the cause.\n2. `Evidence`: profile counters with operator names, values, and whether each is active work, data volume, wait\u002Fbackpressure, memory\u002Fspill, or runtime-filter evidence.\n3. `Reasoning`: how the evidence maps to the execution plan, which side is build\u002Fprobe or RF source\u002Ftarget, why misleading counters are discounted, and whether the join order is reasonable.\n4. `Next checks`: the smallest additional profile\u002Flog\u002Fcode checks needed if the conclusion is still uncertain.\n5. `Solution \u002F mitigation` when requested: only name a solution that is directly supported by this profile or by a matching historical pattern in `references\u002Fknown-issues-solutions.md`. If no historical or profile-proven solution applies, say so and keep the item as a next check instead of inventing advice.\n\nAlways preserve uncertainty. Use \"proven\", \"likely\", and \"not proven\" explicitly when the profile lacks enough detail.\n\n## Scripts\n\n- `scripts\u002Fextract_source_profile_inventory.py`: scan Doris source for factory-created operators and counter\u002Finfo registrations.\n\nScripts are evidence-generation helpers. They do not replace the reading workflow.\n",{"data":40,"body":41},{"name":4,"description":6},{"type":42,"children":43},"root",[44,52,59,65,71,239,245,760,766,771,836,841,847,861],{"type":45,"tag":46,"props":47,"children":48},"element","h1",{"id":4},[49],{"type":50,"value":51},"text","Doris Profile Reader",{"type":45,"tag":53,"props":54,"children":56},"h2",{"id":55},"purpose",[57],{"type":50,"value":58},"Purpose",{"type":45,"tag":60,"props":61,"children":62},"p",{},[63],{"type":50,"value":64},"Use this skill to identify the real bottleneck in an Apache Doris query runtime profile. The core rule is to separate active work from dependency, queue, and backpressure waits before naming an operator as expensive. When the plan contains joins, also separate the immediate runtime bottleneck from the plan-shape cause, especially bad join order and runtime-filter direction.",{"type":45,"tag":53,"props":66,"children":68},{"id":67},"required-reading-order",[69],{"type":50,"value":70},"Required Reading Order",{"type":45,"tag":72,"props":73,"children":74},"ol",{},[75,90,102,114,126,138,195,215,227],{"type":45,"tag":76,"props":77,"children":78},"li",{},[79,81,88],{"type":50,"value":80},"Read ",{"type":45,"tag":82,"props":83,"children":85},"code",{"className":84},[],[86],{"type":50,"value":87},"references\u002Freading-workflow.md",{"type":50,"value":89}," for the analysis workflow and output contract.",{"type":45,"tag":76,"props":91,"children":92},{},[93,94,100],{"type":50,"value":80},{"type":45,"tag":82,"props":95,"children":97},{"className":96},[],[98],{"type":50,"value":99},"references\u002Fcounter-semantics.md",{"type":50,"value":101}," for counter meaning and priority, especially wait counters.",{"type":45,"tag":76,"props":103,"children":104},{},[105,106,112],{"type":50,"value":80},{"type":45,"tag":82,"props":107,"children":109},{"className":108},[],[110],{"type":50,"value":111},"references\u002Foperator-guide.md",{"type":50,"value":113}," for the relevant operator family.",{"type":45,"tag":76,"props":115,"children":116},{},[117,118,124],{"type":50,"value":80},{"type":45,"tag":82,"props":119,"children":121},{"className":120},[],[122],{"type":50,"value":123},"references\u002Ffailure-patterns.md",{"type":50,"value":125}," when the profile shows skew, bad join\u002Fdistribution choices, weak pruning, sort\u002Fspill\u002Fresource pressure, external scans\u002Fcatalogs, lifecycle waits, or when the user expects an issue-level root cause from profile-only evidence.",{"type":45,"tag":76,"props":127,"children":128},{},[129,130,136],{"type":50,"value":80},{"type":45,"tag":82,"props":131,"children":133},{"className":132},[],[134],{"type":50,"value":135},"references\u002Fjoin-order-diagnosis.md",{"type":50,"value":137}," when the profile or plan has multiple joins, a large hash\u002Fnested-loop build, a large scan that might have been pruned by a join, paired fast\u002Fslow plans, hints\u002Freordered SQL, or a request about join shape\u002Freorder.",{"type":45,"tag":76,"props":139,"children":140},{},[141,142,148,150,156,158,164,165,171,172,178,179,185,187,193],{"type":50,"value":80},{"type":45,"tag":82,"props":143,"children":145},{"className":144},[],[146],{"type":50,"value":147},"references\u002Fruntime-filters.md",{"type":50,"value":149}," when a profile or plan includes ",{"type":45,"tag":82,"props":151,"children":153},{"className":152},[],[154],{"type":50,"value":155},"RuntimeFilterInfo",{"type":50,"value":157},", ",{"type":45,"tag":82,"props":159,"children":161},{"className":160},[],[162],{"type":50,"value":163},"RF... \u003C-",{"type":50,"value":157},{"type":45,"tag":82,"props":166,"children":168},{"className":167},[],[169],{"type":50,"value":170},"RF... ->",{"type":50,"value":157},{"type":45,"tag":82,"props":173,"children":175},{"className":174},[],[176],{"type":50,"value":177},"JRFs",{"type":50,"value":157},{"type":45,"tag":82,"props":180,"children":182},{"className":181},[],[183],{"type":50,"value":184},"WaitForRuntimeFilter",{"type":50,"value":186},", or ",{"type":45,"tag":82,"props":188,"children":190},{"className":189},[],[191],{"type":50,"value":192},"AcquireRuntimeFilter",{"type":50,"value":194},".",{"type":45,"tag":76,"props":196,"children":197},{},[198,200,206,208,214],{"type":50,"value":199},"Use ",{"type":45,"tag":82,"props":201,"children":203},{"className":202},[],[204],{"type":50,"value":205},"references\u002Fsource-profile-inventory.md",{"type":50,"value":207}," as the source-backed operator\u002Fcounter inventory. If a counter or operator is not in the narrative docs, do not ignore it; look it up in this inventory and classify it by the rules in ",{"type":45,"tag":82,"props":209,"children":211},{"className":210},[],[212],{"type":50,"value":213},"counter-semantics.md",{"type":50,"value":194},{"type":45,"tag":76,"props":216,"children":217},{},[218,219,225],{"type":50,"value":80},{"type":45,"tag":82,"props":220,"children":222},{"className":221},[],[223],{"type":50,"value":224},"references\u002Fsolution-playbook.md",{"type":50,"value":226}," when the user asks for a fix, workaround, mitigation, tuning, SQL rewrite, or when the requested output schema includes solution fields.",{"type":45,"tag":76,"props":228,"children":229},{},[230,231,237],{"type":50,"value":80},{"type":45,"tag":82,"props":232,"children":234},{"className":233},[],[235],{"type":50,"value":236},"references\u002Fknown-issues-solutions.md",{"type":50,"value":238}," after the root-cause layer is established and a solution is requested. Use it as historical evidence, not as a replacement for profile diagnosis.",{"type":45,"tag":53,"props":240,"children":242},{"id":241},"non-negotiable-interpretation-rules",[243],{"type":50,"value":244},"Non-Negotiable Interpretation Rules",{"type":45,"tag":246,"props":247,"children":248},"ul",{},[249,304,349,361,374,379,399,404,447,460,473,478,483,496,501,506,511,524,566,579,633,661,666,671,676,681,686,707,728,733],{"type":45,"tag":76,"props":250,"children":251},{},[252,254,260,261,267,268,274,275,281,282,288,289,295,296,302],{"type":50,"value":253},"Do not call ",{"type":45,"tag":82,"props":255,"children":257},{"className":256},[],[258],{"type":50,"value":259},"WaitForDependencyTime",{"type":50,"value":157},{"type":45,"tag":82,"props":262,"children":264},{"className":263},[],[265],{"type":50,"value":266},"WaitForDependency[...]Time",{"type":50,"value":157},{"type":45,"tag":82,"props":269,"children":271},{"className":270},[],[272],{"type":50,"value":273},"WaitForData0",{"type":50,"value":157},{"type":45,"tag":82,"props":276,"children":278},{"className":277},[],[279],{"type":50,"value":280},"WaitForDataN",{"type":50,"value":157},{"type":45,"tag":82,"props":283,"children":285},{"className":284},[],[286],{"type":50,"value":287},"WaitForRpcBufferQueue",{"type":50,"value":157},{"type":45,"tag":82,"props":290,"children":292},{"className":291},[],[293],{"type":50,"value":294},"WaitForBroadcastBuffer",{"type":50,"value":157},{"type":45,"tag":82,"props":297,"children":299},{"className":298},[],[300],{"type":50,"value":301},"PendingFinishDependency",{"type":50,"value":303},", or pipeline blocked\u002Fwait counters direct operator compute cost. They are dependency, data-arrival, queue, memory, or backpressure signals.",{"type":45,"tag":76,"props":305,"children":306},{},[307,309,315,317,323,325,331,333,339,341,347],{"type":50,"value":308},"Do not discard high ",{"type":45,"tag":82,"props":310,"children":312},{"className":311},[],[313],{"type":50,"value":314},"RpcMaxTime",{"type":50,"value":316},"\u002F",{"type":45,"tag":82,"props":318,"children":320},{"className":319},[],[321],{"type":50,"value":322},"RpcAvgTime",{"type":50,"value":324}," on ",{"type":45,"tag":82,"props":326,"children":328},{"className":327},[],[329],{"type":50,"value":330},"DATA_STREAM_SINK_OPERATOR",{"type":50,"value":332}," as a generic wait counter. With non-zero ",{"type":45,"tag":82,"props":334,"children":336},{"className":335},[],[337],{"type":50,"value":338},"BytesSent",{"type":50,"value":340}," and ",{"type":45,"tag":82,"props":342,"children":344},{"className":343},[],[345],{"type":50,"value":346},"RpcCount",{"type":50,"value":348},", it is exchange\u002FRPC-path evidence; if it is close to wall time or dominates local serialize\u002Fcompress\u002Fsend timers, keep it in the bottleneck conclusion and check channel, receiver, or BE outlier skew.",{"type":45,"tag":76,"props":350,"children":351},{},[352,354,359],{"type":50,"value":353},"If a session variable, missing optimization, or large row count explains why data reached an exchange, do not make it the primary slow cause unless local scan\u002Fsort\u002Fwindow\u002Fjoin active timers dominate. When ",{"type":45,"tag":82,"props":355,"children":357},{"className":356},[],[358],{"type":50,"value":330},{"type":50,"value":360}," RPC time dominates elapsed time, treat the plan\u002Fdata volume as an amplifier and keep RPC\u002FBE-to-BE transfer as the leading bottleneck candidate.",{"type":45,"tag":76,"props":362,"children":363},{},[364,366,372],{"type":50,"value":365},"When multiple profiles are provided, their differences outrank single-profile wait symptoms. If the slow\u002Ffast profiles differ in join order, pruning, ",{"type":45,"tag":82,"props":367,"children":369},{"className":368},[],[370],{"type":50,"value":371},"instance_num",{"type":50,"value":373},", exchange distribution, or bucket\u002Fsink layout, diagnose that plan\u002Fdata-layout difference before blaming generic RPC, scanner, or exchange backpressure.",{"type":45,"tag":76,"props":375,"children":376},{},[377],{"type":50,"value":378},"If a join\u002Fprojection hotspot is dominated by wide JSON\u002FVARIANT\u002Fstring columns from one table and the work is single-instance or heavily skewed, do not stop at expression CPU. State the likely root layer as join order\u002Fdistribution or cost-model underweighting wide-column work, with expression CPU as the runtime symptom.",{"type":45,"tag":76,"props":380,"children":381},{},[382,384,390,391,397],{"type":50,"value":383},"For INSERT\u002FSELECT profiles, visible massive-row ",{"type":45,"tag":82,"props":385,"children":387},{"className":386},[],[388],{"type":50,"value":389},"SPLIT_BY_STRING",{"type":50,"value":316},{"type":45,"tag":82,"props":392,"children":394},{"className":393},[],[395],{"type":50,"value":396},"cardinality(split_by_string(...))",{"type":50,"value":398}," expressions are primary root-cause candidates. Do not demote them below generic scan\u002Fshuffle\u002Ftable-sink volume unless independent active sink\u002Fwrite timers dominate.",{"type":45,"tag":76,"props":400,"children":401},{},[402],{"type":50,"value":403},"For INSERT skew, receiver or UNION\u002Flocal-exchange skew must be tied back to target bucket count, bucket key, write bucket parallelism, and hot values. If exact DDL is absent, conclude likely target bucket\u002Fkey design mismatch or insufficient write buckets rather than stopping at exchange skew.",{"type":45,"tag":76,"props":405,"children":406},{},[407,409,414,416,422,423,429,431,437,439,445],{"type":50,"value":408},"Before concluding that a full scan or INSERT is slow only because of row volume, search the SQL\u002Fplan text for string-heavy expressions such as ",{"type":45,"tag":82,"props":410,"children":412},{"className":411},[],[413],{"type":50,"value":389},{"type":50,"value":415},", regexp, trim\u002Freplace chains, ",{"type":45,"tag":82,"props":417,"children":419},{"className":418},[],[420],{"type":50,"value":421},"INSTR",{"type":50,"value":157},{"type":45,"tag":82,"props":424,"children":426},{"className":425},[],[427],{"type":50,"value":428},"COALESCE",{"type":50,"value":430},", and ",{"type":45,"tag":82,"props":432,"children":434},{"className":433},[],[435],{"type":50,"value":436},"NULLIF",{"type":50,"value":438},". On massive rows, those expressions remain root-cause candidates even when no ",{"type":45,"tag":82,"props":440,"children":442},{"className":441},[],[443],{"type":50,"value":444},"ProjectionTime",{"type":50,"value":446}," counter is visible.",{"type":45,"tag":76,"props":448,"children":449},{},[450,452,458],{"type":50,"value":451},"For point or narrow queries with tiny output but many tablets\u002Fscanners, state the bucket\u002Ftablet-pruning verdict. High ",{"type":45,"tag":82,"props":453,"children":455},{"className":454},[],[456],{"type":50,"value":457},"ScannerWorkerWaitTime",{"type":50,"value":459}," is a fanout symptom unless workload-pressure evidence exists; if predicates and indexes are effective but many tablets are opened, prefer no bucket pruning\u002Ftable layout over scanner-pool contention.",{"type":45,"tag":76,"props":461,"children":462},{},[463,465,471],{"type":50,"value":464},"Do not rank operators by the largest wait-like counter alone. First rank by ",{"type":45,"tag":82,"props":466,"children":468},{"className":467},[],[469],{"type":50,"value":470},"ExecTime",{"type":50,"value":472},"\u002Factive timers, direct custom timers, rows\u002Fbytes, memory\u002Fspill, and skew.",{"type":45,"tag":76,"props":474,"children":475},{},[476],{"type":50,"value":477},"Before ranking a query bottleneck, verify the profile type. Async-profiler CPU flamegraphs, FE load-image\u002Fload-auth profiles, logs, or cached summaries are valid evidence for their own lifecycle hotspot, but they are not BE query runtime profiles. If the file type does not match the requested slow-query question, report the mismatch and ask for the matching runtime profile instead of forcing an unrelated Doris-query conclusion.",{"type":45,"tag":76,"props":479,"children":480},{},[481],{"type":50,"value":482},"For OOM, timeout-after-spill, or memory-limit profiles, find the memory owner before choosing the root cause: check session\u002Fglobal memory settings, spill state, peak memory by operator, hash-join build\u002Fprobe memory, aggregation hash\u002Fstate memory, sort buffers, table-sink buffers, exchange buffers, and expression materialization. Do not call a large join the root until aggregation-state and expression-materialization costs have been ruled in or out.",{"type":45,"tag":76,"props":484,"children":485},{},[486,488,494],{"type":50,"value":487},"Session\u002Fconfig evidence can outrank operator-shape speculation. Explicit non-default settings such as disabled parallel scan, very small ",{"type":45,"tag":82,"props":489,"children":491},{"className":490},[],[492],{"type":50,"value":493},"parallel_pipeline_task_num",{"type":50,"value":495},", low memory percentage\u002Flimit, disabled two-phase read, or disabled local shuffle should be evaluated before concluding bad join order, scanner contention, or network outlier.",{"type":45,"tag":76,"props":497,"children":498},{},[499],{"type":50,"value":500},"Analyze multiple profiles independently before summarizing. For each profile, name its dominant active\u002Fwait\u002Fresource signal and only then compare them. Do not collapse unrelated profiles into one generic fanout, scan, join, or RPC explanation.",{"type":45,"tag":76,"props":502,"children":503},{},[504],{"type":50,"value":505},"Keep profile-visible bottlenecks separate from issue-level root causes. If a deeper cause requires schema, statistics, version, config, logs, comments, or a fast\u002Fslow comparison that is not present, say what the profile proves and list the exact missing check instead of overclaiming.",{"type":45,"tag":76,"props":507,"children":508},{},[509],{"type":50,"value":510},"For solution fields, do not convert every plausible validation into a fix. First decide the solution source: profile-proven, exact historical pattern, code-backed but unproven next check, or no historical solution. Preserve exact historical parameter names, values, PR numbers, version numbers, and SQL rewrite shapes when they are in the known-pattern evidence.",{"type":45,"tag":76,"props":512,"children":513},{},[514,516,522],{"type":50,"value":515},"If the diagnosis is uncertain or only profile-level, prefer an empty historical solution plus targeted ",{"type":45,"tag":82,"props":517,"children":519},{"className":518},[],[520],{"type":50,"value":521},"next_checks",{"type":50,"value":523}," over a concrete mitigation. A wrong concrete fix is worse than no fix.",{"type":45,"tag":76,"props":525,"children":526},{},[527,529,535,537,543,545,551,553,558,560,565],{"type":50,"value":528},"When the requested schema has ",{"type":45,"tag":82,"props":530,"children":532},{"className":531},[],[533],{"type":50,"value":534},"historical_solution",{"type":50,"value":536},", fill it only for ",{"type":45,"tag":82,"props":538,"children":540},{"className":539},[],[541],{"type":50,"value":542},"profile_proven",{"type":50,"value":544}," or exact ",{"type":45,"tag":82,"props":546,"children":548},{"className":547},[],[549],{"type":50,"value":550},"historical_pattern",{"type":50,"value":552}," actions. If the action still needs validation, or is inferred from a neighboring pattern family, leave ",{"type":45,"tag":82,"props":554,"children":556},{"className":555},[],[557],{"type":50,"value":534},{"type":50,"value":559}," empty and move the action to ",{"type":45,"tag":82,"props":561,"children":563},{"className":562},[],[564],{"type":50,"value":521},{"type":50,"value":194},{"type":45,"tag":76,"props":567,"children":568},{},[569,571,577],{"type":50,"value":570},"Treat merged-profile ",{"type":45,"tag":82,"props":572,"children":574},{"className":573},[],[575],{"type":50,"value":576},"sum",{"type":50,"value":578}," timers as accumulated across parallel instances. A timer can exceed query elapsed time and still be normal when many scanners, drivers, or fragments run in parallel.",{"type":45,"tag":76,"props":580,"children":581},{},[582,584,590,591,597,598,604,605,611,612,618,619,624,626,631],{"type":50,"value":583},"For scans, prioritize ",{"type":45,"tag":82,"props":585,"children":587},{"className":586},[],[588],{"type":50,"value":589},"RowsRead",{"type":50,"value":157},{"type":45,"tag":82,"props":592,"children":594},{"className":593},[],[595],{"type":50,"value":596},"ScanRows",{"type":50,"value":157},{"type":45,"tag":82,"props":599,"children":601},{"className":600},[],[602],{"type":50,"value":603},"ScanBytes",{"type":50,"value":157},{"type":45,"tag":82,"props":606,"children":608},{"className":607},[],[609],{"type":50,"value":610},"ScannerCpuTime",{"type":50,"value":157},{"type":45,"tag":82,"props":613,"children":615},{"className":614},[],[616],{"type":50,"value":617},"ScannerGetBlockTime",{"type":50,"value":157},{"type":45,"tag":82,"props":620,"children":622},{"className":621},[],[623],{"type":50,"value":457},{"type":50,"value":625},", I\u002FO\u002Fdecompression timers, predicate\u002Flazy-read timers, and row-filter counters. ",{"type":45,"tag":82,"props":627,"children":629},{"className":628},[],[630],{"type":50,"value":457},{"type":50,"value":632}," is important, but it indicates scanner scheduling\u002Fthread-pool wait rather than scan CPU.",{"type":45,"tag":76,"props":634,"children":635},{},[636,638,644,646,652,654,659],{"type":50,"value":637},"For runtime filters, distinguish source\u002Fbuild side from target\u002Fprobe scan side. In plan text, ",{"type":45,"tag":82,"props":639,"children":641},{"className":640},[],[642],{"type":50,"value":643},"RFxxx \u003C- expr",{"type":50,"value":645}," is produced from the build side; ",{"type":45,"tag":82,"props":647,"children":649},{"className":648},[],[650],{"type":50,"value":651},"RFxxx -> expr",{"type":50,"value":653}," is applied at a target scan. In profiles, ",{"type":45,"tag":82,"props":655,"children":657},{"className":656},[],[658],{"type":50,"value":155},{"type":50,"value":660}," and scan-side wait\u002Ffilter counters decide whether the RF helped or just waited.",{"type":45,"tag":76,"props":662,"children":663},{},[664],{"type":50,"value":665},"For joins, always identify build side and probe\u002Ftarget side before judging the order. A scan can be the immediate active bottleneck while the root cause is still bad join order if a selective join\u002FRF source is scheduled too late to prune that scan.",{"type":45,"tag":76,"props":667,"children":668},{},[669],{"type":50,"value":670},"When a join\u002Fdistribution choice looks bad, check estimated versus actual rows, statistics\u002Fnull\u002Fhot-value evidence, join distribution, and RF direction if present. Do not stop at \"large scan\" or \"large build\" when the profile exposes a planner\u002Fstatistics symptom.",{"type":45,"tag":76,"props":672,"children":673},{},[674],{"type":50,"value":675},"Do not require a paired fast profile before naming likely bad join order. A single slow profile can be enough when it proves large wasted build\u002Fscan work before an empty probe\u002Fresult, an RF source side that had to scan massively before it could emit an empty\u002Ftiny filter, or a huge intermediate later eliminated by a highly selective or contradictory join predicate.",{"type":45,"tag":76,"props":677,"children":678},{},[679],{"type":50,"value":680},"Do not treat \"the current RF made other scans wait and then skip\" as proof that the join order is good. If producing that empty\u002Ftiny RF required the only expensive scan, the RF source\u002Ftarget choice is itself the join-order question.",{"type":45,"tag":76,"props":682,"children":683},{},[684],{"type":50,"value":685},"When a large build\u002Fsource side is paid before an empty\u002Ftiny probe, preserved side, semi-join key set, or contradictory join can eliminate the result, call the build\u002Fprobe order likely bad unless the profile proves that ordering is semantically forced and no earlier pruning\u002Fshort-circuit is possible.",{"type":45,"tag":76,"props":687,"children":688},{},[689,691,697,699,705],{"type":50,"value":690},"When ",{"type":45,"tag":82,"props":692,"children":694},{"className":693},[],[695],{"type":50,"value":696},"max",{"type":50,"value":698}," is far above ",{"type":45,"tag":82,"props":700,"children":702},{"className":701},[],[703],{"type":50,"value":704},"avg",{"type":50,"value":706}," on scan, join, aggregation, exchange, sort, or sink operators, run a skew pass: compare per-instance rows\u002Ftime\u002Fbytes, tablet or bucket assignment, local shuffle, distribution key, and global\u002Fsession parallelism before calling the cause generic data volume.",{"type":45,"tag":76,"props":708,"children":709},{},[710,712,718,720,726],{"type":50,"value":711},"If a strong single-profile join-order pattern matches, do not hedge as \"suspicious\", \"close to likely bad\", or \"not proven\". Use ",{"type":45,"tag":82,"props":713,"children":715},{"className":714},[],[716],{"type":50,"value":717},"likely bad",{"type":50,"value":719}," when a better legal order still needs validation, and reserve ",{"type":45,"tag":82,"props":721,"children":723},{"className":722},[],[724],{"type":50,"value":725},"not proven",{"type":50,"value":727}," for the exact alternate shape, not for the join-order diagnosis itself.",{"type":45,"tag":76,"props":729,"children":730},{},[731],{"type":50,"value":732},"When a join query has plan-shape evidence, the answer must explicitly judge join order\u002Fbuild-probe\u002FRF direction as good, suspicious, or bad. Do not replace that judgment with a vague \"predicate issue\" or \"plan shape issue\".",{"type":45,"tag":76,"props":734,"children":735},{},[736,738,744,745,751,752,758],{"type":50,"value":737},"A long ",{"type":45,"tag":82,"props":739,"children":741},{"className":740},[],[742],{"type":50,"value":743},"InitTime",{"type":50,"value":157},{"type":45,"tag":82,"props":746,"children":748},{"className":747},[],[749],{"type":50,"value":750},"OpenTime",{"type":50,"value":157},{"type":45,"tag":82,"props":753,"children":755},{"className":754},[],[756],{"type":50,"value":757},"CloseTime",{"type":50,"value":759},", or profile total can matter, but only after confirming it is not accumulated across many instances and not dominated by a known wait\u002Fdependency branch.",{"type":45,"tag":53,"props":761,"children":763},{"id":762},"standard-answer-shape",[764],{"type":50,"value":765},"Standard Answer Shape",{"type":45,"tag":60,"props":767,"children":768},{},[769],{"type":50,"value":770},"When explaining a profile, answer in this order:",{"type":45,"tag":72,"props":772,"children":773},{},[774,785,796,807,818],{"type":45,"tag":76,"props":775,"children":776},{},[777,783],{"type":45,"tag":82,"props":778,"children":780},{"className":779},[],[781],{"type":50,"value":782},"Conclusion",{"type":50,"value":784},": one or two sentences naming the likely bottleneck and, when joins are involved, whether the plan shape\u002Fjoin order is likely the cause.",{"type":45,"tag":76,"props":786,"children":787},{},[788,794],{"type":45,"tag":82,"props":789,"children":791},{"className":790},[],[792],{"type":50,"value":793},"Evidence",{"type":50,"value":795},": profile counters with operator names, values, and whether each is active work, data volume, wait\u002Fbackpressure, memory\u002Fspill, or runtime-filter evidence.",{"type":45,"tag":76,"props":797,"children":798},{},[799,805],{"type":45,"tag":82,"props":800,"children":802},{"className":801},[],[803],{"type":50,"value":804},"Reasoning",{"type":50,"value":806},": how the evidence maps to the execution plan, which side is build\u002Fprobe or RF source\u002Ftarget, why misleading counters are discounted, and whether the join order is reasonable.",{"type":45,"tag":76,"props":808,"children":809},{},[810,816],{"type":45,"tag":82,"props":811,"children":813},{"className":812},[],[814],{"type":50,"value":815},"Next checks",{"type":50,"value":817},": the smallest additional profile\u002Flog\u002Fcode checks needed if the conclusion is still uncertain.",{"type":45,"tag":76,"props":819,"children":820},{},[821,827,829,834],{"type":45,"tag":82,"props":822,"children":824},{"className":823},[],[825],{"type":50,"value":826},"Solution \u002F mitigation",{"type":50,"value":828}," when requested: only name a solution that is directly supported by this profile or by a matching historical pattern in ",{"type":45,"tag":82,"props":830,"children":832},{"className":831},[],[833],{"type":50,"value":236},{"type":50,"value":835},". If no historical or profile-proven solution applies, say so and keep the item as a next check instead of inventing advice.",{"type":45,"tag":60,"props":837,"children":838},{},[839],{"type":50,"value":840},"Always preserve uncertainty. Use \"proven\", \"likely\", and \"not proven\" explicitly when the profile lacks enough detail.",{"type":45,"tag":53,"props":842,"children":844},{"id":843},"scripts",[845],{"type":50,"value":846},"Scripts",{"type":45,"tag":246,"props":848,"children":849},{},[850],{"type":45,"tag":76,"props":851,"children":852},{},[853,859],{"type":45,"tag":82,"props":854,"children":856},{"className":855},[],[857],{"type":50,"value":858},"scripts\u002Fextract_source_profile_inventory.py",{"type":50,"value":860},": scan Doris source for factory-created operators and counter\u002Finfo registrations.",{"type":45,"tag":60,"props":862,"children":863},{},[864],{"type":50,"value":865},"Scripts are evidence-generation helpers. They do not replace the reading workflow.",{"items":867,"total":956},[868,886,898,912,924,934,944],{"slug":869,"name":869,"fn":870,"description":871,"org":872,"tags":873,"stars":22,"repoUrl":23,"updatedAt":885},"doris-architecture-advisor","design Apache Doris data architectures","Workload-aware architecture design for Apache Doris. MUST USE when designing data architectures, choosing between data models, planning ingestion strategies, sizing clusters, or translating business requirements into Apache Doris system designs. Complements doris-best-practices with decision frameworks and sizing-first workflow. Use when user describes a workload involving: IoT, sensor data, telemetry, real-time analytics, dashboard, log analysis, log search, CDC sync, time-series, device monitoring, point query service, ad-hoc analytics, lakehouse federation, ETL\u002FELT pipeline, report analytics, clickstream, user behavior, observability, metrics, fleet tracking, or any OLAP workload requiring table design from scratch. Also triggers on prompts like: \"design a table for...\", \"how should I store...\", \"build an architecture for...\", \"we have X devices sending data every Y seconds\", \"recommend a cluster size for...\", \"what data model should I use for...\", \"we need to ingest X GB\u002Fday\", \"migrate from MySQL\u002FPostgreSQL to Apache Doris\". Also use for legacy analytics\u002Fsearch\u002Fserving stack consolidation prompts even when Apache Doris is not named explicitly, including replacing or migrating from Impala, Kudu, Elasticsearch\u002FES, Greenplum, Presto, HBase, Hive, Hadoop, Redis, or Lambda-style multi-engine data platforms.\n",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[874,877,880,883],{"name":875,"slug":876,"type":15},"Architecture","architecture",{"name":878,"slug":879,"type":15},"Data Engineering","data-engineering",{"name":881,"slug":882,"type":15},"Data Pipeline","data-pipeline",{"name":884,"slug":30,"type":15},"Database","2026-07-12T08:35:33.88758",{"slug":887,"name":887,"fn":888,"description":889,"org":890,"tags":891,"stars":22,"repoUrl":23,"updatedAt":897},"doris-best-practices","optimize Apache Doris table design and clusters","Apache Doris table design and cluster sizing best practices. MUST USE when writing, reviewing, or optimizing Doris CREATE TABLE statements, partition\u002Fbucket strategies, data models, or cluster configurations. ALSO MUST USE whenever the doris-architecture-advisor skill produces DDL — apply the Pre-Flight Checklist to every CREATE TABLE before output. Also triggers on any workload design involving: IoT, analytics, dashboard, CDC, time-series, log analysis, real-time warehouse, point query, data platform, or any scenario where table design decisions are being made. Also triggers on replacing or migrating from legacy analytics\u002Fsearch\u002Fserving stacks such as Impala, Kudu, Elasticsearch\u002FES, Greenplum, Presto, HBase, Hive, Hadoop, Redis, or Lambda-style multi-engine data platforms, even when Apache Doris is not named explicitly. Also use when user provides an Apache Doris connection string or asks to get started. Also triggers on slow query investigation, query profiling, runtime performance diagnosis, tablet skew analysis, and table health checks — any scenario where runtime evidence (profile output, tablet distribution) informs optimization. Cluster lifecycle, billing, and networking are managed-service operations, out of scope here — use your platform's cluster-management console for those.\n",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[892,893,896],{"name":884,"slug":30,"type":15},{"name":894,"slug":895,"type":15},"Engineering","engineering",{"name":13,"slug":14,"type":15},"2026-07-12T08:35:32.619438",{"slug":899,"name":899,"fn":900,"description":901,"org":902,"tags":903,"stars":22,"repoUrl":23,"updatedAt":911},"doris-debug","diagnose Apache Doris production issues","Apache Doris production diagnostics router. Use when Apache Doris queries are slow, imports are failing or timing out, compaction is raising -235 errors, nodes are OOM or crashing, materialized views are not rewriting, or tablet\u002Freplica health is degraded. Routes to the appropriate doris-debug-* skill. Covers shared-nothing and cloud (storage-compute separation) deployments.\n",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[904,905,908],{"name":20,"slug":21,"type":15},{"name":906,"slug":907,"type":15},"Monitoring","monitoring",{"name":909,"slug":910,"type":15},"Operations","operations","2026-07-25T05:56:31.330361",{"slug":913,"name":913,"fn":914,"description":915,"org":916,"tags":917,"stars":22,"repoUrl":23,"updatedAt":923},"doris-debug-cloud","debug Apache Doris cloud mode issues","Use for Doris storage-compute separation (cloud mode) issues: meta-service latency, cache miss storms, object store throughput, and shared-nothing config conflicts in compute groups.\n",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[918,921,922],{"name":919,"slug":920,"type":15},"Cloud","cloud",{"name":20,"slug":21,"type":15},{"name":13,"slug":14,"type":15},"2026-07-25T05:56:24.239866",{"slug":925,"name":925,"fn":926,"description":927,"org":928,"tags":929,"stars":22,"repoUrl":23,"updatedAt":933},"doris-debug-compaction","resolve Apache Doris compaction lag","Use for Doris -235 \u002F too many versions and compaction lag. Error raised in RowsetBuilder::check_tablet_version_count when version_count > max_tablet_version_num (default 2000) or meta serialize size limit.\n",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[930,931,932],{"name":884,"slug":30,"type":15},{"name":20,"slug":21,"type":15},{"name":13,"slug":14,"type":15},"2026-07-25T05:56:31.974921",{"slug":935,"name":935,"fn":936,"description":937,"org":938,"tags":939,"stars":22,"repoUrl":23,"updatedAt":943},"doris-debug-data-lake","debug Apache Doris data lake connectivity","Use for Doris external catalog issues: Hive\u002FIceberg\u002FPaimon\u002FHudi query failures, metadata refresh, filesystem S3\u002FHDFS connectivity, external MV rewrite misses.\n",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[940,941,942],{"name":878,"slug":879,"type":15},{"name":884,"slug":30,"type":15},{"name":20,"slug":21,"type":15},"2026-07-25T05:56:23.920304",{"slug":945,"name":945,"fn":946,"description":947,"org":948,"tags":949,"stars":22,"repoUrl":23,"updatedAt":955},"doris-debug-deployment","troubleshoot Apache Doris deployment failures","Use for Doris FE\u002FBE startup failures, port conflicts, priority_networks misrouting, meta_dir corruption, and ADD\u002FDROP BACKEND issues.\n",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[950,951,954],{"name":20,"slug":21,"type":15},{"name":952,"slug":953,"type":15},"Deployment","deployment",{"name":909,"slug":910,"type":15},"2026-07-25T05:56:21.494401",14,{"items":958,"total":1107},[959,977,989,1000,1013,1026,1044,1055,1065,1076,1086,1096],{"slug":960,"name":960,"fn":961,"description":962,"org":963,"tags":964,"stars":974,"repoUrl":975,"updatedAt":976},"datafusion-python","write Apache DataFusion Python code","Use when the user is writing datafusion-python (Apache DataFusion Python bindings) DataFrame or SQL code. Covers imports, data loading, DataFrame operations, expression building, SQL-to-DataFrame mappings, idiomatic patterns, and common pitfalls.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[965,968,971],{"name":966,"slug":967,"type":15},"Data Analysis","data-analysis",{"name":969,"slug":970,"type":15},"Python","python",{"name":972,"slug":973,"type":15},"SQL","sql",593,"https:\u002F\u002Fgithub.com\u002Fapache\u002Fdatafusion-python","2026-07-12T08:36:04.957626",{"slug":978,"name":978,"fn":979,"description":980,"org":981,"tags":982,"stars":986,"repoUrl":987,"updatedAt":988},"bydbql","generate and execute BanyanDB BydbQL queries","Generate, validate, and optionally execute read-only BanyanDB BydbQL for STREAM, MEASURE, TRACE, and PROPERTY resources. Use when the user asks to query BanyanDB, translate natural language to BydbQL, inspect BanyanDB schema or data, validate BydbQL, or fetch raw BanyanDB records.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[983,984,985],{"name":17,"slug":18,"type":15},{"name":884,"slug":30,"type":15},{"name":972,"slug":973,"type":15},344,"https:\u002F\u002Fgithub.com\u002Fapache\u002Fskywalking-banyandb","2026-07-12T08:31:01.294423",{"slug":990,"name":990,"fn":991,"description":992,"org":993,"tags":994,"stars":986,"repoUrl":987,"updatedAt":999},"compiling","compile and build BanyanDB projects","Compile and build the SkyWalking BanyanDB project. Use when the user asks to compile, build, or generate code for this project.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[995,998],{"name":996,"slug":997,"type":15},"Build","build",{"name":894,"slug":895,"type":15},"2026-07-12T08:31:06.373309",{"slug":1001,"name":1001,"fn":1002,"description":1003,"org":1004,"tags":1005,"stars":986,"repoUrl":987,"updatedAt":1012},"gh-pull-request","create GitHub pull requests for BanyanDB","Create a GitHub pull request for SkyWalking BanyanDB. Use when the user asks to create a PR, submit changes, or open a pull request.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[1006,1009],{"name":1007,"slug":1008,"type":15},"GitHub","github",{"name":1010,"slug":1011,"type":15},"Pull Requests","pull-requests","2026-07-12T08:31:03.792415",{"slug":1014,"name":1014,"fn":1015,"description":1016,"org":1017,"tags":1018,"stars":986,"repoUrl":987,"updatedAt":1025},"vendor-update","update Go and Node.js vendor dependencies","Upgrade Go\u002FNode.js vendor dependencies and sync tool versions. Use whenever the user says \"upgrade dependencies\", \"update vendors\", \"vendor update\", \"run vendor-upgrade\", \"bump dependencies\", \"update packages\", or asks to run the `vendor-update` Make target. This skill also checks `scripts\u002Fbuild\u002Fversion.mk` after upgrading to see if any tracked tool versions need updating too, and removes stale binaries from `bin\u002F` when versions change.\n",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[1019,1022],{"name":1020,"slug":1021,"type":15},"Go","go",{"name":1023,"slug":1024,"type":15},"Node.js","node-js","2026-07-12T08:31:02.555555",{"slug":1027,"name":1027,"fn":1028,"description":1029,"org":1030,"tags":1031,"stars":1041,"repoUrl":1042,"updatedAt":1043},"cayenne-cgen","generate Cayenne entity Java classes","Use this skill whenever the user wants to (re)generate Cayenne entity Java classes from a DataMap. Trigger on phrases like 'generate Java classes', 'regenerate entities', 'run cgen', 'create the entity classes', 'why is the Artist class missing fields', 'where did the `_Abstract*` classes come from', 'sync the entity classes with the model', or any request to materialize Java from the DataMap. Also trigger as a follow-up after modeling changes (someone added an entity, attribute, or relationship and now the Java side is stale). This skill exclusively uses the `mcp__cayenne__cgen_run` MCP tool — it does NOT use `mvn cayenne:cgen` or the Gradle cgen task.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[1032,1035,1038],{"name":1033,"slug":1034,"type":15},"Data Modeling","data-modeling",{"name":1036,"slug":1037,"type":15},"Java","java",{"name":1039,"slug":1040,"type":15},"ORM","orm",343,"https:\u002F\u002Fgithub.com\u002Fapache\u002Fcayenne","2026-07-12T08:32:33.575211",{"slug":1045,"name":1045,"fn":1046,"description":1047,"org":1048,"tags":1049,"stars":1041,"repoUrl":1042,"updatedAt":1054},"cayenne-db-import","import database schema into Cayenne DataMaps","Use this skill when the user wants to import database schema metadata into a Cayenne DataMap — the *model\u002Fmapping only*, not names or Java classes. Trigger on phrases like 'reverse engineer the database', 'import the schema', 'generate a DataMap from my DB', 'add the new tables from the DB into the model', 'import the customer table', 'create entities from these tables', or any request to read database metadata to populate or update a DataMap's XML. This is for *full schema* or *bulk table* import; one-off a-la-carte entity additions belong in the cayenne-modeling skill. IMPORTANT — scope: this imports the mapping ONLY; it does not clean up the Object-layer names or (re)generate Java classes. When the user wants their whole project brought in line with the DB ('sync my project with the database', 'my schema changed, update everything', 'update my entities\u002Fclasses from the DB'), that is the end-to-end `cayenne-full-db-sync` skill, which runs this import and then name cleanup and class generation. To regenerate classes alone use `cayenne-cgen`. The skill runs reverse engineering directly via the `mcp__cayenne__dbimport_run` MCP tool when a DBConnector is already configured; otherwise it opens the CayenneModeler GUI via `mcp__cayenne__open_project` to configure the connection first.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[1050,1051,1052,1053],{"name":884,"slug":30,"type":15},{"name":1036,"slug":1037,"type":15},{"name":1039,"slug":1040,"type":15},{"name":972,"slug":973,"type":15},"2026-07-19T05:40:33.655062",{"slug":1056,"name":1056,"fn":1057,"description":1058,"org":1059,"tags":1060,"stars":1041,"repoUrl":1042,"updatedAt":1064},"cayenne-full-db-sync","synchronize Cayenne projects with database","Use this skill when the user wants to bring their WHOLE Cayenne project in line with the database in one shot — the mapping, the Object-layer names, and the generated Java classes together. This is the end-to-end 'sync with the DB' workflow, and it orchestrates three skills in order: `cayenne-db-import` (import schema metadata into the DataMap) → `cayenne-model-naming` (polish the just-imported names) → `cayenne-cgen` (regenerate Java classes). Trigger on holistic phrases like 'sync my project with the database', 'sync with the DB', 'my schema changed, update everything', 'update my entities\u002Fclasses from the database', 'reverse engineer and regenerate the classes', 'import the new tables and rebuild the entities', 'full DB sync', 'bring the model and classes up to date with the DB'. The distinguishing signal is scope: the user wants the whole project (mapping + names + Java code), not just one stage. For the *model\u002Fmapping only* (no name cleanup, no class generation) use `cayenne-db-import`; to (re)generate classes alone use `cayenne-cgen`; to clean names alone use `cayenne-model-naming`. Uses the `mcp__cayenne__dbimport_run` and `mcp__cayenne__cgen_run` MCP tools via the sub-skills; does NOT use Maven or Gradle goals.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[1061,1062,1063],{"name":884,"slug":30,"type":15},{"name":1036,"slug":1037,"type":15},{"name":1039,"slug":1040,"type":15},"2026-07-19T06:03:49.112969",{"slug":1066,"name":1066,"fn":1067,"description":1068,"org":1069,"tags":1070,"stars":1041,"repoUrl":1042,"updatedAt":1075},"cayenne-model-naming","clean up Cayenne object-layer names","Use this skill to clean up Object-layer names in a Cayenne DataMap — ObjEntity, ObjAttribute, and ObjRelationship names, plus DbRelationship names (the first-class unit of relationship cleanup — every FK has one whether or not an ObjRelationship was generated; the ObjRelationship name is synced to it when one exists) — so they read as descriptive, consistent Java. Trigger on phrases like 'clean up the model names', 'fix the entity names', 'these names look ugly', 'make the names descriptive', 'normalize the ObjEntity\u002Fattribute\u002Frelationship names', 'why is this relationship called team1', 'rename entities to be consistent', 'the import produced Gametype instead of GameType'. Invoke it on an explicit user request, or as a manual follow-up after a `cayenne-db-import` to polish the just-imported additions — it is never triggered automatically. IMPORTANT: this is a LIGHT polish pass — CayenneModeler's reverse-engineering already produces good names for the common case; only improve the specific things its deterministic algorithm cannot (run-together names with no separators like `gametype`, meaningless numbered names like `team1` from multiple relationships between two tables, and a common entity prefix that leaks into relationship names like `aaOrders`). Do NOT rewrite names that are already correct. This is Obj-layer naming polish; for structural model edits use `cayenne-modeling`, and for regenerating classes afterward use `cayenne-cgen`.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[1071,1072,1073,1074],{"name":1033,"slug":1034,"type":15},{"name":884,"slug":30,"type":15},{"name":1036,"slug":1037,"type":15},{"name":1039,"slug":1040,"type":15},"2026-07-22T05:35:32.342548",{"slug":1077,"name":1077,"fn":1078,"description":1079,"org":1080,"tags":1081,"stars":1041,"repoUrl":1042,"updatedAt":1085},"cayenne-modeler","manage Cayenne projects with CayenneModeler","Use this skill when the user explicitly wants to open CayenneModeler (the GUI) on a Cayenne project, or when the modeling task is inherently visual — reverse engineering (delegated to cayenne-db-import), bulk relationship layout, multi-entity visual refactoring. Trigger on phrases like 'open the Modeler', 'open in CayenneModeler', 'launch the GUI', 'edit visually', 'show me the project in the Modeler'. Do NOT trigger as a fallback for ordinary a-la-carte XML edits — those belong in the cayenne-modeling skill, which is faster and doesn't require the user to context-switch.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[1082,1083,1084],{"name":1033,"slug":1034,"type":15},{"name":1036,"slug":1037,"type":15},{"name":1039,"slug":1040,"type":15},"2026-07-12T08:32:37.199428",{"slug":1087,"name":1087,"fn":1088,"description":1089,"org":1090,"tags":1091,"stars":1041,"repoUrl":1042,"updatedAt":1095},"cayenne-modeling","edit and extend Cayenne ORM models","Use this skill whenever the user wants to edit, inspect, or extend the Cayenne ORM model in a project — adding or modifying entities, attributes, relationships, embeddables, named queries, stored procedures, or DataNodes. Trigger on phrases like 'add an ObjEntity', 'add a DbEntity', 'add a relationship', 'expose this column as an attribute', 'create a new DataMap', 'add a named query', 'create an embeddable', 'add a stored procedure', 'change the attribute type', 'mark this column as nullable', 'rename this entity', or any mention of a Cayenne `*.map.xml` or `cayenne-*.xml` file. Also trigger when the user references modeling concepts (ObjEntity, DbEntity, ObjAttribute, DbAttribute, ObjRelationship, DbRelationship, Embeddable, dbEntityName, deleteRule, db-attribute-path, db-relationship-path, defaultPackage) in the context of a Cayenne-using app. This is the *primary* skill for a-la-carte ORM model manipulation — direct XML edits, not the Modeler GUI.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[1092,1093,1094],{"name":884,"slug":30,"type":15},{"name":1036,"slug":1037,"type":15},{"name":1039,"slug":1040,"type":15},"2026-07-19T05:40:32.6889",{"slug":1097,"name":1097,"fn":1098,"description":1099,"org":1100,"tags":1101,"stars":1041,"repoUrl":1042,"updatedAt":1106},"cayenne-query","write and modify Cayenne database queries","Use this skill whenever the user wants to write or modify a Cayenne query — fetching entities by criteria, joining, prefetching to avoid N+1, ordering, paginating, aggregating, or running raw SQL through Cayenne. Trigger on phrases like 'query for X', 'fetch all artists where ...', 'write an ObjectSelect', 'use SQLSelect', 'use SelectById', 'add a prefetch', 'get distinct values', 'count rows', 'find by ID', 'load by primary key', 'build a Cayenne expression', 'why am I getting N+1', 'how do I paginate', 'select a single column', 'select columns into a DTO', 'named query in the DataMap'. Do NOT trigger for modeling changes (use cayenne-modeling) or runtime bootstrap (use cayenne-runtime).",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[1102,1103,1104,1105],{"name":884,"slug":30,"type":15},{"name":1036,"slug":1037,"type":15},{"name":1039,"slug":1040,"type":15},{"name":972,"slug":973,"type":15},"2026-07-12T08:32:35.072322",108]