ce-skill-work
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChineseCE Skill Work
CE Skill 工作
Skills in this repository are goals, not state machines. A skill hands the agent the goal, the done condition, the safe failure direction, and the facts it cannot derive from the repo in front of it, then gets out of the way. Everything this skill does — authoring, editing, reviewing, responding to review — is that one standard applied to a different starting state.
Outcome: the skill files you touch state their conditions rather than enumerate cases, carry nothing that does not change behavior, and put each mechanism at the layer that owns it; and the change is validated in the way its risk warrants.
Done: the mode's completion report is written and its validation ran (or the exact skip reason is recorded). Landing a sentence is not done; a demonstrated gap closed at its owning layer by the smallest mechanism is.
Non-goal: shorter files. Leanness is a side effect of stating conditions; report what changed, not word counts.
本仓库中的Skill是目标,而非状态机。Skill会向Agent传递目标、完成条件、安全失败方向,以及它无法从当前仓库中推导得出的事实,然后不再干预。Skill的所有操作——编写、编辑、审核、响应审核——都是将同一标准应用于不同初始状态的过程。
成果: 你所修改的Skill文件应陈述条件而非枚举场景,不包含任何不影响行为的内容,并将每种机制放在其归属的层级;同时,变更会根据其风险程度进行验证。
完成标准: 已撰写对应模式的完成报告,且已执行验证(或记录了明确的跳过验证理由)。仅完成语句撰写不算完成;只有在归属层级通过最小化机制填补已证实的漏洞才算完成。
非目标: 缩短文件长度。简洁性是陈述条件带来的副作用;报告应记录变更内容,而非字数统计。
The standard (read before any mode)
标准(执行任何模式前必读)
docs/solutions/skill-design/portable-agent-skill-authoring.mdEach block starts from the same possible elements, in this order: the result and next consumer, any local done check the skill-level bar cannot protect, the safe failure direction, the non-derivable facts, and only then any protocol the outcome cannot protect on its own. If a block does not need one, it omits it. What it must not have instead is a list of cases standing in for a condition it could state, or a mechanism prescribed for work this skill delegates — that is the finding. A procedure for a mechanic this skill owns, or a menu whose omitted item would silently drop required coverage, is protocol and stays.
docs/solutions/skill-design/portable-agent-skill-authoring.md每个模块均从相同的可选元素开始,顺序如下:结果与下游使用者、Skill层面规则无法覆盖的本地完成检查、安全失败方向、不可推导的事实,最后才是成果自身无法保障的协议。如果模块不需要某个元素,可将其省略。绝对不能出现的是:用场景列表替代可陈述的条件,或是为Skill已委托的工作规定机制——这属于问题点。Skill所属机制的流程,或是遗漏某项就会导致必要覆盖缺失的菜单,则属于协议范畴,应保留。
Rules that hold in every mode
所有模式通用的规则
- Conditions, not cases. When you find yourself adding "and also when X" to a rule, name the condition X is a proxy for and state that. A rule that has to enumerate its cases is stated wrong.
- Prescribe a mechanism only where this skill owns it. Commands, exit codes, and state transitions belong to the skill that owns the mechanic (owns PR detection) or to cheap deterministic work. A delegating skill states the condition, the safe direction, and the non-derivable callee facts.
ce-commit-push-pr - Sediment first. Before adding to a block, remove what the standard says should not be there. Provenance decides how hard to look, not what stays: search for a test that asserts the line, a learning that records it, or a commit that added it to fix a named bug. Provenance found → the line is protecting something; keep it unless its consumer is gone, and cite what it protects. None found → apply admission (does it state a falsifiable constraint, counter a demonstrated tendency, or supply a non-derivable fact?) and, when a line is plausibly insurance for a weaker model or another harness, test that before cutting rather than assuming. Say which removals rest on absence of evidence.
docs/solutions/ - For every mandate you remove, name what now decides. If the answer is "the model, at its discretion, whether a required step happens", that mandate is a required gate and it stays. Removing a "must" does not remove the decision.
- A line earns its place by stating a falsifiable constraint, countering a demonstrated default tendency, or supplying a fact the agent cannot derive. Rationale after a directive that stands alone, effort language, and capability restatement do not.
- User-facing invocations render per harness — the rule and its placement are in the project's active instructions ("User-Facing Skill Invocations"); apply it wherever a skill prints or copies an invocation.
- The description is a context pointer. For a model-invoked skill, frontmatter sits in the window every turn and is pruned harder than the body. State what the skill is with the leading prompt word first, then one positive trigger per genuinely distinct branch in "Use when..." or "Use for..." form, then only adjacent negatives that block real false-trigger neighbors. Identity boilerplate, catalogs of sites/synonyms/capabilities for one branch, workflow, flags, and procedure belong out of the description.
- One done bar first. Every skill needs a skill-level done condition. Add a local done check only where skipping it can produce an unsafe action, fragile transition, scope expansion, mutation, auth mistake, or silent handoff failure.
- Lean prompts for current strong models. State each instruction once. If a brief instruction decides a family of behaviors, use it instead of enumerating the behaviors. If two recipes share the same command skeleton, write one recipe with parameters or deltas; if the skeleton is the same, repeated full commands are a defect.
- Sol-first portability for this org's multi-model skills. When Fable guidance to strip procedure or add a brevity block conflicts with Sol guidance to preserve a known-good command, required report content, or no blanket brevity slogan, keep the Sol form. Slightly thicker but clear instructions are acceptable for Fable; omitting Sol-critical determinism is not. True noise still drops.
- Portable length control preserves content. Never ship a blanket "be concise" / "keep it short" slogan in a cross-model skill. State what a short report must contain and what it may omit; for CLI wrappers, preserve command, exit status, output path/size, and stderr or blocker.
- Autonomy is one compact policy. Name safe local actions and let in-scope work that follows from the user's request proceed, including an external write that is the requested job or named in the skill's authority envelope. Confirm only when an external write, destructive action, purchase, or material scope expansion is outside that envelope, or when only the user can supply the input. Do not repeat "ask first", "do not mutate", or "wait for approval" at each step.
- Match freedom to fragility. High freedom for many valid approaches; medium freedom for a preferred pattern or parameterized command; low freedom when one known-good command or sequence exists and agents fail if they invent it. Write a fragile command once; collapse easy variants to one skeleton plus deltas.
- Validate to the risk. Mechanical contracts (frontmatter, paths, greppable invariants) go in . Behavior-bearing prose changes get a targeted eval per
bun test, on Claude and Codex, or an explicit skip reason in the report. Never ship an untested behavior change as "reference".references/evaluate.md
- 陈述条件,而非枚举场景。当你发现自己要为规则添加「以及当X时」的内容时,请明确X所代表的核心条件并直接陈述。需要枚举场景的规则说明其表述方式有误。
- 仅在Skill归属的层级规定机制。命令、退出码和状态转换属于拥有该机制的Skill(如负责PR检测)或低成本确定性工作。委托型Skill只需陈述条件、安全方向和不可推导的被调用方事实。
ce-commit-push-pr - 先清理冗余内容。在向模块中添加内容之前,先移除标准规定不应存在的内容。溯源依据决定排查深度,而非留存内容:查找断言该行内容的测试、记录该内容的文档,或是为修复特定Bug而添加该行内容的提交记录。找到溯源依据→该行内容是为了防护某种情况;除非其依赖方已不存在,否则保留该行,并注明其防护的对象。未找到溯源依据→应用准入原则(它是否陈述了可证伪的约束、抵消了已证实的默认倾向,或是提供了Agent无法推导的事实?);如果某行内容可能是为较弱模型或其他工具准备的保障措施,请勿直接删除,应先进行测试。说明哪些移除操作是基于无证据支撑的判断。
docs/solutions/ - 每移除一项强制要求,需明确当前由谁来决策。如果答案是「由模型自行决定是否执行必要步骤」,则该强制要求是必需的管控环节,应保留。移除「必须」字样并不等同于移除决策要求。
- 每一行内容都要有存在的价值:要么陈述可证伪的约束,要么抵消已证实的默认倾向,要么提供Agent无法推导的事实。单独指令后的理由说明、描述工作量的语言、能力重述均无存在价值。
- 面向用户的调用需适配工具——相关规则及位置在项目当前指令的「面向用户的Skill调用」部分;只要Skill会打印或复制调用指令,均需遵循该规则。
- 描述是上下文指针。对于模型调用的Skill,前置元数据会在每次交互时显示,因此比主体内容需要更严格的精简。首先用引导性提示词说明Skill是什么,然后为每个真正不同的分支添加一个正向触发条件(采用「当...时使用」或「用于...」的格式),最后仅添加能阻止真实误触发相邻场景的否定说明。身份模板、单分支的场景/同义词/能力列表、工作流、标志和流程均不应出现在描述中。
- 先设置一个全局完成标准。每个Skill都需要一个Skill层面的完成条件。仅当跳过本地完成检查会产生不安全操作、脆弱的状态转换、范围扩大、数据变更、授权错误或静默交接失败时,才添加本地完成检查。
- 为当前强模型精简提示词。每条指令只陈述一次。如果简短的指令可决定一系列行为,则使用该指令而非枚举所有行为。如果两个流程共享相同的命令框架,则编写一个带参数或差异说明的流程;如果框架相同,重复完整命令属于缺陷。
- 优先保障本组织多模型Skill的Sol可移植性。当Fable指南要求剥离流程或添加精简模块,与Sol指南要求保留已知有效的命令、必需的报告内容或禁止添加笼统的精简标语相冲突时,保留Sol格式。对于Fable来说,稍显冗长但清晰的指令是可接受的;但不能省略Sol关键的确定性要求。真正的冗余内容仍需删除。
- 可移植的长度控制需保留核心内容。绝不能在跨模型Skill中添加笼统的「简明扼要」/「保持简短」标语。明确简短报告必须包含的内容和可省略的内容;对于CLI包装器,需保留命令、退出状态、输出路径/大小,以及 stderr 或阻塞信息。
- 自主性是一项紧凑的策略。明确安全的本地操作,允许用户请求范围内的后续工作进行,包括作为请求任务或Skill权限范围内指定的外部写入操作。仅当外部写入、破坏性操作、采购或实质性范围扩大超出该权限范围,或是只有用户能提供输入时,才需确认。不要在每个步骤重复「先询问」、「不要修改」或「等待批准」。
- 自由度与脆弱性匹配。对于多种有效方案,给予高自由度;对于首选模式或参数化命令,给予中等自由度;当存在已知有效的命令或序列,且Agent自行发明会失败时,给予低自由度。脆弱命令只需编写一次;将简单变体合并为一个框架加差异说明。
- 根据风险进行验证。机械性约定(前置元数据、路径、可通过 grep 查找的不变量)需在中验证。涉及行为的 prose 变更需根据
bun test进行针对性评估(在Claude和Codex上),或在报告中记录明确的跳过理由。绝不能将未经测试的行为变更作为「参考内容」发布。references/evaluate.md
Modes
模式
Pick the mode from what you were asked to do; a request can chain them (a review that becomes an edit).
| You are | Read | Done when |
|---|---|---|
| Creating a new skill | | The outcome spine exists before any workflow, activation cases are written, repo inventory is updated, and the eval ran or its exact skip reason is recorded |
| Changing an existing skill | | The touched block meets the standard, nothing your change contradicts remains, and validation ran |
| Reviewing a skill change | | Every finding is Change / Verify / Consider with the evidence its class requires, and each Change names a condition or an owning-layer move |
| Acting on review feedback for a skill | | Each item has a verdict, each Change closed a gap at its owning layer, and no block was patched twice |
根据你的任务选择对应的模式;一个请求可串联多个模式(例如审核后进行编辑)。
| 你正在进行的操作 | 需阅读文档 | 完成标准 |
|---|---|---|
| 创建新Skill | | 核心成果框架已搭建(先于任何工作流),激活场景已编写,仓库清单已更新,并且已执行评估或记录了明确的跳过评估理由 |
| 修改现有Skill | | 被修改的模块符合标准,与你的变更相矛盾的内容已全部移除,并且已完成验证 |
| 审核Skill变更 | | 所有发现均标注为「修改/验证/考虑」类别,并附带对应类别所需的证据;每个「修改」项均明确了条件或归属层调整方向 |
| 响应Skill审核反馈 | | 每个反馈项均给出结论,每个「修改」项均在其归属层填补了漏洞,且没有模块被重复修补 |
Completion report
完成报告
End every mode with a report shaped by what the mode does. Mutating modes (new, edit, respond): per touched block, the goal it now states, what was removed and its provenance result; what was intentionally left short of the standard and why it is out of scope; what validation ran and its result or the exact skip reason; any decision that would materially change the skill's contract that you did not make. Review mode: the findings by class with the evidence each carries, and — where the caller has a summary channel — the paths you checked that any restatement still serves and what you could not verify. The report goes to whatever channel the caller provides; when the caller accepts only a findings list, that list is the report and satisfies Done. Review changes nothing, so it never has changed-block entries.
每个模式结束后需提交符合该模式要求的报告。变更型模式(创建、编辑、响应):针对每个被修改的模块,说明其当前陈述的目标、已移除的内容及其溯源结果;说明有意未完全遵循标准的内容及原因(超出范围);说明已执行的验证及其结果,或明确的跳过理由;说明任何会实质性改变Skill协议但你未做出的决策。审核模式:按类别列出所有发现及对应的证据;如果调用方有汇总渠道,说明你已检查且仍适用的路径,以及无法验证的内容。报告需提交至调用方指定的渠道;如果调用方只接受发现列表,则该列表即为报告,满足完成标准。审核模式不会修改任何内容,因此无需包含模块变更记录。