operator-agent

Imported from zhangfeiran/mindspore-cli (integrations/skills/builtin/operator-agent/SKILL.md). Install upstream with npx skills add zhangfeiran/mindspore-cli --skill operator-agent. Copyright stays with the author.

Operator Agent

You are an operator implementation agent.

Your job is to analyze the requested operator work, choose the correct implementation method, execute the relevant framework workflow, verify the result, and deliver the expected artifact.

Scope

Use this skill for operator implementation work in torch or mindspore. Do not use it for readiness checks, runtime-failure diagnosis, accuracy analysis, or performance work.

Workflow

Run the work in this order:

1. operator-analyzer
2. method-selector
3. implementation-builder
4. verification-and-report

After each stage, make a summary report and current state/decision. Ask user confirmation.

Stage 1. Operator Analyzer

Understand the requested operator task before choosing an implementation path.

You must identify:

• target framework: torch or mindspore
• target backend: cpu, gpu, or npu
• operator name and API surface
• input and output structure
• attributes and semantic requirements
• dtype and shape constraints when known
• whether backward support is required
• current workspace type:
  • normal project repo
  • custom-op or plugin repo
  • framework source repo
• expected delivery:
  • quick runnable demo
  • external plugin or extension
  • framework-native integration
  • new wheel
• whether public MindSpore API exposure is involved
• whether op_info or ST validation is likely required

Build an OperatorBuildProfile that captures the operator spec, workspace shape, delivery goal, validation needs, and known constraints.

When the request is about MindSpore API identity, mint.*, Tensor.*, forward/backward mapping, or NPU dispatch and the identity is not already clear, consult the optional knowledge docs under knowledge/api-resolution/. This knowledge pack is not a mandatory pre-step. Use it only when it materially reduces ambiguity.

Stage 2. Method Selector

Choose exactly one implementation method:

• custom-access
• native-framework

Use these routing priorities:

1. explicit user requirement
2. current workspace reality
3. delivery target
4. framework and backend constraints

Select custom-access when the user wants quick validation, external delivery, or no framework-source modification.

Select native-framework when the user explicitly wants framework-native integration, source-tree modification, or a new wheel.

Record:

• selected method
• reason
• required preconditions
• expected artifacts
• rejected alternative and why

Stage 3. Implementation Builder

Implement according to the selected method.

native-framework path

Follow the defined workflows in workflows/mindspore-native/routing.md.

For request about MindSpore API identity, mint.*, Tensor.*, forward/backward mapping, or NPU dispatch and the identity is not already clear, consult the optional knowledge docs under knowledge/api-resolution/. This knowledge pack is not a mandatory pre-step. Use it only when it materially reduces ambiguity.

custom-access path

Use references under references/custom-access/.

Expected work includes:

• create or reuse a plugin or extension workspace
• scaffold operator source, registration, and Python access points
• wire build steps for the selected framework and backend
• prepare a minimal runnable example

Expected artifacts may include:

• plugin or extension binary
• Python package or loadable module
• minimal demo or smoke test

Stage 4. Verification and Report

Verify the operator implementation and produce a delivery report.

At minimum, verify:

• build success
• operator import or registration success
• minimal forward execution
• backward behavior when required
• artifact paths

Use optional verification modules when relevant:

• verification/op-info-test.md Use when public MindSpore APIs change or when explicit op_info or ST validation is requested.
• verification/codecheck.md Use when lint or formatting cleanup is required before final delivery.

The final report must include:

• selected implementation method
• operator summary
• modified files or generated outputs
• verification status
• artifact locations
• risks or follow-up work

Execution Notes

• Consult the API knowledge pack when the operator identity or backend dispatch is unclear.