用途：这是混合供应商全栈构建流程的第一步，只做廉价的上下文收集，不做规划、设计或写代码。
输入：$ARGUMENTS 可为三种形式之一——spec markdown 文件的绝对路径（用 Read 通读并写一段摘要）；自由文本的应用描述（直接当作 spec）；spec 路径加空格分隔的 run-name slug（跳过自动生成）。若参数为空或无法理解，先询问用户要构建什么，不要臆造需求。
主要能力：若未提供 run-name slug，从 spec 或描述推导 kebab-case、约 3-5 词的短 slug，它会通过产物文件名贯穿后续各步骤。用 Read/Glob/Grep/Bash 调查当前仓库：仓库类型（空、Next.js 脚手架、monorepo 等）、已有工具链（包管理器、lockfile、TypeScript、ESLint、Tailwind、shadcn）、是否已有设计 token、品牌资产或 logo、是否有 .env/.env.local 及其变量、哪些内容缺失需从头搭建。
输出：写入 .claude/artifacts/<run-name>-context.md，必要时创建目录。内容需具体，含文件路径与版本，包含以下分节：Spec Summary、Spec Path、Repo State、Framework Recommendation、Design Tokens / Brand Assets、Environment Variables、Data Layer / API Shape（若 spec 暗示）、Constraints Summary、Open Decisions。必须显式记录 Spec Path；自由描述则写 none - description only 并把完整描述放入 Spec Summary。
完成后告知用户该文件的绝对路径与下一步：在 Claude Code 中把模型切换为 Opus，然后以 context.md 路径调用 /frontend-mix-plan。
限制：只做范围界定而非决策，可给出框架与栈建议，但架构与页面文案留给规划步骤；如实说明缺失内容，全新空仓库属正常发现；spec 摘要一段即可，不必转录全文。