chore: add pull request template

[voltjia]

Summary

• Add .github/PULL_REQUEST_TEMPLATE.md — GitHub auto-populates this file into the body of every new pull request against this repository.
• Structured sections for contributors to fill in: Summary, Motivation, Type of Change (Conventional Commits selector), Platforms Affected (one checkbox per WITH_* flag in CMakeLists.txt), Test Results on Supported Platforms (table + collapsible pytest dump), Benchmark / Performance Impact, and Notes for Reviewers.
• Final Checklist section mechanically enumerates every rule from CONTRIBUTING.md — Title/Branch/Commits, Scope & Design, General Code Hygiene, C++ (Google style + clang-format v21 + clang-tidy + param order + assert-only error handling + kernel naming + blank-line rules + src/base/ layout), Python (PEP 8 + ruff check + ruff format --check + control-flow blank-line rules + PEP 257), Testing (pytest.mark.parametrize, auto_act_and_assert, regression tests), Build/CI/Tooling (pip install .[dev], compile_commands.json, AUTO_DETECT_DEVICES / AUTO_DETECT_BACKENDS, CUDA-like backend mutual exclusion), Documentation, and Security. Each checkbox references the exact CONTRIBUTING.md clause it enforces so contributors can trace any failed item back to the source rule.

Motivation

CONTRIBUTING.md already documents the standards contributors are expected to meet, but until now there was no checkpoint at PR-submission time — reviewers had to manually catch issues like missing cross-platform test results, non-Conventional PR titles, un-clang-formatted C++, kernel/launcher in a single file, or a constructor whose initializer list disagreed with member declaration order. This shifts that burden into the contributor's own workflow by turning each rule into an explicit, per-item checkbox they must verify before requesting review.

Specific pain points this addresses:

• CONTRIBUTING.md §Pull Requests feat(gemm-iluvatar): add Iluvatar GEMM backend support #3 requires building and testing on every supported platform and including the results in the PR — but the format was unspecified. The template introduces a canonical Platforms Affected checklist + a Test Results table keyed to each WITH_* CMake flag, so reviewers can see coverage at a glance.
• Conventional Commits compliance (title, commits, branch name) is easy to forget; a single checkbox per requirement makes drift visible.
• Style-guide rules that are easy to overlook in review (blank-line rules around classes/functions/namespaces, no-exceptions policy, assert messages including __FILE__/__LINE__/__func__, kernel-vs-launcher file separation, PEP 257 docstrings, control-flow blank-line rules) are now surfaced as explicit checks rather than folded into a generic "follow the style guide" instruction.
• CI parity — the checklist calls out the exact tools CI runs (clang-format v21, ruff check + ruff format --check), so contributors can reproduce CI's pass/fail locally before pushing.

No linked issue — this was requested directly. Non-breaking; purely additive governance file, no runtime or build-system impact.

Type of Change

• feat — new feature / new operator / new platform
• fix — bug fix
• perf — performance improvement (no behavioral change)
• refactor — code restructuring without behavior change
• test — adding or fixing tests only
• docs — documentation only
• build / ci — build system or CI configuration
• chore — tooling, formatting, or other non-code changes
• Breaking change (requires a ! in the Conventional Commits prefix or a BREAKING CHANGE: footer)

Platforms Affected

• CPU (WITH_CPU)
• NVIDIA (WITH_NVIDIA)
• Iluvatar (WITH_ILUVATAR)
• MetaX (WITH_METAX)
• Cambricon (WITH_CAMBRICON)
• Moore (WITH_MOORE)
• Ascend (WITH_ASCEND)
• PyTorch C++ bindings (WITH_TORCH)
• Build system / CMake / CI
• Python bindings / user-facing API

Test Results on Supported Platforms

Platform	Built	pytest Result	Notes / Hardware
NVIDIA	Successfully installed InfiniOps-0.1.0	58 failed, 3055 passed, 1000 skipped, 6 warnings in 183.97s (0:03:03)
Iluvatar	Successfully installed InfiniOps-0.1.0	5 failed, 2909 passed in 231.40s (0:03:51)
MetaX	Successfully installed InfiniOps-0.1.0	5 failed, 2909 passed in 360.88s (0:06:00)
Cambricon	Successfully installed InfiniOps-0.1.0	5 failed, 2179 passed, 1511 skipped, 6 warnings in 841.97s (0:14:01)
Moore	Successfully installed InfiniOps-0.1.0	5 failed, 3600 passed, 315 skipped in 541.03s (0:09:01)
Ascend	Successfully installed InfiniOps-0.1.0	5 failed, 3815 passed, 90 skipped in 555.39s (0:09:15)

Full `pytest` output (optional)

paste here

---

Checklist

Every contributor must verify every item below before requesting
review. Tick each box only after the check has actually been performed —
do not tick speculatively. If an item truly does not apply, replace the
checkbox with N/A and briefly explain why in an inline comment.

Title, Branch, and Commits

