mastermind plugin

No description in the file.

No description in the file.

No description in the file.

No description in the file.

Designs the solution BEFORE code is written, module/API boundaries, data model, state, contracts, and tech decisions, for whatever field is active (frontend, backend, mobile…). Use for any non-trivial feature, new module, or architectural choice. Returns a concrete design + one-line rationale per de

Reviews a diff, a file, or a whole area against MasterMind's principles and rigor gate: correctness, security, edge cases, types, architecture, stack defaults, the field's audit rules. Use after a non-trivial change, before committing, or to audit code you didn't just write. Returns ranked findings

Restructures working code toward better design WITHOUT changing behavior: deeper modules, a cleaner data model, illegal states made unrepresentable, tangled dependencies unpicked. Use to pay down design/architectural debt on code that already works. Distinct from code-reviewer (finds problems, doesn

Makes a technical ADOPTION decision, \"should we use library/tool/pattern X (vs Y, vs build it)?\": evaluated against MasterMind's reuse-with-judgment rubric and returned as a clear verdict with trade-offs. Use when choosing a dependency, framework, or approach. Distinct from /deep-research (broad r

Use when a feature's spec, plan and task list all exist and need checking against each other before code is written: "check the spec and plan agree", "is this ready to build?", "find gaps before we start", "analyze the feature docs", or before building anything that touches money, auth or data from a task list. Not for checking code against intent after building (that's `converge`), not for analyzing code, performance or a bug.

Use when someone wants to know whether an idea deserves building before anyone builds it: "is this worth doing?", "should we build X?", "evaluate this idea", "would users actually want this?", "help me decide whether to invest in this", a product or business idea with no code yet, or a feature request nobody has said yes to. Not for scoping something already decided (that's `interview` or `specify`), not for adopt-vs-build on a library (that's `tech-scout`).

Use when a written feature spec needs its technical plan: "plan this spec", "how should we build this spec?", "make the technical plan for this feature", a spec in specs/ with no plan.md yet, or a plan that a spec or constitution change has made stale. Not for a feature with no spec (that's `specify`, or `build` for a small one), not for one design question outside any feature (that's the `architect` agent).

