القائمة
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.
التثبيت باستخدام 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 | spike |
| description | 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. |
Tight feedback loops beat big plans when the path is unclear (~/.mastermind/engineering/core/agent-loop.md, mindset.md →
design it twice). A spike buys knowledge cheaply — as long as you don't mistake it for the product.
Time-box: 5 build-and-run attempts, roughly 30 minutes — one question needs a handful of tries, not a day; proportionality over ceremony. An attempt is one edit → run → observe cycle against the named question; count them out loud as you go, so the box is observable and not a vibe. Attempt 5 finished without an answer = the box is spent, whatever the clock says.
When it expires, stop — that's a result, not a failure. Report: what you learned, what is still unknown, and one recommendation — proceed (answer is yes, build it properly) / different approach (this path is wrong, here's the next one) / needs more investigation (name what a second spike would target). Then discard the code: it stays throwaway and does not ship, same as a spike that succeeded.
Extending the box is a decision, not drift. Only extend when the attempts narrowed the question rather than wandering — say so explicitly, state the new bound (e.g. "3 more attempts"), and stop there.
Keep it isolated (a scratch branch/dir) so it can't leak into production. The deliverable is the learning, not the code.
The answer to the question + the surprises, and a clear "now build it properly" recommendation (or a "don't build it — here's why").
