Add /commit and /pr slash command skills and document git workflow in CLAUDE.md

.claude/commands/commit.md

@@ -0,0 +1,87 @@
+---
+description: Stage, branch, and commit changes following repo conventions (auto-detects commit-msg hook tag format)
+---
+
+# Commit Changes
+
+Follow these steps precisely to commit the current changes.
+
+## Step 1: Check current branch, status, and commit-msg hook
+
+Run these in parallel:
+- `git status` to see all changed/untracked files
+- `git branch --show-current` to get the current branch name
+- `git diff` to see unstaged changes
+- `git diff --cached` to see staged changes
+- `git log --oneline -5` to see recent commit style
+- Read the active commit-msg hook to discover allowed tag formats:
+  1. Run `git config --get core.hooksPath` to find the hooks directory (defaults to `.git/hooks` if unset)
+  2. Read the `commit-msg` file from that directory (e.g., `cat $(git rev-parse --show-toplevel)/.githooks/commit-msg` or `.git/hooks/commit-msg`)
+  3. Parse the hook to extract the allowed tags (look for patterns like `Feature|Fix|Refactor|...`)
+
+## Step 2: Determine the commit message tag format
+
+Based on the commit-msg hook analysis from Step 1:
+
+- **If a commit-msg hook exists and enforces specific tags** (e.g., `[Feature]`, `[Fix]`, `[Refactor]`, `[Docs]`, `[Test]`, `[CI]`, `[Chore]`, `[Perf]`):
+  Use the repo's required format. Pick the tag that best matches the nature of the change:
+  - `[Feature]` — new functionality
+  - `[Fix]` — bug fix
+  - `[Refactor]` — code restructuring without behavior change
+  - `[Docs]` — documentation only
+  - `[Test]` — adding or updating tests
+  - `[CI]` — CI/CD pipeline changes
+  - `[Chore]` — maintenance, dependencies, tooling
+  - `[Perf]` — performance improvement
+
+- **If no commit-msg hook exists or it doesn't enforce a tag format**:
+  Use `[AMD]` as the default prefix.
+
+## Step 3: Ensure we are on a feature branch (NOT main/master)
+
+If the current branch is `main` or `master`:
+1. Determine a short, descriptive branch name based on the changes (e.g., `fix-mla-bf16-attention`, `add-rocm-triton-kernel`)
+2. Create and switch to the new branch: `git checkout -b <branch-name>`
+
+If already on a feature branch, stay on it.
+
+## Step 4: Stage the changes
+
+- Stage only the relevant changed files by name (e.g., `git add file1.py file2.py`)
+- Do NOT use `git add -A` or `git add .` unless the user explicitly asks
+- Do NOT stage files that look like they contain secrets (.env, credentials, tokens, etc.)
+- If unsure which files to stage, ask the user
+
+## Step 5: Write the commit message
+
+The commit message MUST follow this format:
+- Start with the tag determined in Step 2 (e.g., `[Fix]` or `[AMD]`)
+- Followed by a single concise sentence describing what was changed and why
+- Example (with repo hook): `[Fix] Resolve bf16 type casting in MLA decode attention for dp-attention mode`
+- Example (without hook): `[AMD] Fix bf16 type casting in MLA decode attention for dp-attention mode`
+- Do NOT include `Co-Authored-By` or any other trailers — they are forbidden by project convention
+
+If the user provided `$ARGUMENTS`, incorporate that into the commit message description.
+
+If no arguments were provided, analyze the diff to write an appropriate one-sentence summary.
+
+## Step 6: Create the commit
+
+Always use `--author` to set the commit author explicitly:
+
+```bash
+git commit --author="jacky.cheng <yichiche@amd.com>" -m "[Tag] <one sentence description>"
+```
+
+## Step 7: Verify
+
+Run `git status` and `git log --oneline -3` to confirm the commit was created successfully. Report the branch name and commit hash to the user.
+
+## Important Rules
+
+- NEVER include Co-Authored-By or any trailers in the commit message
+- NEVER amend a previous commit unless the user explicitly asks
+- NEVER force push
+- NEVER skip pre-commit hooks
+- If a pre-commit hook fails, fix the issue, re-stage, and create a NEW commit
+- NEVER commit .env files, credentials, or secrets

