mastermind-project-map

Sterne11

Forks0

Aktualisiert18. Juli 2026 um 21:17

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.

Installation

Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.

Quelle

xcrft

xcrft/mastermind

GitHub-Repository öffnen Creator-Repositorys ansehen

Download

Verwandte BerufeSOC

Basierend auf der SOC-Berufsklassifikation

SoftwareentwicklerInformatik- und Mathematikberufe·SOC 15-1252

Datei-Explorer

2 Dateien

SKILL.md

readonly

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"]}

Mastermind Project Map

Use the deterministic map as the source of claims. Do not reconstruct a map from filenames or model intuition when the backend is available.

Workflow

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.

Reporting contract

Separate:

indexed facts: languages, files, symbols, callers, cycles;
heuristics: filename entry points;
approximations: syntactic edges, name collisions, work-limit skips.

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.

Mehr aus diesem Repository

gleiches Repository

mastermind-design-intake

xcrft/mastermind

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.

2026-07-3111

mastermind-product-intake

xcrft/mastermind

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.

2026-07-3111

mastermind-security-research

xcrft/mastermind

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.

2026-07-3011

mastermind-test-audit

xcrft/mastermind

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.

2026-07-3011

mastermind-runtime-research

xcrft/mastermind

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.

2026-07-3011

mastermind-frontend-audit

xcrft/mastermind

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.

2026-07-3011

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"]}

Mastermind Project Map

Use the deterministic map as the source of claims. Do not reconstruct a map from filenames or model intuition when the backend is available.

Workflow

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.

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.

Reporting contract

Separate:

indexed facts: languages, files, symbols, callers, cycles;
heuristics: filename entry points;
approximations: syntactic edges, name collisions, work-limit skips.

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.