minecraft-modding-mcp

Use when the user explicitly asks for vibe brainstorming, creative implementation ideas, implicit expected behavior, or convention checks, and when an implementation task is creative or convention-dependent. Do not use for obvious mechanical edits.

Use when the user wants to understand, locate, trace, or assess existing code without changing it — questions like "how does X work", "where is Y implemented", "what would changing Z affect", architecture or data-flow mapping, dependency tracing, convention discovery, or pre-planning and pre-debugging evidence gathering. Do not use when a defect needs repair, a plan or spec artifact is requested, or an edit, commit, or diff review is the deliverable.

Use when the user explicitly invokes vibe-coding through a host-specific skill command, host-provided invocation signal, or direct instruction such as "use `vibe-coding`" for a coding workflow.

Use when the user asks to commit, stage, or "save" agent-assisted coding changes — including vague requests like "commit this", "commit please", "コミットして", or "/commit" — and the real work is deciding which files belong in the commit, excluding unwanted or generated files, splitting unrelated changes, or fixing a commit's file set, multi-line message transport, history (amend/rebase), or authorship trailers. This skill owns commit execution, message transport, and git safety.

Use when debugging or repairing existing features from rough agent-assisted coding reports, regressions, failed prior fixes, repeated "still broken" feedback, source-only debugging stalls, unobserved runtime state, tool or automation failures, environment-specific failures, runtime artifact mismatches, security boundary surprises, or fixes that feel wrong.

Use when the user asks to execute, implement, continue, or apply an existing implementation plan, specification, acceptance criteria, task plan, or prior planning output. Do not use for plan creation or coding requests with no concrete plan to bind.

Use when the user explicitly wants implementation planning before coding, asks to create or revise an implementation plan, supplies requirements with explicit approval evidence, a specification, acceptance criteria, or task list, or has inputs concrete enough to plan but not execute. Do not use for rough unapproved requirements drafting.

Use when a user wants to draft, revise, save, approve, or explicitly explore requirements for a rough, ambiguous, contradictory, creative, non-technical, or underspecified coding goal before implementation planning or coding, including explicit chat-only/no-file requirements exploration.

Use when the user asks for agent-assisted code review of a git diff, working tree, branch, base ref, git-backed plan or document change, or review/fix loop where scope triage, delegated reviewers, specification gaps, or cascade-safe fixes may matter.

Use when the primary task is writing, revising, reviewing, or critiquing agent-assisted coding development text, source-code comments or docstrings, README/docs, CHANGELOG/release notes, PR descriptions, UI copy, chat replies, progress updates, final summaries, or git commit messages, especially when text must be LLM-readable, meaning-preserving, format-bound, language-aware, or evidence-bound. Treat incidental wording inside another active workflow as auxiliary.

Use when the user asks to review, confirm, walk through, or pre-check a saved Markdown implementation plan before implementation; interactively reviews plan items one at a time and manages localized item-level decisions.