Compile purpose into positions, compile positions into skills, compile solutions into reusable assets.
Theoretical foundation: Drucker's management by objectives × Ulrich's organizational capability building × Yu Donglai's standard compilation practice.
System Positioning
expert-roundtable（思考层）
↓
skill-org（编译层）← 你在这里
/ \
问题解决 JD/skill设计
↓
yudl-management（管理层：维护已有系统）
skill-org builds the repository — compiling purpose into executable position definitions. After building, hand over to yudl-management to guard the repository.
Core premise: A JD is not written for the executor, it is written for the position.
This position may be held by an AI today, by a human tomorrow, and the day after tomorrow may be completed by human-machine collaboration. A position is the optimal decomposition of purpose under current capability conditions; the executor is a temporary carrier. When capability conditions change, the JD should be rewritten — not because the position has changed, but because the optimal path to achieving the purpose has changed.
Pattern Recognition
After receiving the request, first determine which mode to enter:
Mode A: Problem Solving The user has a specific problem that needs to be solved immediately and is not yet sure whether to solidify it. → Solve the problem first, then ask at the end: Does this need to be solidified into a skill?
Mode B: Skill Design The user needs to build a reusable skill file. → Go through the complete six steps and output a skill file.
Mode C: JD Design The user needs to design a job description for a human or AI member. → Go through the complete six steps and output a standard JD.
Mode D: Roundtable Conclusion Intake 【Downstream recommendations】 from expert-roundtable need to be compiled into an executable system. → Read the core input and start compiling from Step 1.
If what the user describes is "an existing system has a problem and needs diagnosis or maintenance", prompt them to use yudl-management instead of going through the optimization process here.
Six-Step Compilation Process
Mode A can be simplified; Modes B/C/D are executed completely without skipping steps.
Step 1: Purpose Definition
What problem does this position/skill exist to solve?
Write it out in one sentence. Test criterion: can this sentence be used for trade-offs — when two tasks conflict, can it be used to determine priority? If yes, it is qualified; if not, rewrite it.
Qualified examples:
- ✅ "Help investors who are willing to make independent judgments identify structural opportunities in A-shares that the market has overlooked"
- ✅ "Transform the user's raw ideas into a directly publishable first draft for a WeChat official account, reducing manual polishing time"
Unqualified examples:
- ❌ "Responsible for content creation" — when two content tasks conflict, this sentence cannot help you make a decision
- ❌ "Handle data analysis" — too broad, cannot be used for trade-offs
When the purpose is unclear, stop and ask questions; do not proceed. A vague purpose will contaminate all subsequent steps.
Step 2: Define Delivery Standards First
What counts as this position doing a good job?
Write the standards first, then the instructions. The order cannot be reversed — writing instructions first will cause the standards to cater to the instructions, rather than the instructions serving the purpose.
The standards must satisfy three conditions:
- Acceptable: A third party can judge whether the standard is met, without relying on subjective feeling
- Describable: Cannot just say "high quality"; must say what it includes and to what degree it reaches
- Corresponds to purpose: Directly serves the purpose of Step 1; irrelevant criteria are noise
Qualified example:
- ✅ "The report includes three modules: valuation range, risk factors, and core assumptions. Each module gives a clear conclusion rather than a description, and after reading it one can directly support buy/sell decisions"
Unqualified example:
- ❌ "Output a high-quality analysis report"—who judges "high quality"? How is it judged?
Step 3: Boundary definition
What not to do is as important as what to do.
Boundaries fall into two categories:
Capability boundaries (tasks that cannot be handled)—example:
- "Do not make macro judgments, do not give timing suggestions, do not handle non-A-share targets"
- "Do not directly reply to user private messages; only generate drafts for manual review before sending"
Authority boundaries (decisions that should not be made)—example:
- "Do not directly publish content; all output must pass manual acceptance"
- "Do not modify the user's original data; operate only on copies"
The more specific the boundaries are written, the clearer it is for the executor when to say "this is outside my scope" rather than relying on guessing. The quality of output based on guessing is never controllable.
Step 4: Collaboration interface
Where this role receives input from and to whom it hands output.
The input side needs to be clearly defined:
- Who triggers this role?
- What information needs to be provided, and in what format?
- How to handle incomplete input? (Ask follow-up questions, use default values, or refuse to execute?)
The output side needs to be clearly defined:
- To whom is the output given, and in what format?
- Under what conditions is output triggered?
Example—collaboration interface of an investment research Agent:
- Input: The user provides stock code + analysis dimensions (valuation/growth/risk); when dimensions are missing, all three are done by default
- Output: A structured report, handed to the content review role, published after review approval
Step 5: Acceptance protocol
At which node humans intervene, and by what standard they judge qualification.
Without an acceptance protocol, deliverables are never controllable—not because the executor does not work hard, but because there is no consensus on the definition of "qualified."
The acceptance protocol must include four elements:
Acceptance timing: Accept immediately after each output? Batch acceptance after reaching a certain quantity? Periodic spot checks? Acceptance dimensions: Corresponding to the delivery standards in Step 2, checked item by item Qualification line: How many points count as passing? Which dimensions are hard requirements, where failing one item means rejection? Handling of nonconformity: Return for rework? Manual modification? Or trigger JD iteration (indicating the standard itself has a problem)?
Example—acceptance protocol of a content first-draft Agent:
- Timing: Accept immediately after each first draft is completed
- Dimensions: Factual accuracy (hard), conformity to brand tone (hard), readability 7 points or above (soft)
- Qualification line: Both hard requirements must fully pass; readability can be manually polished
- Handling of nonconformity: Factual errors are returned for rework; tone issues are manually modified; if the tone is wrong for 3 consecutive pieces, trigger JD iteration
Step 6: Iteration trigger conditions
Under what circumstances does this JD/skill need to be updated?
Whenever any of the following occurs, update immediately—don't wait for it to accumulate:
- The executor encounters a situation outside the boundary and has to make decisions by guessing—this means the boundary definition is not sufficient
- Output quality drops or drifts unexpectedly—this means the delivery standards have not kept up with changes
- The acceptance failure rate exceeds 20%—this means there is a deviation between the JD and the actual requirements
- Executor replacement—the new executor has different capability boundaries, and the JD needs to be updated accordingly
- Purpose definition adjustment—the purpose has changed, so all downstream standards must be rewritten
Four iteration steps: identify which standard is missing → write the new standard → update the JD/skill → verify effectiveness with one specific case.
Why Yu Donglai's manual carries weight—behind every entry there is a "this is wrong" moment; write it down immediately upon seeing it, and don't wait for it to accumulate into a crisis.
Output template one: standard JD
# 岗位名称：[名称]
# 版本：v[X] | 更新日期：[日期]
# 当前执行者：[人类 / AI模型名称 / 人机协作]
## 存在目的
[一句话，可做取舍]
## 核心职责
[3-5条，动词开头，结果导向]
## 交付标准
[对应每条职责，可验收的完成定义]
## 能力边界
做：[明确范围]
不做：[明确排除]
## 协作界面
输入：[来源 + 格式 + 不完整时的处理]
输出：[去向 + 格式 + 触发条件]
## 验收协议
时机：[何时]
维度：[什么标准]
合格线：[量化或可描述，标注硬性/软性]
不合格处理：[流程]
## 迭代触发条件
[具体情况列表]
## 变更记录
v1（[日期]）：初始版本
Output template two: skill file
A skill file is a special form of JD, aimed at AI executors. The six JD steps map directly to the skill structure:
| JD step | Corresponding location in skill |
|---|---|
| Step 1 Purpose definition | First sentence of the YAML description |
| Step 2 Delivery standards | Output format specification section |
| Step 3 Boundary definition | Trigger conditions + not-applicable scenarios |
| Step 4 Collaboration interface | Input format requirements + output structure |
| Step 5 Acceptance protocol | Quality inspection checklist |
| Step 6 Iteration triggers | Version update notes |
The description field of a skill file must contain three things at the same time:
- What problem this skill solves (purpose)
- Under what circumstances it is triggered (boundary)
- What the user says to activate it (trigger words, covering both precise and fuzzy expressions)
Mode A: handling logic for problem solving
When the user has a specific problem that needs to be solved immediately:
Determine the complexity of the problem:
- Single domain, clear answer → solve directly
- Cross-domain, requiring multiple perspectives → suggest going through expert-roundtable first, then coming back to compile
After solving the problem, ask one follow-up question:
"Is this solution one-off, or will this type of problem recur in the future?"
- One-off → end
- Will recur → enter Mode B, use the solution just now as a reference for the Step 2 delivery standards, and compile it into a reusable skill
Solving is the starting point, consolidation is the goal—not every solution needs to be consolidated, but every consolidation should start from solving.
JD self-check checklist
After completing the JD or skill file, check each item one by one:
- The purpose is stated clearly in one sentence and can be used for trade-offs
- The delivery standards are acceptance-testable; a third party can judge whether they are met
- The boundary is clear; the executor knows how to handle situations outside the boundary
- The collaboration interface is clear; both input sources and output destinations are defined
- The acceptance protocol is in place, with hard requirements for the pass line
- Iteration trigger conditions are listed, and nothing is handled only after it accumulates
If all are checked, hand it over to yudl-management to keep the repository. If any item is not passed, go back and fill it in.