mastermind-project-map

Estrellas11

Forks0

Actualizado18 de julio de 2026 a las 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.

Instalación

Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.

Fuente

xcrft

xcrft/mastermind

Abrir repositorio de GitHub Ver repositorios del creador

Descarga

Ocupaciones relacionadasSOC

Basado en la clasificación ocupacional SOC

Desarrolladores de softwareOcupaciones informáticas y matemáticas·SOC 15-1252

Explorador de archivos

2 archivos

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.

Más de este repositorio

mismo repositorio

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.