Skip to content

Repository navigation

Commit c6ee606

Browse files
hetaoBackendhetaoBackend
committed
Add six engineering practice skills to the ronny stack
1 parent c889a19 commit c6ee606

12 files changed

Lines changed: 705 additions & 3 deletions

File tree

‎README.md‎

Lines changed: 6 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -56,6 +56,12 @@ A stack usually has three kinds of things:
5656
| `long-command-check` | Ten-point audit of long shell commands and background tasks | 04 |
5757
| `context-tax-audit` | What gets injected into every request, and what it does to the prompt cache | 06 |
5858
| `trajectory-review` | Look at how the agent got its result, not only whether it passed | - |
59+
| `engineering-code-review` | Review a change for code health: design, functionality, complexity, tests, approval risk | - |
60+
| `engineering-review-comments` | Write clear, severity-labeled review comments that explain the reasoning | - |
61+
| `engineering-review-feedback` | Handle reviewer comments as the author: fix, clarify, resolve disagreements | - |
62+
| `engineering-small-prs` | Split large features, refactors and migrations into small reviewable PRs | - |
63+
| `engineering-change-descriptions` | Write PR and commit descriptions that say what changed and why | - |
64+
| `engineering-emergency-changes` | Decide whether a hotfix is a real emergency and run expedited review safely | - |
5965

6066
## Install
6167

‎README_ZH.md‎

Lines changed: 6 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -43,6 +43,12 @@ templates/stack-template/ 写你自己的 stack，从这里开始
4343
| `long-command-check` | 长命令和后台任务的 10 项自查 | 04 |
4444
| `context-tax-audit` | 每轮往请求里塞了什么，会不会弄坏提示词缓存 | 06 |
4545
| `trajectory-review` | 不只看结果过没过，回头看 agent 是怎么得到这个结果的 | - |
46+
| `engineering-code-review` | 按代码健康度审查改动：设计、功能、复杂度、测试、能不能批 | - |
47+
| `engineering-review-comments` | 写清楚、标好严重程度、讲明理由的 review 评论 | - |
48+
| `engineering-review-feedback` | 作为作者处理 review 意见：改代码、补说明、化解分歧 | - |
49+
| `engineering-small-prs` | 把大功能、大重构、迁移拆成一串好审的小 PR | - |
50+
| `engineering-change-descriptions` | 写清楚改了什么、为什么改的 PR 和 commit 描述 | - |
51+
| `engineering-emergency-changes` | 判断 hotfix 是不是真紧急，紧急时怎么快审又不丢质量 | - |
4652

4753
## 安装
4854

‎stacks/ronny/.minimax-plugin/plugin.json‎

Lines changed: 9 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -1,9 +1,9 @@
11
{
22
"schemaVersion": 1,
33
"name": "ronny",
4-
"version": "0.1.0",
4+
"version": "0.2.0",
55
"displayName": "Ronny's MCode Stack",
6-
"description": "Daily workflows and self-check skills from the MiniMax Code R&D lead: independent review, subagent split checks, tool and context budget audits, long sessions, long commands, harness experiments and trajectory review.",
6+
"description": "Daily workflows and self-check skills from the MiniMax Code R&D lead: independent review, subagent split checks, tool and context budget audits, long sessions, long commands, harness experiments, trajectory review, plus everyday engineering practice for code review, review comments, small PRs, change descriptions and emergency changes.",
77
"author": "Ronny (MiniMax Code team)",
88
"icon": "icon.png",
99
"category": "Code",
@@ -23,6 +23,12 @@
2323
"skills/handoff-doc/SKILL.md",
2424
"skills/long-command-check/SKILL.md",
2525
"skills/context-tax-audit/SKILL.md",
26-
"skills/trajectory-review/SKILL.md"
26+
"skills/trajectory-review/SKILL.md",
27+
"skills/engineering-change-descriptions/SKILL.md",
28+
"skills/engineering-code-review/SKILL.md",
29+
"skills/engineering-emergency-changes/SKILL.md",
30+
"skills/engineering-review-comments/SKILL.md",
31+
"skills/engineering-review-feedback/SKILL.md",
32+
"skills/engineering-small-prs/SKILL.md"
2733
]
2834
}

‎stacks/ronny/NOTICE.md‎

