메뉴
每周复盘/周报自动化。扫各项目仓本周提交定动静、拉内容数据、盘你自定义的若干业务线状态,收口成「本周真正动了什么 + 哪条线推进哪条停滞 + 下周聚焦≤3件」。当你说做周复盘/周报、盘点各项目进展、基于一周动态定下周聚焦、或问「这周干了啥/该聚焦啥」时使用。触发:/ray-weekly 或 /ray-weekly 「日期范围」。不用于:单项目深挖(直接看那个仓)、对外发布的「本周进展」帖(那走不代笔,只交骨架)、跨季度的战略复盘。
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | ray-weekly |
| description | 每周复盘/周报自动化。扫各项目仓本周提交定动静、拉内容数据、盘你自定义的若干业务线状态,收口成「本周真正动了什么 + 哪条线推进哪条停滞 + 下周聚焦≤3件」。当你说做周复盘/周报、盘点各项目进展、基于一周动态定下周聚焦、或问「这周干了啥/该聚焦啥」时使用。触发:/ray-weekly 或 /ray-weekly 「日期范围」。不用于:单项目深挖(直接看那个仓)、对外发布的「本周进展」帖(那走不代笔,只交骨架)、跨季度的战略复盘。 |
把「每周人肉把所有项目和数据盘一遍」这件重复劳动固化下来。这个 skill 针对的场景很具体——你每周要手动 cd 进十几个仓看 git log、翻内容数据、在脑子里对自己那几条业务线各自到哪了,盘完还常常盘出一堆流水账却没结论。本 skill 替掉的就是这段扫描 + 判断的手工活。
你的立场:盘点是为了判断,不是为了罗列。列 20 条 commit 谁都会,值钱的是那句「这周真正推进的只有核心产品计费这一件,其余都是维护性动作」。最终产出是决策输入,不是活动日志。
/ray-weekly # 默认盘最近 7 天(上个周一至今)
/ray-weekly 2026-07-01..07-07 # 指定日期范围
/ray-weekly 上周 # 自然语言范围也认
先确定时间窗口(默认「1 week ago」到现在),四步走。项目分类地图和现成扫描命令 → 读 references/project-map.md,不要凭记忆敲仓路径。
扫你的项目根目录(如 ~/projects/<类别>/)各仓本周提交,把仓分三档:
_archive/)下的一律排除,不计入「沉睡」制造焦虑。归档 = 主动停,不是停滞。⚠️ 关键区分:沉睡 ≠ 归档。归档目录里的仓再久没动也正常,别把它们列进「本周停滞」。反过来,一个活跃业务仓突然一周没动,才值得单独标出来问一句「为什么」。
扫描命令(按类别批量跑 git log、列各仓最后提交时间)在 references/project-map.md。dist 产物、node_modules、非 git 目录自动跳过。
拉本周对外内容的量化面:
/ray-metrics(若已就绪)拉本周涨粉、曝光、互动、爆款帖;没有就让本人给或跳过,不硬编数字。账本纪律:所有数字以你提供或工具实拉为准。不臆造、不估算、不「大概涨了几百粉」。拉不到就写「本周社媒数据未拉取」,留白比编造强。这条是硬线——你的账本不容猜。
先明确你自己定义的那几条业务/关注线(通常 2-4 条,如「核心产品/变现线」「服务/咨询线」「影响力/内容线」)。对每条线判断本周有无实质推进(不是「有没有想到」,是「有没有动作落地」):
| 线(示例原型) | 本周看什么算推进 | 对应项目/信号 |
|---|---|---|
| 产品 / 变现线 | 新增付费/续费、计费或部署改动、引流工具带量 | 核心产品仓的 commit + 本人报的客户动态 |
| 服务 / 咨询线 | 新线索、诊断/方案交付、回款、案子推进 | /ray-diagnose·/ray-proposal 的实际使用 + 本人报的咨询进展 |
| 影响力 / 内容线 | 内容产出与数据、影响力动作、装配稿落地 | 内容管线仓、Step 2 的数据、知识库更新 |
上表是示例原型,不是固定线路——按你实际关注的线替换。每条线给一句话结论 + 一个方向标记(推进 ↑ / 持平 → / 停滞 ↓)。
⚠️ 注意:有的线(典型是咨询/服务线)推进常常不体现为 git commit(是线下交付、回款、口头进展),必须结合本人提供的信息判断,不能只看仓就把它判成停滞。
诚实优先:某条线本周真没动,就写「停滞 ↓,本周无动作」,不要从边角料里硬抠出「进展」来凑每条都亮。一条线停了本身就是最有价值的信号——它告诉你注意力这周漏了哪。硬找进展等于自欺,直接毁掉这个 skill 的用处。
这是唯一真正动脑的一步,前三步都是为它备料。产出四段:
默认输出一段结构化文字(四段收口在最前,项目/数据/业务线明细在后供回溯),终端直接可读。要归档成文档或长图再另说。
若要把复盘转成对外发布的「本周进展」帖:那越过了功能性产出的边界,进入人设声音。此时只交装配骨架 + 素材(哪几件事值得对外讲、数据点、时间线),观点和口吻留 【你的话:____】 空位给你自己填。内部复盘可以全交付,对外发声不代笔。
_archive/)排除在动态盘点外。把口播文稿、观点句或一个完整选题做成编辑隐喻拼贴风格的视频（黑白半调剪贴 + 平坦色场 + 从空场逐件组装的定格动画）。两种模式：单句 5 秒 B-roll（单条或批量），以及 beat map 驱动的 45–60 秒完整讲解片（含旁白 TTS、内容感知变速、字幕与拼装）。用户说“拼贴 b-roll”“纸拼贴视频”“vox 那种风格的视频”“半调拼贴动画”“给这句口播配画面”“把这个选题做成拼贴讲解视频”时使用；也承接 ray-writer / ray-cover 产出后的视频化下游需求。不用于：需要精确图层与时间线控制（转 HyperFrames）、只要提示词不要成片、真人口播或产品实拍广告。
把已经定稿的中文长文排成适合手机浏览的微信公众号富文本，生成可复制预览，在用户确认后创建或更新公众号草稿，并回读核对标题、封面、正文、空段落、署名和中文编码。用于“给公众号重新排版”“把这篇推到微信公众号草稿箱”“更新已有微信草稿”“公众号排版太单调或有多余空行”“恢复失败的草稿更新”时。优先更新文章 frontmatter 记录的原草稿，不制造同题重复草稿；未经明确授权只做到预览，不发布文章。
rayskills 工具箱的主入口与路由。当用户不确定该用哪个 ray-* skill、只是丢来一个真实任务/处境，或明确要求把一篇内容从 idea、调研、写作、封面一路送到公众号或 X Articles 草稿箱时，用本 skill 读取上下文，判断最该做的一步或执行已确认的内容生产链。也用于一轮工作完成后决定下一步。触发：/ray 或 /ray 后接任何真实任务描述。用户无需记住具体 skill 名。
把灵感、剪藏审核卡、调研包、长期知识或已有草稿装配成有事实、有情绪、有网感和传播力的中文长文，并接入用户本地 Obsidian 知识库的成稿包、调研、草稿、发布与复盘流程。用于用户说“把这个 idea 写成文章”“从这条资料发展成长文”“写一篇公众号或 X 长文”“检查或重写这篇文章”“把内容生产流水化”时；找不到兼容知识库时先转交 ray-obsidian 建立或适配。不得虚构用户经历、数据、现场或情绪，不自动发布，也不使用 WeWrite。
把已经确定核心判断的文章、成稿包或长文转成公众号、普通 X 分享图与 X Articles 后台封面。提炼一个可一眼读懂的视觉隐喻，在 Ray 的编辑视觉体系中选择复古现代主义、极简隐喻、安静油墨、编辑隐喻拼贴或工具桥接方向，先生成无字底图，再用确定性排版写入准确中文标题，并输出各平台文件、提示词和清单。用于“给这篇文章做封面”“公众号和 X 都要封面”“做 5:2 Article 封面”“用 Adrian 或 Vox 那类风格”“把内容生产接上封面管线”时；不用于正文写作、自动发布或完整解说视频。
在用户本地新建、检查或渐进适配一个面向长期知识与内容生产的 Obsidian 知识库，复用 Ray 的资料、知识、灵感、成稿包、调研、草稿、发布与回流分层。用于“帮我搭一个 Obsidian 知识库”“给 ray-writer 准备本地知识库”“把现有 vault 接入内容生产管线”“检查知识库结构是否完整”时；也在 ray-writer 找不到兼容知识库时使用。只补缺失结构，不覆盖、移动或删除用户已有笔记，不强制安装插件、同步服务或 Git。