author-item
仅在明确要求撰写、归档、组织或修订工作成果项、问题工单、成果简报或待办事项条目时使用（第 1 阶段 ATDD：定义目标、可观察的正向与负向验收测试用例、约束和参考，而不规定实现步骤），或在按延迟成本除以持续时间（CD3 / WSJF）对积压事项排序时使用。当需要把模糊请求或分步任务清单转化为结构化的 WHAT-only 工作项或简报时使用。当被要求直接添加、构建或实现代码功能、解析器能力或导出格式时不要使用（改用 deliver-and-verify，即使工作区为空）；起草或评估发布计划、架构、技术栈、合同或预算时不要使用（改用 challenge）；调查故障或解除任务阻塞时不要使用（改用 prove-it 或 unblock）；撰写或翻译面向用户的文案时不要使用（改用 clear-writing）。
机器翻译查看英文原文
Use ONLY when explicitly asked to write, file, structure, or revise a work outcome item, issue ticket, outcome brief, or backlog entry (Stage 1 ATDD: defining goal, observable positive and negative acceptance test cases, constraints, and references without prescribing implementation steps), or when ranking backlog items by Cost of Delay divided by Duration (CD3 / WSJF). Use when turning a vague request or step-by-step task list into a structured WHAT-only work item or brief. Do NOT use when asked to add, build, or implement a code feature, parser capability, or export format directly (use deliver-and-verify, even if the workspace is empty), when drafting or evaluating a launch plan, architecture, tech stack, contract, or budget (use challenge), when investigating a failure or unblocking a task (use prove-it or unblock), or when writing/translating user-facing copy (use clear-writing).
适用对象：软件开发与测试。自动收录 · 待核查。
原作者说明节选
从固定版本的 SKILL.md 提取，保留原文语言。以下内容属于作者说明，本站尚未验证安装、兼容或运行结果。
查看英文原文
原文涵盖的主题
- Author an Outcome Item (author-item)
- 1. Stage 1 ATDD: Write Acceptance Test Cases First
- 2. Granularity & Splitting Rules
- 3. Domain Reference Standards (Load When Needed)
An outcome item states the goal, observable acceptance tests, constraints and references. The executing agent chooses the implementation path. This applies acceptance test-driven development (ATDD) to software, product, commercial and operational work. Before drafting a client UI brief, read the executable backend contract using references/client-contract.md. This applies even when the request supplies a plausible screen sketch. When authoring an item, use four fields: 1. Goal (goal): One plain sentence stating who benefits and what changes in the real world (for users, customers, partners, or operators), plus the parent objective and economic value inputs (cost of delay / duration, see references/priority.md). If the request is a list of tasks or steps, extract the single outcome those steps were trying to achieve. 2. Acceptance Test Cases (acceptance): Write concrete, externally observable positive test cases (what must succeed on the real user/partner/operator surface) and negative/invariant test cases (what must be refused, prevented, or left unbroken). Every acceptance criterion must be verifiable without reading the author's session transcript: Software / Product: end-state d
这里只展示节选，请以完整原文和当前要求为准。
- 来源仓库
- SylphxAI/skills
- 源文件
- skills/author-item/SKILL.md
- 固定版本
- e61c6f49e7bc2ac4f764590438fe01a689addefb
来源与内容状态
本条为自动发现的元数据，尚未完成人工文档核查；适用性与运行结果待核查。
原作者：SylphxAI/skills · 原作者仓库元数据。文档核查：未核查。最近来源检查：2026-11-10T01:01:23.919Z。
分类由名称、说明与路径规则生成，分类不代表已核实适配。
许可与权利归属
MIT。第三方内容及版权归原作者，使用条件以原文为准。
许可原文 ↗本站没有因同步、复制或用户自报成功而将资源标为运行验证通过。
限制与注意事项
- 元数据收录不代表本站已经安装、适配、实测或进行安全审查。