ronny: add four skills for owning agent work

.claude-plugin/marketplace.json

@@ -10,7 +10,7 @@
     {
       "name": "ronny",
       "source": "./stacks/ronny",
-      "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.",
+      "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, agent briefs, evidence-first review of agent output, review capacity and turning repeat corrections into checks, plus everyday engineering practice for code review, review comments, small PRs, change descriptions and emergency changes.",
       "category": "Code",
       "author": {
         "name": "Ronny (MiniMax Code team)"

README.md

@@ -138,6 +138,10 @@ other agents that support skills.
 | | [`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 |
+| Owning agent work | [`agent-brief`](stacks/ronny/skills/agent-brief/SKILL.md) | Before delegating: stakes, hypothesis, scope, what "verified" means |
+| | [`evidence-first-review`](stacks/ronny/skills/evidence-first-review/SKILL.md) | When an agent says done: evidence first, what checks miss, silent decisions |
+| | [`review-capacity-check`](stacks/ronny/skills/review-capacity-check/SKILL.md) | Don't launch more agents than we can stand behind |
+| | [`taste-to-checks`](stacks/ronny/skills/taste-to-checks/SKILL.md) | Turn a repeat correction into a test, lint, hook or CI step |
 | | [`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/).

README_ZH.md

@@ -112,6 +112,10 @@ MiniMax Code 会自动发现这几个目录里的 Skill（每个 Skill 一个子
 | | [`engineering-review-feedback`](stacks/ronny/skills/engineering-review-feedback/SKILL.md) | 作为作者处理 review 意见：改代码、补说明、化解分歧 |
 | 实验与紧急修复 | [`harness-experiment`](stacks/ronny/skills/harness-experiment/SKILL.md) | 小 eval、一次只改一处、多跑几次、看哪些任务翻转了 |
 | | [`trajectory-review`](stacks/ronny/skills/trajectory-review/SKILL.md) | 不只看结果过没过，回头看 agent 是怎么得到这个结果的 |
+| 对 agent 的产出负责 | [`agent-brief`](stacks/ronny/skills/agent-brief/SKILL.md) | 交给 agent 之前：定风险高低，先写自己的猜测，用自己的话写清范围，事先说好怎样算验证过 |
+| | [`evidence-first-review`](stacks/ronny/skills/evidence-first-review/SKILL.md) | agent 说做完了：先看它跑过的命令和输出，再看总结；问清它默默做了哪些决定 |
+| | [`review-capacity-check`](stacks/ronny/skills/review-capacity-check/SKILL.md) | 再开一个会话之前，先看手上做完却还没人把关的活有多少 |
+| | [`taste-to-checks`](stacks/ronny/skills/taste-to-checks/SKILL.md) | 同样的意见提了两次，就写成测试、lint、hook 或 CI |
 | | [`engineering-emergency-changes`](stacks/ronny/skills/engineering-emergency-changes/SKILL.md) | 判断 hotfix 是不是真紧急，紧急时怎么快审又不丢质量 |
 
 上表是 [`stacks/ronny`](stacks/ronny/) 的内容。[`stacks/jiachen`](stacks/jiachen/) 里还有：[`lifting-loops`](stacks/jiachen/skills/lifting-loops/SKILL.md) 找出你总在给 agent 当「人工环节」的那些循环，帮你从里面抽身；[`making-content`](stacks/jiachen/skills/making-content/SKILL.md) 把笔记和素材做成小红书图文和竖版短视频。

stacks/ronny/.claude-plugin/plugin.json

@@ -1,8 +1,8 @@
 {
   "name": "ronny",
   "displayName": "Ronny's MCode Stack",
-  "version": "0.2.5",
-  "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.",
+  "version": "0.3.1",
+  "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, agent briefs, evidence-first review of agent output, review capacity and turning repeat corrections into checks, plus everyday engineering practice for code review, review comments, small PRs, change descriptions and emergency changes.",
   "author": {
     "name": "Ronny (MiniMax Code team)"
   },

stacks/ronny/.codex-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "ronny",
-  "version": "0.2.5",
-  "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.",
+  "version": "0.3.1",
+  "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, agent briefs, evidence-first review of agent output, review capacity and turning repeat corrections into checks, plus everyday engineering practice for code review, review comments, small PRs, change descriptions and emergency changes.",
   "author": {
     "name": "Ronny (MiniMax Code team)"
   },
@@ -11,7 +11,7 @@
   "interface": {
     "displayName": "Ronny's MCode Stack",
     "shortDescription": "Daily workflows and self-check skills from the MiniMax Code R&D lead.",
-    "longDescription": "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.",
+    "longDescription": "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, agent briefs, evidence-first review of agent output, review capacity and turning repeat corrections into checks, plus everyday engineering practice for code review, review comments, small PRs, change descriptions and emergency changes.",
     "developerName": "Ronny (MiniMax Code team)",
     "category": "Developer Tools",
     "capabilities": [

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

@@ -1,9 +1,9 @@
 {
   "schemaVersion": 1,
   "name": "ronny",
-  "version": "0.2.5",
+  "version": "0.3.1",
   "displayName": "Ronny's MCode Stack",
-  "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.",
+  "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, agent briefs, evidence-first review of agent output, review capacity and turning repeat corrections into checks, plus everyday engineering practice for code review, review comments, small PRs, change descriptions and emergency changes.",
   "author": "Ronny (MiniMax Code team)",
   "icon": "icon.png",
   "category": "Code",
@@ -24,6 +24,10 @@
     "skills/long-command-check/SKILL.md",
     "skills/context-tax-audit/SKILL.md",
     "skills/trajectory-review/SKILL.md",
+    "skills/agent-brief/SKILL.md",
+    "skills/evidence-first-review/SKILL.md",
+    "skills/review-capacity-check/SKILL.md",
+    "skills/taste-to-checks/SKILL.md",
     "skills/engineering-change-descriptions/SKILL.md",
     "skills/engineering-code-review/SKILL.md",
     "skills/engineering-emergency-changes/SKILL.md",

stacks/ronny/README.md

@@ -49,6 +49,10 @@ shown by `mcode plugin marketplace list`, or copy single skills into
 | [`long-command-check`](skills/long-command-check/SKILL.md) | Ten-point audit of how an agent runs long shell commands and background tasks | 04 |
 | [`context-tax-audit`](skills/context-tax-audit/SKILL.md) | Inventory what is injected into every request and how it affects the prompt cache | 05 |
 | [`trajectory-review`](skills/trajectory-review/SKILL.md) | Review how the agent got its result, not only whether it passed | - |
+| [`agent-brief`](skills/agent-brief/SKILL.md) | Before delegating: stakes, our own hypothesis, scope in our words, what "verified" means, and the mode | - |
+| [`evidence-first-review`](skills/evidence-first-review/SKILL.md) | When an agent says done: evidence before summary, what each check misses, its silent decisions, try to break it | - |
+| [`review-capacity-check`](skills/review-capacity-check/SKILL.md) | Before launching more sessions: is finished work piling up faster than we can stand behind it | - |
+| [`taste-to-checks`](skills/taste-to-checks/SKILL.md) | Turn a correction we keep making into a test, lint, hook or CI step, proven on the old mistake | - |
 
 ### Engineering practice
 

stacks/ronny/WORKFLOW.md

@@ -5,8 +5,12 @@ Which skill in [`skills/`](skills/) fits which moment of the day:
 | Moment in the day | Skill |
 | --- | --- |
 | Before splitting work across agents | `subagent-split-check` |
+| Before handing a task to an agent | `agent-brief` |
+| Before launching another parallel session | `review-capacity-check` |
 | Before opening a large change | `engineering-small-prs`, `engineering-change-descriptions` |
 | After the agent finishes a change | `independent-review` |
+| When an agent reports done | `evidence-first-review` |
+| When the same correction comes up twice | `taste-to-checks` |
 | Reviewing someone else's PR | `engineering-code-review`, `engineering-review-comments` |
 | Answering review on your own PR | `engineering-review-feedback` |
 | When a hotfix claims to be urgent | `engineering-emergency-changes` |

stacks/ronny/plugin.json

@@ -1,8 +1,8 @@
 {
   "$schema": "https://agent-plugins.org/schemas/1.0.0/plugin.schema.json",
   "name": "ronny",
-  "version": "0.2.5",
-  "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.",
+  "version": "0.3.1",
+  "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, agent briefs, evidence-first review of agent output, review capacity and turning repeat corrections into checks, plus everyday engineering practice for code review, review comments, small PRs, change descriptions and emergency changes.",
   "author": {
     "name": "Ronny (MiniMax Code team)"
   },

stacks/ronny/skills/agent-brief/SKILL.md

@@ -0,0 +1,80 @@
+---
+name: agent-brief
+description: Write the brief before handing a non-trivial task to an agent or subagent, covering stakes, your own hypothesis, goal and scope in your words, what "verified" will mean, and whether the agent is thinking with you or for you. Use before starting a MiniMax Code session, spawning a subagent, or delegating a PR, analysis or doc.
+---
+
+# Agent Brief
+
+We delegate a lot. What we try not to delegate is knowing what we asked for.
+If we cannot write the task down in a few plain lines, the idea is not ready,
+and the agent will fill the gaps with defaults we never chose. Five minutes
+here saves a review that cannot tell right from plausible.
+
+## 1. Set the stakes
+
+Decide how much of this skill to run.
+
+- **Cheap to be wrong**: a throwaway script, a rename, formatting, a local
+  experiment we will delete. Hand it off and skip the rest.
+- **Someone else lives with it**: code that ships, a change to the harness,
+  anything touching users, money, permissions or data, a number that goes into
+  a decision. Run every step, and plan to use `evidence-first-review` after.
+
+When unsure, ask: if this is quietly wrong, who finds out, and when?
+
+## 2. Write a hypothesis first
+
+One line on what we expect the answer or the fix to be, written before the
+agent starts. A wrong guess is fine. Its job is to give us something to compare
+against, so a polished answer does not become the default.
+
+> Hypothesis: the flaky `compaction.e2e` test is a race between the summary
+> write and the next turn, not a model issue.
+
+## 3. Brief in our own words
+
+- **Goal**: the outcome, not the steps.
+- **Who uses it**: a reviewer, a user, another agent.
+- **Out of scope**: what it must not touch (public API, lockfile, other packages).
+- **Constraints**: versions, style, files it may edit, commands it may run.
+
+If we get stuck writing this, we ask the agent to interview us first, or give it
+what we know and ask what we have not thought of. We do not ask it to write the
+brief for us.
+
+## 4. Define "verified" before seeing output
+
+Pick something we can check later, decided now so we cannot bend it to fit
+whatever comes back:
+
+- a named test passes, and a new test fails on the old code;
+- a command and its expected output (`mcode -p "..." --json` returns X);
+- a screenshot or log line from the real app;
+- a number recomputed from the source data.
+
+Give the agent the same means to check itself (test command, fixture, a running
+dev server), so it loops before we look.
+
+## 5. Name the mode
+
+Are we asking it to help us think, or to think for us? Both are fine. In the
+second case, we owe a stricter review, because we will not have the reasoning in
+our heads.
+
+## Card
+
+Paste this at the top of the task:
+
+```text
+Stakes: low | high
+Hypothesis: ...
+Goal / users / out of scope: ...
+Done = (tangible check): ...
+Mode: think with me | do it for me
+When done: show commands run and their output first, then the summary,
+then the decisions and assumptions you made.
+```
+
+## References
+
+- Addy Osmani, ["Critical thinking when agents do the work"](https://x.com/addyosmani/status/2117512471930167377)

stacks/ronny/skills/evidence-first-review/SKILL.md

@@ -0,0 +1,73 @@
+---
+name: evidence-first-review
+description: Review an agent's finished work by reading the evidence before its summary, naming what each check proves and what it misses, pulling out the decisions it made silently, and trying to falsify the result before accepting it. Use when a MiniMax Code session, subagent or cloud agent reports a task done, before merging its PR or acting on its analysis.
+---
+
+# Evidence-First Review
+
+"All tests pass, ready to merge" is a claim, not evidence. We read what the
+agent actually ran before we read what it says about it. The bar for accepting
+the work: we could defend it to the person who will maintain it, and we can
+say what our checks would miss.
+
+This skill is about owning the result. For a clean-context code review of the
+diff itself, pair it with `independent-review`.
+
+## 1. Evidence before summary
+
+Open the transcript or tool log, not the final message. For each command that
+supports "done": did it run on the final code, did it exit 0, does the output
+say what the summary says? Typical gaps we find:
+
+- tests run before the last edit;
+- a filter like `-t compaction` that skipped the suite that matters;
+- "fixed" with no reproduction before the fix;
+- a build that passed only because a step was skipped.
+
+## 2. For each green check, one property it proves and one it does not
+
+| Check | Proves | Does not prove |
+| --- | --- | --- |
+| New unit test passes | the function returns X for this input | the caller passes that input; the test was written with the same wrong assumption |
+| `pnpm typecheck` | types line up | runtime behaviour |
+| E2E with a mock model | the loop wires up | anything about real model output |
+
+If we cannot fill the right column, we do not understand the check yet.
+
+## 3. Ask for the decisions list
+
+Ask the agent: which defaults did you pick, what did you leave out of scope,
+and where did you reinterpret the requirement because two parts clashed? These
+are the choices that end up in production without anyone deciding them. Each one
+is accepted, changed or sent back.
+
+## 4. Try to break it
+
+Ask: what would have to be true for this to be wrong? Then check that one thing
+ourselves. For analysis and docs, open two of the cited sources and recompute
+one number the conclusion depends on.
+
+## 5. Make sure we understand it
+
+- Pick a few lines of the diff at random and explain them without help.
+- For a large change, ask the agent for a short report that ends in three
+  questions about the change; we answer them before merging.
+- For a contested call, have a fresh subagent argue the other side, then
+  decide ourselves.
+- Last question to a fresh context: "What did I miss?"
+
+## 6. Decide
+
+- **Accept**: the evidence matches, decisions are reviewed, we can name the gap.
+- **Ask for more**: missing evidence or an unexplained decision.
+- **Get a human review**: high stakes and we cannot say what the checks miss.
+
+## Output
+
+When we report the work to others, we lead with the evidence (commands and
+results), then: what was checked, one thing that was not, and the key
+decisions.
+
+## References
+
+- Addy Osmani, ["Critical thinking when agents do the work"](https://x.com/addyosmani/status/2117512471930167377)