.claude/commands/pr.md

@@ -0,0 +1,99 @@
+---
+description: Create a GitHub Pull Request following SGLang project conventions with proper sections
+---
+
+# Create a Pull Request for SGLang
+
+Follow these steps precisely to create a well-formatted PR.
+
+## Step 1: Gather context
+
+Run these in parallel:
+- `git status` to check for uncommitted changes
+- `git branch --show-current` to get current branch
+- `git log --oneline main..HEAD` to see all commits on this branch
+- `git diff main...HEAD` to see all changes vs main
+- Check if the branch has a remote tracking branch: `git rev-parse --abbrev-ref --symbolic-full-name @{u} 2>/dev/null`
+
+If there are uncommitted changes, warn the user and ask if they want to commit first (suggest using `/commit`).
+
+## Step 2: Push the branch
+
+If the branch is not pushed or is behind the remote:
+- Push with: `git push -u origin <branch-name>`
+
+## Step 3: Analyze the changes
+
+Read through all the diffs and commits to understand:
+- What was the motivation / bug being fixed / feature being added?
+- What specific files and code were modified?
+- Does this change affect model accuracy (kernel changes, model forward code)?
+- Does this change affect inference speed / performance?
+
+## Step 4: Determine the category of change
+
+Based on the analysis, determine if this PR:
+- **Affects accuracy**: Changes to kernels, model forward code, attention mechanisms, etc. -> Need accuracy test results
+- **Affects performance**: Changes to scheduling, batching, memory management, kernels, etc. -> Need benchmark results
+- **Neither**: Documentation, CI, refactoring with no behavioral change, etc.
+
+## Step 5: Create the PR
+
+Use `gh pr create` with the following template. Fill in each section based on your analysis.
+
+If the user provided `$ARGUMENTS`, use that as the PR title. Otherwise, craft a concise title (under 70 chars) starting with `[AMD]`.
+
+```bash
+gh pr create --title "[AMD] <concise title>" --body "$(cat <<'EOF'
+## Motivation
+
+<Describe the purpose and goals based on the actual changes. Explain what problem this solves or what feature this adds.>
+
+## Modifications
+
+<Bullet list of concrete changes to files/functions/behavior.>
+
+## Accuracy Tests
+
+<If accuracy-related: describe what accuracy tests should be run, or paste results if available.>
+<If not accuracy-related: write "N/A - this change does not affect model outputs.">
+
+## Benchmarking and Profiling
+
+<If performance-related: describe what benchmarks should be run, or paste results if available.>
+<If not performance-related: write "N/A - this change does not affect inference speed.">
+
+## Checklist
+
+- [ ] Format your code according to the [Format code with pre-commit](https://docs.sglang.io/developer_guide/contribution_guide.html#format-code-with-pre-commit).
+- [ ] Add unit tests according to the [Run and add unit tests](https://docs.sglang.io/developer_guide/contribution_guide.html#run-and-add-unit-tests).
+- [ ] Update documentation according to [Write documentations](https://docs.sglang.io/developer_guide/contribution_guide.html#write-documentations).
+- [ ] Provide accuracy and speed benchmark results according to [Test the accuracy](https://docs.sglang.io/developer_guide/contribution_guide.html#test-the-accuracy) and [Benchmark the speed](https://docs.sglang.io/developer_guide/contribution_guide.html#benchmark-the-speed).
+- [ ] Follow the SGLang code style [guidance](https://docs.sglang.io/developer_guide/contribution_guide.html#code-style-guidance).
+
+## Review Process
+
+1. Ping Merge Oncalls to start the PR flow. See the [PR Merge Process](https://github.com/sgl-project/sglang/blob/main/.github/MAINTAINER.md#pull-request-merge-process).
+2. Get approvals from [CODEOWNERS](https://github.com/sgl-project/sglang/blob/main/.github/CODEOWNERS) and other reviewers.
+3. Trigger CI tests with [comments](https://docs.sglang.io/developer_guide/contribution_guide.html#how-to-trigger-ci-tests) or contact authorized users to do so.
+   - `/tag-run-ci-label`, `/rerun-failed-ci`, `/tag-and-rerun-ci`
+4. After green CI and required approvals, ask Merge Oncalls to merge.
+EOF
+)"
+```
+
+## Step 6: Report back
+
+After the PR is created, show the user:
+- The PR URL
+- A summary of what was included
+- Remind them about the review process (ping merge oncalls, get CODEOWNER approvals, trigger CI)
+- If accuracy-related: remind them to run accuracy tests and post results
+- If performance-related: remind them to run benchmarks and post results
+
+## Important Rules
+
+- NEVER force push
+- NEVER create PRs to branches other than `main` unless the user explicitly asks
+- Always use the full template with all sections filled in
+- The PR title should start with `[AMD]` and be under 70 characters

