メニュー
Build an evidence-backed architecture briefing with `mastermind map` or `mmcg_map`. Use when exploring an unfamiliar repository, identifying components and entry points, choosing a reading order, inspecting dependency cycles or hotspots, or explaining codegraph precision and truncation limits.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Turn a design handoff into a task contract that can actually be checked — named source, resolved components, token names instead of raw values, and an explicit list of what stays unverifiable. Use when a Figma frame, mockup, or design spec is handed over for implementation.
Convert a PRD, ticket, or feature request into a task contract that can fail — behaviour split from outcome, product nouns resolved to symbols that exist, unspecified cases surfaced as questions, and success metrics parked where a merge gate cannot wave them through. Use when product writing is handed over for implementation.
Enumerate what a change can reach and what enforces it — privileged operations and their callers, guards and the sites that apply them, and every module that reads a secret — before designing an auth, permission, or secrets change. Feeds the security review; produces a population and a gap list, never a verdict.
Read-only review of whether the tests in a finished change actually prove its behaviour — changed code no test reaches, a test exercising a different path than the one that changed, an assertion edited to match the new output, and a suite that ran nothing. Use after implementation, and whenever a change claims to be covered.
Gather who already depends on a service, handler, or state owner before changing it, and name the runtime gaps the codegraph cannot span. Use before designing a change to an API, queue consumer, background job, migration, or shared state; it feeds the architecture review rather than replacing it.
Read-only review of a finished UI change against the codegraph — a component nothing renders, a props contract changed without its callers, a reinvented component, or a raw value where the design system has a token. Use after implementing React or Vue work; triggers "review this UI change", "check the component", or a finished frontend diff.
| name | mastermind-project-map |
| description | Build an evidence-backed architecture briefing with `mastermind map` or `mmcg_map`. Use when exploring an unfamiliar repository, identifying components and entry points, choosing a reading order, inspecting dependency cycles or hotspots, or explaining codegraph precision and truncation limits. |
| metadata | {"version":"0.2.0","authors":["mastermind"],"tags":["workflow","mmcg","architecture"]} |
Use the deterministic map as the source of claims. Do not reconstruct a map from filenames or model intuition when the backend is available.
Confirm the repository has a fresh index with mastermind status. If it is
absent or stale and the request permits local indexing, run
mastermind index . before mapping.
Choose the narrowest useful repository-relative scope. Use . only for a
repository-wide briefing.
Run JSON first:
mastermind map PATH --format json --depth 2 --top 20
Add --production-only for architecture work where tests, fixtures,
examples, generated output, vendored code, and dependency trees would
otherwise dominate the briefing. With MCP, pass production_only: true.
Use mmcg_map instead when MCP is the active interface. Treat both as the
same schema-v1 engine.
Check scope, every collection's truncated/truncation_reason, limits,
and precision_notes before interpreting results.
Produce a reading order: entry points first, then central symbols, component boundaries, and cycles. Cite repository-relative files and symbol lines.
Treat directory-derived components as navigation groups, not proven semantic
subsystems. Prefer the explicit production filter over manually ignoring
fixture/example/generated results. Keep those paths when the user is asking
about tests, examples, or packaging. De-prioritize high-collision symbol names.
A top_probe proves
only that more rows exist; do not imply the backend can return an uncapped full
list. Narrow the path or change top within its supported range instead.
Use text for a compact terminal briefing and Mermaid only when the user asks
for a diagram. Do not infer runtime entry points from a heuristic label.
Separate:
If the response is truncated, describe what is missing. If the command/tool is unavailable, report that the deterministic backend is missing; do not simulate its output.
Never emit absolute paths, claim dynamic dispatch coverage, or present a Mermaid projection as additional analysis.