git-commit-convention
写 git 提交信息、整理提交历史时使用——Conventional Commits 的格式、类型选择和拆分原则。
审查代码改动(review diff / PR)时使用——按固定清单过正确性、边界、错误处理和测试盲区,避免只看顺眼不顺眼。
Claude Code
$ npx -y skills add 7-e1even/learn-agent --skill code-review-checklist --agent claude-code
Codex
$ npx skills add 7-e1even/learn-agent --skill code-review-checklist -a codex -y
Cursor
$ npx skills add 7-e1even/learn-agent --skill code-review-checklist -a cursor -y
Gemini CLI
$ npx skills add 7-e1even/learn-agent --skill code-review-checklist -a gemini-cli -y
GitHub Copilot
$ npx skills add 7-e1even/learn-agent --skill code-review-checklist -a github-copilot -y
OpenCode
$ npx skills add 7-e1even/learn-agent --skill code-review-checklist -a opencode -y
Windsurf
$ npx skills add 7-e1even/learn-agent --skill code-review-checklist -a windsurf -y
name: code-review-checklist description: 审查代码改动(review diff / PR)时使用——按固定清单过正确性、边界、错误处理和测试盲区,避免只看顺眼不顺眼。
审查的第一原则:**先读需求再读 diff**。不知道这次改动想达成什么,就只能审出格式问题。
按严重度分组给结论:**必须改**(正确性/安全)→ **建议改**(可维护性)→ **可选**(风格)。 每条指出具体行号和理由,不说"感觉不太好"这种无法执行的话。
开发桌面 agent Reina 过程中记下的笔记,讲 coding agent(Claude Code、Codex、opencode 这类工具)的内部实现机制。每篇讲一个机制,把 Reina 里的生产实现简化成零依赖、单文件、可直接运行的 Node 程序——所以这些做法不是照 API 文档推想的,是实际产品里验证过的。 仓库分三块:notes/ 是正篇笔记(s01–s23,每篇一个机制,配可运行 demo);agent_analysis/ 是其他 agent(pi、Kimi
写 git 提交信息、整理提交历史时使用——Conventional Commits 的格式、类型选择和拆分原则。
You MUST use this before any creative work - creating features, building components, adding functionality, modifying behavior, or…
Ask which skill or flow fits your situation. A router over the skills in this repo.