Use when a feature with a spec and a plan needs its ordered task list: "break this into tasks", "make the task list", "what are the steps to build this?", "generate tasks.md", a feature folder with plan.md and no tasks.md, or a task list made stale by a spec or plan change. Not for a feature with no plan (that's `blueprint`), not for one session's to-do list.

No description in the file.

Use when a feature's requirements need testing for one concern before planning or building: "make a security checklist for this spec", "are the UX requirements complete?", "review the API requirements", "what did the spec forget about accessibility?", "give me a requirements checklist for this feature", "does our spec cover abuse or partial failure?", a spec that looks thin on one area such as security, access rules or error recovery, or a sensitive feature heading into `blueprint` or `build`. Not for testing code or QA steps (that's `qa`), not for checking documents against each other (that's `analyze`).

Use the moment the user signals your last answer did not land: "I did not follow that", "I don't understand", "say it simply", "simpler please", "more simply", "you lost me", "what does that mean", "too long", "explain again", "show me", a confused question repeating something you already answered. Re-pitch what you just said, in plain words or as a picture. Not for a new question, and not for documenting a package: that is explain.

Use when a project needs rules every feature must obey, or those rules change: "set up our principles", "write a constitution", "these are our non-negotiables", "from now on every feature must...", "we never allow X in this codebase", "amend the rules", starting spec-first work on a project with no specs/constitution.md. Not for MasterMind's own engineering defaults, and not for one feature's requirements (that's `specify`).

Use after building a feature from a task list, to find out whether the code actually does what its spec, plan and constitution say: "is this feature really done?", "check the code against the spec", "what's still missing?", "did we build everything we planned?", every box in tasks.md ticked, or before calling a spec-driven feature done. Not before code exists (that's `analyze`), not for a single claim (that's `double-check`), not for running the thing end to end (that's `qa`).

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 the user wants to know where the design is hurting, before choosing what to fix: "this is getting messy", "where should we clean up?", "what is the worst part of this codebase?", "why is this so hard to change?", "it takes five files to add one field". Surveys an area, ranks the candidates, and the user picks one. Not for a diff you just wrote: that is code-reviewer. Not for executing a chosen restructure: that is the refactorer agent.

Use when something has to be removed or retired, a feature, endpoint, table column, config key, feature flag, package or whole service; migrating consumers off an old API or version; code that looks dead but might not be. Symptoms: "can we delete this?", "is anything still using this?", "we need everyone off v1", "kill the old one". Not for restructuring that keeps the interface: that's the `refactorer` agent.

Use when you are about to tell the user something works, hand over a decision you feel confident about, or make a change that can't be undone: and when a review came back suspiciously clean. Symptoms: "are you sure?", "you said that was fixed last time", nothing to report, the answer feels too tidy. Not for a routine small change; not for reviewing a finished diff: that's `code-reviewer`; not for driving a finished change end-to-end to get evidence: that's `qa`. Doubt tests a claim (a diagnosis, a design call, an answer), which is often not runnable code.

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, when the context window is filling up on multi-day work, or when a long multi-step task starts re-covering ground it already finished. Not the project's decision history across weeks: that's `roadmap`.

Use when the user asks what MasterMind can do or how to drive it: "help", "what can you do", "how do I use this", "what commands are there", "list your skills", "what are my options": or when they seem unsure how to get started.

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 when the ask is ambiguous, the scope is unclear, terms are being used inconsistently, the work spans multiple files, or it will be handed to another session: and whenever the user wants to be interviewed about it: "interview me", "ask me what you need", "question me on this", "tear this PRD/spec/plan apart", "what would kill this?", "resolve the open questions in the spec". Also when a spec in specs/ still carries [NEEDS CLARIFICATION] markers, or is about to be planned. Symptoms: "make it better", "add the thing", or disagreement about what's in scope. Skip for a clear one-line change.

Use when a task depends on tech you don't actually know, an unfamiliar library, a fast-moving framework, a tricky API, an unfamiliar codebase: or whenever "I think it works like…" is load-bearing. Just-in-time and task-scoped; distinct from levelup, which updates the durable knowledge base.

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", "so you don't repeat it", "don't make that mistake again", "level up", "update your knowledge".

Use to check MasterMind's own instruction files, the kernel, core, skills and agents: for bloat, repeated rules, and contradictions between layers. Fires before a release, after several skills changed, or when the brain feels bloated or self-contradictory. Reports findings with file:line; you approve every change. This lints MasterMind itself, never your project's code: for that, use refactorer.

Use when the project's product, business or technical knowledge needs a home or has gone stale: "document what this product is", "write down how the business works", "where is the source of truth for X?", "how is this codebase built?", "our docs are out of date", starting a new product, joining an existing codebase with no docs, or after a feature converges and what it taught must outlive it. Not usage docs for one internal package (that's `explain`), not the decision history (that's `roadmap`).

Use when something is slow, "why is this slow", "optimize this", "make it faster", jank, lag, a slow query, slow page load, slow render, slow build, high memory, a timeout. Not for correctness bugs; that's debug.

Use when the user wants code written in the documented public style of a named engineer they admire: "write this like Dan Abramov", "make it read like Kent C. Dodds", "in the style of that OSS author". For a public figure with a real body of work; a private colleague's style is `signature` (quarantine-gated). A lens on taste, never impersonation.

Use ONLY when the user explicitly asks to improve a prompt aimed at an AI: "improve my prompt", "fix this prompt", "how should I ask for this", "make this prompt better". A prompt pasted to be answered or executed is a task, not a rewrite request: do that task instead. About prompts for an AI, not about optimizing code.

Use when the right approach is genuinely unknown and reality will teach faster than planning: a risky unvalidated assumption, an unfamiliar integration, "will this even work", "try something quick". The result is explicitly throwaway and does not ship.

Use after finishing a feature or fix to confirm it actually works, when the user says "test this", "does it work", "verify this", "QA it", or before shipping something that has never been driven end-to-end. Also when the user asks for tests to be written or wants to work test-first.

Use whenever secrets or confidential material must be kept out of git: API keys, tokens, credentials, a client's internal patterns, private project data, real names, proprietary code. Triggers: "these keys must never end up in a commit", "make sure this never gets pushed", "this is sensitive", "don't commit this", "set up the lab", or any request to guard against leaking secrets. Also when a `lab/` folder already exists but its guards are missing or broken. (The quarantine lives on disk as `lab/`: the name existing projects already have.)

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.

Use when work spans weeks and the reasoning behind it is piling up: returning to a project after time away, "why did we decide X?", "where did we land on this?", "what's still open?", onboarding someone onto a long-running build, or a choice everyone remembers making and nobody can find. Not one session's state (that's `handoff`), not scoping one feature (that's `interview`).

Use at the start of a task that spans multiple files, touches unfamiliar areas of a codebase, or where it isn't obvious what to load or where to begin. Skips itself for a one-line change or an already-scoped task.

Use when code should match a team's real code style and conventions the user keeps correcting the AI toward: "make it match our codebase", "follow our patterns", "you keep writing it wrong": or when repeated corrections should become durable rules. Private, quarantine-gated. For writing in a named public engineer's style, use `persona`.

Use when a feature is going to be built spec-first and needs its specification written or revised: "write the spec for X", "spec this feature", "start a new feature: ...", "turn this idea into requirements", an assessed idea that got a go, or any feature that spans sessions or people, or touches money, auth, data migration or a public contract. Not for a small clear change (that's `build`), and not for questioning a fuzzy ask before anything is written (that's `interview`).

startup|clear|compact