用途：在 Cursor 中借助 Shrimp Task Manager MCP 规划并拆分工作，把任务图（状态、依赖、验证标准）持久保存在聊天上下文之外，便于新会话或上下文耗尽后继续。它不替代 Cursor Plan Mode 的当前会话交互式规划。
启用条件：需同时满足跨会话连续性（后续聊天或上下文限制后仍继续）与结构化待办（多个任务且有明确依赖）。用户明确要求 Shrimp，或 /next、/retro 已有该工作的 Shrimp 任务时也可启用。单条命令、短问答、单会话内完成的修复，或规划在同一会话结束，应跳过；待办属于 GitHub/Linear 等 issue 跟踪器且不会经 Shrimp 恢复时也不适用。
主要能力与用法：先 list_tasks(status: "in_progress") 与 list_tasks(status: "pending") 查看现有状态；继续时用 get_task_detail，并在 plan_task 中设 existingTasksReference: true。随后 plan_task(description, requirements, existingTasksReference?) 规划，必要时用 analyze_task、reflect_task、research_mode 细化。再用 split_tasks(updateMode, tasksRaw, globalAnalysisResult?) 拆成任务图，每个任务需含 name、description、implementationGuide、verificationCriteria、dependencies、relatedFiles。updateMode 可选 clearAllTasks、append、selective、overwrite。最后返回任务 ID、下一个可执行任务，并激活 mcp-shrimp-execution-loop；仅规划模式不要调用 execute_task。
粒度与依赖：split_tasks 期望粗粒度子任务，每个约 1–2 个工作日（8–16 小时）、单一技术领域，每次拆分不超过 10 个（建议 6–8 个），任务树深度不超过 3 层。依赖在 split_tasks 中是任务名称字符串而非 ID；推荐 execute_task 前先用 list_tasks 或 get_task_detail 确认前置任务已完成。
限制：在 ~/.cursor/mcp.json 中，Shrimp 对所有工作区共用一个 Docker 卷 shrimp_data，并非按 git 仓库隔离；新工作拆分前应 list_tasks 留意其他项目的未完成任务，切换项目上下文时可用 updateMode: clearAllTasks（会先备份）或仅在继续同一 epic 时 append。资料未说明服务器是否会在依赖未完成时硬性阻止 execute_task，需自行在 list_tasks 中核实。