用途
claude-attribution 用于在公开协作场景中披露某段内容由 Claude 起草。它针对的是评论、Issue、PR 描述、代码评审回复和 Trac 评论等文本。规范给出的核心理由来自一位评审者的原话（Gutenberg#81397）：读者无法判断回复是 Claude 生成的还是本人的看法，而明确区分有助于让对话保持为人与人之间的协作。
该规范只管辖标注与边界；行文风格由配套技能 adams-voice 管辖。
主要能力
带标注评论的结构由三部分组成，按此顺序排列：
- 本人的一句话，位于引用之外。用一两句自己的语气说明看法、对读者的期待或下一步计划，用来维持对话属性。仅当交接本身就是全部内容时才可省略。
- 标注语标题，位于引用之外，斜体，单独成行。此处是本人说话，所以使用“我”。
- Claude 起草的正文，整体块引用。每一行都以
>开头，包括段落之间的空行，使引用条贯穿回复的完整高度。
标注出现的两个位置：
- 标题加块引用：用于 Claude 起草的评论、Issue、PR 描述、代码评审回复或 Trac 评论。
- AI Use 脚注：PR 或 Issue 底部的
## AI Use段落，说明 Claude 写了什么（描述、代码或两者），并保留本人的审查承诺。此处不加引用、不用斜体，因为## AI Use标题本身已将其区分开。
使用方式
硬性要求（除这些之外都可变化）：
- 起草正文必须块引用，每一行包括段落间空行都要前缀。只引用第一段比不引用更糟，因为其余部分会被读成本人的话。
- 必须点名 Claude。每个标题都写 “Claude” 或 “Claude Code”。
- 必须说明 Claude 做了什么：撰写、调查、起草、挖掘。读者应知道 Claude 产出的是文字、代码还是两者。
- 标题保持一行，约 12 词以内。它是标签，不是引言。
- 标题用斜体，用下划线包裹。在 Trac 上改用 Wiki 格式
''...''。句式库以纯文本写出，发布时再加斜体。 - 任何包含代码的 PR，其 AI Use 脚注必须保留 “I will review and test.”，这是承诺而非修饰，不可玩笑化、不可省略。
- “我”属于本人，且只在引用之外使用。引用之内按 adams-voice 的标注规则去掉 “I” 和 “my”。
块引用机制：
- 引用内的代码块，围栏行也要加
>。 - 不要在引用内引用第三方，嵌套
> >不可读且混淆说话人；改为点名并转述，或把对方的话提到上方本人的部分。 - 列表、表格、图片都可放在
>之后，逐行加前缀。 - Trac 使用相同的
>引用前缀，格式可直接沿用。 - 很长的输出（超过一两屏）可放进 GitHub 的
<details>块，以标注语标题作为<summary>。但应少用，因为折叠回复容易被忽略，而重点正是可见性。
语气：轻松但不疯癫。参考词汇如 “wonky”、“a big, easy win”、“took another swing at it”。一句轻度措辞，然后让开。经验规则：一行一个意思，不堆叠笑点；不开读者玩笑，不调侃 bug 明显或报告者有误；不虚构投入或事实；🤖 可用于 AI Use 脚注，标题保持无表情符号；同一话题内不重复已用措辞，同一仓库内尽量不重复上一条评论的措辞。
遇到安全议题、用户报告真实故障或数据丢失、激烈或有争议的讨论、时间紧迫的发布阻塞、以及对沮丧报告者的首次回复时，改用平实措辞，例如只说 “I asked Claude to look into this, here is what it found:”。块引用在任何情况下都保留，它是边界而非修饰。
生成新句式的方法：从三个槽位各选一项——谁做的（Claude、Claude Code、I asked Claude、I pointed Claude at this）、怎么做的（dug in、took a deep dive、chased it down、read the whole thread、with some careful prompting、after a few rounds of back and forth）、交接（here is what it found:、and this came back:、which reports:、here is where it landed:）。并非每句都需要三个槽位。动词要与实际工作匹配：“dug into”“chased this down” 适合调查，“Claude's take” 适合观点，“sanity check” 适合对已有判断的二次确认。
规范提供了散文式标题与 AI Use 脚注两组句式库，每组含多条示例。脚注示例中，仅写描述、不含代码的版本无需审查承诺，其余含代码的脚注均保留 “I will review and test.”。
短回复仍然跳过标题：本人会自己写的一段以内回复无需标注。判断标准是谁写了这些词，而不是长度。如果是 Claude 起草并原样转发，即使很短也要标注并引用；如果本人读后用自己的话重写，就是本人的，直接发布。
规范给出四个示例：GitHub Issue 上的一次常规调查、针对设计问题的第二意见、安全报告的平实标题、以及一个 PR 脚注。
适用场景
适用于以本人名义对外发布的、由 Claude 起草的协作文本，覆盖 GitHub 评论、Issue、PR 描述与评审回复，以及 Trac 评论。
限制
反模式清单列举了应避免的做法：起草正文不加引用；只引用第一段；把本人的回复塞进引用内，导致整条评论都是机器口吻；在 Claude 引用中嵌套第三方引用；在整条话题或整周话题中粘贴完全相同的标注句；在安全议题、数据丢失报告或有争议话题上使用俏皮标题；在含 Claude 代码的 PR 中丢掉 “I will review and test.”；表情符号堆叠、感叹号堆叠或炒作词；声称 Claude 并未实际拥有的投入、时长或确定性；多行或多句标题；在本人会自己写的一行回复上加标题；标题未加斜体（会被读成回复首句）或改用加粗（加粗保留给正文中唯一的关键分句）。
以上为技能文档所述内容，具体平台行为与工具支持范围暂未提供。