Menú
Quality gates and verification for MAP workflow
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.
Basado en la clasificación ocupacional SOC
Opt-in proactive architecture-deepening report: ranks codebase areas by recent git hotspot and design friction, generates a ranked Markdown+Mermaid candidate report under .map/<branch>/architecture-report/, then waits for you to pick one candidate before any code changes. Use periodically, or when agentic complexity feels like it is accelerating, to find where a deeper module would buy future leverage. Do NOT use for current-diff code review — use /map-review; do NOT use to plan or implement changes — use /map-plan after picking a candidate here.
ARCHITECT phase - decompose complex tasks into atomic subtasks with research, spec, and branch-scoped plan artifacts under .map.
ARCHITECT phase only: produce an upfront plan by decomposing a complex task into atomic subtasks with clear dependencies, via task-decomposer. Use when the user asks to plan, create a structured plan, break down, decompose, or stage work — e.g. planning a feature, refactor, migration, API/versioning upgrade, or incremental/phased rollout into smaller independent steps before any code is written. Trigger on phrasing like "plan a…", "create a plan for…", "decompose…into tasks", "break this into steps", "roll out incrementally", or "smaller independent steps". Do NOT use to execute work; use map-task or map-efficient.
Decision-frontier wayfinding: build and work a durable map of open design decisions BEFORE planning, for large or foggy efforts where /map-plan would force premature decomposition. Use when a task is too big or too vague to decompose — many unknowns, tangled decisions, or "I'm not even sure what to build yet" — and you want to resolve the key decisions one at a time (research, prototype, grilling, task tickets) behind a claim-before-work frontier, with a "fog of war" for questions you cannot yet state sharply. Produces a handoff that /map-plan consumes. Modes are explicit: chart (start a map), work (resolve one ticket), handoff (finish). Do NOT use when scope is already clear enough to specify — go straight to /map-plan; do NOT use to implement code or to decompose an already-specifiable change.
Token-efficient MAP workflow with state-machine orchestration over Predictor/Actor/Monitor/Evaluator/Reflector. Use when implementing a non-trivial change end-to-end. Do NOT use for tiny one-shot edits; use map-fast.
TDD MAP workflow: write tests from the spec FIRST, then implement, so tests validate intent not implementation. Use when correctness is critical (auth, payments, data integrity). Do NOT use without a spec; use map-efficient instead.
| name | map-check |
| description | Quality gates and verification for MAP workflow |
Run quality gates on the current MAP workflow state.
$map-check [subtask-id]
shell_command to read .map//step_state.jsonshell_command for project test suiteshell_command for project linter