mcpField
A
agentic-skills

agentic-skills

github.com/akillness开发53124 次安装1 天前更新
代码仓库

关于 agentic-skills

agentic-skills 是面向 AI Agent 软件开发的工程工作流框架，覆盖规格定义、规划、实现、测试、审查和发布。它适合需要渐进式开发、依据来源做决策并设置明确质量检查的团队。

主要功能

  1. 01先定义规格再规划
  2. 02通过 TDD 渐进式实现
  3. 03依据来源决定 API 和 SDK 用法
  4. 04运行时、浏览器与安全检查
  5. 05代码审查和发布工作流

适用场景

  1. 01将含糊需求整理为规格
  2. 02分阶段构建并验证软件
  3. 03发布前审查安全性和质量

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/akillness/jeo-skills --skill agentic-skills

安装后在 Claude Code 中输入/agentic-skills确认已加载。

详细介绍

agentic-skills — AI Agent 生产工程框架

关键词：agentic-skills · /spec · /plan · /build · /test · /review · /code-simplify · /ship

“看起来没问题”远远不够。——每项输出都必须以可衡量的验证为依据。

agentic-skills 是一个生产级工程框架，将资深工程师构建软件时采用的工作流、质量关卡和最佳实践编码其中。它借鉴了 Google 的工程文化（Software Engineering at Google）：主干开发、左移测试、Hyrum 定律、Chesterton 的围栏，以及代码即负担的理念。

插件安装（Claude Code）：

/plugin marketplace add addyosmani/agent-skills
/plugin install agent-skills@addy-agent-skills

何时使用此技能

  • 请求需要严格遵循先编写规范再编写代码的约定，以防偏离目标
  • 需要通过精简的垂直切片和频繁验证来逐步实现
  • 任务要求在发布前采用测试驱动开发（Red → Green → Refactor）
  • 任务涉及安全加固或 OWASP Top 10 防护
  • 用户希望以官方文档为依据开展源驱动开发
  • 需要以 Core Web Vitals 为目标进行性能优化
  • 需要生产级 Git 工作流（主干开发、原子提交、CI/CD 质量关卡）
  • 合并前需要依据五个质量维度进行代码审查
  • 生产发布前需要发布清单和分阶段推出

何时不使用此技能

  • 用户需要多 Agent 编排路由 → 转交给 jeo、oh-my-claudecode 或 harness
  • 任务主要是实施前的全局调研 → 转交给 survey
  • 用户需要一次性快速修复，不需要质量关卡 → 直接执行
  • 用户希望设计 Agent 团队 → 转交给 harness

安装

Claude Code（推荐）
/plugin marketplace add addyosmani/agent-skills
/plugin install agent-skills@addy-agent-skills
# Or via HTTPS:
/plugin marketplace add https://github.com/addyosmani/agent-skills.git
Gemini CLI
gemini skills install https://github.com/addyosmani/agent-skills.git --path skills
Cursor / Windsurf

