ソフトウェア開発タスクを進めるときの基本フロー。立ち上げ、ブランチ運用、実装、検証、PR作成、記録までを一気通貫で扱う。「実装して」「修正して」「PR作って」「コードを書く」「dev-workflow」で使用。
「dev-workflow」の検索結果
29 件 ・ 関連度順
概要と使いどころ
三方框架特性落地(原 framework-feature-enablement + framework-extension-dev 合并): 一个入口信号「框架侧特性没落地」,内部分两分支——**分支 A 框架已有 → 使能与验证** (计数契约 + 三层证据 + 使能异常回修);**分支 B 框架缺失 → 补齐开发** (注入点 + 代码组织/注册机制 + 合入姿势:平台注册优先 / 上游 PR / fork 钉版 / monkey 备选)。 分支 A 触发词:量化/稀疏/缓存开关没生效、融合算子没命中、使能异常或精度不符、 "起 vllm 服务""模型在框架里跑不通""把 mindiesd 接到其他框架"。 分支 B 触发词:框架没 comm-stream 掩盖、框架没缓存消费者、框架不支持某 collective/mask、 feature_* NotImplemented、要给框架补一条结构性能力。 near-miss:纯安装/权重 → env-install;纯采集/分析 → profiling-collect / profiling-analyze; 纯选档(该不该开量化、开哪一档)→ dit-perf-opt; mindiesd 仓内 pattern / 算子 / 图下发开发 → dev-workflow + pattern-dev / operator-dev / aclgraph-dev。 由 model-auto-optimization 的 S1(融合接入)/S4(有损使能)/S5(训练感知)与 §0 缺口补齐策略路由, 亦由 dev-workflow 的框架接入/验证场景指引加载。
日本語の概要は準備中です。原文の説明を表示しています。
変更をコミットしてドラフトPRを作成する一連のGit/ghワークフロー。ユーザーが「コミットして」「PR作って」「draft PR」等を求めたときに使用し、status/diff確認・命令形コミット・push・gh pr create --draft(--assignee hodanov)まで実行する。ユーザーの明示リクエストが無くても、実装完了後にcommitやPRが必要になった場面(dev-workflowのcommitフェーズ等)では必ずこれを使う。`git commit` や `gh pr create` を単体でBash直接実行しない。
Contributor workflow for native cmux setup, tagged dev builds, Xcode project normalization and sidebar extensions. Use for native build inputs, setup or tagged app verification.
日本語の概要は準備中です。原文の説明を表示しています。
The complete development workflow for SkillHub contributors including local dev, staging validation, testing, and PR creation. Ensures agents follow the correct sequence of steps.
日本語の概要は準備中です。原文の説明を表示しています。
Use when setting up or optimizing developer workflows in a monorepo, managing mise tasks, git hooks, CI/CD pipelines, database migrations, or release automation. Invoke for development environment setup, build automation, testing workflows, and release coordination.
日本語の概要は準備中です。原文の説明を表示しています。
Configure development tasks, git hooks, CI/CD, or release automation. Use when creating or fixing a repository development workflow.
日本語の概要は準備中です。原文の説明を表示しています。
Guide plugin development workflow — editing skills, agents, hooks, or eval framework in this repo. Use when modifying files in plugins/elixir-phoenix/, lab/eval/, or lab/autoresearch/. Ensures changes pass eval, lint, and tests before committing.
日本語の概要は準備中です。原文の説明を表示しています。
Writes implementation plans before coding: phases, plan files, specs, definition of done. Use when planning a multi-step feature or breaking a large refactor into phases.
日本語の概要は準備中です。原文の説明を表示しています。
简化模型代码的快速验证载体:用随机权重/精简代码在 NPU 上快速验证模型架构 兼容性、算子先接入与融合可行性(产物:架构兼容性 + 基线/快验输出),无需真实权重。 已部署模型的框架侧验证见 framework-integration,环境安装见 env-install。 当用户需要确认模型能否跑通、评估参数量与显存占用、或在算子接入/融合优化前 做快速验证时使用此 skill;即使用户只提到"帮我试试这个模型能不能跑"而未说 dummy run,也应触发。由 model-auto-optimization 的 S0/S1(融合/编译快验)阶段调用, 亦由 dev-workflow 的模型验证阶段指引加载。
日本語の概要は準備中です。原文の説明を表示しています。
分布式并行策略选型与实测(USP / CP 通信掩盖 / CFG / TP/RSP/PP 概览;含拓扑相关选型 (按实测拓扑分域条件化:域内 bulk vs 跨域 head-parallel 翻转)与 AlltoAllV 缺陷绕过)。在 model-auto-optimization 中承担 S3:优先 USP、结合拓扑带宽差异选 CP,少量 step + 多 rank 验证特性开启与掩盖(产物:并行方案 + 多 rank 证据)。当用户需要多卡并行 策略选择、**序列并行形态抉择**(纯 Ulysses vs 复合 AllGather-KV×Ulysses:按 GQA / 跨域带宽 / 形态 plumbing 条件化定胜负)、**并行 × 稀疏叠加**(seam 契约:先汇聚后稀疏、 窗口偏移、块对齐、per-head 掩码;含「稀疏看似生效实则未生效」判定)、通信掩盖调优 (含**掩盖率上限**:1-1/n 何时成立、c/f 决定的真实上限、没生效的排查)、**并行方案 差异归因**(阶段 Δ 分解 / 集合通信按 communicator 归属 / 4→8 卡线性度),或排查多卡 跑不动 / 通信暴露大 / 换卡组 / 端口 bind / HCCL 带宽验证问题时使用;**并收编原并行作用域诊断**: 改了 SP/CP/Ulysses/AllGather-KV 后**不报错但结果没变/性能没变**、或小规模能跑大规模崩 (如 Ascend EE1003 coreDim 超限)时,用本技能证明"改动到底有没有生效"(判别量逐层收窄 + 两侧对照 + 日志≠生效,见 `references/scope-effectiveness-check.md`); 即使用户只说 "多卡跑不动""通信暴露大""为什么没达到 6/7 的掩盖率""CP 和 USP 该选哪个""CP 叠稀疏 怎么不生效"而未说并行,也应触发。特性档位/接口事实见 `docs/zh/features/parallelism.md` /`usp.md`(仓内真源),框架侧开启见 framework-integration; 本技能承载选型决策、monkey-patch 掩盖与多卡诊断实测。 由 dev-workflow 多卡场景触发,亦由 model-auto-optimization 的 S3 阶段触发。
日本語の概要は準備中です。原文の説明を表示しています。
MindIE-SD 仓库开发总入口(侧轨)。当用户进行 MindIE-SD 的任何代码开发工作时使用此 skill—— 包括但不限于写 pattern、改测试、部署到昇腾、跑 benchmark、性能分析、多卡并行、复盘归档。 模型/三方框架自动优化类任务(非本仓代码改动)由 model-auto-optimization 入口承接, 本入口只在优化流程需要新增 pattern/算子/部署代码时承接其指向的开发子任务。 即使用户未明确提到"开发流程",只要涉及 MindIE-SD 代码改动都应触发。
日本語の概要は準備中です。原文の説明を表示しています。
MindIE-SD Python 代码格式与 lint 规则。当编写、格式化、lint 检查或审查 MindIE-SD 项目的 Python 代码时使用此 skill。 即使用户只提到"提个MR"或"代码好像有 lint 问题"而未明确说格式化,也应触发;Markdown 格式问题见 markdown-lint,提交/PR 规范见 mindie-sd-community-governance。 通常由 dev-workflow 在编码阶段指引加载。
日本語の概要は準備中です。原文の説明を表示しています。
MindIE-SD 核心算子(FA/BSA/GMM/MM)性能基准工具链。使用:模型优化(model-auto-optimization 的 S1/S4 选型)中用 mindie_bench 对单算子做实现级实测,按 dtype/量化档/稀疏度/形态对比 选出最优配置(产物:选型证据;稀疏度-性能曲线供 S4 稀疏度选型);开发:benchmarks/ 工具链扩展与新算子接入测试(供 operator-dev / pattern-dev 调用)。 当用户需要对比算子实现选型、新增或修改 benchmark 代码、排查 benchmark 数据异常、 给基准加算子/指标时使用;即使用户只说"benchmark 数据不对""给基准加个算子" "对比下这几个 FA 实现哪个快"也应触发;特性级方案选档请走 dit-perf-opt (本 skill 只做实现级实测)。 由 model-auto-optimization 的 S1/S4 选型场景与 operator-dev 的算子接入验证场景调用, 亦由 dev-workflow 在基准开发时指引加载。
日本語の概要は準備中です。原文の説明を表示しています。
NPU 图批量下发能力(aclgraph / aclgraph_ex 家族)的开发与调优。覆盖 mindiesd 的 aclgraph_backend:NPUGraph 静态 capture、全局 graph pool、 lazy capture、专用 copy stream + event 管线、shape/dtype 校验、max_entries 驱逐。 当用户需要减少 host launch 开销、静态 shape 大 batch 场景加速、 或排查 NPUGraph replay 输入不匹配问题时使用此 skill。 即使用户只提"批量下发""graph capture""图捕获"而未说 aclgraph,也应触发; pattern/Inductor 融合(default 后端)见 pattern-dev,算子本体见 operator-dev, 本技能只覆盖图批量下发。由 dev-workflow 的编译开发阶段与 model-auto-optimization 的 图下发场景指引加载。
日本語の概要は準備中です。原文の説明を表示しています。
MindIE-SD 仓库 Markdown 格式 lint 规则。当编写、修改或审查 Markdown 文件(README、文档、 变更日志等)、或 CI 门禁报出 markdownlint 违规时使用此 skill。 即使用户只提到"格式问题"或"MD040报错"而未说 markdownlint,也应触发;Python 格式问题见 code-standards。 通常由 dev-workflow 和 code-standards 在编码/审查阶段指引加载。
日本語の概要は準備中です。原文の説明を表示しています。
远程昇腾访问工具:为部署与验证提供访问远端昇腾服务器的通用执行通道, 覆盖 SSH 连接复用、容器内命令执行、空闲卡选择与文件传输。 当需要在远端昇腾设备执行命令、查询 NPU 状态、 选择空闲卡或向远端传输文件时使用本技能; 即使用户只提到「在服务器上跑个命令」而未说明 SSH,只要目标是远端昇腾环境也应触发; 只提供远程执行通道,不负责安装/编译(env-install)与框架验证(framework-integration)。 由 env-install 的部署流程与 dev-workflow 的部署阶段调用,亦可独立使用。
日本語の概要は準備中です。原文の説明を表示しています。
profiling 数据统一采集:远端昇腾采集 NPU 性能数据回传本地,供 profiling-analyze 分析。 两条入口——mindiesd 自家脚本入口(collect_profile.py)与三方框架入口 (collect_patch_template.py 补丁 + torchrun,含 vLLM-Omni HTTP 服务等分场景); warmup 在 profiler 外(默认 5 步,compile ≥10)。 只要用户想"开 profiler/采 profile/拿算子级数据",自家脚本或 vllm、LightX2V 等框架都先 用本入口;分析/瓶颈定位/优化选型/并行/基准请求分别属 profiling-analyze、 dit-perf-opt、dit-parallel-opt、benchmark-dev,本入口不承接。 由 model-auto-optimization 的 S1(融合分析)阶段调用,亦由 profiling-analyze 与 dev-workflow 的 采集场景指引加载。
日本語の概要は準備中です。原文の説明を表示しています。
对 profiling 数据(kernel_details.csv / trace_view.json / step_trace_time.csv)做统一分析: 5 层递进管道(analyze_trace.py)+ baseline/优化后 kernel diff(compare_traces.py),输出 瓶颈诊断、算子执行序、可融合候选与 P0-P2 方向建议。输入统一来自 profiling-collect。 只要用户有 profiling 产出并问"为什么慢/瓶颈在哪/优化前后差多少/往哪个方向",都用本技能;采集走 profiling-collect,方案选档走 dit-perf-opt,实现/并行/基准走 pattern-dev/dit-parallel-opt/benchmark-dev——本技能只做诊断与方向。 由 model-auto-optimization 的 S1(融合分析)/S3(并行)阶段调用,亦由 dev-workflow 的分析阶段指引加载。 融合机会候选只做**识别**;候选的**边界与收益判定**(能不能融成一个单元、融多大、值不值)交 `fusion-scope-analyze`(本技能的辅助技能)——本技能不判融合边界。
日本語の概要は準備中です。原文の説明を表示しています。
优化域入口(L2):拿到**已明确的瓶颈点 / 瓶颈标签**后,按标签把任务**分发**到四个优化模块 (DiT 计算 `dit-perf-opt` / DiT 通信 `dit-parallel-opt` / VAE `vae-opt` / host `host-opt`),并给出域内**最小前置集**与**域级验收口径**(性能入库口径引 `perf-gate`、精度判据引 `accuracy-gate`)。 **本技能不再承载选档与实施内容**(Step 2–4 闭环、特性档位选择、组合试验已全部归 `dit-perf-opt`)。 入口信号(任一即可触发):① 用户或编排层已给出**瓶颈点/瓶颈标签**("瓶颈已经明确,按这个点优化"); ② **框架侧特性没落地**(该开的开关/特性没开,需要先判走哪个模块)。 near-miss(看似相关但不属本技能): - **瓶颈未明**("这个模型怎么加速""怎么跑通""采个 profile",还要先定位)→ 先走 `model-auto-optimization`(唯一有分析权的一方),本入口**不接受未定位的任务**。 - 问"要不要开量化、开哪一档""量化/稀疏/Cache 怎么选怎么开" → `dit-perf-opt`(选档与实施在模块层)。 - 多卡并行形态 / 通信掩盖 / TP·offload → `dit-parallel-opt`;VAE·TAE 解码段 → `vae-opt`;交付搬运 / 装载预热等固定开销 → `host-opt`。 - 需要改本仓代码(pattern / 算子 / 测试 / 文档)→ `dev-workflow`。 由 model-auto-optimization 的阶段路由与用户直接声明瓶颈两条路径触发。
日本語の概要は準備中です。原文の説明を表示しています。
PyTorch Inductor pattern matcher 机制开发:扩展本仓 compile 能力(default/Inductor 后端), 或扩展三方框架自带的类似能力——Pattern 创建/注册/调试、GraphPatternEntry 手动改图、 Copy 算子(InplaceCopy/ViewCopy)消减的机制与全生命周期,含 Phase 1–7 出口证据纪律。 当用户需要写/改/调试 pattern、处理融合不命中、做 Copy/InplaceCopy 消减或注册 replacement 时 使用;即使用户只说"pattern 不生效""copy 算子变多了""compile 没融合"而未说全称,也应触发 (触发词:pattern / pattern matcher / register_replacement / GraphPatternEntry / compile 融合 / Copy 消减)。 边界:批量下发(图 capture/replay)见 aclgraph-dev;算子本体开发见 operator-dev; 框架侧特性使能/补齐见 framework-integration。 由 dev-workflow 的 pattern/compile 开发场景路由触发,亦由 model-auto-optimization 的 S1 kernel 融合(接入/compile)替换场景指向(框架侧使能不支持、需新增/适配 pattern 时)。
日本語の概要は準備中です。原文の説明を表示しています。
算子级开发与性能优化:Triton / Ascend C / Catlass / PyPTO / TileLang 算子 编写、精度对齐与性能调优。优先路由到外部 cannbot-skills 技能库(不重复其内容), 本 skill 只保留场景 → skill 映射与 MindIE-SD 特有补充。 当用户需要新增/优化算子、定位算子性能或精度问题时使用此 skill。 即使用户只提到"写个 triton kernel"或"这个算子怎么加速"而未说算子,也应触发; pattern 融合/编译后端见 pattern-dev,算子基准选型/接入测试见 benchmark-dev。 由 dev-workflow 或 pattern-dev 的 replacement kernel 场景触发。
日本語の概要は準備中です。原文の説明を表示しています。
多模态模型自动优化流程总入口(编排层):把一个三方框架托管的扩散模型从环境准备到无损/有损 优化自动跑完。任务判定后按 S0 环境准备、S1 kernel 融合优化(原 S1/S2 合并)、S3 并行通信、 S4 有损优化、S5 训练感知(预留,少步蒸馏 + SLA/QAT)、闭环复验路由到能力技能(env-install / framework-integration / profiling-collect / profiling-analyze / performance-optimization / dit-parallel-opt / dummy-run 等),检查各阶段产物与验收并回填经验槽位。 当用户需要对具体模型做框架接入、无损/有损加速、并行调优或确认收益时使用本入口;即使用户只提 模型名加"优化/加速/跑通/采profile"而未说框架或阶段,也应由本入口判定路由。仓库代码开发类任务 请走 dev-workflow。流程执行/验收按 workflows/optimization-flow.md,run-state + stage_gate 门禁。
日本語の概要は準備中です。原文の説明を表示しています。
环境安装与准备:把部署环境从零安装就绪——mindiesd 编译安装(本地昇腾直装 / SSH 推远端容器 / Docker 镜像直装)与三方推理框架全栈安装(vLLM-Omni 源码构建、DiffSynth-Engine 部署、 LightX2V editable 部署),并负责模型权重确认与下载(下载前先确认远端是否已存在)。不含特性使能与验证 (framework-integration)与 profiling(profiling-collect);SSH 工具由 remote-access 提供。 当用户需要安装 MindIE-SD、源码构建/直装 vLLM-Omni 或 LightX2V(editable + PLATFORM=ascend_npu)、 或确认/下载模型权重时使用此技能; 即使用户只提到"把代码推到服务器""在容器里装 vllm 全栈""准备 lightx2v 调优环境"而未说昇腾, 只要上下文涉及环境安装与准备都应触发。由 model-auto-optimization S0 与 dev-workflow 部署阶段指引加载。
日本語の概要は準備中です。原文の説明を表示しています。