Lines changed: 37 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,37 @@
1+
# Third-party notices
2+
3+
The six `engineering-*` skills in [`skills/`](skills/) were written by the
4+
stack's author and first published in
5+
[agentara/skills](https://github.com/agentara/skills/tree/main/skills/engineering).
6+
They are included here under that repository's MIT license, reproduced below.
7+
8+
Their content is adapted from
9+
[Google Engineering Practices](https://google.github.io/eng-practices/),
10+
licensed under [CC-BY 3.0](https://creativecommons.org/licenses/by/3.0/).
11+
Each `SKILL.md` keeps its own source and license note.
12+
13+
## agentara/skills license
14+
15+
```
16+
MIT License
17+
18+
Copyright (c) 2026 agentara
19+
20+
Permission is hereby granted, free of charge, to any person obtaining a copy
21+
of this software and associated documentation files (the "Software"), to deal
22+
in the Software without restriction, including without limitation the rights
23+
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
24+
copies of the Software, and to permit persons to whom the Software is
25+
furnished to do so, subject to the following conditions:
26+
27+
The above copyright notice and this permission notice shall be included in all
28+
copies or substantial portions of the Software.
29+
30+
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
31+
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
32+
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
33+
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
34+
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
35+
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
36+
SOFTWARE.
37+
```

‎stacks/ronny/README.md‎

Lines changed: 16 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -16,5 +16,21 @@ Ronny, R&D lead of MiniMax Code. Each skill pairs with an article in the
1616
| [`context-tax-audit`](skills/context-tax-audit/SKILL.md) | Inventory what is injected into every request and how it affects the prompt cache | 06 |
1717
| [`trajectory-review`](skills/trajectory-review/SKILL.md) | Review how the agent got its result, not only whether it passed | - |
1818

19+
### Engineering practice
20+
21+
Six everyday engineering skills, also published in
22+
[agentara/skills](https://github.com/agentara/skills/tree/main/skills/engineering)
23+
and adapted from Google Engineering Practices (CC-BY 3.0). See
24+
[`NOTICE.md`](NOTICE.md) for licenses.
25+
26+
| Skill | What it does |
27+
| --- | --- |
28+
| [`engineering-code-review`](skills/engineering-code-review/SKILL.md) | Review a change for code health: design, functionality, complexity, tests, approval risk |
29+
| [`engineering-review-comments`](skills/engineering-review-comments/SKILL.md) | Write clear, severity-labeled review comments that explain the reasoning |
30+
| [`engineering-review-feedback`](skills/engineering-review-feedback/SKILL.md) | Handle reviewer comments as the author: fix, clarify, resolve disagreements |
31+
| [`engineering-small-prs`](skills/engineering-small-prs/SKILL.md) | Split large features, refactors and migrations into small reviewable PRs |
32+
| [`engineering-change-descriptions`](skills/engineering-change-descriptions/SKILL.md) | Write PR and commit descriptions that say what changed and why |
33+
| [`engineering-emergency-changes`](skills/engineering-emergency-changes/SKILL.md) | Decide whether a hotfix is a real emergency and run expedited review safely |
34+
1935
Plain-text versions of the checklists live in [`checklists/`](checklists/).
2036
How Ronny strings them together: [`WORKFLOW.md`](WORKFLOW.md) (coming soon).

‎stacks/ronny/WORKFLOW.md‎

Lines changed: 4 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -11,7 +11,11 @@ that are already written down. A rough map:
1111
| Moment in the day | Skill |
1212
| --- | --- |
1313
| Before splitting work across agents | `subagent-split-check` |
14+
| Before opening a large change | `engineering-small-prs`, `engineering-change-descriptions` |
1415
| After the agent finishes a change | `independent-review` |
16+
| Reviewing someone else's PR | `engineering-code-review`, `engineering-review-comments` |
17+
| Answering review on your own PR | `engineering-review-feedback` |
18+
| When a hotfix claims to be urgent | `engineering-emergency-changes` |
1519
| When a long session starts to drift | `long-session-check`, `handoff-doc` |
1620
| Before and after any harness change | `harness-experiment`, `trajectory-review` |
1721
| When auditing an agent's design | `tool-budget-audit`, `long-command-check`, `context-tax-audit` |

‎stacks/ronny/skills/engineering-change-descriptions/SKILL.md‎

Lines changed: 119 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,119 @@
1+
---
2+
name: engineering-change-descriptions
3+
description: 'Use when writing, rewriting, or reviewing PR/CL descriptions, commit messages, or code-change summaries that explain what changed and why. TRIGGER on "write PR description", "improve this commit message", "summarize this diff", "CL description", "change description", or "make this PR/CL description easier to review". DO NOT TRIGGER for code review, PR splitting, code restructuring, user-facing changelogs, or reviewer replies unless the requested output is a change description.'
4+
---
5+
6+
# Engineering Change Descriptions
7+
8+
A change description is permanent engineering history. It should let reviewers understand the change now and help future maintainers find and understand it later.
9+
10+
Adapted from Google Engineering Practices Documentation, especially "Writing good CL descriptions." Source: <https://google.github.io/eng-practices/review/developer/cl-descriptions.html>. License: CC-BY 3.0.
11+
12+
## What a Good Description Answers
13+
14+
- What changed?
15+
- Why did it change?
16+
- What context, constraints, or tradeoffs are not obvious from the code?
17+
- How was it tested?
18+
- What risks, migrations, rollbacks, or follow-ups should reviewers know?
19+
20+
Even small changes deserve context when the reason is not obvious.
21+
22+
## First Line
23+
24+
The first line should:
25+
26+
- Stand alone in version control history.
27+
- Be short, specific, and focused on what the change does.
28+
- Use an imperative form when writing a commit or CL title.
29+
- Avoid vague labels like "fix bug", "cleanup", "phase 1", "misc", or "add helpers".
30+
- Be followed by a blank line when there is a body.
31+
32+
## Body
33+
34+
Include only useful context:
35+
36+
- Problem being solved.
37+
- Why this approach was chosen.
38+
- User-visible or developer-visible behavior changes.
39+
- Important implementation notes.
40+
- Known limitations or follow-up work.
41+
- Bug IDs, issue links, benchmark results, design docs, migration docs, or rollout plans.
42+
- Enough context for links that might later become inaccessible.
43+
- Test commands and results, when appropriate.
44+
45+
Before submitting, reread the description after review changes and make sure it still matches the final diff.
46+
47+
## Templates
48+
49+
### Standard PR
50+
51+
```markdown
52+
[Imperative one-line summary]
53+
54+
## Why
55+
[Problem, user need, production issue, maintainability reason, or design context.]
56+
57+
## What Changed
58+
- ...
59+
- ...
60+
61+
## Testing
62+
- ...
63+
64+
## Risk / Rollback
65+
- Risk:
66+
- Rollback:
67+
```
68+
69+
### Small Change
70+
71+
```markdown
72+
[Imperative one-line summary]
73+
74+
[One paragraph explaining why this change exists and any non-obvious context.]
75+
76+
Testing: [command or manual check]
77+
```
78+
79+
### Refactor
80+
81+
```markdown
82+
[Describe the structural change and what it replaces]
83+
84+
This prepares for [future change] by [specific reason], without intentionally changing behavior.
85+
86+
Testing: [existing or new tests that protect behavior]
87+
```
88+
89+
### Generated or Mechanical Change
90+
91+
```markdown
92+
[Describe the mechanical rewrite]
93+
94+
Generated by [tool/version/command] to [reason]. Manual edits: [none/list].
95+
96+
Verification: [format/test/build command]
97+
```
98+
99+
## Rewrite Checklist
100+
101+
When improving an existing description:
102+
103+
1. Extract the actual behavior from the diff.
104+
2. Replace vague first lines with a concrete action.
105+
3. Add the missing why.
106+
4. Preserve useful issue links and test evidence.
107+
5. Remove process noise that does not help reviewers or future maintainers.
108+
109+
## Common Mistakes
110+
111+
- Describing only the implementation without the reason.
112+
- Writing a title that future searchers cannot distinguish from similar changes.
113+
- Depending entirely on external links for crucial context.
114+
- Leaving the description stale after review significantly changes the diff.
115+
- Hiding risk, limitations, or rollout requirements because they feel inconvenient.
116+
117+
---
118+
119+
*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).*

0 commit comments

Comments
 (0)