Guides Platform

Appearance

i-have-adhd：让编程 Agent 先给行动，再给解释 ​

编程 Agent 给出的答案可能技术上正确，却把真正要执行的命令藏在背景、备选项和客套话之后。读者需要反复滚动，才能重新确认“现在做到哪一步”和“接下来只做什么”。i-have-adhd 把这个问题当成输出结构问题：先给动作，多步骤编号，每轮重述进度，错误直接写位置、原因和修复办法；当任务本身需要完整解释时，再放宽篇幅限制。

仓库的主要交付物是一套 i-have-adhd Skill，而不是诊断工具或任务管理器。skills/i-have-adhd/SKILL.md 是唯一行为源，Cursor 目录中保留一份同步镜像；插件清单、命令、hook 和扩展负责把同一套规则接入不同 Agent。这个区别很重要：使用者得到的不是两个功能相近的 Skill，而是一份规则在多个运行时中的不同装载方式。

GitHub 仓库信息 ​

信息内容
项目标题i-have-adhd
项目描述面向编程 Agent 的 ADHD 友好输出 Skill，让回答先呈现下一步行动，以编号步骤、进度重述和克制的错误说明降低执行摩擦。
GitHub 仓库ayghri/i-have-adhd
官网地址未知（已检索但未找到独立的项目官网）
主要开发语言Python 85.37%、TypeScript 7.2%、JavaScript 5.05%
开源许可证MIT
最近代码更新2026-09-16（GitHub pushed_at；核对日期：2026-09-18）

插件清单当前标记版本为 0.3.0，仓库没有 GitHub Release。安装命令默认跟随 main，因此重装或更新可能取得晚于本文固定提交的内容；希望稳定复现时，应先审查目标 revision 再安装。

一份规则怎样覆盖多个 Agent ​

Skill 正文只有 142 行，却不等于“让回答短一点”。十条规则共同改变信息出现的顺序：第一行给可执行动作，复杂任务只展示当前工作集，跨轮对话重述状态，完成后给出可观察结果，尚有后续时只留下一个短动作。规则还明确保留例外：解释型请求可以展开，危险操作必须先确认，连续三轮调试失败后应停止猜修，系统或宿主指令始终优先。

仓库把内容与装载机制分成四层：

层次主要内容作用
行为源skills/i-have-adhd/SKILL.md定义触发语义、持续状态、十条规则、例外和发送前检查
兼容镜像.cursor/skills/i-have-adhd/SKILL.md为 Cursor 保留相同内容；不是第二个独立能力
分发入口Claude、Codex、Gemini、Kimi、Qwen 等 manifest，以及安装文档告诉各运行时从哪里发现 Skill、如何显示和调用
持续状态SessionStart hook、Pi/OMP 扩展、OpenCode 插件和全局指令示例处理显式启用、常驻启用、会话恢复、压缩后重注入和关闭

Skill 包内部没有 references/、scripts/、templates/ 或任务素材；规则全文直接放在 SKILL.md。仓库级 scripts/ 与 evals/ 用于维护和评测，不会在普通对话中被 Skill 自动加载。logo.png 是插件展示资产，也不参与回答生成。这样的包很轻，但行为质量主要依赖模型是否遵循文字指令，缺少独立的确定性格式化器来兜底。

安装前先选作用范围 ​

固定提交中的安装文档列出 Antigravity、AstronClaw、Claude Code、Codex、Grok、Gemini CLI、GitHub Copilot、Hermes、Kimi Code CLI、OpenCode、Pi、Oh My Pi、Qwen Code、Zed，以及 Cursor、Amp 等通用 Agent Skills 宿主。本文没有逐个平台执行安装；兼容性属于仓库文档与 manifest 的静态证据。

这些入口可以归为三类：

方式适合场景代价
显式 Skill 或命令只想在当前会话、当前任务使用每次需要主动输入 $i-have-adhd、/i-have-adhd 或对应命令
插件或扩展运行时需要命令、状态恢复或 hook会安装 manifest、扩展或 hook；应先审查来源和写入位置
全局指令文件希望所有会话默认采用相同输出风格影响范围最大，可能与团队规范、长文任务或其他输出风格冲突

对 Codex，仓库给出的按需安装方式是：

bash
codex plugin marketplace add ayghri/i-have-adhd --ref main
codex plugin add i-have-adhd@i-have-adhd
codex plugin list

