# engineering-review-comments Adopt this skill: https://proskills.md/skills/other/minimax-ai-mcode-stack-stacks-ronny-skills-engineering-review-comments Page: https://proskills.md/skills/other/minimax-ai-mcode-stack-stacks-ronny-skills-engineering-review-comments This document is the public skill bundle for that page. It contains SKILL.md and every helper file the catalog carries. No login is required. ## File: stacks/ronny/skills/engineering-review-comments/SKILL.md size: 4818 upstream: https://github.com/minimax-ai/mcode-stack/blob/main/stacks/ronny/skills/engineering-review-comments/SKILL.md ````text --- name: engineering-review-comments description: 'Use when drafting, rewriting, classifying, or improving code review comments as a reviewer. TRIGGER on rough review notes, requests to make comments clearer or kinder, severity labels, "how should I phrase this review comment?", "write review comments", author pushback, or turning findings into PR comments. If role is unclear, ask reviewer or author. DO NOT TRIGGER for full code review, PR descriptions, or author responses unless wording is requested.' --- # Engineering Review Comments Review comments should improve the code and the developer's future judgment. They should be clear about severity, grounded in engineering reasoning, and directed at the code rather than the person. Adapted from Google Engineering Practices Documentation, especially "How to write code review comments" and "Handling pushback in code reviews." Source: . License: CC-BY 3.0. ## Comment Shape Use this structure for non-trivial comments: ```text SEVERITY: Observation about the code. Why this matters: engineering reason, user impact, maintainability impact, or violated project rule. Requested action: concrete fix, question, or decision the author needs to make. ``` Keep tiny comments tiny. Use the full shape when intent could be misunderstood. ## Severity Labels - `BLOCKER`: must change before approval because correctness, maintainability, security, data, test, or operational risk is unacceptable. - `IMPORTANT`: should change before approval; can be waived only with an explicit rationale. - `QUESTION`: reviewer needs information before deciding. - `NIT`: minor polish. Do not block approval. - `OPTIONAL` or `CONSIDER`: a suggestion the author can decline. - `FYI`: educational context or future consideration; no action expected. ## Writing Rules - Comment on the code, design, tests, or behavior; do not characterize the author. - Explain why when asking for anything beyond obvious style or mechanical cleanup. - Prefer "this makes X harder because..." over "I don't like X." - Ask for simpler code when a review-thread explanation is needed to understand ordinary behavior. - Accept a code comment only when the code cannot reasonably express the why by itself. - Provide direct code or a specific design only when it is faster or safer than making the author infer it. - Otherwise describe the problem and let the author choose the implementation. - Point out good engineering choices when useful, and say why they are good. ## Wording Patterns Use these patterns directly when helpful: ```text BLOCKER: This path can return success before the write is durable. If the process crashes after this point, callers will believe the operation completed even though the data may be missing. Please either move the success response after the durable write or make the operation explicitly asynchronous and observable. ``` ```text QUESTION: What guarantees that this callback cannot run concurrently? If it can run in parallel, `pending` can be decremented twice from the same value. If the framework serializes this callback, please add a short comment at the boundary where that guarantee comes from. ``` ```text NIT: This helper name reads as if it validates the payload, but it only normalizes whitespace. Could we rename it to `normalizePayloadText`? ``` ```text OPTIONAL: Consider extracting this branch into a named helper. The current version is correct, but a helper would make the three policy cases easier to scan. ``` ## Handling Pushback When the author disagrees: 1. Re-evaluate their argument first. They may be closer to the code or have context you missed. 2. If they are right, say so plainly and resolve the comment. 3. If you still disagree, restate their point, then explain the code-health reason for your request. 4. Distinguish mandatory requests from preferences. 5. If the thread stops making progress, move to a higher-bandwidth discussion and summarize the decision back in the review. Do not keep arguing because you wrote the first comment. The goal is the best code, not defending the initial wording. ## Common Mistakes - Leaving unlabeled comments that authors interpret as mandatory. - Writing a correct critique in a tone that makes collaboration harder. - Asking the author to explain confusing code only in the review tool. - Turning every comment into a complete design assignment. - Treating educational notes as blockers. --- *Also published in [agentara/skills](https://github.com/agentara/skills/tree/main/skills/engineering) (MIT, Copyright (c) 2026 agentara) by the same author. The content is adapted from Google Engineering Practices under CC-BY 3.0; see the source note above. Full notices: [`NOTICE.md`](../../NOTICE.md).* ```` ## File: README.md upstream: https://github.com/minimax-ai/mcode-stack/blob/main/README.md ````text

MCode Stack: the workflows and skills the MiniMax Code team uses to build MiniMax Code

License: MIT validate skills: stacks/ for MiniMax Code

English · 中文