CLAUDE.md

@@ -93,4 +93,11 @@ env.sh       — Central environment config (HOST_HOME, AGENT_BOX_DIR)
 
 ## Trace Analyzer
 
-When debugging or adding features to `trace_analyzer.py`, use the `/trace-analyzer` skill command for detailed guidance on pattern tables, half-layer handling, and diagnostic steps. See `profile/trace-analyzer.md`.
+When debugging or adding features to `trace_analyzer.py`, use the `/trace-analyzer` skill command for detailed guidance on pattern tables, half-layer handling, and diagnostic steps. See `profile/trace-analyzer.md`.
+
+## Git Workflow Skills
+
+Two slash commands are available for streamlined git workflows:
+
+- **`/commit`** — Stage changes, ensure you're on a feature branch (creates one if on main), and commit with an `[AMD]` prefixed message. Usage: `/commit` or `/commit <description>`.
+- **`/pr`** — Push the branch and create a GitHub PR with the full SGLang template (Motivation, Modifications, Accuracy Tests, Benchmarking, Checklist, Review Process). Usage: `/pr` or `/pr <title>`.

benchmark/run-local-benchmark-e2e.sh

@@ -29,6 +29,7 @@ Common options:
   --keep-container                   Do not stop/remove container on exit.
   --no-sudo-docker                   Use docker directly instead of sudo docker.
   --accuracy                         Run GSM8K accuracy benchmark after perf bench.
+  --accuracy-only                    Run GSM8K accuracy benchmark only (skip perf bench).
   --no-accuracy                      Skip accuracy benchmark (skip interactive prompt).
   --accuracy-num-questions <int>     Number of GSM8K questions. Default: 2000
   --accuracy-parallel <int>          GSM8K parallel requests. Default: 1000
@@ -106,6 +107,7 @@ USE_SUDO_DOCKER=1
 HOST_HOME_DIR=""
 MTP_MODE=""
 ACCURACY_MODE=""
+ACCURACY_ONLY=0
 ACCURACY_NUM_QUESTIONS=2000
 ACCURACY_PARALLEL=1000
 ACCURACY_NUM_SHOTS=5
@@ -189,6 +191,11 @@ while [[ $# -gt 0 ]]; do
       ACCURACY_MODE=1
       shift
       ;;
+    --accuracy-only)
+      ACCURACY_MODE=1
+      ACCURACY_ONLY=1
+      shift
+      ;;
     --no-accuracy)
       ACCURACY_MODE=0
       shift
@@ -539,42 +546,46 @@ if (( ACCURACY_MODE == 1 )); then
     | tee -a "$HOST_ACCURACY_LOG"
 fi
 
