用途：在编写或修改跟踪系统中的条目时使用，包括史诗、故事、任务、缺陷报告、调研（spike）与验收标准，也包括把讨论、评审发现等转化为问题单。不适用于权衡设计方案——需要论证设计时用 writing-design-docs，问题单只链接设计文档而不内联。本技能只覆盖写作，不涉及优先级或流程建议。前置要求：technical-writing 技能（硬性规则、真实规则、风格）。
主要能力与写作骨架：核心原则是“不依赖作者也能存活”，每份问题单回答四问：什么结果（世界达到的状态，而非步骤）、什么决定 Done（可独立检验的验收检查，如“上传失败显示重试横幅并以 WARN 记录日志”）、证据是什么（链接仓库路径、文档、URL）、谁负责未决部分（点名或标为 unassigned，禁止含糊归属）。故事/任务骨架含 Problem/Why、Outcome、Acceptance 清单、Out of scope、Open items、Sources；缺陷报告先写 Symptom（原样报错字符串，可搜索），再 Reproduction、Expected、Actual、Environment、Open items、Suspected cause（仅调查过且标为假设）。团队使用 Gherkin 风格 given/when/then 时也可作验收格式。
用法与约定：读先行——填写前读同类最近最多两条问题单并对齐惯例，不足则照填。报告人联系不上时按“具名缺口”直接提交，不阻塞。技术的检查点（类型、读者、目的、非目标）是唯一应停下来询问的地方。类型表每跟踪系统一份、一行定义：史诗、故事、任务、缺陷、spike（产出是决定，不是代码）。规则包括：单一归属（问题单管 what/why，仓库中的计划管 how）；票据键只出现在提交与计划文档，不进代码、注释、测试名或用户可见字符串；信任代码而非问题单状态；追加不重写（范围变更用带日期追加说明）；子任务为粗粒度可审查切片；估算需标注并说明依赖；关闭时记录原因，尤其是 won't-fix 与重复。验收须过“做什么不写怎么做”“有可验证输出”的可测试性门槛；故事可用 INVEST 做规模检查，不满足 small 或 testable 应先拆分。
限制：资料未提供安装方式、命令、价格、平台支持及具体工具集成等事实；上述内容仅为写作规范与流程约定。