dev-workflow

Orchestrates MindIE-SD repository development with Test-First loops, parallel execution, and retrospective archiving.

14|5|Updated Mar 30, 2026
One-click install
npx skills add https://github.com/Ascend/MindIE-SD --skill dev-workflow-ascend
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: dev-workflow
Source: https://github.com/Ascend/MindIE-SD/tree/main/.agents/skills/dev-workflow
Command: npx skills add https://github.com/Ascend/MindIE-SD --skill dev-workflow-ascend

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Developing code for the MindIE-SD repository (patterns, operators, graph dispatch, tests) involves many sub-workflows—writing tests first, deploying to Ascend NPU environments, running pytest, profiling, and retrospectives—and it is easy to skip gates or route tasks to the wrong sub-skill. This Skill acts as the L1 orchestration entry point that routes every MindIE-SD code change to the right capability skill and enforces order and deliverable contracts. ## Core Features & Use Cases - Entry Routing: Splits work between MindIE-SD repo changes (this entry), third-party framework changes (framework-integration), and environment/deployment tasks (env-install, remote-access), based on which repository the modified files live in. - Test-First Closed Loop: Enforces the cycle of writing a failing test, implementing, deploying to the remote Ascend environment, and verifying with pytest, with evidence (commands, exit codes, results) recorded per feature point. - Parallel Development & Retrospective: Runs independent modules in parallel on separate NPU cards, merges shared files last, and closes each phase with a retrospective checklist, rework-lessons updates, and case backfilling. - Use Case: When asked to add a new fusion pattern for a model, this Skill routes pattern authoring to pattern-dev, deployment to env-install, validation to dummy-run/framework-integration, and ensures the Test-First gate and retrospective are completed before claiming done. ## Quick Start Ask the assistant to add a new fusion pattern to MindIE-SD following the full development workflow with tests written first and remote NPU verification.

Frequently Asked Questions about dev-workflow

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I add a new fusion pattern to MindIE-SD?

Follow the Test-First loop: write a failing test, implement the pattern, deploy to the remote Ascend environment, and verify with pytest. Pattern authoring itself is routed to the pattern-dev skill, deployment to env-install, and model validation to dummy-run or framework-integration.

How do I optimize multi-card inference when profiling shows high communication exposure?

Route to dit-parallel-opt for parallel strategy and communication masking (comm-stream masking via mindiesd.parallel). Use profiling-collect to gather real NPU data and profiling-analyze to locate the bottleneck before choosing an optimization.

When should tasks go to dev-workflow versus framework-integration?

Decide by which repository the changed files live in. MindIE-SD repo changes (patterns, kernels, graph dispatch, tests) go through dev-workflow; third-party framework changes go through framework-integration, with cross-repo features split into per-side subtasks.

What is the retrospective process after finishing a development phase?

Review problems and improvements, update references/rework-lessons.md if needed, cross-check whether module skills need updates, and refresh the skill inventory and directory tree in .agents/README.md. Process notes and todos are not written into that file; history lives in git log.

Does this workflow require specific tools or environment access?

It requires git and the repository workspace, plus SSH-based remote access to an Ascend NPU container for deployment and pytest verification. It has no extra tool dependencies itself since it orchestrates other skills like env-install and remote-access.

Why must tests be written before implementation in this workflow?

The Test-First contract requires each feature point to show a failing test before implementation, then pass after deployment and pytest. This creates verifiable evidence (commands, exit codes, results) per feature, and missing evidence means the feature cannot be claimed as complete.