前端开发工具【免费下载链接】dillingerThe last Markdown editor, ever.项目地址https://gitcode.com/gh_mirrors/di/dillinger点击查看免费下载本文以仓库内 .agent/skills/plan-writing/SKILL.md 为核心骨架系统讲解结构化任务规划plan-writing技能的任务拆解原则、规划纪律、计划文件结构与验证标准并以 Dillinger 仓库中真实落地的 Next.js 迁移计划、任务追踪清单与/plan工作流为佐证展示该框架如何在多步骤工程功能开发、重构、修复、迁移中落地为可执行、可验证、可追踪的计划产物。读完本文你将掌握一套短而具体、任务可验证、验证永远收尾的 AI 辅助规划范式并能直接在类似多步骤工作中复用。技能是什么一条面向多步骤工作的规划技能plan-writing是 Dillinger 仓库 .agent 目录下众多 Agent 技能skills之一其元信息frontmatter定义如下--- name: plan-writing description: Structured task planning with clear breakdowns, dependencies, and verification criteria. Use when implementing features, refactoring, or any multi-step work. allowed-tools: Read, Glob, Grep ---适用场景实现功能、重构以及任何多步骤工作允许的工具仅Read、Glob、Grep——规划阶段只做读代码、搜文件、列目录的信息收集不写任何代码来源文档首部注明 Source: obra/superpowers即该技能脱胎于开源 superpowers 技能体系仓库将其吸收为本地技能之一。技能的本质是把一项复杂工作拆成清晰、可行动、带验证标准的小任务的框架。Dillinger 仓库本身正处于 Angular.js 向 Next.js 14 迁移的周期见 docs/plans/CLAUDE.md 中记录的迁移计划活动因此该技能与仓库内大量规划文档形成了方法论 ↔ 落地证据的互证关系。任务拆解四大原则SKILL.md 规定任何计划中的任务都必须满足四条拆解原则1. 小而聚焦的任务Small, Focused Tasks要求说明每个任务耗时2–5 分钟每个任务的产出一个明确结果独立性可独立验证仓库中的迁移计划正是如此切分以 docs/plans/2026-01-19-nextjs-migration.md 为例Phase 1 被拆成1.1 初始化 Next.js 项目、1.2 安装核心依赖、1.3 配置 Tailwind 设计令牌等互不纠缠的任务每个任务都只产出单一文件或单一能力。2. 明确的验证标准Clear Verification规划时必须回答三个问题如何知道它做完了How do you know its done?可以检查/测试什么What can you check/test?预期输出是什么Whats the expected output?每个任务末尾都带Verify:检查点例如迁移计划中# 任务 1.2 的验证步骤 npm ls monaco-editor/react zustand markdown-it # Expected: All packages listed without errors# 任务 1.3 的验证步骤 npm run build # Expected: Build succeeds3. 逻辑排序Logical Ordering识别依赖关系Dependencies identified尽可能并行Parallel work where possible标出关键路径Critical path highlighted铁律Phase X: Verification永远放在最后。这一点在 tasks/todo.md 的依赖图中有完整呈现- T1: Freeze the executable ship scope ... depends_on: [] - T2: Add automated verification infrastructure ... depends_on: [T1] - T3: Restore markdown, preview, import/export ... depends_on: [T2] - T4: Finish image handling, service/OAuth consistency ... depends_on: [T2, T3] - T5: Run the release gate ... depends_on: [T3, T4]T5发布门禁测试、类型检查、Lint、构建、浏览器 UI/UX 验证作为最后一个任务依赖前面全部工作——这正是Verification 永远收尾原则的直接体现。4. 项目根目录动态命名Dynamic Naming in Project Root计划文件以{task-slug}.md命名保存到项目根目录名称由任务派生例如 add auth →auth-feature.md绝不放在.claude/、docs/或临时目录里。仓库配套的/plan工作流 .agent/workflows/plan.md 给出了更细的命名规则从请求中提取 2–3 个关键词、转小写、用连字符连接、不超过 30 字符例如 e-commerce cart →PLAN-ecommerce-cart.md。需要说明的是仓库实际生成的迁移计划产物归档于 docs/plans/ 目录如2026-01-19-nextjs-migration.md属于仓库自身在长期迭代中的归档实践而技能文档规定的即时规划产物命名规范以 SKILL.md 与/plan工作流为准。五大规划原则是原则不是模板SKILL.md 特别强调 NO fixed templates. Each plan is UNIQUE to the task.——计划必须因任务而异禁止套用统一模板。原则 1保持简短Keep It SHORT❌ 错误✅ 正确50 个任务外加子-子任务最多 5–10 个清晰任务列出每一个微步骤只列可行动项冗长的任务描述每任务一行规则计划超过一页就是太长需要简化。原则 2具体而非泛化Be SPECIFIC, Not Generic❌ 错误✅ 正确Set up projectRunnpx create-next-appAdd authenticationInstall next-auth, create/api/auth/[...nextauth].tsStyle the UIAdd Tailwind classes toHeader.tsx规则每个任务都要有清晰、可验证的产出。迁移计划就是具体化的范本它不止写创建状态管理而是给出完整动作——Createnext-app/lib/types.tsDocument / UserSettings 接口与 DEFAULT_SETTINGS、DEFAULT_DOCUMENT_BODY 常量、Createnext-app/stores/store.tsZustand store含 hydrate/persist。对照当前仓库 lib/types.ts 与 stores/store.ts 可以确认这些规划产出已真实落地。原则 3按项目类型动态组织内容Dynamic Content Based on Project Type场景计划应回答的问题新项目NEW PROJECT技术栈选什么MVP 是什么文件结构怎样新增功能FEATURE ADDITION影响哪些文件需要什么依赖如何验证生效修 BugBUG FIX根因是什么改哪个文件/哪一行如何测试修复原则 4脚本因项目而异Scripts Are Project-Specific禁止复制粘贴脚本命令必须根据项目类型选择。项目类型相关脚本前端/Reactux_audit.py、accessibility_checker.py后端/APIapi_validator.py、security_scan.py移动端mobile_audit.py数据库schema_validator.py全栈按实际改动范围混合错误做法给每个计划都塞进全部脚本正确做法只放与本任务相关的脚本。Dillinger 仓库的技能目录里确实存在这些脚本如 .agent/skills/api-patterns/scripts/api_validator.py、.agent/skills/frontend-design/scripts/ux_audit.py、.agent/skills/database-design/scripts/schema_validator.py规划时按需选用。原则 5验证必须简单Verification is Simple❌ 错误✅ 正确Verify the component works correctlyRunnpm run dev, click button, see toastTest the APIcurl localhost:3000/api/users returns 200Check stylesOpen browser, verify dark mode toggle works验证描述要具体到跑什么命令、看到什么现象、得到什么返回码。计划结构模板灵活非固定SKILL.md 给出的最小可用骨架# [Task Name] ## Goal One sentence: What are we building/fixing? ## Tasks - [ ] Task 1: [Specific action] → Verify: [How to check] - [ ] Task 2: [Specific action] → Verify: [How to check] - [ ] Task 3: [Specific action] → Verify: [How to check] ## Done When - [ ] [Main success criteria]就这些。除非确有必要不要添加 phases、子章节。保持最小化仅在真正需要时增加复杂度。## Notes [Any important considerations]仓库中的迁移计划对这一骨架做了贴合实际扩展Goal是单句目标Migrate Dillinger from Angular.js to Next.js 14 with App Router, maintaining 100% functional parity.并附加了Architecture单页编辑器 Zustand Monaco markdown-it Next.js API routes localStorage 持久化与Tech StackNext.js 14、TypeScript、Tailwind CSS、Zustand、Monaco Editor、markdown-it、Lucide React两行上下文每个任务内部采用统一的**Files:**列出将创建/修改的文件→**Step 1/2/3...**具体命令与代码→**Verify**检查命令与预期输出→**Commit**git 提交信息结构例如任务 1.1 使用npx create-next-applatest next-app --typescript --tailwind --eslint --app --src-dirfalse --import-alias/* --use-npm最佳实践速查Best Practices: Quick Reference从目标开始——要构建/修复什么最多 10 个任务——超过则拆成多个计划每个任务可验证——有明确的完成标准项目专属——不做复制粘贴模板随进度更新——完成一项就勾选[x]。何时使用When to Use从零开始的新项目新增功能修复复杂 Bug跨多文件的重构。仓库实战方法论如何落地成可追踪产物迁移计划的目标—任务—验证三段式docs/plans/2026-01-19-nextjs-migration.md 完整复刻了技能的骨架单句 Goal 定义了100% 功能对等的总目标5 个 PhaseProject Setup → State Management → Markdown Rendering → Monaco Editor → UI Components各自包含 2–5 个任务每个任务都携带真实可运行的npm/git命令、完整代码清单与npm run build级别的验证点。后续的 docs/plans/2026-01-19-nextjs-migration-phase2.mdGitHub/Dropbox 云端集成OAuth token 存 HTTP-only cookieAPI routes 统一代理云端通信与 docs/plans/2026-01-19-phase3-design.md 等文档延续同一范式形成可回溯的规划链条。验证收尾与发布门禁tasks/todo.md 是Verification 永远最后的活样本任务链末尾的 T5 定义了一个完整的发布门禁——npm run verify依次执行npm run lint、npm run typecheck、npm run test:unit、npm run build与基于生产服务器的playwright test。该清单还记录了具体验证证据例如 PDF 导出修复在 tests/routes/export-pdf.route.test.ts 增加路由级回归测试并通过本地POST http://127.0.0.1:3015/api/export/pdf冒烟验证返回有效单页 PDF托管端最终以HTTP/2 200、Content-Type: application/pdf收尾。这说明验证不是计划末尾的一句口号而是被测试资产tests/ 目录下的组件、hooks、lib、routes 测试与执行记录双重支撑的工程环节。/plan 工作流规划模式的调用入口仓库用 .agent/workflows/plan.md 定义了/plan命令将本技能包装成可调用的工作流模式其关键规则包括不写代码——该命令只生成计划文件交给 project-planner Agent见 .agent/agents/project-planner.md而非原生 Plan 子代理苏格拉底式提问门Socratic Gate——规划前先澄清需求动态命名——计划文件按任务关键词命名例如/plan e-commerce site with cart→PLAN-ecommerce-cart.md规划完成后给出固定格式的反馈[OK] Plan created: ...与下一步建议Review →/create开始实现或手动修改计划。这一工作流把规划技能进一步封装成了团队/仓库内人人可调用的标准命令规划产物最终经由 docs/reports/2026-03-10-refactor-finish-report.html 之类的报告形成闭环。小结plan-writing 技能的核心价值可以浓缩为三句话计划要短到一页以内、具体到命令级别任务要小到 2–5 分钟可完成、且每条都有可验证的完成标准验证永远作为最后一个阶段收尾。Dillinger 仓库的迁移计划、任务追踪清单与/plan工作流共同证明这套框架不是纸面方法论而是能够产出真实代码、测试与部署记录的可执行工程范式。对任何需要在多步骤工作中保持节奏、依赖清晰、结果可证的团队或 AI Agent 而言这套技能都值得直接借鉴。赞分享前端开发工具【免费下载链接】dillingerThe last Markdown editor, ever.项目地址https://gitcode.com/gh_mirrors/di/dillinger点击查看免费下载相关推荐Codewhale plan 技能实战把任务编排进原生 plan/Work 状态的方法论与源码实现Codewhale plan 技能实战把任务编排进原生 plan/Work 状态的方法论与源码实现 本指南以 crates/tui/assets/skills人工智能AI Agent代码智能体CLI工具调用MCP Clientssuperpowers-zh 编写计划writing-plans技能全解析从规格说明到可执行实现计划的方法论与实战模板superpowers zh 编写计划writing plans技能全解析从规格说明到可执行实现计划的方法论与实战模板 在 AI 编程工具ClaudeAI 技能AI 插件人工智能开发工具forgecode 实施计划编写实战以用户认证系统示例计划详解 create-plan 的结构、校验与执行闭环forgecode 实施计划编写实战以用户认证系统示例计划详解 create plan 的结构、校验与执行闭环 本文以 forgecode 仓库中 creat人工智能AI Agent代码智能体AI 应用CLI开发工具上一篇Light-Weight RefineNet性能优化提升实时语义分割速度的7个技巧下一篇youtube-dl-gui疑难问题解决常见错误与故障排除方法创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考