菜单
Use when the user asks for a written record of what was done — "write it up", "give me a report", "summarize what you changed", "document this cycle" — or at the end of a build/QA cycle ONLY if the project's cycle-report preference is on. Off by default: never produce one unprompted, and skip it for a one-line change.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use on the first substantive work in a project MasterMind isn't set up for yet, when the user says "init", "initialize", "set up MasterMind", "onboard", "get me ready", or when no field pack matches the project's detected stack.
Use after a correction or review finding worth remembering, when standards may have drifted from the live ecosystem, when switching MasterMind to a new domain or stack, or when the user says "remember this", "learn from that", "level up", "update your knowledge".
Use when implementing any non-trivial feature, change, or fix — "build me X", "add this feature", "implement this", "make this work", "can you create". Covers new functionality, meaningful changes to existing code, and anything where quality matters. Not for a one-line diff — just do that.
Use when a bug isn't obvious, resists a quick fix, keeps coming back, or you're about to start guessing — "why is this broken", "this keeps happening", intermittent or flaky failures, a crash you can't explain, behaviour that makes no sense. Not for a typo or an obvious mistake.
Use when an internal package, module, or shared component has little or no usage documentation and people (or future AI sessions) keep using it wrong — "document this", "write docs for our library", onboarding someone onto an internal API, or handing a package to another team.
Use when work needs to survive losing context — before a /clear on a long task, when pausing something unfinished, when handing over to a teammate or the next session, or when the context window is filling up on multi-day work.
| name | report |
| description | Use when the user asks for a written record of what was done — "write it up", "give me a report", "summarize what you changed", "document this cycle" — or at the end of a build/QA cycle ONLY if the project's cycle-report preference is on. Off by default: never produce one unprompted, and skip it for a one-line change. |
Turn a completed cycle into a concise, skimmable record someone can read without re-reading the diff. It's the same content as the in-chat verdict, made durable and shareable.
build / qa only if the project preference says so (below).
Default is off — never auto-generate otherwise.Read .mastermind/prefs.md in the project root for a cycle-report: line — one of:
off (default, and the assumption if the file/key is missing) — never auto-report.ask — at the end of a report-worthy cycle, offer once: "want a report? markdown / html / no".markdown — always write a Markdown report.html — always write a self-contained HTML report.The init skill sets this once, at the first task. The user can change it anytime ("reports off",
"always give me html reports") — update the line in .mastermind/prefs.md to match.
Keep it tight — a bloated report gets ignored (same rule as the brain: signal density beats volume).
.mastermind/reports/<slug>-<YYYY-MM-DD>.md (use today's date), or a
path the user names. Cheap, diffable, opens anywhere.cycle-report: html) — one self-contained file (inline CSS, no external
assets or scripts), lightly MasterMind-styled, so it opens in any browser. Costs more tokens.Tool-agnostic: always a plain file on disk — never rely on a tool-specific artifact surface.
An HTML report adds meaningful output tokens (~1.5–4k) vs Markdown (~0.4–1k); the in-chat verdict is ~free. Match effort to stakes: for a one-line change, skip the report entirely — offer nothing. Reserve it for cycles someone would actually want to read or share.