[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6ACTEQZ2S4PDZ2MW3C12HJ4":3,"skill-same:01M6ACTEQZ2S4PDZ2MW3C12HJ4":105},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":23,"publishedAt":29,"linkOnly":30,"markdownContent":31,"markdownBody":32,"frontMatter":33,"refName":34,"commitSha":35,"skillDirectory":36,"forksCount":37,"repositoryHtmlUrl":38,"repositoryHomepageUrl":39,"ownerHtmlUrl":40,"ownerBlogUrl":41,"ownerDescription":6,"updatedAt":42,"install":43,"resources":56},"01M6ACTEQZ2S4PDZ2MW3C12HJ4","doris-profile-reader",null,"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.","apache\u002Fdoris-skills","apache","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F47359?v=4","01M6AC83E6K4FDKK7HZ8WNMQKE","The Apache Software Foundation","01M6ACSCMG5B9TTB7694HY14D0",50,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fapache\u002Fdoris-skills\u002Fblob\u002Fmain\u002Fskills\u002Fdoris-profile-reader\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[24,25,26,27,9,28],"doris","doris profile reader","performance","triage","operator","2026-11-10 10:12:30",false,"---\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","# 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",{"name":5,"description":7},"main","3f49b0021e7900d691790da5feec34034826b970","skills\u002Fdoris-profile-reader",15,"https:\u002F\u002Fgithub.com\u002Fapache\u002Fdoris-skills","https:\u002F\u002Fdoris.apache.org","https:\u002F\u002Fgithub.com\u002Fapache","https:\u002F\u002Fwww.apache.org\u002F","2026-11-04 15:50:17",{"source":8,"skillName":5,"commands":44,"prompt":54,"zipAvailable":55},[45,48,51],{"tool":46,"command":47},"npx","npx skills add apache\u002Fdoris-skills --skill doris-profile-reader",{"tool":49,"command":50},"bunx","bunx skills add apache\u002Fdoris-skills --skill doris-profile-reader",{"tool":52,"command":53},"pnpm","pnpm dlx skills add apache\u002Fdoris-skills --skill doris-profile-reader","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fapache\u002Fdoris-skills\u002Fblob\u002Fmain\u002Fskills\u002Fdoris-profile-reader\u002FSKILL.md",true,[57,63,67,71,75,79,83,87,91,95,99],{"path":58,"resourceType":59,"resourceTypeDesc":60,"sizeBytes":61,"sourceHtmlUrl":62},"agents\u002Fopenai.yaml","REFERENCE","参考文档",1134,"https:\u002F\u002Fgithub.com\u002Fapache\u002Fdoris-skills\u002Fblob\u002Fmain\u002Fskills\u002Fdoris-profile-reader\u002Fagents\u002Fopenai.yaml",{"path":64,"resourceType":59,"resourceTypeDesc":60,"sizeBytes":65,"sourceHtmlUrl":66},"references\u002Fcounter-semantics.md",18234,"https:\u002F\u002Fgithub.com\u002Fapache\u002Fdoris-skills\u002Fblob\u002Fmain\u002Fskills\u002Fdoris-profile-reader\u002Freferences\u002Fcounter-semantics.md",{"path":68,"resourceType":59,"resourceTypeDesc":60,"sizeBytes":69,"sourceHtmlUrl":70},"references\u002Ffailure-patterns.md",22000,"https:\u002F\u002Fgithub.com\u002Fapache\u002Fdoris-skills\u002Fblob\u002Fmain\u002Fskills\u002Fdoris-profile-reader\u002Freferences\u002Ffailure-patterns.md",{"path":72,"resourceType":59,"resourceTypeDesc":60,"sizeBytes":73,"sourceHtmlUrl":74},"references\u002Fjoin-order-diagnosis.md",14229,"https:\u002F\u002Fgithub.com\u002Fapache\u002Fdoris-skills\u002Fblob\u002Fmain\u002Fskills\u002Fdoris-profile-reader\u002Freferences\u002Fjoin-order-diagnosis.md",{"path":76,"resourceType":59,"resourceTypeDesc":60,"sizeBytes":77,"sourceHtmlUrl":78},"references\u002Fknown-issues-solutions.md",19397,"https:\u002F\u002Fgithub.com\u002Fapache\u002Fdoris-skills\u002Fblob\u002Fmain\u002Fskills\u002Fdoris-profile-reader\u002Freferences\u002Fknown-issues-solutions.md",{"path":80,"resourceType":59,"resourceTypeDesc":60,"sizeBytes":81,"sourceHtmlUrl":82},"references\u002Foperator-guide.md",21152,"https:\u002F\u002Fgithub.com\u002Fapache\u002Fdoris-skills\u002Fblob\u002Fmain\u002Fskills\u002Fdoris-profile-reader\u002Freferences\u002Foperator-guide.md",{"path":84,"resourceType":59,"resourceTypeDesc":60,"sizeBytes":85,"sourceHtmlUrl":86},"references\u002Freading-workflow.md",19127,"https:\u002F\u002Fgithub.com\u002Fapache\u002Fdoris-skills\u002Fblob\u002Fmain\u002Fskills\u002Fdoris-profile-reader\u002Freferences\u002Freading-workflow.md",{"path":88,"resourceType":59,"resourceTypeDesc":60,"sizeBytes":89,"sourceHtmlUrl":90},"references\u002Fruntime-filters.md",7766,"https:\u002F\u002Fgithub.com\u002Fapache\u002Fdoris-skills\u002Fblob\u002Fmain\u002Fskills\u002Fdoris-profile-reader\u002Freferences\u002Fruntime-filters.md",{"path":92,"resourceType":59,"resourceTypeDesc":60,"sizeBytes":93,"sourceHtmlUrl":94},"references\u002Fsolution-playbook.md",10888,"https:\u002F\u002Fgithub.com\u002Fapache\u002Fdoris-skills\u002Fblob\u002Fmain\u002Fskills\u002Fdoris-profile-reader\u002Freferences\u002Fsolution-playbook.md",{"path":96,"resourceType":59,"resourceTypeDesc":60,"sizeBytes":97,"sourceHtmlUrl":98},"references\u002Fsource-profile-inventory.md",66958,"https:\u002F\u002Fgithub.com\u002Fapache\u002Fdoris-skills\u002Fblob\u002Fmain\u002Fskills\u002Fdoris-profile-reader\u002Freferences\u002Fsource-profile-inventory.md",{"path":100,"resourceType":101,"resourceTypeDesc":102,"sizeBytes":103,"sourceHtmlUrl":104},"scripts\u002Fextract_source_profile_inventory.py","SCRIPT","脚本",6015,"https:\u002F\u002Fgithub.com\u002Fapache\u002Fdoris-skills\u002Fblob\u002Fmain\u002Fskills\u002Fdoris-profile-reader\u002Fscripts\u002Fextract_source_profile_inventory.py",[106,132,143,164,175,187],{"skillNo":107,"name":108,"nameZh":6,"description":109,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":110,"categories":111,"keywords":113,"publishedAt":29},"01M6M1B6Y0NBNVC1WN8QEVGZ28","doris-pr-description","Write, rewrite, or check the title and description of an Apache Doris pull request against the Doris PR standard. Takes the facts from the handoff file that development left when there is one, and collects them from the diff, commits, linked issue, and existing tests otherwise; classifies the PR type, fills that type's required fields, drafts the issue a Feature needs, validates the draft with a bundled checker, and creates or updates the PR on GitHub only after the user confirms. Use whenever the user wants to open, create, submit, or update a Doris PR; write, fix, or improve a PR title or description; prepare a branch for review; rewrite an existing PR's description for comparison; or check whether a description meets the standard. Also use for short requests in any language, such as \"open a PR\", \"write the PR description\", or \"is this PR description good enough?\", even when the standard is not mentioned.","https:\u002F\u002Fgithub.com\u002Fapache\u002Fdoris-skills\u002Fblob\u002Fmain\u002Fskills\u002Fdoris-pr-description\u002FSKILL.md",[112],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[114,115,24,116,117,118,119,120,121,122,123,9,124,125,126,127,128,129,130,131],"pr","pr description","doris pr description","checker","update","only","request","updates","good","submit","pr title","open","improve","branch","short","fix","create","review",{"skillNo":133,"name":134,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":135,"categories":136,"keywords":138,"publishedAt":29},"01M6M1B0334YPC8P5KQ11V0JX8","develop-with-evidence","https:\u002F\u002Fgithub.com\u002Fapache\u002Fdoris-skills\u002Fblob\u002Fmain\u002Fskills\u002Fdevelop-with-evidence\u002FSKILL.md",[137],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[139,140,141,142],"develop with evidence","with","evidence","develop",{"skillNo":144,"name":145,"nameZh":6,"description":146,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":147,"categories":148,"keywords":153,"publishedAt":29},"01M6ACTH4YX29N7GXTT61H6WTK","doris-repo-review","Review an Apache Doris PR from a local clone with the same multi-agent, shared-ledger convergence workflow as the CI Code Review Runner. Use when the user supplies a PR to `\u002Fdoris-repo-review`, asks to review a Doris PR locally, or asks for the CI-style review flow. Safely align only the current worktree to the exact PR head, refuse to disturb tracked local changes, write equivalent English and Chinese review documents with verified path-line anchors, and never build, test, or edit source. Treat a review as pipeline-equivalent only when an explicitly selected qualified reviewer uses a supported effort (xhigh or max, plus ultra for Codex), preferring GPT-6 Astra on Codex and Fable 5.1 on Claude Code. After a converged APPROVE result, automatically post one machine-readable PASS comment bound to the reviewed commit.","https:\u002F\u002Fgithub.com\u002Fapache\u002Fdoris-skills\u002Fblob\u002Fmain\u002Fskills\u002Fdoris-repo-review\u002FSKILL.md",[149,152],{"categoryNo":150,"categoryName":151,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000007","代码审查",{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[131,154,24,155,156,157,158,159,160,161,114,162,9,163],"doris repo review","gpt","workflow","code review","codex","test","commit","documents","code","worktree",{"skillNo":165,"name":166,"nameZh":6,"description":167,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":168,"categories":169,"keywords":170,"publishedAt":29},"01M6ACTCZC9VCV91Q0RVNZC2R5","doris-debug-tablet","Use for Doris tablet\u002Freplica health, version skew, clone backlog, disk balance, and tablet repair. Commands: SHOW PROC tablet_health, SHOW TABLET, ADMIN REPAIR.","https:\u002F\u002Fgithub.com\u002Fapache\u002Fdoris-skills\u002Fblob\u002Fmain\u002Fskills\u002Fdoris-debug\u002Ftablet\u002FSKILL.md",[],[171,172,24,173,174],"doris debug tablet","doris debug","debug","admin",{"skillNo":176,"name":177,"nameZh":6,"description":178,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":179,"categories":180,"keywords":181,"publishedAt":29},"01M6ACTAVGGVYTAWTPMMZYS71J","doris-debug-resource-isolation","Use for Doris Workload Group \u002F resource tag queue starvation, CPU\u002Fmemory isolation leaks, and workload policy debugging. Commands: SHOW WORKLOAD GROUPS, EXPLAIN resource.","https:\u002F\u002Fgithub.com\u002Fapache\u002Fdoris-skills\u002Fblob\u002Fmain\u002Fskills\u002Fdoris-debug\u002Fresource-isolation\u002FSKILL.md",[],[24,173,182,172,183,184,185,186],"doris debug resource isolation","policy","memory","workload","debugging",{"skillNo":188,"name":189,"nameZh":6,"description":190,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":191,"categories":192,"keywords":193,"publishedAt":29},"01M6ACT8YW06ATHK11E5NA8XAT","doris-debug-query","Use for Apache Doris slow\u002Fhanging\u002Ftimeout queries. Covers FE planner (Nereids timeout), BE Profile bottlenecks, and Exchange WaitForData \u002F brpc E1008 on port 8060. Session vars: enable_profile, query_timeout, nereids_timeout_second.","https:\u002F\u002Fgithub.com\u002Fapache\u002Fdoris-skills\u002Fblob\u002Fmain\u002Fskills\u002Fdoris-debug\u002Fquery\u002FSKILL.md",[],[173,24,172,194,9],"doris debug query"]