القائمة
Quality gates and verification for MAP workflow
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف 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