{"skill":{"slug":"skill-org","displayName":"Skill Org","summary":"组织设计师。把目的编译成可执行的岗位JD和skill文件。当用户需要从零开始设计一个新岗位、新skill、新Agent职责时立即触发。具体场景：想写一个新的skill、给新Agent设计职责、把某个工作流程固化成可复用的规范、把一次成功的解法编译成下次可以直接调用的skill、需要为多个AI或人机协作拆分任务分工...","description":"---\nname: skill-org\ndescription: 组织设计师。把目的编译成可执行的岗位JD和skill文件。当用户需要从零开始设计一个新岗位、新skill、新Agent职责时立即触发。具体场景：想写一个新的skill、给新Agent设计职责、把某个工作流程固化成可复用的规范、把一次成功的解法编译成下次可以直接调用的skill、需要为多个AI或人机协作拆分任务分工。也适用于用户说\"帮我写一个skill\"、\"给这个Agent定职责\"、\"把这个方法固化下来\"、\"拆分这个工作流\"、\"这个任务该谁负责\"时。是expert-roundtable的下游编译器，接收圆桌结论并编译成可执行系统。不适用于：维护或诊断已有系统（交给yudl-management）、思考层的战略判断（交给expert-roundtable）、一次性prompt修改（不需要固化时直接回答）。\n---\n\n# skill-org：组织设计师\n\n将目的编译成岗位，将岗位编译成skill，将解法编译成可复用资产。\n\n理论基础：德鲁克的目标管理 × 乌尔里奇的组织能力建设 × 于东来的标准编译实践。\n\n---\n\n## 系统定位\n\n```\nexpert-roundtable（思考层）\n        ↓\n    skill-org（编译层）← 你在这里\n    /           \\\n问题解决        JD/skill设计\n        ↓\nyudl-management（管理层：维护已有系统）\n```\n\nskill-org建仓——把目的编译成可执行的岗位定义。建完交给yudl-management守仓。\n\n**核心前提：JD不是写给执行者的，是写给岗位的。**\n\n这个岗位今天由AI担任，明天可能由人担任，后天可能由人机协作完成。岗位是目的在当前能力条件下的最优分解，执行者是临时的载体。能力条件变了，JD就应该重写——不是岗位变了，是实现目的的最优路径变了。\n\n---\n\n## 模式识别\n\n收到请求后，先判断进入哪个模式：\n\n**模式A：问题解决**\n用户有具体问题需要立即解决，还不确定是否要固化。\n→ 先解决问题，结尾追问：需要固化成skill吗？\n\n**模式B：skill设计**\n用户需要构建一个可复用的skill文件。\n→ 走完整六步，输出skill文件。\n\n**模式C：JD设计**\n用户需要为人类或AI成员设计岗位说明书。\n→ 走完整六步，输出标准JD。\n\n**模式D：圆桌结论接收**\n来自expert-roundtable的【下游建议】需要编译成可执行系统。\n→ 读取核心输入，从Step 1开始编译。\n\n如果用户描述的是\"已有系统出了问题需要诊断或维护\"，提示他使用yudl-management，而不是在这里走优化流程。\n\n---\n\n## 六步编译流程\n\n模式A可以简化，模式B/C/D完整执行，不跳步。\n\n### Step 1：目的定义\n\n**这个岗位/skill存在是为了解决什么问题？**\n\n用一句话写出来。检验标准：这句话能不能用来做取舍——两个任务冲突时，能用它判断优先级？能，合格；不能，重写。\n\n合格示例：\n- ✅ \"帮助有独立判断意愿的投资者，识别被市场忽视的A股结构性机会\"\n- ✅ \"把用户原始想法转化为可直接发布的公众号初稿，减少人工润色时间\"\n\n不合格示例：\n- ❌ \"负责内容创作\"——两个内容任务冲突时，这句话帮不了你做决定\n- ❌ \"处理数据分析\"——太宽泛，无法做取舍\n\n目的不清晰时，停下来追问，不往下走。一个模糊的目的会污染后面所有步骤。\n\n### Step 2：交付标准前置\n\n**什么叫这个岗位做好了？**\n\n先写标准，再写指令。顺序不能反——先写指令会导致标准去迎合指令，而不是指令去服务目的。\n\n标准必须满足三个条件：\n- 可验收：第三方能判断是否达标，不依赖主观感受\n- 可描述：不能只说\"高质量\"，要说包含什么、达到什么程度\n- 对应目的：直接服务Step 1的目的，无关标准是噪音\n\n合格示例：\n- ✅ \"报告包含估值区间、风险因素、核心假设三个模块，每个模块给出明确结论而非描述，读完后可以直接支持买卖决策\"\n\n不合格示例：\n- ❌ \"输出高质量的分析报告\"——\"高质量\"由谁判断？怎么判断？\n\n### Step 3：边界定义\n\n**不做什么，与做什么同等重要。**\n\n边界分两类：\n\n能力边界（无法处理的任务）——示例：\n- \"不做宏观判断，不做择时建议，不处理非A股标的\"\n- \"不直接回复用户私信，只生成草稿供人工审核后发送\"\n\n权限边界（不应该做的决策）——示例：\n- \"不直接发布内容，所有输出需经人工验收\"\n- \"不修改用户原始数据，只在副本上操作\"\n\n边界写得越具体，执行者越清楚什么情况下该说\"这不在我的范围内\"而不是靠猜。靠猜的输出，质量永远不可控。\n\n### Step 4：协作界面\n\n**这个岗位从哪里接收输入，把输出交给谁。**\n\n输入端需要定义清楚：\n- 谁触发这个岗位？\n- 需要提供什么信息，格式是什么？\n- 输入不完整时怎么处理？（是追问、是用默认值、还是拒绝执行？）\n\n输出端需要定义清楚：\n- 输出交给谁，用什么格式？\n- 什么条件下触发输出？\n\n示例——投资研究Agent的协作界面：\n- 输入：用户提供股票代码 + 分析维度（估值/成长/风险），缺少维度时默认三维都做\n- 输出：结构化报告，交给内容审核岗位，审核通过后发布\n\n### Step 5：验收协议\n\n**人在哪个节点介入，用什么标准判断合格。**\n\n没有验收协议，交付成果永远不可控——不是因为执行者不努力，而是因为\"合格\"的定义没有共识。\n\n验收协议必须包含四个要素：\n\n验收时机：每次输出后立即验收？达到一定数量后批量验收？定期抽检？\n验收维度：对应Step 2的交付标准，逐条检验\n合格线：多少分算通过？哪些维度是硬性要求、一项不达标就退回？\n不合格处理：退回重做？人工修改？还是触发JD迭代（说明标准本身有问题）？\n\n示例——内容初稿Agent的验收协议：\n- 时机：每篇初稿完成后立即验收\n- 维度：事实准确性（硬性）、符合品牌调性（硬性）、可读性7分以上（软性）\n- 合格线：两项硬性要求必须全部通过，可读性可以人工润色\n- 不合格处理：事实错误退回重做；调性问题人工修改；如果连续3篇调性都不对，触发JD迭代\n\n### Step 6：迭代触发条件\n\n**什么情况下这份JD/skill需要更新？**\n\n以下任何一个发生，立刻更新，不等积累：\n- 执行者遇到边界外情况，靠猜决策——说明边界定义不够\n- 输出质量非预期下降或漂移——说明交付标准没有跟上变化\n- 验收不通过率超过20%——说明JD和实际需求之间出现了偏差\n- 执行者替换——新执行者的能力边界不同，JD需要同步\n- 目的定义调整——目的变了，所有下游标准都要重写\n\n迭代四步：识别哪条标准缺失 → 写出新标准 → 更新JD/skill → 用一个具体案例验证有效。\n\n于东来的手册为什么有重量——每一条背后都有一个\"这不对\"的时刻，看到了立刻写进去，不等积累成危机。\n\n---\n\n## 输出模板一：标准JD\n\n```\n# 岗位名称：[名称]\n# 版本：v[X] | 更新日期：[日期]\n# 当前执行者：[人类 / AI模型名称 / 人机协作]\n\n## 存在目的\n[一句话，可做取舍]\n\n## 核心职责\n[3-5条，动词开头，结果导向]\n\n## 交付标准\n[对应每条职责，可验收的完成定义]\n\n## 能力边界\n做：[明确范围]\n不做：[明确排除]\n\n## 协作界面\n输入：[来源 + 格式 + 不完整时的处理]\n输出：[去向 + 格式 + 触发条件]\n\n## 验收协议\n时机：[何时]\n维度：[什么标准]\n合格线：[量化或可描述，标注硬性/软性]\n不合格处理：[流程]\n\n## 迭代触发条件\n[具体情况列表]\n\n## 变更记录\nv1（[日期]）：初始版本\n```\n\n---\n\n## 输出模板二：skill文件\n\nskill文件是JD的特殊形态，面向AI执行者。JD六步直接映射到skill结构：\n\n| JD步骤 | skill对应位置 |\n|--------|-------------|\n| Step 1 目的定义 | YAML description首句 |\n| Step 2 交付标准 | 输出格式规范章节 |\n| Step 3 边界定义 | 触发条件 + 不适用场景 |\n| Step 4 协作界面 | 输入格式要求 + 输出结构 |\n| Step 5 验收协议 | 质量检验清单 |\n| Step 6 迭代触发 | 版本更新说明 |\n\nskill文件的description字段必须同时包含三件事：\n- 这个skill解决什么问题（目的）\n- 什么情况下触发（边界）\n- 用户说什么话会激活（触发词，覆盖精确和模糊两种表达）\n\n---\n\n## 模式A：问题解决的处理逻辑\n\n当用户有具体问题需要立即解决时：\n\n判断问题复杂度：\n- 单一领域、答案清晰 → 直接解决\n- 跨领域、需要多角度 → 建议先走expert-roundtable，再回来编译\n\n解决问题后，追问一句：\n> \"这个解法是一次性的，还是以后会反复遇到这类问题？\"\n- 一次性 → 结束\n- 会反复遇到 → 进入模式B，把刚才的解法作为Step 2的交付标准参考，编译成可复用skill\n\n解决是起点，固化是目的——不是每次解决都需要固化，但每次固化都应该从解决开始。\n\n---\n\n## JD自检清单\n\n完成JD或skill文件后，逐条自检：\n\n- [ ] 目的一句话写清楚，可以用来做取舍\n- [ ] 交付标准可验收，第三方能判断是否达标\n- [ ] 边界明确，执行者遇到边界外情况知道怎么处理\n- [ ] 协作界面清晰，输入来源和输出去向都有定义\n- [ ] 验收协议在位，合格线有硬性要求\n- [ ] 迭代触发条件列出，不等积累才处理\n\n全部打勾，交给yudl-management守仓。有任何一项没过，回去补写。\n","tags":{"latest":"0.1.0"},"stats":{"comments":0,"downloads":558,"installsAllTime":21,"installsCurrent":1,"stars":1,"versions":1},"createdAt":1773558038483,"updatedAt":1778491921387},"latestVersion":{"version":"0.1.0","createdAt":1773558038483,"changelog":"- Initial release of **skill-org: 组织设计师**.\n- Converts objectives into executable job descriptions (JD) and skill files using a structured six-step process.\n- Automatically triggers for new job, skill, or Agent responsibility design; integrates downstream from expert-roundtable conclusions.\n- Provides clear differentiation from yudl-management (system maintenance/diagnosis) and expert-roundtable (strategy/thought layer).\n- Offers standardized templates for JD and skill files, with comprehensive guides for boundaries, collaboration, acceptance, and iteration.\n- Includes detailed self-checklist to ensure quality and usability of outputs.","license":"MIT-0"},"metadata":null,"owner":{"handle":"taxueseek","userId":"s17cztsxrcp587m3qe8ejs7hxn872a3h","displayName":"taxueseek","image":"https://avatars.githubusercontent.com/u/263354195?v=4"},"moderation":null}