[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M7985DFYH5RRCDFTWAFYDFGA":3,"skill-same:01M7985DFYH5RRCDFTWAFYDFGA":57},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":17,"publishedAt":18,"linkOnly":19,"markdownContent":20,"markdownBody":21,"frontMatter":22,"refName":23,"commitSha":24,"skillDirectory":25,"forksCount":13,"repositoryHtmlUrl":26,"repositoryHomepageUrl":6,"ownerHtmlUrl":27,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":28,"install":29,"resources":42},"01M7985DFYH5RRCDFTWAFYDFGA","triton-npu-optimize",null,"Iteratively optimize a Triton Ascend NPU operator with correctness and performance gates. Use for operator optimization tasks that need repeated correctness validation, benchmark validation, multi-round experiment tracking, reusable optimization notes, and profiler-backed performance analysis when benchmark results need deeper explanation.","Piagari\u002Fhelix","Piagari","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F129916910?v=4","01M7980QB9Y8WK5TSSRJDC7H1X","01M7980QCA2FWSBBSSM695Y10B",0,"Apache-2.0","https:\u002F\u002Fgithub.com\u002FPiagari\u002Fhelix\u002Fblob\u002Fmain\u002Fskills\u002Ftriton\u002Ftriton-npu-optimize\u002FSKILL.md",[],[],"2026-11-15 14:19:17",false,"---\nname: triton-npu-optimize\ndescription: Iteratively optimize a Triton Ascend NPU operator with correctness and performance gates. Use for operator optimization tasks that need repeated correctness validation, benchmark validation, multi-round experiment tracking, reusable optimization notes, and profiler-backed performance analysis when benchmark results need deeper explanation.\n---\n\n# Optimize\n\n## Goal\n\nOptimize one Triton Ascend NPU operator through validated rounds anchored to a canonical `baseline\u002F`.\n\nUse this skill when the user wants the operator itself improved rather than only generating or running tests and benchmarks.\n\nOptimize target modes:\n\n- `kernel`: optimize the Triton Ascend NPU kernel path itself. Compare rounds with a kernel-oriented `compare-perf` view, but if the comparison falls back to total-op for some cases, record the resolved `effective_metric_source` and surface that mismatch as a warning instead of discarding the round outright.\n- `operator`: optimize end-to-end operator latency. Wrapper logic, data movement, scheduling, pre-processing, post-processing, and kernel code are all valid optimization surfaces as long as the Triton Ascend NPU computation path remains real. Show both kernel and total-op `compare-perf` views, but use the total-op view as the canonical round conclusion.\n\n## Inputs\n\n- Operator source code or an operator file path\n\n## Outputs\n\n- `baseline\u002F`\n- `opt-round-N\u002F`\n- completed round entries and one final `## Overall Summary` in `opt-note.md`\n- round-local `profile\u002F`, `ir\u002F`, `perf-analysis.md`, or `compiler-analysis.md` artifacts when deeper investigation is needed\n\n## Core Loop\n\n- establish or reuse `baseline\u002F`\n- open `opt-round-N\u002F`, initialize round strategy state through `ascend-npu-optimize-state start-round`, and start `attempts.md`\n- choose the current analysis level\n- treat each round as one code-changing optimization attempt followed by canonical validation\n- make one coherent optimization attempt\n- optionally screen the direction cheaply with `probe-bench` when the available run-eval surface exposes it\n- validate correctness and benchmark performance\n- After the first canonical `run-bench` plus `compare-perf` conclusion for that attempt, stop editing the current round.\n- record the round outcome\n\n## Stage 0: Baseline Setup\n\n- Reuse the existing `baseline\u002F` only when it remains canonical for the current operator workspace.\n- Otherwise use the sibling `ascend-npu-prepare-optimize-baseline` skill to establish or repair the baseline before creating `opt-round-1\u002F`.\n- Establish or reuse `baseline\u002F` before treating any `opt-round-N\u002F` directory as a completed optimization round.\n- Read [artifacts.md](references\u002Fartifacts.md) before choosing authoritative baseline or round artifact paths.\n- Read [opt-note-format.md](references\u002Fopt-note-format.md) before initializing `opt-note.md`.\n- Keep top-level optimize workflow references at the skill boundary: use sibling skills for baseline preparation, evaluation, profiling, IR analysis, compiler-source analysis, and round gating rather than direct helper-script paths here.\n\n## Stage 1: Round Entry\n\n- Create `opt-round-N\u002F` from a validated parent candidate and keep parent-child traceability explicit.\n- Use the sibling `ascend-npu-optimize-state` skill's `start-round` subcommand to initialize the active round's `round_strategy`, `analysis_policy`, and `reason` before the first code change in that round.\n- Start `attempts.md` immediately so every meaningful attempt and measurement is recorded.\n- Treat the structured `State Update` blocks in `attempts.md` as script-written workflow history; do not manually duplicate the same `round_strategy`, `analysis_policy`, and `reason` bookkeeping in both `attempts.md` and `summary.md`.\n- For round 1, record the initial round hypothesis in `opt-round-1\u002Fattempts.md` before the first code change.\n- When pattern triage is used, explicitly record the candidate patterns you considered, the selected pattern if one is chosen, and why that pattern looks plausible in `attempts.md`.\n- When a named pattern guides the round, explicitly record the final selected pattern direction in `summary.md`.\n- Record the current analysis level as `Primary analysis level`, and record `Supporting evidence` separately.\n- Record why that level may help and what evidence supports starting there.\n- If the round starts from reused deeper evidence, cite the reused evidence path and explain why the shallower level is already established or insufficient.\n- Treat `opt-note.md` as the top-level round ledger plus final `## Overall Summary`.\n- If the active round's intent or required evidence depth changes mid-round, use the sibling `ascend-npu-optimize-state` skill's `set-current-round-state` subcommand instead of silently changing the round contract in prose only.\n\n## Stage 2: Layered Analysis\n\nOptimize analysis is layered.\n\n- Default escalation order: `pattern triage -> profiling diagnosis -> IR attribution -> compiler-source escalation`.\n- Start each round at the shallowest level that can justify the next move.\n- Escalate only when the current level is insufficient.\n- Keep `Primary analysis level` distinct from `Supporting evidence` in round records.\n- Using IR as supporting evidence does not automatically change the round's primary analysis level.\n- Record the chosen level and why the round stayed there or escalated deeper.\n- Show the level explicitly in `attempts.md`, for example `Primary analysis level: profiling diagnosis`.\n- When a round escalates, record both `Escalation: \u003Cfrom> -> \u003Cto>` and `Escalation reason: \u003Cwhy the previous level was insufficient>`.\n- Do not rely on the presence of `profile\u002F`, `ir\u002F`, or `perf-analysis.md` to imply the current level; state it directly.\n\n### pattern triage\n\n- Inspect current code structure and benchmark behavior before choosing a direction.\n- Use the staged `triton-npu-optimize-knowledge` skill as the generic optimize knowledge library.\n- When the optimize target is `operator`, also use the staged `torch-npu-optimize-knowledge` skill for Torch NPU and whole-operator pattern routing such as framework-op fallback, wrapper-level changes, or broader operator restructuring.\n- Read the staged `triton-npu-optimize-knowledge` skill's `references\u002Fpattern_index.md` before detailed pattern references.\n- Read only the one or two most relevant detailed pattern files under the staged `triton-npu-optimize-knowledge` skill's `references\u002Fpatterns\u002F` directory after the generated index has narrowed the candidate set.\n- When the optimize target is `operator` and the bottleneck looks Torch NPU or framework-op specific, read the staged `torch-npu-optimize-knowledge` skill's `references\u002Fpattern_index.md` before detailed Torch NPU pattern references.\n- When code structure is still unclear at pattern triage, inspect the operator file directly and narrow candidates with the generated pattern index.\n- Do not leave the chosen pattern implicit in free-form prose; write it down explicitly in `attempts.md`, and carry the final named pattern direction into `summary.md` when it guided the round.\n- Very strongly consider using subagents to read pattern references, scan for potentially useful optimization ideas, and report back which patterns look promising for the current kernel.\n- When subagents are available, prefer using them to broaden pattern exploration before committing to the round hypothesis.\n- Pattern references are helpful guidance, not the only allowed source of ideas.\n- If your own Triton, Ascend NPU, or kernel-optimization knowledge suggests a stronger direction than the current pattern library, you may use that direction directly as long as you still record the hypothesis clearly and validate it with the same correctness and benchmark gates.\n- You do not need an existing pattern file to justify every optimization round.\n- When the kernel is structurally matmul-like, read the staged `triton-npu-optimize-knowledge` skill's `references\u002Fpatterns\u002Fclassic-matmul.md` before rewriting the hot loop so the round records the standard tiled-matmul shape, dtype, and masking rules explicitly.\n- Do not treat pattern triage as permission for aimless pattern search without tying the candidate patterns back to the kernel structure or observed evidence.\n\n### profiling diagnosis\n\n- Use profiling diagnosis as the default deeper entrypoint when pattern triage is not enough.\n- Use the sibling `ascend-npu-profile-operator` skill when benchmark numbers need operator-level performance evidence, hotspot diagnosis, bottleneck analysis, or profiler-backed comparison across runs.\n- Use the sibling `ascend-npu-analyze-round-performance` skill when one round needs a deeper diagnosis that should end in `opt-round-N\u002Fperf-analysis.md`, especially for scalar\u002Fvector\u002Fcube imbalance, transfer-heavy behavior, or suspected pipeline overlap issues.\n- Use the sibling knowledge skill's symptom cards to narrow pattern candidates after structured profiler or IR evidence exists, rather than rereading the whole pattern library.\n- This deeper diagnosis may end as either `profile-only diagnosis` or `profile-plus-IR diagnosis`.\n- Write `opt-round-N\u002Fperf-analysis.md` when the deeper round-analysis flow is used.\n\n### IR attribution\n\n- Use IR attribution only after profiler-backed symptoms still need explanation.\n- `ascend-npu-analyze-round-performance` may still own `opt-round-N\u002Fperf-analysis.md` when the round deepens from profiler evidence into IR-backed attribution.\n- In that flow, use `triton-npu-analyze-ir` as the IR evidence companion for capture, navigation, and stage-level inspection.\n- Use the sibling `triton-npu-analyze-ir` skill when compiler lowering details, stage-to-stage IR changes, or round-local IR evidence are needed to explain benchmark behavior.\n- Keep IR evidence under `opt-round-N\u002Fir\u002F`.\n- In optimize rounds, keep IR capture round-local. Use the `triton-npu-analyze-ir` skill's helpers with argument shapes such as:\n  ```text\n  capture_ir.py --ir-dir opt-round-N\u002Fir --bench-file bench_\u003Coperator>.py --operator-file opt-round-N\u002F\u003Coptimized-operator>.py\n  inspect_ir.py list-stages --ir-dir opt-round-N\u002Fir --sort-by interesting --limit 20\n  ```\n\n### compiler-source escalation\n\n- Use compiler-source escalation only when compiler source analysis is enabled and after profiler and IR evidence have narrowed a concrete compiler-side question.\n- Use the sibling `triton-npu-analyze-compiler-source` skill only when the round still needs performance-focused explanation before the next operator change is clear.\n- When compiler source analysis is enabled, treat the compiler source checkout as read-only and use compiler-source evidence only when it is genuinely needed.\n- Write `opt-round-N\u002Fcompiler-analysis.md`.\n\n## Kernel Semantic Repairs\n\n- During kernel optimization work, inspect kernel compare-helper call sites such as `tl.maximum()` and `tl.minimum()` across the operator, not only the lines touched by the primary optimization.\n- If a kernel compare-helper call omits `propagate_nan`, you may add `propagate_nan=tl.PropagateNan.ALL` as a consistency repair when the intended semantics are explicit NaN propagation.\n- Treat this as a semantic choice because it can change NaN-input behavior. Do not present it as a no-op cleanup.\n\n## Stage 3: Validate And Record\n\n- Run correctness validation before trusting any performance result.\n- After correctness passes, you may use the sibling `ascend-npu-run-eval` skill's `probe-bench` flow as a fast baseline-vs-candidate screen when you need a cheap directional signal before paying canonical benchmark cost.\n- Use `probe-bench` only when the active run-eval surface actually exposes it. If the current surface does not expose `probe-bench`, skip the screen and continue with canonical validation.\n- Treat `probe-bench` as non-canonical screening evidence only. Do not use its output as the official round perf artifact, do not write probe artifacts into `round-state.json`, and do not claim round speedups from probe output alone.\n- Use `probe-bench` to reject clearly bad candidates early or to justify keeping a clearly promising direction long enough to run canonical benchmarking.\n- After correctness passes, run benchmark validation and preserve the round-local benchmark evidence.\n- In each round directory, keep the optimized operator snapshot as `opt_\u003Coriginal-operator>.py`.\n- In each round directory, keep the benchmark artifact as `opt_\u003Coriginal-operator>_perf.txt`, ensure that file is generated by the `ascend-npu-run-eval` skill's `run-bench` flow, and record that exact filename in `round-state.json`.\n- Use `baseline\u002F\u003Coperator>_perf.txt` for canonical optimize-session performance comparisons, even when the current round also compares locally against its parent.\n- Once baseline and round perf artifacts both exist, use the `ascend-npu-run-eval` skill to run `compare-perf`.\n- Even after `probe-bench` reports `likely_gain` or `likely_regression`, still run canonical `run-bench` and `compare-perf` before recording any official round conclusion.\n- Treat the `ascend-npu-run-eval` skill's `compare-perf` flow as the only authority for claimed benchmark deltas and speedups, including `Avg improvement`, `Geomean speedup`, and any claimed benchmark delta.\n- Record exactly one resolved comparison basis in `round-state.json` as `effective_metric_source`, using `kernel`, `total-op`, or `mixed`.\n- In `kernel` target mode, prefer the kernel-oriented comparison result, but if `compare-perf` falls back to total-op for some or all cases, keep the round eligible and record that fallback as a warning.\n- In `operator` target mode, show both kernel and total-op comparison results so you can diagnose whether kernel improvements translated end-to-end, then record `effective_metric_source: total-op` for the official round conclusion.\n- If the result is slower, inconclusive, or not worth promoting, close the round and carry the next optimization idea into a new round instead of revising the current round again.\n- If correctness repair is no longer worthwhile, canonical benchmark execution keeps failing, or the time cost is no longer justified, close the round as a rejected terminal round instead of exiting silently. Preserve the minimum round artifacts, write `correctness_status` and `benchmark_status` honestly, and still use `submit-round` so the workflow records the round outcome.\n- When `benchmark_status` is `passed`, `round-state.json` must include the benchmark artifact metadata fields. When `benchmark_status` is `failed` or `not_run`, those benchmark metadata fields may be omitted if no canonical perf artifact was produced.\n- Do not hand-calculate speedups or percentage improvements from raw perf files.\n- Use the sibling `ascend-npu-optimize-state` skill's `submit-round` subcommand to submit the current round and repair the round until it passes before continuing or stopping.\n- After the round submission passes, read the JSON `guideline` field for the exit signal and follow its stop-or-continue instruction for the current session.\n- Before opening the next round, use the sibling `ascend-npu-optimize-state` skill's `start-round` subcommand to re-check the one-round-at-a-time and no-blind-sweep workflow constraints.\n\n## Round Records\n\n- `attempts.md`: chronological round log for the current round, including the script-written `State Update` history, `Primary analysis level`, `Supporting evidence`, the starting hypothesis, selected pattern candidates and pivots when pattern triage is used, escalation reasons, meaningful code changes, correctness failures, probe-screening outcomes when `probe-bench` is used, and canonical benchmark outcomes.\n- `summary.md`: round conclusion, optimization points that mattered, the final selected pattern direction when one guided the round, the final analysis level, supporting evidence that decided the round, and unresolved questions if deeper analysis may still be needed. Do not duplicate the full round strategy state history here.\n- `opt-note.md`: top-level round ledger plus final `## Overall Summary`.\n\n## Learned Lessons\n\nMaintain `learned_lessons.md` in the operator workspace as a strict reusable optimization-knowledge distillation log.\n\nAdmission criteria:\n\nAppend a lesson only when it passes all admission criteria:\n\n- The lesson generalizes to a family of Triton Ascend NPU operators, not only the current operator.\n- The lesson is supported by correctness, benchmark, profiler, IR, or compiler-error evidence.\n- The lesson is written as a reusable rule, diagnostic mapping, or optimization heuristic.\n- The lesson states where it applies or what limits it.\n- The lesson could plausibly be promoted into an optimize skill, profiling analysis reference, IR analysis reference, or pattern reference.\n\nUse `learned_lessons.md` for concise distilled rules such as:\n\n- profile-to-optimization mappings\n- IR-to-code-change mappings\n- compiler error repairs that reveal recurring Triton or Ascend NPU constraints\n- new optimization points inferred from recurring Triton code patterns\n- validated benchmark interpretation rules that would help future rounds start faster\n\nDo not use `learned_lessons.md` for round narrative, local command failures, failed guesses, temporary troubleshooting notes, file names, shape-specific details, or summaries of what happened in one round.\n\nPut round-local narrative, temporary troubleshooting notes, command failures, and shape-specific details in `opt-round-N\u002Fattempts.md`, `opt-round-N\u002Fsummary.md`, or `opt-note.md` instead.\n\n## Hard Rules\n\n- Optimize the operator file itself, not the generated tests or benchmark harness.\n- Optimize the Triton kernel path, not just the public wrapper surface.\n- Do not replace the core computation with pure PyTorch just to improve benchmark numbers.\n- Do not claim success for a round without both correctness evidence and benchmark evidence.\n- Do not begin with blind tiling, autotune, or launch-parameter search when the available evidence does not justify that direction.\n- When launch or tile\u002Fblock configuration tuning is justified, prefer `autotune` over burning multiple optimization rounds on hand-tuned parameter sweeps.\n- Do not finish a round by restoring the parent snapshot alone; if edits are discarded, restart from the last validated parent as a new attempt or round instead of claiming rollback as the delivered optimization.\n- Do not spend optimization rounds tuning `num_warps` for Ascend NPU targets; it is CUDA-oriented and is not a meaningful Ascend launch knob.\n- When an operator file defines multiple Triton kernels on a relevant hot path, fuse them into a single kernel first, then optimize that fused kernel rather than tuning separate kernels in isolation.\n- Do not write forward-looking optimization plans or predict what to try next. After each round, the next optimization direction must be driven by fresh profiling or benchmark evidence from the changed code. Write no more than one round at a time.\n","# Optimize\n\n## Goal\n\nOptimize one Triton Ascend NPU operator through validated rounds anchored to a canonical `baseline\u002F`.\n\nUse this skill when the user wants the operator itself improved rather than only generating or running tests and benchmarks.\n\nOptimize target modes:\n\n- `kernel`: optimize the Triton Ascend NPU kernel path itself. Compare rounds with a kernel-oriented `compare-perf` view, but if the comparison falls back to total-op for some cases, record the resolved `effective_metric_source` and surface that mismatch as a warning instead of discarding the round outright.\n- `operator`: optimize end-to-end operator latency. Wrapper logic, data movement, scheduling, pre-processing, post-processing, and kernel code are all valid optimization surfaces as long as the Triton Ascend NPU computation path remains real. Show both kernel and total-op `compare-perf` views, but use the total-op view as the canonical round conclusion.\n\n## Inputs\n\n- Operator source code or an operator file path\n\n## Outputs\n\n- `baseline\u002F`\n- `opt-round-N\u002F`\n- completed round entries and one final `## Overall Summary` in `opt-note.md`\n- round-local `profile\u002F`, `ir\u002F`, `perf-analysis.md`, or `compiler-analysis.md` artifacts when deeper investigation is needed\n\n## Core Loop\n\n- establish or reuse `baseline\u002F`\n- open `opt-round-N\u002F`, initialize round strategy state through `ascend-npu-optimize-state start-round`, and start `attempts.md`\n- choose the current analysis level\n- treat each round as one code-changing optimization attempt followed by canonical validation\n- make one coherent optimization attempt\n- optionally screen the direction cheaply with `probe-bench` when the available run-eval surface exposes it\n- validate correctness and benchmark performance\n- After the first canonical `run-bench` plus `compare-perf` conclusion for that attempt, stop editing the current round.\n- record the round outcome\n\n## Stage 0: Baseline Setup\n\n- Reuse the existing `baseline\u002F` only when it remains canonical for the current operator workspace.\n- Otherwise use the sibling `ascend-npu-prepare-optimize-baseline` skill to establish or repair the baseline before creating `opt-round-1\u002F`.\n- Establish or reuse `baseline\u002F` before treating any `opt-round-N\u002F` directory as a completed optimization round.\n- Read [artifacts.md](references\u002Fartifacts.md) before choosing authoritative baseline or round artifact paths.\n- Read [opt-note-format.md](references\u002Fopt-note-format.md) before initializing `opt-note.md`.\n- Keep top-level optimize workflow references at the skill boundary: use sibling skills for baseline preparation, evaluation, profiling, IR analysis, compiler-source analysis, and round gating rather than direct helper-script paths here.\n\n## Stage 1: Round Entry\n\n- Create `opt-round-N\u002F` from a validated parent candidate and keep parent-child traceability explicit.\n- Use the sibling `ascend-npu-optimize-state` skill's `start-round` subcommand to initialize the active round's `round_strategy`, `analysis_policy`, and `reason` before the first code change in that round.\n- Start `attempts.md` immediately so every meaningful attempt and measurement is recorded.\n- Treat the structured `State Update` blocks in `attempts.md` as script-written workflow history; do not manually duplicate the same `round_strategy`, `analysis_policy`, and `reason` bookkeeping in both `attempts.md` and `summary.md`.\n- For round 1, record the initial round hypothesis in `opt-round-1\u002Fattempts.md` before the first code change.\n- When pattern triage is used, explicitly record the candidate patterns you considered, the selected pattern if one is chosen, and why that pattern looks plausible in `attempts.md`.\n- When a named pattern guides the round, explicitly record the final selected pattern direction in `summary.md`.\n- Record the current analysis level as `Primary analysis level`, and record `Supporting evidence` separately.\n- Record why that level may help and what evidence supports starting there.\n- If the round starts from reused deeper evidence, cite the reused evidence path and explain why the shallower level is already established or insufficient.\n- Treat `opt-note.md` as the top-level round ledger plus final `## Overall Summary`.\n- If the active round's intent or required evidence depth changes mid-round, use the sibling `ascend-npu-optimize-state` skill's `set-current-round-state` subcommand instead of silently changing the round contract in prose only.\n\n## Stage 2: Layered Analysis\n\nOptimize analysis is layered.\n\n- Default escalation order: `pattern triage -> profiling diagnosis -> IR attribution -> compiler-source escalation`.\n- Start each round at the shallowest level that can justify the next move.\n- Escalate only when the current level is insufficient.\n- Keep `Primary analysis level` distinct from `Supporting evidence` in round records.\n- Using IR as supporting evidence does not automatically change the round's primary analysis level.\n- Record the chosen level and why the round stayed there or escalated deeper.\n- Show the level explicitly in `attempts.md`, for example `Primary analysis level: profiling diagnosis`.\n- When a round escalates, record both `Escalation: \u003Cfrom> -> \u003Cto>` and `Escalation reason: \u003Cwhy the previous level was insufficient>`.\n- Do not rely on the presence of `profile\u002F`, `ir\u002F`, or `perf-analysis.md` to imply the current level; state it directly.\n\n### pattern triage\n\n- Inspect current code structure and benchmark behavior before choosing a direction.\n- Use the staged `triton-npu-optimize-knowledge` skill as the generic optimize knowledge library.\n- When the optimize target is `operator`, also use the staged `torch-npu-optimize-knowledge` skill for Torch NPU and whole-operator pattern routing such as framework-op fallback, wrapper-level changes, or broader operator restructuring.\n- Read the staged `triton-npu-optimize-knowledge` skill's `references\u002Fpattern_index.md` before detailed pattern references.\n- Read only the one or two most relevant detailed pattern files under the staged `triton-npu-optimize-knowledge` skill's `references\u002Fpatterns\u002F` directory after the generated index has narrowed the candidate set.\n- When the optimize target is `operator` and the bottleneck looks Torch NPU or framework-op specific, read the staged `torch-npu-optimize-knowledge` skill's `references\u002Fpattern_index.md` before detailed Torch NPU pattern references.\n- When code structure is still unclear at pattern triage, inspect the operator file directly and narrow candidates with the generated pattern index.\n- Do not leave the chosen pattern implicit in free-form prose; write it down explicitly in `attempts.md`, and carry the final named pattern direction into `summary.md` when it guided the round.\n- Very strongly consider using subagents to read pattern references, scan for potentially useful optimization ideas, and report back which patterns look promising for the current kernel.\n- When subagents are available, prefer using them to broaden pattern exploration before committing to the round hypothesis.\n- Pattern references are helpful guidance, not the only allowed source of ideas.\n- If your own Triton, Ascend NPU, or kernel-optimization knowledge suggests a stronger direction than the current pattern library, you may use that direction directly as long as you still record the hypothesis clearly and validate it with the same correctness and benchmark gates.\n- You do not need an existing pattern file to justify every optimization round.\n- When the kernel is structurally matmul-like, read the staged `triton-npu-optimize-knowledge` skill's `references\u002Fpatterns\u002Fclassic-matmul.md` before rewriting the hot loop so the round records the standard tiled-matmul shape, dtype, and masking rules explicitly.\n- Do not treat pattern triage as permission for aimless pattern search without tying the candidate patterns back to the kernel structure or observed evidence.\n\n### profiling diagnosis\n\n- Use profiling diagnosis as the default deeper entrypoint when pattern triage is not enough.\n- Use the sibling `ascend-npu-profile-operator` skill when benchmark numbers need operator-level performance evidence, hotspot diagnosis, bottleneck analysis, or profiler-backed comparison across runs.\n- Use the sibling `ascend-npu-analyze-round-performance` skill when one round needs a deeper diagnosis that should end in `opt-round-N\u002Fperf-analysis.md`, especially for scalar\u002Fvector\u002Fcube imbalance, transfer-heavy behavior, or suspected pipeline overlap issues.\n- Use the sibling knowledge skill's symptom cards to narrow pattern candidates after structured profiler or IR evidence exists, rather than rereading the whole pattern library.\n- This deeper diagnosis may end as either `profile-only diagnosis` or `profile-plus-IR diagnosis`.\n- Write `opt-round-N\u002Fperf-analysis.md` when the deeper round-analysis flow is used.\n\n### IR attribution\n\n- Use IR attribution only after profiler-backed symptoms still need explanation.\n- `ascend-npu-analyze-round-performance` may still own `opt-round-N\u002Fperf-analysis.md` when the round deepens from profiler evidence into IR-backed attribution.\n- In that flow, use `triton-npu-analyze-ir` as the IR evidence companion for capture, navigation, and stage-level inspection.\n- Use the sibling `triton-npu-analyze-ir` skill when compiler lowering details, stage-to-stage IR changes, or round-local IR evidence are needed to explain benchmark behavior.\n- Keep IR evidence under `opt-round-N\u002Fir\u002F`.\n- In optimize rounds, keep IR capture round-local. Use the `triton-npu-analyze-ir` skill's helpers with argument shapes such as:\n  ```text\n  capture_ir.py --ir-dir opt-round-N\u002Fir --bench-file bench_\u003Coperator>.py --operator-file opt-round-N\u002F\u003Coptimized-operator>.py\n  inspect_ir.py list-stages --ir-dir opt-round-N\u002Fir --sort-by interesting --limit 20\n  ```\n\n### compiler-source escalation\n\n- Use compiler-source escalation only when compiler source analysis is enabled and after profiler and IR evidence have narrowed a concrete compiler-side question.\n- Use the sibling `triton-npu-analyze-compiler-source` skill only when the round still needs performance-focused explanation before the next operator change is clear.\n- When compiler source analysis is enabled, treat the compiler source checkout as read-only and use compiler-source evidence only when it is genuinely needed.\n- Write `opt-round-N\u002Fcompiler-analysis.md`.\n\n## Kernel Semantic Repairs\n\n- During kernel optimization work, inspect kernel compare-helper call sites such as `tl.maximum()` and `tl.minimum()` across the operator, not only the lines touched by the primary optimization.\n- If a kernel compare-helper call omits `propagate_nan`, you may add `propagate_nan=tl.PropagateNan.ALL` as a consistency repair when the intended semantics are explicit NaN propagation.\n- Treat this as a semantic choice because it can change NaN-input behavior. Do not present it as a no-op cleanup.\n\n## Stage 3: Validate And Record\n\n- Run correctness validation before trusting any performance result.\n- After correctness passes, you may use the sibling `ascend-npu-run-eval` skill's `probe-bench` flow as a fast baseline-vs-candidate screen when you need a cheap directional signal before paying canonical benchmark cost.\n- Use `probe-bench` only when the active run-eval surface actually exposes it. If the current surface does not expose `probe-bench`, skip the screen and continue with canonical validation.\n- Treat `probe-bench` as non-canonical screening evidence only. Do not use its output as the official round perf artifact, do not write probe artifacts into `round-state.json`, and do not claim round speedups from probe output alone.\n- Use `probe-bench` to reject clearly bad candidates early or to justify keeping a clearly promising direction long enough to run canonical benchmarking.\n- After correctness passes, run benchmark validation and preserve the round-local benchmark evidence.\n- In each round directory, keep the optimized operator snapshot as `opt_\u003Coriginal-operator>.py`.\n- In each round directory, keep the benchmark artifact as `opt_\u003Coriginal-operator>_perf.txt`, ensure that file is generated by the `ascend-npu-run-eval` skill's `run-bench` flow, and record that exact filename in `round-state.json`.\n- Use `baseline\u002F\u003Coperator>_perf.txt` for canonical optimize-session performance comparisons, even when the current round also compares locally against its parent.\n- Once baseline and round perf artifacts both exist, use the `ascend-npu-run-eval` skill to run `compare-perf`.\n- Even after `probe-bench` reports `likely_gain` or `likely_regression`, still run canonical `run-bench` and `compare-perf` before recording any official round conclusion.\n- Treat the `ascend-npu-run-eval` skill's `compare-perf` flow as the only authority for claimed benchmark deltas and speedups, including `Avg improvement`, `Geomean speedup`, and any claimed benchmark delta.\n- Record exactly one resolved comparison basis in `round-state.json` as `effective_metric_source`, using `kernel`, `total-op`, or `mixed`.\n- In `kernel` target mode, prefer the kernel-oriented comparison result, but if `compare-perf` falls back to total-op for some or all cases, keep the round eligible and record that fallback as a warning.\n- In `operator` target mode, show both kernel and total-op comparison results so you can diagnose whether kernel improvements translated end-to-end, then record `effective_metric_source: total-op` for the official round conclusion.\n- If the result is slower, inconclusive, or not worth promoting, close the round and carry the next optimization idea into a new round instead of revising the current round again.\n- If correctness repair is no longer worthwhile, canonical benchmark execution keeps failing, or the time cost is no longer justified, close the round as a rejected terminal round instead of exiting silently. Preserve the minimum round artifacts, write `correctness_status` and `benchmark_status` honestly, and still use `submit-round` so the workflow records the round outcome.\n- When `benchmark_status` is `passed`, `round-state.json` must include the benchmark artifact metadata fields. When `benchmark_status` is `failed` or `not_run`, those benchmark metadata fields may be omitted if no canonical perf artifact was produced.\n- Do not hand-calculate speedups or percentage improvements from raw perf files.\n- Use the sibling `ascend-npu-optimize-state` skill's `submit-round` subcommand to submit the current round and repair the round until it passes before continuing or stopping.\n- After the round submission passes, read the JSON `guideline` field for the exit signal and follow its stop-or-continue instruction for the current session.\n- Before opening the next round, use the sibling `ascend-npu-optimize-state` skill's `start-round` subcommand to re-check the one-round-at-a-time and no-blind-sweep workflow constraints.\n\n## Round Records\n\n- `attempts.md`: chronological round log for the current round, including the script-written `State Update` history, `Primary analysis level`, `Supporting evidence`, the starting hypothesis, selected pattern candidates and pivots when pattern triage is used, escalation reasons, meaningful code changes, correctness failures, probe-screening outcomes when `probe-bench` is used, and canonical benchmark outcomes.\n- `summary.md`: round conclusion, optimization points that mattered, the final selected pattern direction when one guided the round, the final analysis level, supporting evidence that decided the round, and unresolved questions if deeper analysis may still be needed. Do not duplicate the full round strategy state history here.\n- `opt-note.md`: top-level round ledger plus final `## Overall Summary`.\n\n## Learned Lessons\n\nMaintain `learned_lessons.md` in the operator workspace as a strict reusable optimization-knowledge distillation log.\n\nAdmission criteria:\n\nAppend a lesson only when it passes all admission criteria:\n\n- The lesson generalizes to a family of Triton Ascend NPU operators, not only the current operator.\n- The lesson is supported by correctness, benchmark, profiler, IR, or compiler-error evidence.\n- The lesson is written as a reusable rule, diagnostic mapping, or optimization heuristic.\n- The lesson states where it applies or what limits it.\n- The lesson could plausibly be promoted into an optimize skill, profiling analysis reference, IR analysis reference, or pattern reference.\n\nUse `learned_lessons.md` for concise distilled rules such as:\n\n- profile-to-optimization mappings\n- IR-to-code-change mappings\n- compiler error repairs that reveal recurring Triton or Ascend NPU constraints\n- new optimization points inferred from recurring Triton code patterns\n- validated benchmark interpretation rules that would help future rounds start faster\n\nDo not use `learned_lessons.md` for round narrative, local command failures, failed guesses, temporary troubleshooting notes, file names, shape-specific details, or summaries of what happened in one round.\n\nPut round-local narrative, temporary troubleshooting notes, command failures, and shape-specific details in `opt-round-N\u002Fattempts.md`, `opt-round-N\u002Fsummary.md`, or `opt-note.md` instead.\n\n## Hard Rules\n\n- Optimize the operator file itself, not the generated tests or benchmark harness.\n- Optimize the Triton kernel path, not just the public wrapper surface.\n- Do not replace the core computation with pure PyTorch just to improve benchmark numbers.\n- Do not claim success for a round without both correctness evidence and benchmark evidence.\n- Do not begin with blind tiling, autotune, or launch-parameter search when the available evidence does not justify that direction.\n- When launch or tile\u002Fblock configuration tuning is justified, prefer `autotune` over burning multiple optimization rounds on hand-tuned parameter sweeps.\n- Do not finish a round by restoring the parent snapshot alone; if edits are discarded, restart from the last validated parent as a new attempt or round instead of claiming rollback as the delivered optimization.\n- Do not spend optimization rounds tuning `num_warps` for Ascend NPU targets; it is CUDA-oriented and is not a meaningful Ascend launch knob.\n- When an operator file defines multiple Triton kernels on a relevant hot path, fuse them into a single kernel first, then optimize that fused kernel rather than tuning separate kernels in isolation.\n- Do not write forward-looking optimization plans or predict what to try next. After each round, the next optimization direction must be driven by fresh profiling or benchmark evidence from the changed code. Write no more than one round at a time.\n",{"name":5,"description":7},"main","5d6a3de8bf1eb43267adffc8e27a87d85fd81a4b","skills\u002Ftriton\u002Ftriton-npu-optimize","https:\u002F\u002Fgithub.com\u002FPiagari\u002Fhelix","https:\u002F\u002Fgithub.com\u002FPiagari","2026-07-16 20:07:51",{"source":8,"skillName":5,"commands":30,"prompt":40,"zipAvailable":41},[31,34,37],{"tool":32,"command":33},"npx","npx skills add Piagari\u002Fhelix --skill triton-npu-optimize",{"tool":35,"command":36},"bunx","bunx skills add Piagari\u002Fhelix --skill triton-npu-optimize",{"tool":38,"command":39},"pnpm","pnpm dlx skills add Piagari\u002Fhelix --skill triton-npu-optimize","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FPiagari\u002Fhelix\u002Fblob\u002Fmain\u002Fskills\u002Ftriton\u002Ftriton-npu-optimize\u002FSKILL.md",true,[43,49,53],{"path":44,"resourceType":45,"resourceTypeDesc":46,"sizeBytes":47,"sourceHtmlUrl":48},"references\u002Fartifacts.md","REFERENCE","参考文档",13413,"https:\u002F\u002Fgithub.com\u002FPiagari\u002Fhelix\u002Fblob\u002Fmain\u002Fskills\u002Ftriton\u002Ftriton-npu-optimize\u002Freferences\u002Fartifacts.md",{"path":50,"resourceType":45,"resourceTypeDesc":46,"sizeBytes":51,"sourceHtmlUrl":52},"references\u002Fopt-note-format.md",3683,"https:\u002F\u002Fgithub.com\u002FPiagari\u002Fhelix\u002Fblob\u002Fmain\u002Fskills\u002Ftriton\u002Ftriton-npu-optimize\u002Freferences\u002Fopt-note-format.md",{"path":54,"resourceType":45,"resourceTypeDesc":46,"sizeBytes":55,"sourceHtmlUrl":56},"references\u002Fround-failure-handling.md",2676,"https:\u002F\u002Fgithub.com\u002FPiagari\u002Fhelix\u002Fblob\u002Fmain\u002Fskills\u002Ftriton\u002Ftriton-npu-optimize\u002Freferences\u002Fround-failure-handling.md",[58,65,72,79,84,91],{"skillNo":59,"name":60,"nameZh":6,"description":61,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":62,"categories":63,"keywords":64,"publishedAt":18},"01M7985HE7EHEXX41M79MSZCMJ","triton-npu-repair-guide","Heuristic fixes for Ascend Triton compile\u002FJIT\u002Fkernel errors and numerical precision mismatches when editing or converting the operator. Does not replace ascend-npu-gen-test, ascend-npu-gen-bench, or harness specs.","https:\u002F\u002Fgithub.com\u002FPiagari\u002Fhelix\u002Fblob\u002Fmain\u002Fskills\u002Ftriton\u002Ftriton-npu-repair-guide\u002FSKILL.md",[],[],{"skillNo":66,"name":67,"nameZh":6,"description":68,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":69,"categories":70,"keywords":71,"publishedAt":18},"01M79858YFWE96X7ZA1BJRVDEX","triton-npu-optimize-knowledge","Generic reference-only optimize knowledge for pattern triage and evidence-backed symptom routing. This skill does not define optimize workflow or own round artifacts.","https:\u002F\u002Fgithub.com\u002FPiagari\u002Fhelix\u002Fblob\u002Fmain\u002Fskills\u002Ftriton\u002Ftriton-npu-optimize-knowledge\u002FSKILL.md",[],[],{"skillNo":73,"name":74,"nameZh":6,"description":75,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":76,"categories":77,"keywords":78,"publishedAt":18},"01M79854BZPJ0XY5PTPQWTCY7Q","triton-npu-optimize-knowledge-v3","Generic reference-only optimize knowledge (v3 working copy) for pattern triage and evidence-backed symptom routing. This skill does not define optimize workflow or own round artifacts; prefer this tree for ongoing knowledge updates.","https:\u002F\u002Fgithub.com\u002FPiagari\u002Fhelix\u002Fblob\u002Fmain\u002Fskills\u002Ftriton\u002Ftriton-npu-optimize-knowledge-v3\u002FSKILL.md",[],[],{"skillNo":80,"name":67,"nameZh":6,"description":68,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":81,"categories":82,"keywords":83,"publishedAt":18},"01M79850QM6QZP8VP6ZRQBQHCT","https:\u002F\u002Fgithub.com\u002FPiagari\u002Fhelix\u002Fblob\u002Fmain\u002Fskills\u002Ftriton\u002Ftriton-npu-optimize-knowledge-v2\u002FSKILL.md",[],[],{"skillNo":85,"name":86,"nameZh":6,"description":87,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":88,"categories":89,"keywords":90,"publishedAt":18},"01M7984W6SW3BZM5EXGRJ1VBXY","triton-npu-convert-pytorch-operator","Convert one PyTorch operator into a Triton NPU-backed PyTorch operator, preserve the trailing input-helper block, and validate the converted output through standalone or differential testing.","https:\u002F\u002Fgithub.com\u002FPiagari\u002Fhelix\u002Fblob\u002Fmain\u002Fskills\u002Ftriton\u002Ftriton-npu-convert-pytorch-operator\u002FSKILL.md",[],[],{"skillNo":92,"name":93,"nameZh":6,"description":94,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":95,"categories":96,"keywords":97,"publishedAt":18},"01M7984PRE5N1CWZBCXVC6G1K9","triton-npu-cann-ext-api-patterns","A5-only specialized optimization pattern references for Triton Ascend NPU kernels that use CANN Triton extension APIs. This skill does not define the optimize workflow; it only provides pattern material for optimize to consume.","https:\u002F\u002Fgithub.com\u002FPiagari\u002Fhelix\u002Fblob\u002Fmain\u002Fskills\u002Ftriton\u002Ftriton-npu-cann-ext-api-patterns\u002FSKILL.md",[],[]]