这组命令从普通终端执行，不要求进入业务仓库；前两条会改变当前用户的 Codex 插件安装状态，并通过网络读取 GitHub 仓库，第三条只做列表检查。成功信号是 codex plugin list 中出现 i-have-adhd。仓库文档没有说明 Codex 在既有同名配置上的合并或覆盖细节，因此安装前应先查看当前列表；命令失败时保留原始错误，检查 Codex 是否支持 plugin 子命令及 GitHub 访问是否正常，不要用 sudo 或手工改写配置来绕过失败。本文没有执行这些命令。

安装后输入 $i-have-adhd 才会显式启用，allow_implicit_invocation: false 与 Skill 的 disable-model-invocation: true 都表达了默认不让模型自行开启。若只想在一个项目试用，也可以把 canonical Skill 目录放到该项目支持的 Skills 路径，而不把规则写进用户级 ~/.codex/AGENTS.md。

更新前先阅读仓库 diff。卸载 Codex 版本时运行：

bash
codex plugin remove i-have-adhd
codex plugin marketplace remove i-have-adhd

Claude Code 使用 marketplace 与 plugin 命令；Gemini 同时提供按需 custom command 和默认常驻的 extension；GitHub Copilot、Cursor、Amp 等可以通过 Skills 目录分发。需要准确命令时以固定提交下的 INSTALL.md 为准，不要把一个平台的启用方式套到另一个平台。

最短有效体验 ​

安装成功不代表规则已经生效。以 Codex 的显式模式为例，新开一个会话，先输入：

text
$i-have-adhd
请解释怎样在新目录中创建一个空 Git 仓库，并告诉我完成后如何确认。

预期结果至少满足三个可观察信号：第一行直接给出创建目录或初始化仓库的动作；多个动作采用编号；结尾只留下一个可以立即执行的验证步骤。若回答仍以背景说明开头，或没有出现清晰的下一步，说明“插件已列出”只验证了安装，尚未证明 Skill 被当前会话加载。

关闭时输入 stop adhd mode 或 normal mode。Skill 要求 Agent 用一行确认并恢复默认风格。再问一次同类问题，确认回答不再受持续规则约束。以上是可手工执行的验收路径，本文没有安装目标插件，也没有把预期输出冒充运行结果。

i-have-adhd 基础档案 ​

项目内容
功能重排编程 Agent 的回答，使行动、进度和错误处理更容易找到
适用多步骤编码、调试、仓库操作和需要跨轮保持状态的任务
不适用ADHD 诊断或治疗、需要原样格式的输出、必须完整展开的长篇解释
触发Codex 使用 $i-have-adhd；其他宿主使用各自的 Skill、slash command、插件或扩展入口
输入与依赖普通用户请求；canonical 模式本身只有 Markdown 指令，不要求浏览器、账号或付费 API
预期产物同一任务的行动优先回答，不生成独立业务文件
验证检查首行、编号、状态重述、单一下一步和关闭后的风格恢复
副作用按需模式改变当前会话输出；插件安装、全局指令和 always-on 标记会写入用户或项目配置
证据等级Skill 行为与适配机制为静态确认；实际 Agent 遵循程度未在本文运行验证

显式与常驻两类触发路径 ​

按需模式的关键不是“提示一次”，而是让会话持续携带规则：

Mermaid 流程图
查看源码
flowchart LR
    Install[安装或放置 Skill] --> Invoke[显式调用 i-have-adhd]
    Invoke --> Load[加载 canonical SKILL.md]
    Load --> Reply[按十条规则生成回答]
    Reply --> Check[检查首行动作、编号与下一步]
    Check --> Continue[后续轮次重述当前状态]
    Continue --> Stop[stop adhd mode / normal mode]
    Stop --> Default[恢复宿主默认风格]

在 Claude Code 的常驻路径中，用户先创建 .i-have-adhd-always 标记。SessionStart hook 只有看到标记才读取 canonical Skill，剥离 YAML frontmatter 后把规则写到启动上下文；文件不存在或读取失败时直接退出，不阻断会话。删除标记关闭后续会话的自动注入，当前会话仍可用停止短语退出。

这条常驻路径可以完整地手工验收：

  1. 先用 claude plugin list 确认 i-have-adhd 已安装，再运行 touch ~/.claude/.i-have-adhd-always 创建选择加入标记。
  2. 新开 Claude Code 会话，不输入 /i-have-adhd，直接提交前文创建空 Git 仓库的测试请求。
  3. 检查回复是否从动作开始、用编号组织步骤，并只留下一个明确的下一步；这些是常驻注入生效的可观察信号。
  4. 运行 rm ~/.claude/.i-have-adhd-always，结束当前会话，再新开会话提交同一请求；新会话不应再自动注入规则。
  5. 如果标记没有生效，固定提交的排障说明要求更新 marketplace 插件并重启，因为 hook 只在启动时读取。