**The workflows and skills the MiniMax Code team uses to build MiniMax Code. Open source, install and use.** This is not a prompt collection or a list of "best practices". It is what people on the team actually use every day: how to keep AI-written code at a high bar, how to decide whether a task should go to a subagent, how long to wait on a long command, how to keep long sessions from going dull, and what goes into context on every turn. Each piece is a `SKILL.md` skill or checklist that installs straight into [MiniMax Code](https://github.com/MiniMax-AI/minimax-code). - [Quick start](#quick-start) - [What's inside](#whats-inside) - [How it works](#how-it-works) - [Articles](#articles) - [Stacks](#stacks) - [Contributing](#contributing) ## Quick start **Claude Code, one command.** The command adds this marketplace and installs a whole stack. In a shell: ```bash claude plugin install ronny --marketplace MiniMax-AI/mcode-stack ``` Inside a Claude Code session: ```bash /plugin install ronny --marketplace MiniMax-AI/mcode-stack ``` Use `jiachen` in place of `ronny` for that stack. From a clone of this repository, `scripts/install.sh` installs `ronny` (`scripts/install.sh jiachen` for that stack) with `claude` or `codex` when either is on `PATH`, and otherwise copies that stack's skills into `~/.agents/skills/`. Older Claude Code can add the marketplace first, then install: ```bash /plugin marketplace add MiniMax-AI/mcode-stack /plugin install ronny@mcode-stack ``` **Codex.** Add the marketplace, then install from the Plugins Directory or the CLI: ```bash codex plugin marketplace add MiniMax-AI/mcode-stack codex plugin add ronny@mcode-stack ``` Substitute `jiachen` the same way. To take a single skill instead of the plugin, copy that skill's folder into `~/.agents/skills/`. Codex and MiniMax Code both scan that directory; the copy steps are below. **One skill, for all your projects:** ```bash git clone https://github.com/MiniMax-AI/mcode-stack.git ~/mcode-stack mkdir -p ~/.agents/skills cp -R ~/mcode-stack/stacks/ronny/skills/long-command-check ~/.agents/skills/ ``` Open a new session and type `/skills` in MiniMax Code to see it. Run it with `/long-command-check`, or let the agent load it from its description. **The whole stack, as a plugin:** ```bash mcode plugin marketplace list # shows your local plugin directory ``` Copy the whole `stacks/ronny` directory into that directory, then open `/plugins` in MiniMax Code and press `Ctrl+R` to refresh. A local plugin is installed as soon as it is in that directory; press Space in the panel to enable or disable it. **Every stack, from the MiniMax Code marketplace:** This repository is also a plugin marketplace, so you can install a stack without copying files and pick up updates later. In MiniMax Code desktop, open **Plugins**, choose **Add marketplace** and enter `MiniMax-AI/mcode-stack`; each stack then shows up as one plugin you can install, update or uninstall. Adding marketplaces is rolling out gradually, so your version may not have it yet.
More install options MiniMax Code discovers skills in these directories (one subdirectory per skill, containing `SKILL.md`): - For the current project only: `.minimax/skills/`, `.claude/skills/` or `.agents/skills/` in the project - For all projects: `~/.agents/skills/` (`~/.claude/skills/` and `~/.codex/skills/` are read too) `mcode plugin add` installs from the official catalog only; it does not take a GitHub URL or a local path. The skills use the common `SKILL.md` format, so most of them also work in other agents that support skills.
## What's inside

The skills in stacks/ronny, grouped by moment in the day, plus what stacks/jiachen adds

| When | Skill | What it does | | --- | --- | --- | | Plan & split | [`subagent-split-check`](stacks/ronny/skills/subagent-split-check/SKILL.md) | Decide whether work goes to a subagent or stays in the main loop | | | [`engineering-small-prs`](stacks/ronny/skills/engineering-small-prs/SKILL.md) | Split large features, refactors and migrations into small reviewable PRs | | | [`engineering-change-descriptions`](stacks/ronny/skills/engineering-change-descriptions/SKILL.md) | Write PR and commit descriptions that say what changed and why | | Context & tools | [`tool-budget-audit`](stacks/ronny/skills/tool-budget-audit/SKILL.md) | Measure what tools cost in context; trim, tool search or programmatic tool calling | | | [`context-tax-audit`](stacks/ronny/skills/context-tax-audit/SKILL.md) | What gets injected into every request, and what it does to the prompt cache | | Long sessions & commands | [`long-session-check`](stacks/ronny/skills/long-session-check/SKILL.md) | Drop, summarize or write to file; compact or start fresh; memory scoping | | | [`handoff-doc`](stacks/ronny/skills/handoff-doc/SKILL.md) | A hand-off doc so a new session can pick up the work | | | [`long-command-check`](stacks/ronny/skills/long-command-check/SKILL.md) | Ten-point audit of long shell commands and background tasks | | Review | [`independent-review`](stacks/ronny/skills/independent-review/SKILL.md) | Review a diff from a clean context: only diff, requirement and test results | | | [`engineering-code-review`](stacks/ronny/skills/engineering-code-review/SKILL.md) | Review a change for code health: design, functionality, complexity, tests, approval risk | | | [`engineering-review-comments`](stacks/ronny/skills/engineering-review-comments/SKILL.md) | Write clear, severity-labeled review comments that explain the reasoning | | | [`engineering-review-feedback`](stacks/ronny/skills/engineering-review-feedback/SKILL.md) | Handle reviewer comments as the author: fix, clarify, resolve disagreements | | Experiments & hotfixes | [`harness-experiment`](stacks/ronny/skills/harness-experiment/SKILL.md) | Small eval, one change at a time, repeated runs, look at flipped tasks | | | [`trajectory-review`](stacks/ronny/skills/trajectory-review/SKILL.md) | Look at how the agent got its result, not only whether it passed | | | [`engineering-emergency-changes`](stacks/ronny/skills/engineering-emergency-changes/SKILL.md) | Decide whether a hotfix is a real emergency and run expedited review safely | The table above is [`stacks/ronny`](stacks/ronny/). [`stacks/jiachen`](stacks/jiachen/) adds [`lifting-loops`](stacks/jiachen/skills/lifting-loops/SKILL.md), which finds the loops where you keep acting as a manual step for your agents and lifts you out of them, and [`making-content`](stacks/jiachen/skills/making-content/SKILL.md), which turns notes and material into Xiaohongshu image posts and short vertical videos. A stack usually has three kinds of things: | Kind | What it is | How to use it | | --- | --- | --- | | Skill | A directory with a `SKILL.md` | Invoke it in MiniMax Code with `/`, or let the agent load it from its description | | Checklist | Also a skill: the agent walks your project item by item. A plain-text copy lives in `checklists/` | Same as above, or just read it | | Workflow | A ````