免费获取 · 一键下载即用
Orchestrates the RLM repo workflow end-to-end with phase gates, locked artifacts, addenda, traceability, and automatic bootstrap/upsert of AGENTS/PLANS scaffolding. Trigger phrases: "Implement requirement <run-id>", "Run RLM Phase <N>", "resume requirement", "lock Phase <N>", "verify locks".
Bootstrap and navigate the spec-kit demo environment. Use this when asked to set up the demo, bootstrap the demo, jump to a phase, go to a phase, switch phases, or clean up a demo.
완료된 결과물을 최종 수락합니다 (Phase 3 → Phase 5). Worktree를 main에 머지하고 정리합니다. 사용자가 '수락', '머지', '최종 수락'을 말하거나 /mst:accept를 호출할 때 사용. 기본적으로 /mst:approve에서 자동 호출되며, workflow.auto_accept_result=false 시 수동 사용.
飞书多维表格的完整生命周期管理：从零搭建 + 日常 CRUD 操作。 **当以下情况时使用此 Skill**： (1) 用户说"搭建多维表格"、"做一个XX表"、"搭一个XX系统" (2) 用户描述业务需求并希望用多维表格实现 (3) 需要查询、新增、修改、删除多维表格中的记录 (4) 需要管理字段、视图、数据表 (5) 需要批量导入数据或批量更新 (6) 用户提到"多维表格"、"bitable"、"数据表"、"记录"、"字段" --- > **⚠️ 最高优先级指令 — 创建多维表格的唯一方式：** > > 当用户要求「搭建」「做一个」「搭一个」多维表格系统时，**必须按顺序完成以下 3 步**： > > **第 1 步：设计 JSON 配置并调用脚本创建表** > ``` > exec(command='cat > /tmp/bitable_config.json << ...') > exec(command='python3 ~/.openclaw/skills/feishu-bitable/scripts/create_bitable_template.py --config /tmp/bitable_config.json') > ``` > > **第 2 步：用脚本生成的 Markdown 创建配置文档（禁止跳过！禁止自己写内容！）** > ``` > exec(command='cat /tmp/bitable_config_doc.md') ← 读取脚本自动生成的完整 Markdown > feishu_create_doc(title="从 __CONFIG_DOC_TITLE__ 获取", markdown="上面 cat 的完整内容") > ``` > > **第 3 步：向用户汇报** > 告知多维表格链接 + 配置文档链接 + 需手动完善的事项。 > > **禁止使用 feishu_bitable_app 工具创建！禁止让用户手动创建！禁止跳过配置文档！禁止自己编写配置文档内容！** # 飞书多维表格技能 你是一个多维表格专家。覆盖**从零搭建**到**日常操作**的完整生命周期。 ## 架构 - **从零搭建** → 调用 Python 脚本（Phase 1-4，确定性执行，无默认字段/空行问题） - **日常操作** → 用飞书插件的 `feishu_bitable_*` 工具（查询、新增、修改、删除、批量操作） - **凭据** → 脚本自动从 OpenClaw 配置读取，与飞书插件共用同一应用 **判断用哪个路径：** - 用户要"搭建"/"做一个"/"搭一个" → Phase 1-4（脚本搭建） - 用户要"查记录"/"加一行"/"改字段"/"导入数据" → 日常 CRUD 操作 --- # 一、从零搭建（Phase 1-4） **⚠️ 禁止手动调用 feishu_bitable_* 工具创建表！必须用脚本！** 飞书 API 创建表时会自动附带默认字段（多行文本、单选、日期、附件）和空行，只有脚本能从源头避免。 ## Phase 1: 需求分析（内部思考，禁止向用户提问） > **⚠️ 铁律：禁止向用户提问！禁止问澄清问题！直接读模式库 → 设计 JSON → 搭建！** > > 用户说"搭建XX系统"时，你必须**立刻开始搭建**，不要问"你需要哪些模块"、"你的业务是什么"等问题。 > 用户可以在搭建完成后通过配置文档的「修改意见区」提出修改。 **内部分析（不输出给用户）**，用六问法快速拆解： | | 问题 | 决定 | |--|------|------| | Q1 | 涉及几类数据？ | 建几张表 | | Q2 | 关联关系？（1:N / N:N） | 单向/双向关联 | | Q3 | 核心指标？ | 公式/汇总 | | Q4 | 数据从哪来？ | 录入方式 | | Q5 | 数据到哪去？ | 输出方式 | | Q6 | 谁在哪个节点消费？ | 视图和权限 | 读取实战模式库（详见 [references/system-patterns.md](references/system-patterns.md)），匹配最接近的模式： - "项目管理"/"任务管理" → 项目管理模式 - "客户"/"销售"/"CRM" → CRM 模式 - "库存"/"进销存" → 进销存模式 - "工单"/"售后" → 工单系统模式 - 其他类型 → 参考最接近的模式，自行设计合理的表结构 **分析完成后立即进入 Phase 2，开始搭建。** --- ## Phase 2: 设计 JSON + 调用脚本搭建 ### 2.1 设计 JSON 配置 ```json { "app_name": "系
v0.1 开发日志：各 Phase 的架构决策、接口设计、文件变更和测试覆盖记录。
Enforces a 4-phase architecture design workflow by reading `.arch/state.json` on every request to gate responses by phase. Phase 1 extracts and validates requirements from PRDs; Phase 2 selects architecture patterns and establishes high-level structure; Phase 3 designs and accepts components sequentially; Phase 4 finalises and documents the solution. Use when discussing system design, solution architecture, PRD analysis, component design, technology selection, or architecture patterns — distinct from general coding help by its strict phase-gating, anti-pattern detection, and state-tracked component acceptance.
One-Person Company (OPC) 编排技能 — 复杂任务的多 Agent 协作指挥中枢。 【优先触发条件 — 满足任意一条即应调用 OPC】 ① 任务需要多个步骤且步骤之间有依赖关系（如 策划→搭建→发布） ② 任务预计超过 50K tokens 或 10 分钟 ③ 任务涉及多个领域（调研+创作+开发+发布 等两个以上领域并存） ④ 任务需要多个专业角色分工（研究员、工程师、设计师等） ⑤ 任务明确包含"并行执行""多路线""团队协作"等关键词 ⑥ 用户提到"全链路""从头到尾""完整流程""做一个完整的X" 核心能力：Context Intake（用户模型读取+背景摄入）、任务分解、多角色编排、状态持久化、断点续传、用户模型自更新。 触发词（任意匹配）： OPC、一人公司、多agent、编排、全链路、复杂项目、帮我做完整的、 需要多个步骤、并行执行、团队协作、策划+搭建+发布、研究项目、内容流水线 --- # OPC — One-Person Company 编排技能 v5.2 > 用户是老板，OpenClaw 是 CEO，Sub-agents 是专业员工。 > 用户只说"我要做 X"，CEO 负责拆活儿、招人、盯进度、**亲自验收**、交结果。 --- ## 30 秒上手 ``` 1. 触发 OPC → Phase 0: Context Intake（理解背景目标，给出方案，等确认） 2. 确认后 → Phase 1: init 项目 + 任务分解 3. spawn Sub-agents → Phase 2: 注入角色卡 + 注册状态 4. 监控执行 → Phase 3: 主动检查 + trigger-evaluate + 汇报进度 5. 交付汇总 → Phase 4: cost 报告 + close 项目 ``` --- ## Phase 0：Context Intake（最重要，不可跳过） OPC 被触发后，**第一步必须理解背景，给出方案，征询确认**。 ### 必须明确的四个维度 ``` 【背景】业务场景是什么？有什么前置条件？新建还是继续？ 【目标】交付物是什么？怎么判断"完成"？ 【约束】截止时间？token 预算？平台限制？ 【范围】从哪里开始到哪里结束？什么不在本次范围？ ``` ### 方案输出格式（等用户确认才开始） ```markdown ## 📋 OPC 项目方案 **背景理解**：{一句话概括} **目标**：{交付物 + 成功标准} **约束**：{时间/预算/限制} **推进方案**： - 角色配置：{N 个角色，名称 + 主要职责} - 协作模式：{串行/并行/混合} - 预估总预算：~{N}K tokens - 预计耗时：~{N} 分钟 **确认后开始执行，是否有需要调整的地方？** ``` ### 确认轮次 | 复杂度 | 判断标准 | 轮次 | |--------|---------|------| | 简单 | ≤2 角色，单流水线 | **1 轮**（Phase 0+1 合并）| | 中等 | 3-5 角色，有并行 | **1 轮**（Phase 0+1 合并）| | 复杂 | >5 角色，>200K 预算 | **2 轮**（理解→方案分开）| 详细决策逻辑 → brain/core-flow.md --- ## 核心执行命令速查 ```bash # Phase 1 — 项目初始化 python3 engine/project_state.py init "项目名" python3 engine/project_state.py update-phase <pid> phase_1_planning # Phase 2 — agent 注册 python3 engine/project_state.py agent-start <pid> <label> '{"role":"角色名"}' # Phase 3 — 监控 python3 engine/project_state.py agent-complete <pid> <label> '{"output":"..."}' <tokens> python3 engine/project_state.py agent-fail <pid> <label> '{"error":"原因"}' python3 engine/project_state.py trigger-evaluate <pid> # 每轮循环必须调用 # 断点续传 python3 engine/project_state.py checkpoint <pid> <label> '{"completedSteps":[...],"nextStep
skill-sample/ ├─ SKILL.md ⭐ 必备：技能说明入口：用途 / 安装 / 用法 / 示例 / 依赖 ├─ manifest.sample.json ⭐ 推荐：机器可读元信息：用于索引 / 校验 / 自动填表 ├─ LICENSE.sample ⭐ 推荐：授权与使用范围：开源 / 限制 / 商用说明 ├─ scripts/ │ └─ example-run.py ✅ 可运行示例脚本：让用户导入后立刻验证“能用” ├─ assets/ │ ├─ example-formatting-guide.md 🧩 输出规范：统一排版 / 结构 / 风格 │ └─ example-template.tex 🧩 模板资源：报告/文档模板，快速生成标准产物 └─ references/ 🧩 参考资料库：方法论 / 结构指南 / 最佳实践 ├─ example-ref-structure.md 🧩 结构参考：章节框架 / 目录组织 ├─ example-ref-analysis.md 🧩 分析参考：常用套路 / 指标口径 └─ example-ref-visuals.md 🧩 视觉参考：图表规范 / 可视化建议
更多 Agent Skills 规范 详见Anthropic官方文档：https://agentskills.io/home
├─ ⭐ 必备：YAML Frontmatter（必须存在，放在文件最顶部） │ ├─ ⭐ name ：技能唯一名；须符合命名规则，并建议与目录名一致 │ └─ ⭐ description ：技能描述；建议包含触发关键词（便于检索/匹配） │ ├─ ✅ 可选：Frontmatter 扩展字段（规范允许，但非强制） │ ├─ ✅ license ：许可证标识（也可配合单独 LICENSE 文件） │ ├─ ✅ compatibility ：兼容性/运行环境要求（仅在确实有限制时写） │ ├─ ✅ metadata ：任意键值对（如 author/version/source_url 等） │ └─ 🧩 allowed-tools ：允许工具白名单（规范标注为 experimental） │ └─ ✅ 推荐：Markdown 正文（自由格式，但建议按“渐进式披露”组织） ├─ ✅ Overview / Purpose ：一句话说明目标 + 不做什么（边界） ├─ ✅ When to use ：触发条件/适用场景（让模型/用户知道何时调用） ├─ ✅ Step-by-step ：步骤化流程（最好 3–6 步，保证可复现） ├─ ✅ Inputs / Outputs ：输入格式、输出格式、产物位置（文件/文本/JSON等） ├─ ✅ Examples ：至少 1 个可复制示例（越“能跑”越好） ├─ 🧩 Files & References ：引用assets/、references/、scripts/（相对路径） ├─ 🧩 Edge cases ：边界情况/限制（大文件、速率限制、失败回退） ├─ 🧩 Troubleshooting ：常见错误与解决（依赖缺失、路径不对、权限问题） └─ 🧩 Safety notes ：涉及联网/写文件/执行命令时给出提醒（建议写）
在 GitHub 和各类社区里，技能文件分散、难检索、也难判断是否可靠。SkillWink 把开源技能集中整理成可搜索、可筛选、可直接下载使用的技能库，让你更快找到“正好能用”的那一个。并且支持在SkillWink上直接上传skills。
我们提供 AI 语义搜索 + 关键字检索，支持 版本更新与多维排序（下载/点赞/评论/更新），并为每个技能提供 SKILL.md 开放标准与来源信息。你还可以在详情页直接 评论讨论、交流用法与改进建议。
快速上手：
支持下载与导入 skills（.zip/.skill），本地放置后即可生效：
~/.claude/skills/（Claude Code）
~/.codex/skills/（Codex CLI）
~/.gemini/skills/（Gemini CLI）
同一份 SKILL.md 跨平台通用。
你需要了解的：技能是什么、怎么运行的、怎么找、怎么导入、怎么判断可信、怎么参与共建。
这里的“skills（技能）”是一种可复用的任务能力包，通常包含 SKILL.md 说明（用途、输入输出、使用方法）以及可选的脚本/模板/示例文件。
你可以把它理解为：给 AI 助手或工具链用的“插件说明书 + 资源包”，可被反复安装与分享。
技能系统采用“渐进式披露”策略，高效管理上下文信息，具体流程如下：
发现阶段：系统启动时，智能体仅加载各技能的名称与简要描述——信息精简，足以判断其适用场景，避免冗余加载。
激活阶段：当任务需求与某技能描述匹配时，智能体才将对应的完整 SKILL.md 说明文档动态载入上下文。
执行阶段：智能体严格遵循文档指引执行操作，并按需调用关联文件或运行内置代码模块。
核心优势：该设计使智能体始终保持轻量高效，同时具备“按需扩展上下文”的能力，既保障响应速度，又确保复杂任务拥有充分执行依据。
推荐 3 种方式组合使用：
注：以上导入方式文件大小控制在10M之内。
常见路径如下（不同系统略有差异，以你本机为准）：
同一份 SKILL.md 通常可以跨工具复用。你在 SkillWink 导入后，也可以查看“放置指引/安装说明”。
可以。很多技能本质是标准化说明 + 资源，只要目标工具支持读取该格式，就能共享使用。
比如：检索类技能 + 写作类技能 + 自动化脚本，形成“发现 → 处理 → 输出”的工作流。
一部分skills来源于公开的 GitHub 仓库。我们会筛掉低质量仓库（至少 2 星），并扫描基本质量指标，还有一部分是SkillWink平台的创作者独立上传的。作为使用者，在安装前应始终审查代码，对安全问题负责。
最常见原因是这几类：
我们会尽量避免。你可以用 排序 + 评论 让“好用的”更靠前：
