All authors
Claude Skills by mehrad-dm
github.com/mehrad-dm33 skills0 installs20 views
- AnalyzeUse 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.Votes: 0GitHub stars: 23
- AssessUse 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`).Votes: 0GitHub stars: 23
- BlueprintUse 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).Votes: 0GitHub stars: 23
- BreakdownUse 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.Votes: 0GitHub stars: 23
- BuildUse 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: including small features, which still need verifying before \"done\". Only a literal one-line edit skips this.Votes: 0GitHub stars: 23
- ChecklistUse 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...Votes: 0GitHub stars: 23
- ClarifyUse 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.Votes: 0GitHub stars: 23
- ConstitutionUse 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`).Votes: 0GitHub stars: 23
- ConvergeUse 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`).Votes: 0GitHub stars: 23
- DebugUse 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.Votes: 0GitHub stars: 23
- DeepenUse 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.Votes: 0GitHub stars: 23
- DeprecateUse 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.Votes: 0GitHub stars: 23
- Double CheckUse 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 dia...Votes: 0GitHub stars: 23
- ExplainUse 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.Votes: 0GitHub stars: 23
- HandoffUse 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`.Votes: 0GitHub stars: 23
- HelpUse 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.Votes: 0GitHub stars: 23
- InitUse 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.Votes: 0GitHub stars: 23
- InterviewUse 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. Sympt...Votes: 0GitHub stars: 23
- LearnUse 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.Votes: 0GitHub stars: 23
- LevelupUse 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\".Votes: 0GitHub stars: 23
- LintUse 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.Votes: 0GitHub stars: 23
- Living DocsUse 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'...Votes: 0GitHub stars: 23
- PerformanceUse 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.Votes: 0GitHub stars: 23
- PersonaUse 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.Votes: 0GitHub stars: 23
- PromptUse 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.Votes: 0GitHub stars: 23
- PrototypeUse 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.Votes: 0GitHub stars: 23
- QaUse 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.Votes: 0GitHub stars: 23
- QuarantineUse 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 ...Votes: 0GitHub stars: 23
- ReportUse 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.Votes: 0GitHub stars: 23
- RoadmapUse 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`).Votes: 0GitHub stars: 23
- RouteUse 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.Votes: 0GitHub stars: 23
- SignatureUse 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`.Votes: 0GitHub stars: 23
- SpecifyUse 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`).Votes: 0GitHub stars: 23