mastermind

Plugin mastermind from marketplace mastermind in mehrad-dm/mastermind. Commands read from the repo's manifest — 1 month ago.

Skills (32)

• analyze

  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 da

• assess

  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 fea

• blueprint

  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 `s

• breakdown

  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

• checklist

  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 t

• clarify

  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 yo

• constitution

  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 proj

• converge

  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,

• debug

  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.

• deepen

  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 c

• deprecate

  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 nee

• double-check

  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 t

• explain

  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.

• handoff

  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

• help

  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.

• init

  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.

• interview

  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 P

• learn

  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.

• levelup

  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\", \"leve

• lint

  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 approv

• living-docs

  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, jo

• performance

  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.

• persona

  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` (qu

• prompt

  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 A

• prototype

  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.

• qa

  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.

• quarantine

  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\",

• report

  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

• roadmap

  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 o

• route

  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.

• signature

  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 n

• specify

  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 tou

Subagents (4)

• architect

  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

• code-reviewer

  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

• refactorer

  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

• tech-scout

  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

Hooks (1)

• SessionStart

  "${CLAUDE_PLUGIN_ROOT}/hooks/session-start.sh"

Similar plugins