将每个 skills/*.md 文件的内容复制到 .cursor/rules/ 或编辑器的规则配置中。

OpenCode

通过仓库根目录中的 AGENTS.md 执行由 Agent 驱动的工作。

本地克隆
git clone https://github.com/addyosmani/agent-skills.git
# Reference skill files from the local path

开发生命周期阶段

选择与当前工作相符的阶段。每个阶段对应一个或多个斜杠命令。

阶段 1 — 定义 /spec

技能：idea-refine、spec-driven-development

当请求含糊或缺少明确说明时，从这里开始。

  • idea-refine：将粗略想法转化为具体、可执行的提案
  • spec-driven-development：在编写任何代码之前，创建完整的 PRD（需求、约束、验收标准）
/spec "build a user authentication flow"

防止自我合理化：绝不要因为“想法很明显”而跳过规范——意图不一致会导致代价最高的返工。

阶段 2 — 规划 /plan

技能：planning-and-task-breakdown

将规范拆解为规模小、可独立验证的工作单元。

  • 将用户故事拆解为可独立完成和测试的任务
  • 开始之前评估影响范围
  • 明确依赖关系并显式安排顺序
/plan  # after /spec is frozen
阶段 3 — 构建 /build

技能：incremental-implementation、test-driven-development、context-engineering、source-driven-development、frontend-ui-engineering、api-and-interface-design

依据规范进行实现，而不是临时依据聊天上下文发挥。

  • incremental-implementation：采用精简的垂直切片；每个切片都必须通过测试后才能开始下一个
  • test-driven-development：Red → Green → Refactor；失败测试出现之前，绝不编写实现代码
  • context-engineering：在恰当的时机向 LLM 提供恰当的信息
  • source-driven-development：所有 SDK/API/框架决策都以官方文档为依据
  • frontend-ui-engineering：组件架构、设计令牌、无障碍性和性能预算
  • api-and-interface-design：优先定义契约的 API 设计，并在实现前进行验证
/build  # slice-by-slice against the frozen spec
阶段 4 — 验证 /test

技能：browser-testing-with-devtools、debugging-and-error-recovery

在宣称成功之前先进行验证。

  • browser-testing-with-devtools：运行时检查、网络跟踪、性能分析、无障碍审计
  • debugging-and-error-recovery：五步分诊（观察 → 重现 → 假设 → 测试 → 修复）
/test  # mechanical + semantic + browser verification

偏差阈值：

  • 0.00–0.15 — 极佳，可以继续
  • 0.15–0.30 — 密切关注
  • 0.30+ — 停止并纠正后再继续
阶段 5 — 审查 /review 和 /code-simplify

技能：code-review-and-quality、code-simplification、security-and-hardening、performance-optimization

合并前从五个维度进行审查。

  • code-review-and-quality：正确性、可读性、可维护性、性能、安全性
  • code-simplification：在降低认知负担的同时保持行为不变
  • security-and-hardening：OWASP Top 10 防护、机密扫描、输入验证
  • performance-optimization：先测量；优化前先设定 Core Web Vitals 目标
/review        # five-axis quality gates
/code-simplify # behavior-preserving clarity pass

变更规模标准：

  • 小型：< 200 行，单一关注点
  • 中型：200–500 行，相关关注点
  • 大型：> 500 行 → 拆分，或在 PR 描述中说明理由
阶段 6 — 发布 /ship

技能：git-workflow-and-versioning、ci-cd-and-automation、deprecation-and-migration、documentation-and-adrs、shipping-and-launch

严谨地发布。

  • git-workflow-and-versioning：基于主干的开发、原子提交、语义化版本控制
  • ci-cd-and-automation：质量门禁流水线、测试自动化、部署安全
  • deprecation-and-migration：系统性移除旧版代码，并提供迁移指南
  • documentation-and-adrs：为不明显的决策编写架构决策记录
  • shipping-and-launch：发布前检查清单、分阶段推出（1% → 10% → 50% → 100%）、回滚计划
/ship  # pre-launch checklist + staged rollout

专家角色

用于审查工作的三个专家角色：

角色侧重点
code-reviewer正确性、架构、可读性、测试覆盖率
test-engineer测试策略、边界情况、覆盖率缺口
security-auditorOWASP Top 10、机密、身份验证流程、输入验证

参考清单

清单用途
testing-patterns测试类型、隔离、覆盖率目标
security-checklistOWASP 一致性、身份验证、机密、标头
performance-checklistCWV 目标、打包体积预算、渲染路径
accessibility-checklistWCAG 2.1 AA、键盘、ARIA、焦点

理念基础

原则应用
代码即负担每一行代码都是维护负担；应说明其存在的理由
海勒姆定律所有可观察到的行为最终都会被依赖——应明确说明契约
切斯特顿栅栏移除某项内容前，先弄清它存在的原因
碧昂丝法则“如果你喜欢它，就应该为它编写测试”
左移尽早（规范阶段）而不是临近发布时（生产环境）发现问题
基于主干的开发短期分支、频繁集成，为高风险工作使用功能标志

命令速查表

命令阶段用途
/spec定义编码前编写规范 / PRD
/plan规划将规范拆分为可验证的任务
/build构建按照规范增量实现
/test验证浏览器 + 运行时 + 验收验证
/review审查五维质量门禁
/code-simplify审查保持行为不变的清晰度优化
/ship发布发布前检查清单 + 分阶段推出

操作规则

  1. 先定规范，再写代码 — 规范未冻结前，绝不开始实现
  2. 先写测试，再做实现 — 采用 TDD；编写任何功能代码之前，必须先有一个失败的测试
  3. 先查来源，再做假设 — 使用任何 SDK/API 前，先查阅官方文档
  4. 先做测量，再做优化 — 性能优化必须有基线测量产物
  5. 先验证，再完成 — “看起来没问题”还不够；所有输出都需要可量化的证明
  6. 渐进式发布 — 分阶段推出并制定回滚计划；对于有风险的变更，绝不一次性部署到整个集群

来源：addyosmani/agent-skills — MIT 许可证

说明

  1. 确定任务触发条件和预期输出。
  2. 按从上到下的顺序，遵循此技能中的工作流步骤。
  3. 验证输出后，再进入下一步。
  4. 如果任何步骤失败，记录阻碍因素和备用方案。

示例

  • 示例：先将此技能应用于小范围，验证通过后再扩展到完整范围。

最佳实践

  • 确保输出可重复且可审计。
  • 优先进行小范围、可逆的更改，避免大范围、高风险的编辑。
  • 明确记录假设。

参考资料

  • 项目规范：.agent-skills/skill-standardization/SKILL.md
  • 验证器脚本：.agent-skills/skill-standardization/scripts/validate_skill.sh

评论

支持 Markdown