itmisx/deepx-code
17 skills
$npx skills add itmisx/deepx-codeSkillInstalls
brainstorming在任何创造性工作(做新功能、建组件、加能力、改行为)动手之前使用。通过结构化对话把模糊需求逼成清晰、经用户批准的设计,再进入写计划阶段。拿到批准前不写任何代码。creating-workflows当用户想「创建/生成一个 workflow(可复用的多子-agent 编排脚本)」时使用。讲清 deepx workflow 的 JavaScript 脚本格式、可用 API,以及如何用 Workflow 工具保存与运行。dispatching-parallel-agents当面对 2 个及以上彼此独立、无共享状态、无先后依赖、可并行处理的任务时使用。executing-plans当已有一份写好的实现计划、需要分步执行并在检查点处复核时使用。finishing-a-development-branch当实现完成、测试全过、需要决定如何收尾集成时使用——给出合并 / 提 PR / 清理等结构化选项,引导完成开发收尾。frontend-design做有辨识度、生产级、高设计质量的前端界面。当用户要构建网页组件、页面、海报或应用(网站、落地页、仪表盘、React 组件、HTML/CSS 布局,或美化任何 Web UI)时使用。产出有创意、精致、避免千篇一律 AI 风格的代码与界面。karpathy-guidelines减少 LLM 常见编码错误的行为准则。在写代码、审查或重构时使用:避免过度复杂、做最小化精准改动、显式暴露假设、定义可验证的成功标准。openspec规格驱动开发(SDD)。实现任何功能或改动时使用——写代码前先就规格达成一致:在 openspec/changes/<id>/ 写 proposal、spec deltas、tasks(复杂时加 design),对齐后再严格按规格实现,完成后把 delta 归档进基线 specs/。receiving-code-review收到代码审查反馈、在落实建议之前使用,尤其当反馈不清楚或技术上存疑时——要技术上较真、核实,而非敷衍附和或盲目照改。requesting-code-review在完成任务、实现重要功能、或合并前使用,核实工作是否满足需求。subagent-driven-development在当前会话内执行含独立任务的实现计划时使用(为每个任务派独立子 agent,分两阶段复核)。superpowers开始任何非琐碎任务时使用——确立 Superpowers 方法论及如何发现/使用其 skill。在任何回复(包括澄清提问)之前先调用相关 skill。对应 deepx 工作模式 sp。systematic-debugging遇到任何 bug、测试失败或异常行为时,在提出修复方案之前使用。test-driven-development实现任何功能或修复 bug 时,在写实现代码之前使用(测试先行,RED-GREEN-REFACTOR)。using-git-worktrees当开始需要与当前工作区隔离的功能开发、或执行实现计划之前使用——通过原生工具或 git worktree 兜底,确保有一个隔离的工作区。verification-before-completion在说出任何"完成了/修好了/应该能用了/测试通过了"之前使用。任何完成声明都必须有刚刚跑出来的、亲眼读过的证据,不许靠推断或感觉。这是刚性 skill。writing-plans当已有多步任务的规格或需求、在动代码之前使用,把工作拆成可执行的小步计划。