All authors
Claude Skills by MiniMax-AI
github.com/MiniMax-AI28 skills0 installs0 views
- Lifting LoopsFinds loops where the user keeps acting as a manual step for agents (retrying, judging output, approving, carrying context, starting the same task by hand, doing the agent's work) and proposes how to lift the user out: delete a stale rule, change a skill / AGENTS.md / playbook, add a script or metric, add a skill or scheduled task, or advise the user. Keeps a private loop ledger and promotes Claude Code auto-memory into artifacts. With a task already in the session, reflects on that session; ...Votes: 0GitHub stars: 544
- Making ContentContent production in three modes: rewrite, Xiaohongshu (小红书) image post, short video. Rewrite (default): turns an AI-sounding Chinese or mixed Chinese-English draft (post, newsletter, engineering blog, commentary) into the author's restrained style: few emoji, short paragraphs, hedged claims, neutral wording, English terms split by spaces. Triggers: 按我的风格改, 去 AI 味, 润色, 改改这篇, or a vague 帮我改改 when the context is a structured draft. Also for a Xiaohongshu image post from scratch (title, cover, ...Votes: 0GitHub stars: 544
- Req Design为已排期的需求做方案：列至少两个选项、写决策记录、评估波及面（blast radius）、定验收检查点，全部落进需求文档。Use when a requirement is scheduled and before implementation, or when someone asks 方案怎么定 / 这个改动会影响哪些地方.Votes: 0GitHub stars: 544
- Req Intake在需求刚提出时，先挑战它是否该做，写下一条能验证的预期效果，再用模板建飞书需求文档和飞书项目（Meegle）工作项，两边互相链接。Use when someone raises a product or technical requirement, says 提需求 / 我想要 / 能不能加, or before any requirement work starts without a doc and a work item.Votes: 0GitHub stars: 544
- Req Outcome上线后对照 intake 写下的预期效果收集证据，判断是否达成；没达成就写清差距和下一步；只有拿到证据才关闭需求。Use after the observation window of a shipped requirement, when someone asks 这个需求效果怎么样 / 可以关了吗, or before closing a work item.Votes: 0GitHub stars: 544
- Req Prioritize对一个已受理的需求，对照当前在做的工作（WIP）评估成本、影响、风险，给出排期建议和理由；提出人提建议，负责人拍板。Use after req-intake, at backlog grooming or sprint planning, or when someone asks 这个需求优先级多高 / 能不能插队.Votes: 0GitHub stars: 544
- Req Ship上线前做就绪检查（回滚方案、可观测性、完成定义 DoD），全部有证据后再推进 Meegle 状态或节点。Use before a requirement is deployed or marked done, when someone says 可以上线了吗 / 准备发布, or before transitioning the work item to a released state.Votes: 0GitHub stars: 544
- Req Track按固定节奏跟进进行中的需求，用站会格式记录进展、阻塞和下一步；超过约定时间没有更新的需求要显式标出来，不能悄悄沉下去。Use for daily or weekly requirement check-ins, when asked 这个需求到哪了 / 有没有卡住的, or from a scheduled routine.Votes: 0GitHub stars: 544
- Agent BriefWrite 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.Votes: 0GitHub stars: 544
- Context Tax AuditInventory 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.Votes: 0GitHub stars: 544
- Engineering Change DescriptionsUse 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.Votes: 0GitHub stars: 544
- Engineering Code ReviewUse 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.Votes: 0GitHub stars: 544
- Engineering Emergency ChangesUse 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.Votes: 0GitHub stars: 544
- Engineering Review CommentsUse 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.Votes: 0GitHub stars: 544
- Engineering Review FeedbackUse 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.Votes: 0GitHub stars: 544
- Engineering Small PrsUse 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.Votes: 0GitHub stars: 544
- Evidence First ReviewReview 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.Votes: 0GitHub stars: 544
- Handoff DocWrite 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.Votes: 0GitHub stars: 544
- Harness ExperimentRun 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.Votes: 0GitHub stars: 544
- Independent ReviewReview 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.Votes: 0GitHub stars: 544
- Long Command CheckAudit 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.Votes: 0GitHub stars: 544
- Long Session CheckCheck 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.Votes: 0GitHub stars: 544
- Review Capacity CheckCheck whether finished agent work is piling up faster than we can stand behind it, and fix that by tightening automatic checks or running fewer parallel sessions instead of starting another one. Also checks that multi-agent chains read original sources, and which skills we are letting go. Use before launching another parallel session or subagent batch, at the end of a day with many agent PRs, or in a weekly review.Votes: 0GitHub stars: 544
- Subagent Split CheckDecide 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.Votes: 0GitHub stars: 544
- Taste To ChecksTurn a review correction we keep making on agent output into something that runs on its own, a test, lint rule, hook, CI step or project rule, so the miss does not come back next session. Use when we keep correcting agents on the same mistake (import order, naming, a forbidden API, a missing test), when the same review comment shows up on a second PR, or after a review finds a miss that a check could have caught.Votes: 0GitHub stars: 544
- Tool Budget AuditAudit 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.Votes: 0GitHub stars: 544
- Trajectory ReviewReview 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.Votes: 0GitHub stars: 544
- ExampleReplace with one sentence on what this skill does, then when the agent should use it. The agent decides whether to load the skill from this line, so be specific.Votes: 0GitHub stars: 544