【免费下载链接】SkillsAgent skills for designers and builders using Codex, Claude, Cursor, and other AI coding agents项目地址https://gitcode.com/gh_mirrors/skills48/Skills点击查看免费下载本仓库agent-skills/workflow目录下收录了四类面向真实项目的日常协作技能进度截图progress screenshots、评分到目标score to target、发布变更ship change与多线程管理threads manager。它们把用户在每个线程里反复强调的给截图、打到 8 分、正确发布、管好其他线程这几条规则固化成了可复用的流程与配套脚本。读完本文你将掌握一套可移植的 Agent 工作流何时截图、如何锚定评分标准、怎样在不破坏协作的前提下完成一次从提交到上线的完整发布以及如何审计多个并行 Agent 线程的合并、变更日志与线上健康状态。一、为什么需要 Workflow Skills现代 AI 编码 Agent如 Codex、Claude、Cursor可以在一个真实项目上并行开展多个线程的修改。但改完就说与真正交付之间隔着大量琐碎而关键的检查截图有没有真实呈现、评分有没有标准、提交是否只包含自己的文件、发布是否真的在线上生效、其他线程的工作是否被正确地合并与归档。agent-skills/workflow/README.md将这些用户在每个线程里重复的规则整理为一组过程技能workflow skills并强调其可移植性技能本身不绑定某个具体项目项目特有的细节托管方式、变更日志格式、截图存放目录应写入该项目的AGENTS.md或放在技能目录旁的本地references/project.md中。这个设计让同一套流程可以跨项目复用同时尊重每个项目自己的规则。技能速查表需求从哪里开始工作推进中主动提供开始、关键时刻与结果的真实截图workflow-progress-screenshots基于锚定评分标准按 10 分制评分并逐轮改进到目标分workflow-score-to-target发布一次变更截图、变更日志、测试、提交、fast-forward 推送、草稿转正式发布、实测体积与 50 MB 上限workflow-ship-change统筹同一仓库上的多个 Agent 线程合并了什么、什么已上线、什么该归档、什么被中断workflow-threads-manager四项技能的配合关系从第一个可用版本起就用进度截图持续记录当用户提出目标分数时评分到目标每一轮都配一张图达到标准后发布变更线程管理器最终确认每个线程都按这套流程交付在main上、变更日志带图、已上线、完成即归档。二、workflow-progress-screenshots把所见变成证据核心规则发送而非描述用宿主工具SendUserFile或报告内嵌图片把图真正送到用户眼前一句话里的路径不算。主动且持续每个有意义的阶段第一个可用版本、每个大修复、评分循环的每一轮都发图便于用户尽早纠偏既不要攒到最后一次报告也不要在每次保存时轰炸。开始、关键时刻、结果凡是存在 before/after 的变更都要用相同构图捕获三态——变更前状态、交互瞬间悬停、瞄准、动画中、面板展开、最终结果修复类任务则展示 bug 与修复后状态。只拍真实渲染必须捕获真实页面/游戏/应用而不是原型或想象用 review fixture、URL 开关或调试钩子搭好状态而不是口头描述。发送前逐张检查游离的 toast、加载到一半的美术或缺失字体、错误的场景或过期的数字都意味着需要重拍图与说明不符就不算证据。说明图片证明了什么每图一行如Before提示显示 out of rangeAfter90% hit · 5 damage。如实标注明确说明是headless 浏览器捕获还是浏览器视口390×844 视口只是手机尺寸的浏览器检查不是设备测试脚本编排或摆拍的时刻要标注为 staged。比较需同构图before/after 用相同视口、相机与状态并用compare.py并排展示。捕获方式应用内浏览器面板在可见时可使用面板隐藏时会卡住requestAnimationFrame并返回过期或黑帧此时应改用 headless 捕获。Headless 捕获scripts/capture.mjs直接通过 Chrome DevTools ProtocolCDP截取真实页面零依赖Node 22 自带 WebSocket。用法与关键环境变量node capture.mjs url out.png|out.jpg [js step ...] # WIDTH1600 HEIGHT900 SCALE1 MOBILE0 视口MOBILE1 → 390×844 且 2x 缩放 手机 UA # WAIT_FORjs 表达式 轮询直到为真再截图如 window.__app?.ready # SETTLE1500 加载/等待后的稳定毫秒数WebGL 场景用 3000–5000 # STEP_WAIT800 每个 js step 后的等待毫秒数 # CHROME/path/to/chrome 覆盖浏览器二进制1600×900 用于桌面MOBILE1用于 390×844 手机视口SETTLE3000–5000适用于 WebGL/3D 场景——它们 headless 渲染较慢拍早了会缺模型、字体和图标一次只跑一个捕获繁忙机器上并行 headless Chrome 会产生协议错误、漏帧从源码看该脚本会先建临时 profile、用--headlessnew启动 Chrome通过Target.createTarget创建页面并附着会话执行视口覆盖Emulation.setDeviceMetricsOverride、导航、WAIT_FOR轮询、按序执行 JS 步骤最后Page.captureScreenshot输出 PNG/JPEGJPEG quality88同时收集Runtime.exceptionThrown与 console error打印页面错误因此坏页面会被抓到而不是被拍下。并排对比scripts/compare.py将多张图带标签并排放置before/after 两联或 start → key moment → result 三联支持--width 800与--cols N默认每行最多 3 个面板基于 Pillow 实现python compare.py out.jpg before.png Before after.png After python compare.py out.jpg start.png Start moment.png Key moment result.png Result动效静态图会漏掉运动穿过效果的连续帧短连拍若应用暴露了页面时钟则放慢它也可以发一帧条。项目若指定了专用捕获工具如use the Codex browser就用它。捕获脚本与输出应放在项目内被 gitignore 的目录如qa/captures/而不是重启即被清空的 scratchpad。最终报告中的呈现截图内联在变更摘要之后逐张配说明说明哪些是 headless 捕获、手机检查用了哪个视口无法捕获的内容要说明原因不可以用文字描述顶替。三、workflow-score-to-target把质量变成可追踪的分数用户常以数字设定质量线score them out of 10. lets get them to 8 out of 10、anything less than 6, get them to 6。该技能的目标不只是打分而是达到目标、证明达标、并如实说明短板。1. 锁定目标与清单复述标准目标分6/8/9以及它作用于每一项还是平均值——Get them to 8 意味着每一项都达到 8列出被评分的每一项每个技能、每把武器、每个界面元素、每个对象逐项打分绝不当作一个整体打分指明用户对标物他比较的游戏或网站没有基准的 7 分毫无意义用户设定过一次的标准就是该类工作的长期规则应记录到未来工作可见之处项目说明、记忆或测试。2. 评分前先锚定评分标准把量纲写下来让每个轮次的分数含义一致。默认锚点分数含义10同类最佳值得研究学习9优秀受过训练的眼睛几乎挑不出毛病8打磨到位且有意为之只有细微瑕疵7良好但存在可见缺陷6可接受能工作、读起来清楚但有明显粗糙处5平庸想法在执行却让人分心3–4明显坏掉或错误之处1–2几乎不能用或看起来是别的东西再把每项拆成3–5 条标准每条 0–2 分使总分为 10 且每分都有理由。例如动画看重量与节奏、身体力学、最终姿态、道具、上下文与变化技能看规则、悬停落点与数字、施放姿态、效果、音效与可残留可见物对象看游玩距离上的剪影、材质与细节、融入场景、可读性。凡能测量的标准就测量脚滑低于行进速度的 10%、武器穿模毫米数、40 局 48% 胜率、28 MB 下载量——数字能防止分数跟着情绪漂移。3. 基于真实证据诚实评分只依据真实物体的渲染、录屏或测量评分不看代码、不凭记忆先捕获状态见进度截图技能改动前先给基线打分before→after 才是证明必要时独立评审把截图交给一个没参与工作的新子代理给它评分标准与基准但不要给它你的期望或历史分数每项尽可能用两位盲审取较低分或弥合差异绝不四舍五入凑达标7.5 分面对 8 分标准就是没达标。4. 逐轮改进先修最低分项再修每项中扣分最多的那条标准重新截图用同一评分标准与评审配置重新评分每轮发一张图开始与结果并附分数变化如Hollow Keeper 3 → 6 → 8当每一项达标即停若某项因任务外原因模型上限、美术资源、性能预算停滞就如实上报为未达标附原因与所需条件爬分时守住护栏不要用牺牲性能预算、测试或其他项分数的方式去抬高某一个分数并注明任何取舍。5. 锁定成果凡是机器可校验的标准补一条测试防止静默回退如七种姿态下武器不穿模、技能有自己的姿态与卡片、胜率不低于 90%将记分卡保存到项目内如qa/area/README.md包含评分标准、每项 before/after、证据与日期供后续轮次沿用。报告格式先给结论All 49 now score 8 or better; 38 started below 8; the average rose from 6.7 to 8.1.然后依次给表格项、before → after、修复的主要缺陷或仍短的原因参照templates/scorecard.md、评分方式评分标准、基准、评审者——你自己、独立子代理还是盲审——以及依据什么证据、不完美之处刚过线但有已知瑕疵的项、仍低于目标的项、图片每项或每轮的 before/after。最后说明分数是判断哪些标准是实测的并如实标注截图。仓库还提供templates/critic-prompt.md作为独立评审提示词模板粘贴进全新子代理后它要求评审者只依据所见评分、先打开全部证据文件、逐项给出每标准分数与最大扣分缺陷、不四舍五入、不假设证据未显示的内容。四、workflow-ship-change从提交到上线的完整发布流程一个变更只有满足以下全部条件才算完成报告要逐项展示截图真实渲染的开始状态、关键时刻与结果内联展示在报告中独立的变更日志版本图片出现在游戏内变更日志页面已验证自己的测试、合入提交的测试、资源检查、在已推送提交上运行的全量测试套件已提交一个内聚提交只暂存自己的文件已推送以 fast-forward 方式推到main并在 GitHub 确认已上线该精确main的构建已发布并在真实域名上确认可用已测量提交、推送、上传与发布的大小全部实测而非估算。推送到项目自己的仓库与上线站点属于长期授权无需每次询问除非遇到下文护栏要求停下。开始前先读项目的AGENTS.md与本技能旁的references/project.md若有项目规则经常变化与技能冲突时以项目规则为准。护栏停下并询问用户任何超过 50 MB 的上传git push、Netlify 部署、媒体发布、发往任何外部服务的文件先用upload-size.sh或push-main.sh打印的包体积测量询问时说明体积按整次操作计数绝不拆分以绕过上限一次完整的 Supabase 媒体发布约 861 MiB必须询问force-push、改写远端历史、改变仓库可见性、推送到其他仓库新建站点或项目或改变站点访问、域名、DNS除非任务恰好如此且用户要求权限检查拦截部署、回滚或上传时停下不要换路径重试、不要借其他线程执行告诉用户确切的点击路径或命令发布后线上损坏报告里首先说明附实测证据与回滚点击路径不掩盖。护栏绝不绝不发布除干净已推送的origin/main之外的任何东西无未合入分支、无未提交文件绝不用 Netlify 兜底部署大型媒体——媒体放在 Supabase Storage绝不发布到项目已弃用的宿主即使旧脚本仍指向它绝不运行宽泛的图像优化器pnpm images:optimize或optimize-images.py --apply它会重写其他会话的待处理图片改用runtime-assets.py --only your glob后再--verify绝不暂存凭据、.env*、node_modules、缓存或构建产物绝不在共享 checkout 中使用git add -A本地提交在远端确认之前不叫已推送部署在域名确认之前不叫已上线绝不杀死自己未启动的进程先检查其工作目录lsof -a -p pid -d cwd。操作步骤步骤 0开始前。git fetch后git log origin/main --oneline -30并检索自己的区域查看兄弟 worktreegit -C wt diff --stat是否有人在做同样的修改。在自己基于origin/main分支的 worktree 里工作其他会话则直接编辑共享 checkout。步骤 1截图。用项目 review fixture?reviewname在 1600×900 下捕获真实游戏取开始、关键时刻与结果三态项目指定工具则用之否则用 CDP headless 捕获见进度截图技能并说明用了哪种使用前逐张检查如实标注headless 捕获、手机视口不是设备测试捕获脚本放在 worktree 内 gitignore 的qa/captures/。步骤 2变更日志版本。严格遵循项目的变更日志规则格式、版本、图片加入方式面向玩家写作——他们现在能看到或做到什么不写文件名或哈希仅涉及测试、工具、文档或规则的变化不配版本若其他会话占用了你的版本号合入时重新编号并保留他们的条目。步骤 3验证。过程中随手跑受影响的套件合入main后用git diff --name-only old-base new-base -- tests找出合入提交触碰的每个测试文件并运行发了图片就做图片校验全量套件在繁忙机器上需 10–40 分钟用后台运行并读日志疑似超时的失败要单独重跑再定性如实报告哪些是全量、哪些是定向附通过/失败计数。步骤 4提交。先确认git diff --cached为空只暂存显式路径对暂存内容运行commit-size.sh其数字进报告一个内聚变更一个提交迭代中用一个 work-in-progress 提交 amend 而非堆小提交消息遵循仓库风格并以系统给出的署名行结尾。步骤 5合入并推送。git fetch后git rebase origin/main共享分支上可 merge解决冲突时保留所有人的工作生成类 JSON图像审计、清单取上游文件、重新加入自己的记录并用项目工具重算总数对每个src与tests文件跑node --check再运行自己的测试与合入提交的测试最后运行push-main.sh拒绝任何非 fast-forward 的推送用git merge-base --is-ancestor校验否则退出码 1 并提示先 rebase/merge用git pack-objects实测将发送的包体积超过默认 50 MB--limit-mb可调即退出码 3 停下询问绝不拆分以--progress推送并抓取 git 的 Writing objects 行即实际发送字节数推送后再次 fetch 并确认origin/main等于 HEAD否则报告 NOT CONFIRMED。若main移动了回到步骤 1 重来在已推送提交上跑全量套件坏则向前修复。步骤 6发布上线。在 HEAD 精确等于origin/main且跟踪文件干净的 checkout 中构建若构建改动了跟踪文件先提交并推送该文件再重新构建用upload-size.sh测量将上传的内容upload-size.sh dist以及任何媒体发布超过 50 MB 停下询问先部署到草稿/预览 URL用verify-live.sh检查页面、脚本、美术与 gate 路由全部通过才转生产——这一步的存在是因为历史上一次生产部署丢掉了 edge function站点页面 200 而图片全部 404无人能玩转正式后在真实域名上再跑一次verify-live.sh记录部署 ID、发布时间、线上游戏版本与发送字节数若其他会话在你之后也发布了只要它也发布的是main就没问题。从源码看verify-live.sh会先抓取页面本身的状态码非 2xx 即坏再解析页面里的src/href/...引用逐一 curl 检查2xx/3xx 通过并支持可选环境变量AUTH_PATH无 token POST404 说明 gate 缺失、400/401/403 说明 gate 在响应与PRIVATE_PATH无会话抓取期望 401/403 或 3xx200 说明未设防、404 说明缺失任何一项失败即输出 BROKEN: N check(s) failed 并以退出码 1 拦截生产转正。报告格式简短、按序① 已推送并确认的提交哈希提交体积文件数、总体积、最大文件与推送体积发送字节数② 上线情况URL、部署 ID、时间、线上版本、verify-live.sh结果上传体积发送字节、构建站点体积、媒体发布若未发布说明原因如held: needs a media release over 50 MB; asking③ 面向玩家的变更说明 变更日志版本与标题④ 测试哪些全量、哪些定向通过/失败计数⑤ 带说明的截图标注为 headless 捕获⑥ 任何推迟或偏离之处及原因。五、workflow-threads-manager统筹多线程并行协作用户会在同一个仓库上并行运行多个 Agent 线程并让本线程负责跟踪。每次检查回答四个问题自上次检查以来什么落到了main上每个变更是否都有带图片的变更日志条目线上是否健康且最新还是已损坏或落后于main每个线程在做什么运行中、已完成、任务被截断、还是等待用户什么可以归档什么需要用户介入若有本项目的references/project.md先读它每次检查都先读项目的AGENTS.md因为其他线程在不断改规则线上宿主、变更日志格式、体积上限与技能冲突时以AGENTS.md为准。工具会话工具mcp__ccd_session_mgmt__*若只显示为 deferred 工具名先用 ToolSearch 加载list_sessions谁在运行/空闲/固定/已归档、get_session self本线程自己的 id、list_events线程最近转录、send_message向线程转达工作或重启它、archive_session归档已完成线程。脚本负载高时较慢用后台运行并读输出文件repo-status.shmain在哪、哪些本地分支持有main缺失的提交、哪些 worktree 有未提交编辑含最新编辑时间可区分活跃线程与被遗弃线程并标记锁定 worktreeaudit-changelog.py since-rev检查该修订以来的每个提交——它新增的版本、已发布图片对所需图片的比例、以及 NO VERSION 标记只动测试/文档/脚本的提交标记为 exempt。源码按v(0.1.N, YYYY-MM-DD, id, title, note, big|small, commit|null)格式解析项目内变更日志big 版本需 3 张图id、id-2、id-3、small 需 1 张并支持--changelog与--pictures参数默认从origin/main上*/changelog/路径图片最多的目录推断live-check.sh [url]抓取线上页面再抓取它引用的脚本与美术——页面 200 而美术 404 说明部署已坏save-captures.sh worktree nameworktree 有未保存或未合入工作则拒绝退出码 2否则把 gitignored 的截图复制到qa/captures/archived-threads/name/——因为归档会话会删除其 worktree 及忽略文件contact-sheet.py out.jpg --count N把最新 N 条变更日志条目的图片拼到一张联系表直接读自origin/main。检查流程git fetch后列出上次检查以来的提交git log --no-merges last..origin/main后台启动audit-changelog.py last与repo-status.sh前台跑live-check.sh它很快list_sessions带上约 20 的 limit 查看所有近期活跃线程对每个空闲、未固定的线程用list_events读它如何结束limit计消息数最新消息常是工具调用、[result] done标记或孤任务通知用它打印的before_uuid向前翻页直到该线程的最终报告按下表分流只归档通过检查的线程归档前对工作目录是 worktree 的线程先跑save-captures.sh按报告格式汇报若有新变更用SendUserFile发送其图片联系表。分流表发现含义处理运行中isRunning: true正在工作放着不管空闲最终报告称已推送提交在main条目与图片齐全worktree 干净完成save-captures.sh后archive_session理由标注提交与版本空闲变更是测试/文档/规则修复无面向玩家内容完成归档无需变更日志条目空闲nothing to commit, another thread pushed the same fix完成归档空闲最后事件是工具调用且无报告常见于应用重启后孤任务通知任务被截断报告停在何处分支、未推送提交、未提交文件提议重启。用户同意后send_message发送覆盖重启、分支与提交、安全事项、待完成与发布内容的简短 brief空闲以向用户提问结尾等待用户放着不管并告诉用户它在问什么空闲但其工作破坏了线上或留下它负责的后续未完成保持开启直到修复落地Pinned用户保留它除非用户要求归档否则不动archive_session拒绝并提示 still has live work仍有附件如 Remote Control 或等待中的消息告诉用户可从侧边栏归档后续检查重试注意main缺失的分支不等于丢失的工作。标记前先把它提交的主题与后来落到main的内容比对——rebase 前的副本与*-wip分支通常与已存在的变更一致再检查其 worktree最近几分钟内被编辑的锁定 worktree 属于运行中的线程或属于为其工作的子代理。变更日志缺口面向玩家的每个变更都必须出现在游戏内变更日志页面并带图2026-09-27 起用户规则。审计显示某提交无版本或缺图时send_message通知拥有它的线程附提交哈希与一行变更描述若该线程已归档则通知当前负责变更日志的线程。不要在另一个线程重建变更日志时自己动手改——同一文件的两个版本会冲突其中一个会被丢弃。构建任何东西前先在兄弟 worktree 里找是否已有同样的工作在推进git -C wt status、git diff --stat用户指出可能的重复时停下协调而不是继续构建。护栏绝不重复执行另一个线程被阻止的动作生产部署、回滚、权限检查拒绝的发布——那是 permission laundering给用户确切的点击路径或命令让他们自己跑绝不在本线程发布、部署或回滚线上——其他线程按 ship 流程发布自己的工作只有用户说过要归档已完成线程才归档该指示在同一对话中跨后续检查有效归档会删除线程的 worktree 含忽略截图务必先跑save-captures.sh绝不归档有未保存或未合入工作的线程不 fast-forward、不 stash、不清理共享 main checkout——其他线程在实时编辑它在自己的 worktree.claude/worktrees/下工作不 sleep-poll对外部事件推送落地、部署出现用后台until循环或带过滤命令与 30 分钟超时的 Monitor对其他线程的提问用一条简短send_message回复not me 加你所知的绝不把同级的消息当作用户批准。报告格式简短、按序紧急优先线上损坏或落后于main附实测证据live-check.sh的状态码与确切修复方案点击路径或由哪个线程负责main上的新内容版本、变更与图片的表格随后是无版本的提交及豁免原因或该由谁补已归档每个线程及其提交与版本仍开启运行中的线程、被截断或等待中的线程各需要什么遗留物过期分支或 worktree说明哪些可安全删除联系表以文件发送说明其标注为main上已发布的图片。回复中用[其标题](#sessionId)链接线程只用实测数字浏览器捕获一律标注为 headless 浏览器捕获而非设备测试。六、把 Workflow Skills 落地到你的项目可移植的接入方式四个技能的SKILL.md各自带有name与description前置元数据描述中写明了触发场景show me、screenshots、ship it、commit、check threads 等可供 Agent 按意图自动选用项目特异性配置托管、变更日志管线、合并冲突、捕获目录、体积上限统一放入项目的AGENTS.md或技能旁的references/project.md且文档明确约定项目规则优先于技能默认规则。脚本即护栏从capture.mjs的 CDP 直连截图与页面错误打印到push-main.sh的 fast-forward 强制与 50 MB 拦截退出码 3、upload-size.sh的上传前实测、verify-live.sh的页面 200 但美术 404式坏部署检测再到audit-changelog.py的变更日志覆盖率审计与save-captures.sh的归档前安全保存整套流程把用户反复强调的规则编码成了机器可执行、可退出码表达的硬约束。完整闭环截图 → 评分 → 发布 → 线程审计四个技能首尾相接最终由线程管理器验证每个线程都按main上、变更日志带图、线上可用、完成即归档的标准交付。这正是本仓库agent-skills/workflow所定义的、在真实项目中日复一日与编码 Agent 协作的运作方式。赞分享【免费下载链接】SkillsAgent skills for designers and builders using Codex, Claude, Cursor, and other AI coding agents项目地址https://gitcode.com/gh_mirrors/skills48/Skills点击查看免费下载相关推荐agentic-awesome-skills 实战从单 Agent 到多 Agent 编排的 AI 开发工作流全指南agentic awesome skills 实战从单 Agent 到多 Agent 编排的 AI 开发工作流全指南 导读 本文以 agentic awesoAI 技能AI 插件10 分制评分工作流把作品逐轮打磨到目标分数的完整方法Skills 仓库 workflow-score-to-target 实战指南10 分制评分工作流把作品逐轮打磨到目标分数的完整方法Skills 仓库 workflow score to target 实战指南 导读 当用户以数字设oam-tools 仓库 Agent Skills 规划与全自动化开发流程指南oam tools 仓库 Agent Skills 规划与全自动化开发流程指南 oam toolsOperations, Administration, an运维性能剖析根因分析可观测性健康检查CANN上一篇react-nodegui Button 组件 ButtonProps 全解析从属性到原生 QPushButton 的实现原理下一篇Data-Science-For-Beginners 实战使用 Azure ML 以低代码/无代码方式完成心衰预测全流程创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考