1实现原理 · 为什么它能做到
执行体是 6 路并行 fan-out：六个互相独立的 inspector 各自负责一个维度（代码/脚本安全、文档 SSOT 一致性、安全/PII、开放 PR 分诊、开放 issue 分诊、marketplace 清单完整性），同一时刻并行跑完。
marketplace-health-check/SKILL.md
Six independent inspectors cover, in parallel:
注：六维之间没有依赖关系，所以能完全并行——这是本 skill 相对「单个 agent 串行扫全仓」的全部性能来源；每个 inspector 只带自己那一段 prompt，上下文互不污染。
并行不是口头建议而是代码实现：workflow.js 里 phase('Inspect') 之后用 parallel() 把六个 dim 各起一个 agent()，每个 agent 绑定同一份 CHECK_SCHEMA 结构化输出契约。
marketplace-health-check/scripts/repo-health-check.workflow.js
const checks = await parallel(dims.map(d => () => agent(COMMON + d.prompt, { label: 'check:' + d.key, phase: 'Inspect', schema: CHECK_SCHEMA })))
注：这里在做什么：dims 数组的每一项 = 一个维度（key + 一段长 prompt），parallel 并发调度，agent(..., {schema}) 强制每个 inspector 交出同形状 JSON，主 agent 拿到的就是可汇总的六份结果。
必须 inline 运行，禁止 context: fork——因为 fork 出来的 subagent 无法再 spawn subagent、也无法启动 workflow，一旦 forked 整个 fan-out 会静默失效。
marketplace-health-check/SKILL.md
**This skill must run inline (no `context: fork`).**
注：SKILL.md 把这条写进「Why a workflow — and why it MUST run inline」段，是和运行环境耦合的硬约束，不是风格建议。
脚本通过 Workflow 工具的 script 参数整段内联传入，而不是让宿主按安装路径去找文件。
marketplace-health-check/SKILL.md
Read the bundled script and launch it **inline via the `script` parameter**
注：配套调用形态在 SKILL.md 代码块里给出：Workflow({ script: <full contents of scripts/repo-health-check.workflow.js>, args: { repo: "<owner/name>", scale: "<one-line summary from Step 1>" } })——消除「skill 装在哪」这个变量。
先用一次快速 scout 采集仓库规模（repo 名、skill 数、开放 PR/issue 数、manifest 版本、HEAD、最新 release），作为 args 共享给六个 inspector；不传则每个 inspector 自行重新发现。
marketplace-health-check/SKILL.md
gh repo view --json nameWithOwner,stargazerCount,isPrivate | jq -c .
注：对应 workflow.js 的 ctx 逻辑：const repoName = ctx.repo || … 与 const scale = ctx.scale || 'NOT pre-supplied …'，以及注释 args is OPTIONAL — if omitted, each inspector self-discovers the repo scale first.；SKILL.md 还要求先确认 isPrivate: false 才把 PII 当发布风险。
输出契约被 schema 钉死：每维返回 dimension/health/summary/findings[]/stats，findings 每条必须带 severity（critical|high|medium|low|info）、title、detail、location、recommendation。
marketplace-health-check/scripts/repo-health-check.workflow.js
severity: { type: 'string', enum: ['critical', 'high', 'medium', 'low', 'info'] },
注：同一 schema 里 health 限四档（good|minor-issues|needs-attention|critical），且 additionalProperties: false——六份结果因此可以直接拼成一张健康表，也逼 inspector 不许自造字段。
输出纪律是本 skill 的核心：inspector 的结论被明确降级为 hypotheses，禁止原样转述，必须由执行者亲自复验后再报告。
marketplace-health-check/SKILL.md
**Agent findings are HYPOTHESES, not conclusions. Never relay them verbatim.**
注：SKILL.md 要求对每条 high/critical 用一条快命令复核（grep 泄漏值、sed -n 看坏行、gh repo view 核对宣称状态），再经四问过滤：probability / cost / real scenario / verifiable。
报告按优先级与证据等级分层，而不是把 25 条 finding 倒给用户。
marketplace-health-check/SKILL.md
- **🔴 Must-fix** — each VERIFIED high/critical, with exact location + a concrete fix
注：层级为：一行结论 + 六维健康表 → 🔴 Must-fix → 🟠 Backlog → 🟢 Optional → 💡 Key insights；每条再打 ✅ real / ⚠️ partly / ❌ false-alarm，SKILL.md 直言多数原始 agent 输出是噪音。
全程声明只读（inspectors 不得改文件、不得评论 PR/issue、不得 push），并在开工前把成本告知用户。
marketplace-health-check/scripts/repo-health-check.workflow.js
This is READ-ONLY: do NOT modify files, comment on PRs/issues, or push. gh CLI is authenticated.
注：成本在 SKILL.md 里量化：~15-20 min, ~400-500k output tokens 并要求 tell the user the cost up front；后续修复被推给 owner 决策，skill 不自动改、不自动评论。
2核心能力
01六维仓库体检的并行编排（Workflow 脚本 + 6×agent 并行 fan-out）
02结构化 finding 输出（health 四档 / severity 五档 / 必填 location 与 recommendation）
03开放 PR 逐个分诊：worth-merging / needs-changes / low-quality-or-spam / SHOULD-DECLINE，并检查外部 PR 普遍漏掉的强制 version bump 与 CHANGELOG
04开放 issue 分类（real-bug / skill-request / cross-list-or-promotion / question）并主动排查 broken-install-command 这一类 bug
05marketplace 清单完整性校验：跑 check_marketplace.sh 与 check_doc_skill_lists.py，核对 orphan SKILL.md、套件成员注册、版本与计数对账
06安全/PII 语义审计：关键词无关的泄漏（真实人名、私有域名）、.security-scan-passed marker 缺口清单、case 文件人读复核
07Counter-Review 判据库：anti-target / git history 曝光 / scan marker 必要性而非充分性 / 强制版本号 / promotion 默认拒绝
08按优先级 + 证据等级分层的最终报告（🔴/🟠/🟢 + ✅/⚠️/❌ + insights）
3外部依赖
| 类型 | 依赖 |
|---|---|
| cli | gh（GitHub CLI） |
| cli | jq |
| cli | git |
| cli | bash（执行仓库自带检查脚本） |
| cli | python3 |
| cli | uv（跑 skill-creator 的 security_scan 模块） |
| cli | claude plugin validate（经 check_marketplace.sh 调用） |
| cli | gitleaks（经 security_scan.py 调用） |
| cli | grep / find / sed（检索与逐行核对） |
| api | GitHub REST API（经 gh CLI：PR / issue / release / repo 元数据，只读） |
4风险提醒 风险提醒：黄色 · 留意使用
风险提醒：黄色 · 留意使用
- 强仓库绑定，迁仓即失真 — 六个维度 prompt 硬编码 daymade-claude-code/marketplace-dev/scripts/*、daymade-skill/skill-creator/*、~/scripts/git-pii-guard、macos-cleaner 等本仓路径；换仓库使用需要重写 prompt，否则会出现「脚本不存在」「路径找不到」式的假 finding。
- 只读是约定的、不是强制的 — inspector 实际持有 bash 与已认证的 gh；不得修改/评论/push 只是 prompt 与文档约束。执行者若越界或误判，后果由宿主权限兜底。另外 security_scan.py 的 marker 改写是已知的、需要人工 git checkout 还原的副作用。
- 对抗性输入面真实存在 — 仓库文件与外部可写的 PR/issue 正文都会进入 inspector 上下文；agent 权限足够大时，被注入的指令有落地可能。Counter-Review 只能提高发现错误结论的概率，不能阻止执行。
- 效果取决于执行者的判断力 — 方法论文档自己承认 inspector 会给出「正确发现问题、但修法让事情更糟」的建议（如把真实私有域名写进公开 .gitleaks.toml）；过滤质量取决于模型水平，且六份碎片结果的人工汇总本身就是工作量。
- 成本与时延偏高 — 6 个子 agent、约 15-20 分钟、40-50 万 output token；对小仓库或只改一两个文件的任务性价比明显不如直接读代码。
风险提醒：黄色，知晓即可。它不是纯 prompt skill：由 Workflow 脚本派生 6 个具备 shell 与 gh 权限的 inspector，会用用户已登录的 GitHub 凭证对 api.github.com 发只读查询，并点名执行仓库自带脚本（check_marketplace.sh / check_doc_skill_lists.py / security_scan.py）。没有外发到第三方的端点、没有读取密钥文件、没有破坏性写操作，故不到橙档；但它确实执行脚本并发起带凭证的网络请求，档次高于纯只读的绿/蓝。残余风险有三：①代码级副作用 security_scan.py 会改写 marker，只读承诺靠事后 git checkout 补救；②只读是 prompt 约束而非权限约束，inspector 实际持有 gh 写权限；③注入面（仓库文件与 PR/issue 正文进入有权限的 agent 上下文）是其最大不确定项。
5第二遍独立确认
- [ok] 六维清单与代码 dims 一一对应 — SKILL.md 列的六维（代码/脚本安全、文档 SSOT、安全/PII、开放 PR、开放 issue、marketplace 清单）与 workflow.js 的六个 key（code-and-script-safety / doc-consistency / security-pii / pull-requests / issues / marketplace-integrity）逐项对应，dims 数组经计数恰为 6 项，无多无少。
- [ok] parallel fan-out 是真实实现而非修辞 — 源码含 phase('Inspect') 与 parallel(dims.map(d => () => agent(COMMON + d.prompt, { label: 'check:' + d.key, phase: 'Inspect', schema: CHECK_SCHEMA })))，description 里「parallel fan-out Dynamic Workflow」无夸大。
- [ok] 必须 inline 的运行约束 — SKILL.md 逐字存在该段，且理由（forked subagent 不能 spawn subagents 或启动 workflow）与 workflow 脚本调用 agent()/parallel() 的宿主能力要求自洽。
- [ok] 外部 CLI 调用点真实存在 — gh、jq、git、bash、python3、uv、claude plugin validate、gitleaks 均在 SKILL.md 或 workflow.js 逐字可定位；gitleaks 仅出现在 methodology 对 security_scan.py 实现的描述里，属间接调用（该脚本确实存在于 daymade-skill/skill-creator/scripts/security_scan.py）。
- [unlocatable] gh 网络端点域名 — 仓库内检索 api.github.com / github.com 零命中：skill 只写 gh CLI is authenticated. 与各 gh 子命令，端点域名按 gh CLI 的默认行为推断为 api.github.com，无法在源码内取证，已在 external_deps 与 security.network_calls 中标注该推断。
- [discrepancy] 只读承诺 vs 实际副作用 — 脚本注释、COMMON prompt 与 SKILL.md 三处 READ-ONLY 声明针对「文件修改/评论/push」，但 methodology 自述 security_scan.py MUTATES the marker file，并要求 git checkout 还原。故第一遍若把本 skill 概括为「零写入」属过强；准确说法是「对代码与协作面无写入，但被点名执行的扫描器有一条 marker 写副作用，靠人工还原」。
- [ok] 资产引用路径真实存在 — workflow.js 引用的 check_marketplace.sh、check_doc_skill_lists.py 与 security_scan.py 在 pin commit 下均真实存在；SKILL.md 提到「repo 根、bundles 之外的 decline policy 参考文档」对应仓库根 references/promotion-policy.md，CLAUDE.md 亦以 references/promotion-policy.md 指向它。
- [unlocatable] 成本声明可验证性 — 「~15-20 min, ~400-500k output tokens」来自该 skill 蒸馏时的实测会话，仓内无基准、日志或脚本可复算，只能视为作者经验值。
6结论
适合：适合 daymade/claude-code-skills 这类规模已成型、以 marketplace.json 为 SSOT、且有开放 PR/issue 队列的多套件仓库做发布前全量体检；也适合作为「多路 fan-out + 结构化 schema + Counter-Review」工作流的模板被其他审计 skill 照抄（照抄时需替换 dims 里的仓库路径与脚本）。
不适合：不适合只查单个文件或单个 skill 的场景（description 自己划界：not just one-file checks）；不适合直接搬到别的仓库（维度 prompt 与本仓机具绑定）；不适合没有 gh 认证或没有 GitHub 远端的环境（PR/issue/release 三个维度会直接落空）；不适合期待 skill 自动修复或自动回复贡献者——文档明确把修复与对外沟通留给 owner。
安装 agent 直装可复制
① 本站镜像 更新 2026-09-15
方式 A · 人下载镜像包下载 marketplace-health-check.tar.gz
sha256:
方式 B · JSON 格式安装指南，复制给 agent066980771e4106d8…agent 读 JSON 指南后会自动从本站下载安装，无需更多说明。
② 上游 GitHub · 原始来源
来源信息 GitHub 原始
作者 / 仓库daymade / daymade/claude-code-skills
原始 GitHubdaymade/claude-code-skills ↗
Stars1392
最近推送2026-09-09
本 skill commit
d5c4678cb5许可MIT（仓库根 LICENSE 文件；GitHub API spdx MIT；Copyright (c) 2025 daymade）
本站信息
收录日期2026-09-06
分类文档与知识
侦查报告AI 侦查 · 2 遍 · 2026-09-06
本站镜像与 GitHub 原始是不同来源：本站锁定 commit 快照经 /r2 分发；GitHub 为实时上游，内容可能已更新。