跳到正文
cccskills
免费在 GitHub 公开

recurring-review-findings

Use when the same remark keeps being made in a repository's pull request reviews, or when someone asks what the reviews keep catching and how to stop catching it. Groups the comment history into recurring findings and decides, for each, the rung that removes it: a design that makes it impossible, a lint or type rule, a test in CI, a convention, a fix to the skill that produced the code. Produces a report in aiview with a recommendation per finding, applied on a yes. Not for reviewing one pull request (pr-review) and not for writing a rule already decided (write-conventions).

中文简介正在准备中。当前显示原文说明。

Ovich/swarmstorm星标 13(GitHub 13 + cccskills 0)

实测评分 未实测

查看安装方法

包含的文件(4)

  • SKILL.md4.2 KB
  • references/ladder.md4.7 KB
  • scripts/comments.mjs2.2 KB
  • scripts/comments.test.mjs1.3 KB

SKILL.md(原文)

安装前可以查看交给 AI 代理的指令内容。

Recurring review findings

A review comment made twice is a finding about the process: something upstream, a design, a tool, a test, a rule, a brief, let it reach a human. Find the rung where it stops.

Read the history

  1. Run scripts/comments.mjs <owner/repo> for the thread openers: every review comment by a person, bots excluded, replies excluded, with its pull request, path, date and body. --since <ISO> after an earlier run, --json to parse.
  2. The person's own words are the signal. A bot's comment counts as a second source, never as the finding. A reply that says "done" and cites a commit is the evidence of what the fix was: read it for the shape the person accepted.
  3. Read the reports of pr-review in aiview (list --kind report) for the findings the agent raised itself, and the conventions file for the rules that already exist: a finding a rule already covers is a finding about the rule, its wording, its cost line, or its enforcement.

Group

  • A finding is one thing the person wanted done differently, named in their words, however many files and pull requests it spans. "One service owns the current user", "the mock is a module, not a branch in the client", "a primitive stays in ui/, business logic leaves it".
  • Two occurrences is a candidate, three is overdue. One occurrence stays a comment, unless the person's reply said "that is now the rule": then it is a decision already made and the question is only its rung.
  • Count what it cost: the occurrences, the pull requests, the rework commits each one caused.
  • A comment whose answer was "no, and here is why" is not a finding. Drop it, and say so in the report: the person may want a rule saying why.

Choose the rung

Read references/ladder.md before choosing: the rungs in order of preference, the criterion that admits a finding to each, the artefact each produces. The highest rung the finding admits wins: every rung below it leaves a human to catch it again. A finding may take two rungs, the design change that removes its class and the test that keeps it removed.

The report

One report document, opened in aiview when the reading starts: kind report from the filename YYYY-MM-DD-review-findings.report.md, tags = review-findings, started when the reading began. Tell the person the URL.

Per finding, a section: the person's words, the occurrences linked, the cost, the rung with its criterion met, the artefact drafted in full (the rule text in the shape write-conventions asks, the lint configuration, the test, the sentence for the skill, the design change as a paragraph and the modules it creates), and one line saying what stays with a human after it. A recommendation first where two rungs compete. The close: a table of finding, rung, cost, and the ones dropped with why.

Apply

On the person's yes, per finding, never as a batch. A rule goes through write-conventions, capture mode. A lint rule and a test go into the repository on a branch, the test red on the tree's existing violations first. A design change is a plan (write-plan), never a change made from here. A sentence for a skill in this collection is proposed to the person with the skill named, written on the yes.

Red flags

ThoughtReality
"This one is obvious, a rule will do"A rule is read after the code is written. Try the rungs above it first.
"Five occurrences, so a lint rule"The count says how urgent. The criterion says which rung.
"The person wrote 'can we', so it is a question, not a finding"Read the reply. A "done, commit x" answered it as a finding.

评价

还没有评价。欢迎分享你的使用感受。

评论

无需登录即可发表。欢迎分享使用感受、提问,或说明在哪些环境下无法运行。

还没有评论。来写第一条吧。

提交后会立即公开。请勿填写邮箱、电话等个人信息。URL 最多 2 个。

0 / 1000 字

此表单受 reCAPTCHA 保护,适用 Google 的隐私权政策和服务条款。

同一仓库的技能

aiview

免费

Use whenever a document is produced for the user to read and react to while it evolves: a brainstorm board, a plan, a design language, a prototype, a PR analysis, a review report, a live PDF. Also when a document must be registered, opened, listed, moved or retired, or a prototype's bindings checked. Not for code, tests or configuration, or any file nobody opens in a browser.

中文简介正在准备中。当前显示原文说明。

Ovich/swarmstorm132026年10月29日 更新

Use when a person wants to think an idea through and keep the discussion: a feature, a tool choice, an architecture question, before a plan or without one, with the agent through an interview. Produces a board in aiview holding the decisions, the diagrams and what was investigated. Not for a swarm of seats working it (brainswarm), not for an implementation plan and not for bug fixes.

中文简介正在准备中。当前显示原文说明。

Ovich/swarmstorm132026年10月29日 更新

Use when a person wants a swarm of role seats to work a topic on the swarm board under a chosen protocol: a brainstorm (ideas before any judgment), a debate (questions argued to decisions, a skeptic endorsing) or an editorial (one text drafted, read by seats standing for its readers, revised), a protocol or template the project keeps as a `protocol-<name>` skill (or an older `brainswarm-<name>` one), or a custom protocol recommended for the person's intent, or a seat's brief names a brainswarm protocol. Produces the run's record in aiview, written by the orchestrator alone. Not for one person thinking aloud with the agent (brainstorm, interview) and not for a plan's slices (execute-plan).

中文简介正在准备中。当前显示原文说明。

Ovich/swarmstorm132026年10月29日 更新

cold-read

免费

Use when dispatched to cold-read a plan, as an agent that was not in the conversation that wrote it, to say whether it can be carried out from the document alone. Produces what the reader would build, its questions, and a verdict, ready or not ready, repeated as the writer fixes the plan. Not for judging the design (interview, pr-review), not for the mechanical checks (aiview plan check, tracker check), and not for writing the plan (write-plan).

中文简介正在准备中。当前显示原文说明。

Ovich/swarmstorm132026年10月29日 更新

Use when code is hard to follow and is to be audited or reworked: long if/else or switch chains, cascades of type checks or parse attempts, kind fields compared to strings, flag parameters, deep nesting, a function hard to read. Also for complexity guardrails, or one long conditional function pasted. Produces a ranked audit of families, one family reworked behind characterization tests, or the guardrails.

中文简介正在准备中。当前显示原文说明。

Ovich/swarmstorm132026年10月29日 更新

Use when a page is wanted to work on something with the person during development, fed the project's real data (comparing model answers, walking an agent call by call, measuring an output against its template), when such a workbench has to change, be reworked or its feed broke, or mid-session when turns went into aligning with the person on how to do a kind of work that recurs and real project data could show it. Produces the page in aiview, kind `workbench`, and the project's `workbench-<bench>` skill with its feed and operating steps. Not for designing a product screen (design-prototype) or verifying user stories (verification-skill-create).

中文简介正在准备中。当前显示原文说明。

Ovich/swarmstorm132026年10月29日 更新

查看 Ovich 的全部技能

报告此技能的问题