这个 Skill 能做什么，适合哪些场景？
这是一个面向 Effect 代码库的文档技能，位于 pingdotgg/t3code 仓库（MIT 许可）内，专门处理 Effect 公共 API 的 JSDoc 注释。它规定了统一的注释模板（短描述、When to use、Details、Gotchas、Example）、标签顺序（@deprecated、@default、@see、@category、@since）以及大量文风约束，使注释能通过 jsdocs oxlint 自定义规则并支持 JSON 文档提取。技能包含完整的工作流：先检查声明与测试，再改写注释，最后运行 pnpm docgen 和 pnpm lint 做最小化验证。适合维护 Effect 库、需要稳定文档风格的团队使用。
- 检查声明、实现、附近测试与现有 JSDoc 后，按标准模板改写公共 API 注释
- 对单个 API 修复或整模块精炼两种任务分别给出工作流
- 执行 @see 审计：只保留指向语义相关公共 API 的标签
- 执行 Gotchas 审计：把真实的边界情况与易错行为归入 Gotchas 段落
- 校验标签要求：根声明需 @category 和稳定 semver @since，成员 JSDoc 可用 @default
- 运行最窄相关验证：包目录下 pnpm docgen，以及 pnpm lint
- 维护 Effect 库的开发者在新增导出 API 时，需要一次写出符合 jsdocs 规则的注释，避免 lint 报错返工
- 接手遗留 Effect 模块的贡献者想精炼整个模块的文档，但不确定哪些 @see 该保留、哪些注释该归入 Gotchas
- 团队需要解决 oxlint 的 jsdocs 诊断（如缺少 @since、@example 不合规），并准备文档用于 JSON 提取
- 评审公共 API 文档的维护者，用它作为检查清单核对示例标题、段落顺序和文风是否达标
- 不使用 Effect 库的 TypeScript 项目——注释模板和 @category/@since 约定都是 Effect 专属的
- 只想生成任何代码文档（而不受 Effect 风格约束）的团队——它不提供其他风格的模板
- 没有 pnpm/docgen/lint 工具链的环境——技能指定的验证步骤无法执行
如何安装这个 Skill？
- 未验证发布者身份，需谨慎对待维护承诺。
- 技能只针对 Effect 生态，若用于其他框架可能不适用。
- 验证命令 pnpm docgen 和 pnpm lint 依赖于具体项目配置，可能无法在隔离环境中运行。
- Shell / 命令行
- 本地文件系统
pnpm (for validation: pnpm docgen, pnpm lint)
来源未提供该技能的独立安装命令。技能文件位于 t3code 仓库的 .repos/effect-smol/.agents/skills/jsdocs/SKILL.md，需自行将该目录复制到你的 Agent Skills 兼容客户端的技能目录。T3 Code 本体的安装方式见仓库 README（与其技能集是不同的事情）：
T3 Code 本体（npx 运行）
npx t3@latestT3 Code 桌面版（macOS，Homebrew）
brew install --cask t3-codeT3 Code 桌面版（Windows，winget）
winget install T3Tools.T3CodeT3 Code 桌面版（Arch Linux，AUR）
yay -S t3code-bin如何使用这个 Skill？
安装后，把下面任意一句发给 Agent 即可触发：
- 给 src/Schema.ts 里新导出的 decodeUnknown 函数补上符合 jsdocs 规则的 JSDoc，包含 @category 和 @since
- 精炼整个 src/Platform.ts 模块的公共 API 文档，做一遍 @see 和 Gotchas 审计
- 解决 oxlint 报出的 jsdocs 诊断：这个 API 的 @example 要改成 **Example** (Title) 段落
- 检查 Event.ts 的现有 JSDoc 是否满足公共 API 文档要求，把松散的 ts 代码块整理成标准示例
技能由模型在遇到 JSDoc 相关任务时自动触发（其 frontmatter 描述了适用场景：新增/修复 JSDoc、解决 jsdocs 诊断、准备文档提取、评审公共 API 文档）。使用流程：
- 向代理描述任务（修某个 API 或精炼整个模块）；
- 技能指示代理先检查声明、实现和附近测试，再改写注释为标准模板；
- 模块级任务会额外执行 @see 与 Gotchas 审计；
- 最后按变更范围运行验证：
pnpm docgen
pnpm lint仅编辑技能文风内容时不要求运行大范围验证。
这个 Skill 有哪些优点和局限？
- 规则极其具体：模板结构、标签顺序、示例标题写法、验证命令全部明文规定，输出可预期
- 包含 @see 和 Gotchas 两个专项审计，适合整模块的系统性文档精炼
- 强调最小化验证，避免对纯文案修改跑不必要的全量检查
- 文风规则（如 When to use 以 Use when/Use to 开头、示例标题用动名词）保证文档一致性
- 高度绑定 Effect 生态与 jsdocs oxlint 规则，对其他代码库几乎不可复用
- 验证依赖 pnpm docgen 和 pnpm lint，需要已配置好的 Effect 包环境
- 规则篇幅很长，属于重量级指令技能，可能占用较多上下文
- 来源未提供该技能本身的测试或使用效果数据
这个 Skill 与同类方案有什么区别？
与相关 Skills 并排比较；分数均按同一 FSRS 标准得出。
| Skill | FS 评分 | Star 数 | 最近更新 | License |
|---|---|---|---|---|
| Effect JSDoc 规范撰写技能 本页 | 77 · 高度推荐 | ★ 26k | 3 天前 | MIT |
| Anti-Slop：反低证据代码模式的 Oxlint 规则集 | 62 · 推荐 | ★ 5.3k | 1 个月前 | MIT |
| cmux 后端开发规则技能 | 51 · 谨慎使用 | ★ 28k | 今天 | NOASSERTION |
| Scratchpad 示例提取器 | 49 · 谨慎使用 | ★ 26k | 3 天前 | MIT |
| TradingView Lightweight Charts 技能 | 68 · 推荐 | ★ 18k | 3 天前 | Apache-2.0 |
FollowSkills 如何评估这个 Skill？
该技能只涉及文档编写，不执行命令或修改文件，权限最小化。验证步骤提示运行 pnpm docgen 和 pnpm lint，但需要用户主动执行。未发现敏感数据处理或外部副作用。来源归属清晰：仓库有 MIT 许可证，但发布者未经验证。因此信任得满分。
技能描述清晰、流程一致，但静态审查无法执行验证。存在测试文件（如 .repos/alchemy-effect 下的集成测试），但并非直接针对此技能。因此可靠性仅给中档，因静态限制不能超过 10。
应用场景明确（编写或修复 Effect 公共 API 的 JSDoc），触发条件精准（解决 jsdocs 诊断、准备 JSON 提取等）。边界明确：不支持模块级注释或默认导出。环境适配上，所有文档操作为本地，无需海外服务，适合中文用户。因此给满分。
信息架构良好，分工作流、格式、规则、审计。提供安装/依赖说明（如 pnpm docgen）。有版本说明（@since 要求）和许可证。但无 changelog 和明确维护者，发布者未验证。因此给满分，因为文档本身很完整，扣分点为维护责任不明确。
从描述看，技能能完成核心任务：生成符合规则的 JSDoc。但静态评估无法验证输出是否直接可用，且该技能主要指导 LLM 生成代码，边际价值不明确。因此给 7，因静态限制不能超过 7。
仓库有 CI 工作流（如 .github/workflows/ci.yml）和测试文件，但并非直接针对此技能。静态审查无法独立复现技能行为，因此不超过 5。
点击维度查看打分理由
证据充分度：低 — 主要依赖静态检查、作者材料或有限演示；适合发现线索，不适合做高风险决策。
查看完整评分方法 →