• PR title follows Conventional Commits (e.g. feat(nvidia): …, fix(cuda/gemm): …).
• Branch name follows <type>/xxx-yyyy-zzzz where <type> matches the PR title's Conventional Commits type and words are joined with hyphens (see CONTRIBUTING.md §Branches).
• Each commit message follows Conventional Commits.
• Small PR is a single squashable commit; or, for a large PR, every commit is meaningful, well-formed, and independently reviewable (see CONTRIBUTING.md §Pull Requests feat: support GEMM on CPU & MetaX and add generic dispatcher #1).
• No stray merge commits from master — the branch is rebased cleanly on top of the current master.
• No fixup! / squash! / wip commits remain.

Scope and Design

• Changes are minimal — nothing unrelated to the stated motivation was added (CONTRIBUTING.md §Code/General feat: support GEMM on CPU & MetaX and add generic dispatcher #1).
• No dead code, commented-out blocks, debug prints, printf/std::cout/print(...) left behind, or TODO without an owner and issue link.
• No unrelated formatting churn that would obscure the diff.
• Public API changes (if any) are intentional, documented, and reflected in affected callers/tests.

General Code Hygiene (applies to all languages)

• The code is self-explanatory; comments were added only where the why is non-obvious (CONTRIBUTING.md §Code/General build: add CMake build system and README #2).
• Every modified or added file ends with a single trailing newline (CONTRIBUTING.md §Code/General feat(gemm-iluvatar): add Iluvatar GEMM backend support #3).
• No trailing whitespace, tab/space mixing, or stray BOMs.
• Identifiers in comments and error messages are wrapped in backticks (e.g. the `seqlens_k` tensor) (CONTRIBUTING.md §Code/General feat: add the implementation of Add operator on CPU, NVIDIA, and MetaX #4).
• All comments and error messages are in English (CONTRIBUTING.md §Code/General refactor: adapt dispatcher for full C++17 compatibility and support pip install on MetaX #5).
• Comments and error messages are complete sentences — capitalized first letter, terminal punctuation — unless the language/framework convention says otherwise (CONTRIBUTING.md §Code/General feat(ops): add RmsNorm with Iluvatar, NVIDIA, CPU backends and fp16/bf16 support #6; Python build: add CMake build system and README #2).

C++ Specific (if C++ files changed)

• Code follows the Google C++ Style Guide strictly.
• clang-format (version 21, per .github/workflows/clang-format.yml) has been run against all modified .h, .cc, .cuh, and .mlu files; the diff is clean.
• clang-tidy concerns (per .clang-tidy) have been reviewed — no new warnings beyond the existing baseline.
• Operator parameter order is inputs first, outputs last; attributes are between inputs and outputs; naming follows PyTorch → ONNX → CUDA API precedence (CONTRIBUTING.md §C++ build: add CMake build system and README #2).
• No exceptions are thrown. Error paths use assert with messages that include at least __FILE__, __LINE__, and __func__ (CONTRIBUTING.md §C++ feat(gemm-iluvatar): add Iluvatar GEMM backend support #3).
• Error and warning message wording follows the LLVM Coding Standards (CONTRIBUTING.md §C++ feat: add the implementation of Add operator on CPU, NVIDIA, and MetaX #4).
• Kernel files are named correctly: custom = kernel / kernel_v2 / …; well-known algorithms use the algorithm name; library-based implementations use the library name (CONTRIBUTING.md §C++ refactor: adapt dispatcher for full C++17 compatibility and support pip install on MetaX #5).
• Kernel and kernel launcher are in separate files: launcher .h, kernel follows platform conventions (e.g. .cuh + .cu) even when non-templated (CONTRIBUTING.md §C++ feat(ops): add RmsNorm with Iluvatar, NVIDIA, CPU backends and fp16/bf16 support #6).
• Constructor initializer list order matches member declaration order (CONTRIBUTING.md §C++ feat: add the implementation of Gemm operator on Cambricon #7).
• Exactly one blank line between classes, between classes and functions, and between functions (CONTRIBUTING.md §C++ feat(ops): add Iluvatar GPU backend for Add #8).
• Exactly one blank line between members (functions and variables) within a class (CONTRIBUTING.md §C++ feat/dev causalsoftmax cuda Draft #9).
• Exactly one blank line before and after the contents of a namespace (CONTRIBUTING.md §C++ feat: add swiglu op with NVIDIA and CPU backends #10).
• New operators added via src/base/<op>.h (inheriting Operator<Op>) with platform implementations under src/<category>/<platform>/ inheriting the base (CONTRIBUTING.md §Adding an Operator feat: support GEMM on CPU & MetaX and add generic dispatcher #1–2).
• No raw new/delete; RAII / smart pointers / existing allocators are used.

Python Specific (if Python files changed)

• Code is PEP 8 compliant; ruff check passes cleanly on CI (see .github/workflows/ruff.yml).
• ruff format --check passes cleanly — if not, run ruff format and commit the result.
• Comments are complete English sentences, starting with a capital letter and ending with punctuation; Markdown backticks are used for code references (CONTRIBUTING.md §Python feat: support GEMM on CPU & MetaX and add generic dispatcher #1).
• Framework-specific conventions (e.g. lowercase pytest.skip messages without terminal period) are honored where applicable (CONTRIBUTING.md §Python build: add CMake build system and README #2).
• No blank line between the function signature and the body when there is no docstring or comment (CONTRIBUTING.md §Python feat(gemm-iluvatar): add Iluvatar GEMM backend support #3).
• A blank line is present before and after if, for, and similar control-flow statements (CONTRIBUTING.md §Python feat: add the implementation of Add operator on CPU, NVIDIA, and MetaX #4).
• A blank line appears before each return, except when it directly follows a control-flow statement (CONTRIBUTING.md §Python refactor: adapt dispatcher for full C++17 compatibility and support pip install on MetaX #5).
• Docstrings (if any) follow PEP 257 (CONTRIBUTING.md §Python feat(ops): add RmsNorm with Iluvatar, NVIDIA, CPU backends and fp16/bf16 support #6).
• Type hints are added / kept consistent with the surrounding code.

Testing

• pytest was run locally on every supported platform that this PR can affect, and the results are recorded in the "Test Results" table above (CONTRIBUTING.md §Pull Requests feat(gemm-iluvatar): add Iluvatar GEMM backend support #3).
• For any platform that could not be tested, an explicit reason is given in the table and a reviewer with access has been tagged.
• New functionality has matching tests under tests/ following tests/test_add.py / tests/test_gemm.py patterns (CONTRIBUTING.md §Adding an Operator feat(gemm-iluvatar): add Iluvatar GEMM backend support #3).
• Tests use pytest.mark.parametrize correctly: dependent parameters share one decorator (e.g. @pytest.mark.parametrize("dtype, rtol, atol", …)), independent parameters use separate decorators ordered by parameter declaration.
• Where appropriate, pytest.mark.auto_act_and_assert is used and the test returns a Payload whose func and ref share the same calling convention.
• Default dtype / device parameterization is relied on, or overridden with an explicit pytest.mark.parametrize when necessary.
• Any new test that is flaky under parallelism is marked so, or documented to require pytest -n 1.
• For bug fixes: a regression test has been added that fails on master and passes with this PR.

Build, CI, and Tooling

• The project builds cleanly from a fresh directory with pip install .[dev] on at least one affected platform.
• compile_commands.json still regenerates (CMake option CMAKE_EXPORT_COMPILE_COMMANDS=ON in pyproject.toml — required by the code-lint skill and clang-tidy -p).
• New backends / devices have been added to auto-detection in CMakeLists.txt under if(AUTO_DETECT_DEVICES) and to if(AUTO_DETECT_BACKENDS) if applicable.
• Only one CUDA-like GPU backend is selectable at a time — the existing mutual-exclusion check in CMakeLists.txt is not broken.
• Both CI workflows (clang-format.yml, ruff.yml) are green locally (or expected to be green on CI).
• No new runtime dependency was added without updating pyproject.toml's [project.optional-dependencies] (or justified in the PR description).

Documentation

• README.md, CONTRIBUTING.md, or inline docs updated when behavior, build flags, or developer workflow changed.
• New operators, new dispatch helpers, or new public utilities are documented (docstring, header comment, or an addition to CONTRIBUTING.md §Some Code Explanations).
• Any user-visible breaking change is called out explicitly under "Motivation" and in the commit/PR title with a ! or BREAKING CHANGE: footer.

Security and Safety

• No secrets, access tokens, internal URLs, customer data, or personal hardware identifiers have been committed.
• Third-party code is license-compatible and attributed.
• No unsafe pointer arithmetic, uninitialized reads, or missing bounds checks were introduced.

[voltjia]

results.log

[voltjia]

results.log

[voltjia]

请 @Ziminli 初审，@kilinchange 或 @whjthu 终审。

[Ziminli]

PR description 里面有很多 PR 的链接，比如：

No blank line between the function signature and the body when there is no docstring or comment (CONTRIBUTING.md §Python #3).).

后面的

(CONTRIBUTING.md §Python #3).

看出来了这里是对应 CONTRIBUTING.md 里 Python 那一章的第三点，但是这个格式会被 GitHub 这里的 Markdown 理解为 PR 号并且展示为对应的 PR title，建议更换格式避免造成困惑。

[voltjia]

PR description 里面有很多 PR 的链接，比如：

No blank line between the function signature and the body when there is no docstring or comment (CONTRIBUTING.md §Python #3).).

后面的

(CONTRIBUTING.md §Python #3).

看出来了这里是对应 CONTRIBUTING.md 里 Python 那一章的第三点，但是这个格式会被 GitHub 这里的 Markdown 理解为 PR 号并且展示为对应的 PR title，建议更换格式避免造成困惑。

此处是刻意为之的，因为感觉这样好看一点。