个人自用的 skill 仓库。
这里主要用来沉淀在 AI Coding、Agent 协作和日常开发中可重复使用的技能说明、流程模板和配套素材，目标是把零散经验整理成可复用、可维护、可持续迭代的能力单元。
- 可直接调用的 skill
- 针对特定任务的工作流说明
- 配套的脚本、示例和素材
- 个人验证过、愿意长期维护的方法论
- 一个 skill 只解决一类明确问题
- 触发条件要清楚，避免模糊描述
- 步骤要短、直接、可执行
- 优先沉淀可复用的模板，而不是一次性技巧
- 能配脚本就不要只写概念
建议每个 skill 独立成目录，入口文件统一为 SKILL.md。
.
├── README.md
└── <skill-name>/
├── SKILL.md
├── assets/
├── examples/
└── scripts/
- 适用场景
- 明确的触发描述
- 输入和输出约束
- 可执行的步骤
- 边界条件和不适用情况
- 必要时附带示例或脚本
这个仓库不是为了展示，而是为了自己长期积累和复用。
核心目标只有三个：
- 减少重复思考
- 提高任务执行质量
- 让常用经验可以快速迁移到不同项目
- 逐步沉淀常用工作流模板
- 形成一套适合个人使用的 skill 编写规范
ai-doc-driven-dev- 单入口的文档驱动开发 workflow
- 从旧
claude-community-plugins/plugins/ai-doc-driven-dev迁移而来 - 覆盖文档路由、文档检测、需求/技术方案生成或更新、工作流约束和模式提取
- 核心门禁：bug、回归、优化、后续变更先路由到已有需求/技术方案；能归属原需求时更新原文档，不默认新建 bug 文档
- 自带 requirement / technical design / CLAUDE.md / AGENTS.md 模板，以及前后端 pattern hints
cst- 客诉 / 客服问题排查工作流
- 先和用户对齐现象，再优先按环境变量里配置好的日志方式查日志、分别看前端和后端代码、查 MySQL、定位根因
CST_LOG_ACCESS_METHOD用来指定日志访问方式；如果是aliyun-cli，对应凭证通过环境变量注入即可，不需要把密钥写死在命令里- 前端和后端代码位置分别配置；可以是不同 repo，也可以是同 repo 下不同路径
- 结论输出顺序固定为：现象 -> 动作 -> 代码问题，并且要让产品和研发都能看懂
- 如果配置了
CST_FEISHU_DOC_URL并完成lark-cli init，排查结论还能自动追加到飞书文档里 - 根因清楚后，再决定要不要进入修复分支
e2e-coverage-guard- 根据飞书 Base 或 Doc 里的变更记录检查 E2E 覆盖
- 以用户旅程为单位映射 bug、需求、优化和功能变更，而不是一个 bug 一个测试
- 只生成或补齐 E2E 测试用例，不运行测试、不修业务代码
figma-1to1-ui-restoration- Figma 1:1 UI 还原工作流
- 先锁定边界，完整遍历可见节点、状态、资产和变量，再开始实现或收紧已有实现
- 强制区分真实可渲染节点、平台原生节点、交互代理节点和注释/演示节点
- 通过结构、几何、内容、视觉 diff 和状态覆盖多层验证后，才能宣称 1:1
figma-restoration-review- 只读审查已有 UI 实现相对 Figma 的还原质量
- 输出按严重程度排序的 deviation checklist，不修改代码
- 覆盖结构、几何、样式、内容和状态五个维度
five-layer-classifier- 按 AI Coding 五层模型给项目、目录或文件集做职责分类
- 输出文件级或文件组级分类表、高风险误判清单、正式入口和迁移/拆分建议
- 适合产品仓 / 控制仓拆分前、public / private 审计和 agent 读取顺序梳理
skill-lifecycle- 管理 skill 的完整生命周期：新增、修复、改进和通过 PR 交付
- 创建或修改 skill 时配合
skill-standard使用 - 强调先明确意图，再脚手架、编写、验证和提交 PR
skill-standard- SKILL.md 编写和审查标准
- 约束语义清晰、触发描述、资产说明、路径可移植、依赖声明、类型识别和完成信号
- 统一覆盖通用标准、任务型 skill 标准、控制型 skill 标准和混合模式检查
- 用来审查或收敛其他 skill 的质量