用途：批量解决 GitHub issue。用户以空格分隔传入 issue 编号（如 1234 5678 9012）；若未提供参数，则用 gh CLI 结合用户贡献历史推荐可处理的开放 issue，并先与用户确认。
主要流程：为每个 issue 创建独立 git worktree 与专用分支（git worktree add ../$(basename $PWD)-issue-<NUMBER> -b fix/issue-<NUMBER>），在 worktree 中安装构建（pnpm i && pnpm build），再在其中启动 mc 无头实例执行任务（示例：pnpx tsx <path-to-mastracode>/src/main.ts --timeout 1800 --prompt "Activate the understand-issue skill for issue <NUMBER>"）。实例作为后台进程运行，需跟踪 PID。
监控：在主项目根目录建立 reports/，为每个 issue 维护 reports/issue-<NUMBER>.md，记录编号、标题、链接、状态、方案与改动、PR URL 及阻塞项。每 3 分钟检查一次所有进程，读取 PID 尾部输出并更新报告，向用户汇报状态表。
完成与续跑：实例结束或超时后检查 git diff --stat 及新 changeset、ISSUE_SUMMARY 文件；若超时但有进展，以带上下文的续跑提示重启；若已完成（代码+测试+changeset），审查 diff 并交用户审核，批准后提交推送并按 /gh-new-pr 约定创建 PR，正文引用 Closes #<NUMBER>，随后更新报告中的 PR URL。
后续处理：PR 创建后用 /gh-pr-comments <PR_NUMBER> 处理评审反馈；推送后用 gh pr checks <PR_NUMBER> 检查 CI，失败则用 /gh-fix-ci 诊断修复，超时同样带上下文重启。
规则与限制：pnpm build 期间每次只跑 2 个构建以控制 CPU，mc 实例可全部并行（IO 密集）；每个 issue 始终只用一个 worktree，调试、PR 评论、CI 修复均在该 worktree 中进行；超时进程必须以含 diff 与末尾输出上下文的续跑提示重启；进程不得无人监控，每 3 分钟检查；持续更新报告文件；创建 PR 前审查所有 mc 输出，子代理产出视为不可信。
以上内容依据提供的技能说明整理；关于支持的平台、收费与版本等信息暂未提供。