minimax-ai/ronny
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.
Inventory everything an agent injects into each request besides the user's message, such as system prompt, environment info, skill list, tool definitions, per-turn context blocks and reminders, and check necessity, frequency, precision, position and prompt-cache impact. Use when reviewing an agent's prompt assembly, chasing low cache hit rates, or trimming per-turn overhead.
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.
Use when reviewing code, pull requests, patches, CLs, diffs, or proposed implementations for engineering quality, code health, design, functionality, tests, maintainability, specialist risk, or approval risk. TRIGGER on "review this PR", "code review", "LGTM?", "approve?", "is this code/diff/change safe to merge/deploy?", and local diff reviews. DO NOT TRIGGER for PR descriptions, PR splitting, author review-feedback responses, or non-code safety questions unless code review is requested.
Use when a code hotfix, rollback alternative, production/security/legal fix, launch blocker, or hard external deadline claims expedited review or relaxed process. TRIGGER on "emergency change", "hotfix", "prod incident", "major security hole", "must ship today", "hard deadline", "bypass review", or "fast-track this PR" for qualification only. DO NOT TRIGGER for ordinary urgency, soft deadlines, Friday timing, manager pressure, time-zone delay, or review unless emergency status is disputed.
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.
Use when handling code review feedback as the change author, addressing reviewer comments, drafting replies, resolving disagreements, or summarizing updates. TRIGGER on "address review feedback", "respond to this review comment", "reviewer asked", "I disagree with reviewer", "what should I reply?", or "apply PR comments". If role is unclear, ask reviewer or author. DO NOT TRIGGER for reviewer comment writing, full code review, or PR descriptions unless author-response behavior is requested.
Use when planning, splitting, shrinking, or sequencing large features, refactors, migrations, or pull requests into small reviewable PRs or CLs. TRIGGER on "split this PR", "this diff is too large", "stacked PRs", "change sequence", "reviewable chunks", "migration plan", "how should I break this up?", or implementation scope too broad for one review. DO NOT TRIGGER for full code review, PR description writing, or tiny one-file edits that already form one self-contained change.
Write a hand-off document so a fresh session or another person can continue the current task without the chat history. Use when switching tasks, after several compactions, before clearing a session, or when asked to write a handoff, brief, or progress doc.
Run a harness change as a controlled experiment, with a small end-to-end eval, one change at a time, repeated runs, and looking at flipped tasks, request count, tokens and cache hits, not just the average score. Use before and after changing prompts, tools, skills, subagent layout, compaction or other agent scaffolding, or when asked whether a change helped.
Review a code change from a clean context, the way an outside reviewer would. Use after the agent finishes an implementation, before merging, or when asked for an independent or second-opinion review of a diff.
Audit how an agent harness runs long shell commands, covering foreground wait limits, moving to background without re-running, timeouts, completion notification, polling, output size, cleanup and behaviour after compaction. Use when building or reviewing an agent's shell or background-task tool, or when an agent hangs on dev servers, long builds or test runs.
Check how an agent or a working session handles long conversations, covering tool-result clearing, compaction, what gets written to files, when to start a new session, and how memory is scoped. Use when a long session starts forgetting constraints, after several compactions, or when reviewing an agent's compaction and memory design.
Decide whether a piece of work should go to a subagent or stay in the main agent loop. Use before spawning subagents, when designing a multi-agent architecture, or when auditing an existing set of subagents for merging back.
Audit how much context an agent's tools consume, through tool definitions and tool results, and decide whether to trim the catalog, add tool search, or add programmatic tool calling. Use when an agent has many tools or MCP servers, picks the wrong tools, or burns context on tool output.
Review how an agent reached its result, not only whether the result passed, covering tools called, detours, unverified assumptions and wasted round trips, and turn the findings into concrete harness or prompt fixes. Use after an agent task finishes or fails, when an eval task flips, or when asked to look at the process behind a result.