-for c in "${CONCURRENCY_ARRAY[@]}"; do
-  NUM_PROMPTS=$((c * PROMPTS_MULTIPLIER))
-  CONTAINER_BENCH_LOG="${CONTAINER_RESULT_DIR}/bench_c${c}.log"
-
-  BENCH_ARGS=(
-    python3 -m sglang.bench_serving
-    --backend sglang
-    --host localhost
-    --port "$SERVER_PORT"
-    --model "$MODEL_PATH"
-    --dataset-name "$DATASET_NAME"
-    --random-input-len "$RANDOM_INPUT_LEN"
-    --random-output-len "$RANDOM_OUTPUT_LEN"
-    --random-range-ratio "$RANDOM_RANGE_RATIO"
-    --max-concurrency "$c"
-    --num-prompts "$NUM_PROMPTS"
-    --disable-tqdm
-    --output-file "$CONTAINER_BENCH_JSONL"
-  )
+if (( ACCURACY_ONLY == 1 )); then
+  log "Accuracy-only mode: skipping perf benchmark"
+else
+  for c in "${CONCURRENCY_ARRAY[@]}"; do
+    NUM_PROMPTS=$((c * PROMPTS_MULTIPLIER))
+    CONTAINER_BENCH_LOG="${CONTAINER_RESULT_DIR}/bench_c${c}.log"
+
+    BENCH_ARGS=(
+      python3 -m sglang.bench_serving
+      --backend sglang
+      --host localhost
+      --port "$SERVER_PORT"
+      --model "$MODEL_PATH"
+      --dataset-name "$DATASET_NAME"
+      --random-input-len "$RANDOM_INPUT_LEN"
+      --random-output-len "$RANDOM_OUTPUT_LEN"
+      --random-range-ratio "$RANDOM_RANGE_RATIO"
+      --max-concurrency "$c"
+      --num-prompts "$NUM_PROMPTS"
+      --disable-tqdm
+      --output-file "$CONTAINER_BENCH_JSONL"
+    )
 
-  if (( PROFILE_MODE == 1 )); then
-    BENCH_ARGS+=(--profile)
-  fi
+    if (( PROFILE_MODE == 1 )); then
+      BENCH_ARGS+=(--profile)
+    fi
 
-  if [[ -n "$BENCH_EXTRA_ARGS" ]]; then
-    # shellcheck disable=SC2206
-    BENCH_EXTRA_ARRAY=($BENCH_EXTRA_ARGS)
-    BENCH_ARGS+=("${BENCH_EXTRA_ARRAY[@]}")
-  fi
+    if [[ -n "$BENCH_EXTRA_ARGS" ]]; then
+      # shellcheck disable=SC2206
+      BENCH_EXTRA_ARRAY=($BENCH_EXTRA_ARGS)
+      BENCH_ARGS+=("${BENCH_EXTRA_ARRAY[@]}")
+    fi
 
-  BENCH_CMD="$(quote_join "${BENCH_ARGS[@]}")"
-  log "Running benchmark: concurrency=${c}, num_prompts=${NUM_PROMPTS}"
-  docker_cmd exec "$CONTAINER_NAME" bash -lc \
-    "cd /sgl-workspace/sglang/python && ${BENCH_CMD} 2>&1 | tee -a $(quote_one "$CONTAINER_BENCH_LOG")" \
-    | tee -a "$HOST_CLIENT_LOG"
-done
+    BENCH_CMD="$(quote_join "${BENCH_ARGS[@]}")"
+    log "Running benchmark: concurrency=${c}, num_prompts=${NUM_PROMPTS}"
+    docker_cmd exec "$CONTAINER_NAME" bash -lc \
+      "cd /sgl-workspace/sglang/python && ${BENCH_CMD} 2>&1 | tee -a $(quote_one "$CONTAINER_BENCH_LOG")" \
+      | tee -a "$HOST_CLIENT_LOG"
+  done
+fi
 
 if (( PROFILE_MODE == 1 )); then
   log "Collecting TP0 trace from /tmp"