Vllm-ascend main2main
install
source · Clone the upstream repo
git clone https://github.com/vllm-project/vllm-ascend
Claude Code · Install into ~/.claude/skills/
T=$(mktemp -d) && git clone --depth=1 https://github.com/vllm-project/vllm-ascend "$T" && mkdir -p ~/.claude/skills && cp -r "$T/.agents/skills/main2main" ~/.claude/skills/vllm-project-vllm-ascend-main2main && rm -rf "$T"
manifest:
.agents/skills/main2main/SKILL.mdsource content
main2main
Adapt vLLM-Ascend to upstream vLLM main branch evolution — proactively or reactively.
Scenario Detection
Determine which workflow the user needs, then Read the corresponding document:
Proactive Upgrade — Read
proactive-upgrade.md (in the same directory as this SKILL.md)
- User wants to analyze what changed in vLLM and adapt vllm-ascend
- User mentions upgrading, bumping, or syncing to a newer vLLM commit
- No CI failure is involved; the goal is forward-looking analysis
CI Failure Diagnosis — Read
error-analysis.md (in the same directory as this SKILL.md)
- User shares a GitHub Actions URL, run ID, or mentions CI is red
- User mentions schedule_test_vllm_main failures or "main2main" test failures
- The goal is to diagnose and fix existing breakage
If both signals are present (e.g., user says "upstream changed an API and CI is failing"), prefer CI Failure Diagnosis — fixing active breakage takes priority over proactive analysis.
Both workflows share the common knowledge below. After reading the relevant document, also read
reference/error-patterns.md for concrete fix examples — do this immediately if the user's message already mentions a specific error type (TypeError, AttributeError, ImportError, etc.), or whenever you encounter such errors during analysis.
Common Knowledge
Version Compatibility Pattern
Most fixes require
vllm_version_is() guards to maintain backward compatibility:
from vllm_ascend.utils import vllm_version_is if vllm_version_is("0.16.0"): # pinned release version # Use old API else: # Use new API (main branch)
The compatible release version comes from
vllm_version matrix in .github/workflows/pr_test_full.yaml.
Output Contract
Both workflows produce two common outputs:
- Code changes — applied to the working tree (unstaged)
- Structured summary — output in conversation, following the format defined in each workflow's final step
The skill does not perform git or GitHub operations (no branch, commit, push, or PR). After the skill completes:
- Standalone mode: proceed with creating a branch, committing changes, pushing, and submitting a PR. Use the structured summary as the PR body content.
- Workflow mode: the orchestrating Workflow handles all git/PR operations using the structured summary.