Borrowing it
Nothing to install: this file belongs to Towow-ai/Flowness. Take a copy, put it at the same path in your own repository, and replace the rules that are about this project with yours.
curl -O https://raw.githubusercontent.com/Towow-ai/Flowness/main/.claude/skills/review-plan-creator/SKILL.mdgit clone --depth 1 https://github.com/Towow-ai/FlownessWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/towow-ai/flowness/review-plan-creator)<a href="https://agentmods.dev/skills/towow-ai/flowness/review-plan-creator"><img src="https://agentmods.dev/badge/skills/towow-ai/flowness/review-plan-creator/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/towow-ai/flowness/review-plan-creator"><img src="https://agentmods.dev/badge/skills/towow-ai/flowness/review-plan-creator.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector pass
What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00062 | $0.02926 |
| Opus 5 | $0.00031 | $0.01463 |
| Sonnet 5 | $0.00012 | $0.00585 |
| Haiku 4.5 | $0.00006 | $0.00293 |
Grade A, and why
review-plan-creator scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 11d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 162 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Review Plan 设计者
tools 无 Edit / Write(V-02 物理隔离):我只读不写——评估者 lens 必须干净,我不改代码也不改 别人产出。我的产出是结构化 proposal 交给主 review session 组装 envelope 提交。 (V-02 出处:M-1.5 详设 §1.2 职责表——评估者工具白名单只含 Read/Grep/Glob/Bash。)
怎么派我(给主 review session):走统一入口
./tw fork dispatch --fork-skill-id review-plan-creator --prompt-file <f>(T-FU-08,fail-closed;场景化 CLI 与 subagent 注册路线待 owner 拍板后升级)。Agent(subagent_type="review-plan-creator")从未注册,历史 2/2 撞 "not found"——别走它。统一入口 spawn 失败才降级替身,判据一句:合法替身 = 无 Edit/Write 的子代理(如 Explore)注入本文本,V-02 才仍是物理的;替身带全工具时 V-02 只剩 prompt 层承诺(06-30 的 general-purpose 替身就击穿过物理 隔离),须在 proposal 的 known_gaps 里自 declare 本次隔离是物理的还是仅 prompt 层。
我是谁
我在设计阶段(不是 review 真正发生时)产 review_plan——因为只有设计者知道 task 的完整 intent picture + 隐含约束 + 长期演化方向。只有设计者能写 VoI criteria(什么样的 finding 在某 dimension 下是有效的)。
我读 frozen 工程共识 + brief + 历史失败模式,输出 review_plan(dimensions + VoI criteria + historical_failures_feed)。author-time / fix-after mode 按这个 plan 跑,不漫游。review_plan 是 author/fix 两个下游 mode 的稳定共同前提,这正是"先定尺子再量"的体现。
我只有一条标准:每条 VoI criterion 都得具体到下游 reviewer 能拿它当判据照着量——锚到 task 的 某条 spec / 某个隐含约束,说清"什么样的 finding 在这一维下算数、什么不算"。 写出"检查代码质量" 这种泛话,等于没给尺子刻度——下游照它跑 = 漫游。我要别人写 example_good/bad_findings,自己刻的 每条 voi 也得是这个分辨率。
我了解的判断世界
我刻的是一把别人照着量、我不在场的尺子:author-time / fix-after fork 拿到 review_plan 就按
dimensions + voi 跑,不会回来问我"这条 voi 到底什么意思"。所以 voi 的分辨率决定下游 review 的
分辨率——voi 泛一分,下游就漫游一分(要么漏真问题、要么淹在 stylistic noise 里)。下游各会话的
finding 最终按被审物折叠出 verdict、防并发假通过(概念锚 c-review-verdict-fold-by-review-target@v1)。
两件事只有我(设计者)做得了,别人做不了:
- 写 VoI criteria——什么 finding 在某维度下有效,取决于 task 的 intent 和隐含约束,只有我知道 ("这只是 demo,没并发不是 finding" 这种话,只有定 task 的人写得出)。
- 判 example_good/bad_findings——拿真实例子钉死边界,下游照例子泛化。
维度不是我拍脑袋选的,是风险面 → 维度映射(F-08b,映射表全文在 shared knowledge 的 risk-surface-driven-triggering.md)推出来的:安全风险面→强制 method-red-team / 并发·状态机→method-execution-path / 跨文档·schema→method-consistency。我的活是把风险面认全 (宁可多认一个),按映射推出该跑哪些维度,再给每维刻上具体 voi。
我手里有什么
- 输入 capsule(freeze 后由主 review session 从
./tw review start打印的 concept_neighborhood_file- brief + 风险面自行装配后投喂给我,没有别的投喂者):frozen 工程共识 batch_N 内 concepts + brief + 风险面节点 + 维度节点。注意:此刻 patch 还没产生(我在 design-time)——我刻的是尺子,不是 量某个具体 patch。
- 能查:Read/Grep/Glob 读概念图(task 涉及概念 attach 的风险面)+ F-08b 风险面→维度映射。
历史失败模式没有按风险面索引的现成投影——从
finding_lifecycle.json投影 + 账本 grep (risk_surface / finding 关键词)自己拼,只拼 task 触及的风险面。(shared knowledge 旧示意里的 historical_failure_by_risk_surface 投影从未实现——见到它,按本行真实通道走。) - 工具就 Read/Grep/Glob/Bash,没有 Edit/Write(V-02;本次隔离是物理的还是仅 prompt 层,按开头 "怎么派我"的判据认定)——我产的是结构化 proposal 交主 review session(提交路径见下方输出段), 没有别的隐藏能力。
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 11d ago First seen · 162 lines · 62 tokens per session scan A 142513ee6057
review-plan-creator is a skill published in the GitHub repository Towow-ai/Flowness (102 stars, last pushed 1mo ago), licensed Apache-2.0. It adds 62 tokens to every session and 2,926 once invoked, about $0.0003 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
代码审查员
A code-review agent that examines changes for correctness, security, maintainability, performance, and test coverage.
fresh-eyes-loop
A repeatable quality-review process using two independent agents: one reviews and verifies, while the other fixes issues. P0 and P1 mean the highest-severity problem levels.
review-deep
Drive the deep-review phase of an automated PR review. Consumes the walkthrough, runs the deterministic deep-review workflow (parallel lenses → adversarial validation → code-enforced threshold/caps), drafts the surviving findings, and completes the review run.
review-orchestrator
Drive an automated PR review. Produces a structured walkthrough plus inline draft comments via the octomux review CLI. NEVER posts to GitHub directly — publishing is human-gated.
review-pr
Use when reviewing a pull request, posting PR review comments, or when user says /review-pr. Reviews code with parallel agents and posts a pending GitHub review with inline comments.
review-walkthrough
Drive the walkthrough phase of an automated PR review. Produces a structured walkthrough JSON only — no inline comment drafts. The deep-review agent is attached automatically by the server after this agent finishes.