这仍是依据仓库文档和 hook 源码整理的手工验收建议，并非本文已经运行的结果。创建或删除标记只针对默认 ~/.claude 配置目录；使用 CLAUDE_CONFIG_DIR 时应在对应目录操作。

Pi/OMP 扩展处理得更细：扩展保存启用状态，把“规则已注入”和“已关闭”写成不同的上下文标记；会话树恢复或上下文压缩后，扩展会检查最新标记，必要时重新注入。多运行时兼容真正困难的部分，是防止规则在会话恢复、主题切换和上下文压缩后悄悄失效。

OpenCode 的 always-on 路径会在每轮系统提示中追加规则，影响范围和上下文成本都高于一次性注入。选择常驻模式前，应先判断宿主是否已有团队级指令、输出模板或安全策略；宿主高优先级规则与任务的明确格式要求仍然优先。

评测结果要连同失败一起读 ​

仓库提供了可复现的评测框架，而不只是 README 中的“前后对比”。记录于 2026-08-02 的首轮结果使用 claude-opus-4-8、14 个案例、每种条件 3 次试验，共 84 条响应；盲评的加权分从基线 4.045 提升到候选 4.473，行动性和简洁性增幅最大。

这组数字没有让 Skill 通过仓库自己的发布门。候选仍有 3 个 blocking finding，因此结果明确标为 FAILED。其中两项来自无法使用工具却要求 Agent 实际编辑仓库的评测设计缺陷，另一项是真正值得警惕的回归：在 partial-success 场景中，规则要求“原因、再修复”，可能推动模型在证据不足时把某个原因写成确定事实。三次试验不足以证明稳定效果，同一模型家族生成并裁判结果也限制了外推范围。

因此更稳妥的用法是保留“行动优先”，同时要求错误原因区分已确认、推测和未知。仓库已把安全确认、真实歧义和调试循环列为破例条件，但使用者仍应观察自己的任务集，而不是把一次评测当成所有模型与 Agent 的质量证明。

安全、成本与适用判断 ​

canonical Skill 不读取凭据、不启动浏览器、不调用付费服务，也不直接提交 Git 或发布内容。风险主要来自安装和持久化层：插件管理器需要网络访问并写入配置；全局 AGENTS.md、GEMINI.md 或 always-on 标记会扩大影响范围；OpenCode、Pi/OMP 等适配器会读取本地 Skill 和状态文件。安装前检查固定 revision、manifest 与 hook，卸载时同时移除 marketplace、插件和常驻标记。

i-have-adhd 适合经常被长回答打断执行节奏、希望 Agent 每轮明确状态的开发者。若只偶尔需要短答案，一条项目级输出约定成本更低；若平台原生支持 output style，原生配置通常比跨平台插件更容易维护；若团队必须共享统一行为并希望在多种 Agent 之间迁移，这个仓库的 canonical Skill 加适配器结构才显出价值。

不要照搬“列表最多五项”作为分析上限。Skill 已明确，这条规则只约束可见工作集，不能删掉完整性所需的信息；安全审计、候选比较和接口清单仍应保留全量结果，再分组展示。也不要把“错误写原因”变成强制确定语气，证据不足时写“尚未确认原因，先检查……”比给出干脆但错误的结论更可靠。

值得学习的设计 ​

仓库最值得借鉴的是单一行为源：规则只在 canonical SKILL.md 中维护，manifest、hook 与扩展围绕 canonical 文件适配，Cursor 镜像还有明确的同步约束。第二个优点是启用权交给用户，显式调用、常驻模式和停止短语各自有清楚边界。第三个优点是仓库公开了失败的评测门和负向案例，没有把总分提升包装成已经解决所有质量问题。

维护成本也很现实。平台越多，安装命令、触发语法、状态恢复和卸载路径越容易漂移；仓库没有 Release，默认跟随 main 增加了复现成本；纯指令型 Skill 最终仍依赖模型遵循，跨模型效果需要新的隔离评测。想定制规则时，先 fork 并修改 canonical 文件，再检查镜像、manifest、安装文档和评测是否同步，而不是只复制 README 中的十行摘要。

继续探索 ​

先阅读固定提交中的 canonical Skill，再按自己的 Agent 打开 安装说明。需要常驻模式时，继续核对 SessionStart hook 或对应运行时扩展；评估是否值得采用时，把 评测结果 中的失败门、样本量和回归案例一起纳入判断。

参考资料 ​

全部公开文章由同一个站点构建和发布。

Guides Platform