mirror of
https://github.com/NVIDIA/Model-Optimizer.git
synced 2026-10-02 03:14:52 +08:00
Keval MorabiaandClaude Opus 5
96b4aac90a
### What does this PR do? Type of change: documentation Trims the 0.46 and 0.47 changelog entries and adds the guidelines that keep future entries (and comments, docstrings, tests) from growing the same way. **`CHANGELOG.rst`** - 0.47: `**New Features**` split into `*Quantization*` / `*Megatron Framework (M-LM / M-Bridge)*` / `*Misc*`, matching 0.46's organization. - 0.46 bug fixes: all 14 entries condensed to symptom → cause → fix. - Removed internal `NVBug` IDs (0.45, 0.46) and root-cause forensics that only matter to maintainers — exact tensor shapes, upstream-bug analysis, internal helper names. - Trimmed the most verbose feature entries (dLLM, Torch-TensorRT ViT, `local_hessian` Triton, `module_search_spaces`, `constant_amax`, CP/DP, `day0-release`) and the Phi-4-multimodal breaking-change note. **`AGENTS.md`** - What earns a changelog entry, and that entries are one or two sentences written for external users, with features filed under the right `**New Features**` sub-section. - What belongs in a PR description, so detail redirected out of the changelog and docstrings has a defined home. **`CONTRIBUTING.md`** - *Comment cautiously*: comments and docstrings capped at one or two lines; rationale, benchmarks, and root cause go in the PR description. - *Test design principles*: new lead bullet preferring the highest-level test that runs the real code path, with GPU/framework behavior going to `tests/gpu*` instead of monkeypatched CPU approximations in `tests/unit`; one test per behavior, `@pytest.mark.parametrize` over near-duplicate test functions. **`.github/PULL_REQUEST_TEMPLATE.md`** - Changelog checklist item now asks for a very short summary. ### Usage N/A — documentation only. ### Testing `pre-commit run --files CHANGELOG.rst AGENTS.md CONTRIBUTING.md .github/PULL_REQUEST_TEMPLATE.md` passes, including the RST and markdownlint hooks. No code changes, so no test suite applies. ### Before your PR is "*Ready for review*" - Is this change backward compatible?: N/A - If you copied code from any other sources or added a new PIP dependency, did you follow guidance in `CONTRIBUTING.md`: N/A - Did you write any new necessary tests?: N/A - Did you update [Changelog](https://github.com/NVIDIA/Model-Optimizer/blob/main/CHANGELOG.rst)?: N/A <!-- this PR only edits existing entries --> - Did you get Claude approval on this PR?: ❌ ### Additional Information Only the wording of released 0.45/0.46 entries changed; no entry was added or removed. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Signed-off-by: Keval Morabia <28916987+kevalmorabia97@users.noreply.github.com> Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
3.8 KiB
3.8 KiB
Agent Instructions for ModelOpt
These instructions apply to AI-assisted work in this repository.
Repository orientation
- Start with
README.mdfor project overview and install. - Use
modelopt/for source,tests/for focused test coverage, andexamples/ordocs/for usage patterns. - Agent skills live under
plugins/modelopt/skills/, the installable plugin's canonical skill tree..agents/skillsand.claude/skillsexpose those skills through relative symlinks. Shared agent config and scripts remain under.agents/. See.agents/README.mdfor the convention.
Coding guidelines
- Coding guide: Code development and review require reading and following the coding standards in CONTRIBUTING.md; do not skip this step.
- Use relative paths from the repo root in commands and file references.
Iterative development
- Running tests: Follow the
writing and running tests
instructions. For fast initial iteration, choose focused tests for the
changed area from
tests/. - Running pre-commit: Follow the pre-commit hook instructions. Hooks may modify files; review and re-stage those changes before committing.
- Signed commit: Use
git commit -s -S -m "<message>"for commits so they follow the signing your work requirements. - Never
git pushwithout explicit approval in the current turn. Commit locally is fine; publishing to a remote is not. - After
git commit, stop and wait for the user to say "push", "publish", "ship", or equivalent before runninggit push,gh pr create, or any push-option flags like-o merge_request.create.
Contributing and PR readiness
- Before opening or marking a PR ready for review, read the submitting your code guidance.
- Read
.github/PULL_REQUEST_TEMPLATE.mdand satisfy the checklist. - PR description: fill the template sections — what changed and why, a usage snippet if it adds an API or flag, and what you actually ran under Testing. Root cause, benchmark numbers, and design rationale belong here. Don't restate the diff file by file.
- Only changelog-worthy changes get a
CHANGELOG.rstentry: new features, backward breaking changes, deprecations, and fixes for critical or known bugs from a previous release. Skip bugs introduced and fixed within the same unreleased cycle. - Keep each entry to one or two sentences written for external users: what
changed and what they need to do. No internal bug numbers (e.g. NVBug IDs),
root-cause analysis, or implementation detail — that belongs in the PR
description. File features under the matching
**New Features**sub-section used by recent releases (e.g.*Quantization*,*Speculative Decoding*,*Megatron Framework (M-LM / M-Bridge)*,*Misc*) rather than relabeling existing ones.
Responding to PR review feedback
- Judge each comment on its merits before acting. Check it against the current code — reviewers comment on stale diffs, and bot findings (CodeRabbit, Claude) are claims to verify, not instructions. Weight CODEOWNERS reviewers above bots; if a reviewer reaffirms after your pushback, that settles it.
- Pick one outcome per thread: address it in a commit, push back citing the code that shows the comment is wrong, or postpone it as out of scope. Report which threads got which when you ask for push approval.
- Reply in every thread the pushed commits addressed — a sentence on what changed and where. Those replies need no extra approval; pushback and postpone replies do, since no commit backs them. Never resolve threads: that is the reviewer's call.