菜单
将全国大学生电子设计竞赛（电赛/NUEDC）及类似嵌入式、机器人、测控、电源、信号赛题编译成可执行工程任务：拆解得分路径，识别系统闭环和一至两个主矛盾，生成基础方案骨架、第一版 MVP、Codex 工程任务书、观测变量、验证门槛、非代码问题和停止条件。用于用户提供赛题 PDF、图片、文字或评分规则，要求分析赛题、规划实现、确定先做什么，或在生成代码前形成任务书时。
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/54xkeee/agent-diansai-skill --skill analyze-nuedc-task命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
Use when Codex needs to plan or implement code for NUEDC/electronic-design-contest projects with multiple scoring tasks, staged goals, maintainable architecture, task cycles, MVP/basic functions first, module interfaces, main contradiction analysis, hard-part code design, verification gates, and iterative implementation from simple to difficult.
当用户第一轮输入完整 NUEDC/电赛/嵌入式竞赛赛题、PDF、图片、评分规则或要求 Codex 从赛题分析到代码实现全流程跑通时使用。该 skill 作为上层 Orchestrator，调度 planning-with-files-zh、analyze-nuedc-task、nuedc-code-planner、stm32-keil/stm32cubemx 等能力，建立文件 checkpoint、得分路径、主矛盾、MVP、代码周期和验证门槛，避免直接生成一坨不可运行的完整代码。
基于 Manus 风格的文件规划系统，用于组织和跟踪复杂任务的进度。创建 task_plan.md、findings.md 和 progress.md 三个文件。当用户要求规划、拆解或组织多步骤项目、研究任务或需要超过5次工具调用的工作时使用。支持 /clear 后的自动会话恢复。触发词：任务规划、项目计划、制定计划、分解任务、多步骤规划、进度跟踪、文件规划、帮我规划、拆解项目
基于 SOC 职业分类
正在显示 SKILL.md
| name | analyze-nuedc-task |
| description | 将全国大学生电子设计竞赛（电赛/NUEDC）及类似嵌入式、机器人、测控、电源、信号赛题编译成可执行工程任务：拆解得分路径，识别系统闭环和一至两个主矛盾，生成基础方案骨架、第一版 MVP、Codex 工程任务书、观测变量、验证门槛、非代码问题和停止条件。用于用户提供赛题 PDF、图片、文字或评分规则，要求分析赛题、规划实现、确定先做什么，或在生成代码前形成任务书时。 |
把任意赛题稳定压缩成：“先做什么、为什么先做、做到什么算过、下一步交给谁做”。
本 Skill 不直接替用户实现完整赛题，也不输出泛泛的风险文章。默认交付一份可以继续交给 Codex、硬件、机械和测试人员执行的工程任务包。
赛题事实、用户已确认条件、合理推断、待确认项，不得把推断写成事实。严格按以下顺序执行。不要用长篇风险枚举替代这些动作。
从评分规则反推工程优先级，输出：
| 层级 | 要回答的问题 |
|---|---|
| 共享必做闭环 | 被多个目标得分项共同依赖、没有它主要得分链不成立的能力是什么？ |
| 基础得分闭环 | 最快能稳定展示并拿到基础分的完整闭环是什么？ |
| 提高得分闭环 | 在基础闭环上增加哪些能力才能继续得分？ |
| 炫技但低优先级 | 哪些功能看起来高级，但目前不直接增加得分或稳定性？ |
| AI 易误解点 | 哪些表述容易让通用智能体过度实现、漏掉限制或错误理解？ |
不要按赛题条目机械排序。找出得分项共享的前置能力和单点失败。最低分项目、共享必做闭环和推荐的首个原型可能是三件不同的事，必须分别判断。
把题目翻译成：
对每类闭环说明目标、反馈量和闭环失败时的表现：
某类闭环不适用于题目时，明确写“不需要”及原因。不要为了填表虚构闭环。
主矛盾定义：
评分目标中最依赖现实物理耦合、最难靠纯代码补救，并且不解决就无法继续构建得分链的环节。
主矛盾优先出现在两个闭环、两个物理域或两个任务阶段的交接处，例如感知到控制、运动到瞄准、无标记导航到路径跟踪、功率级到采样闭环。不要把“直线控制”“圆弧循迹”“云台 PID”“电源效率”等独立模块能力直接命名为主矛盾，除非该模块本身的物理可行性尚未成立且确实阻断主要得分链。
每个主矛盾只回答：
不要把普通模块工作、通用风险或“需要调 PID”列为主矛盾。最多保留两个。
先生成系统结构，再谈文件和代码：
| 层 | 内容 |
|---|---|
| 输入层 | 传感器、测量对象、用户输入 |
| 估计层 | 从输入得到的系统状态 |
| 控制层 | 根据目标和状态产生控制量 |
| 执行层 | 电机、云台、继电器、PWM、DAC、通信等 |
| 决策层 | 任务阶段、状态切换、异常降级 |
| 记录层 | 为调试和验收记录的关键数据 |
说明子系统之间的数据流，并标出第一版启用哪些部分、暂缓哪些部分。
区分两个原型，不得自动把最低分项目当作主矛盾原型：
MVP-0 主矛盾验证原型：最便宜地证明或否定主矛盾，可以不直接得分。MVP-1 最小得分闭环：在 MVP-0 通过后，最快形成可展示、可得分的完整闭环。MVP-0 必须同时满足：
两个原型都使用固定输出：
若一个 MVP 同时验证过多未知项，将它继续缩小。
默认将 MVP-0 翻译为可以直接交给编程智能体的任务，不直接实现代码。若 MVP-0 主要是机械、硬件或测试实验，则任务书只要求 Codex 实现必要的数据采集、控制和日志支撑，不强行把实验变成软件项目。
任务书必须包含：
项目目标：
第一版功能范围：
输入：
输出：
模块及职责：
模块接口：
最小状态机/执行流程：
必须打印或记录的日志：
验收测试：
禁止实现的功能：
停止并询问用户的条件：
模块应从闭环和职责导出，不要先从 motor.c、pid.c 等文件名出发。接口信息不足时写出接口需求，不编造型号、引脚、单位或参数。
观测变量必须能定位“第一个失效环节”，至少覆盖：
阶段门槛遵循：
每个门槛写明测试条件、通过判据和未通过时不得继续的工作。
输出：
出现以下情况时停止生成完整代码，只输出待确认项或验证任务：
默认使用 engineering-task-package.md 的九段结构，保持简洁、可执行：
风险、失败模式和动态耦合用于支持主矛盾与 MVP 决策，不单独堆成长列表。需要发现候选耦合时读取 risk-checklist.md，只保留会改变得分路径、MVP 或任务书的内容。
用户明确要求完整分析文档时，可以展开解释；否则优先交付短而完整的工程任务包。
只有以下条件全部满足才算完成：