fallow-review

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Fallow Review: graph-grounded code review

Fallow Review:基于图谱的代码评审

fallow review
turns a changeset into a deterministic, graph-derived review brief and an agent-contract loop. It answers "where do I look, and what calls actually need human taste?" rather than "will CI block this?" (that is
fallow audit
, which gates).
review
always exits 0, so it is safe to run regardless of verdict.
The four jobs it does, in order:
  • subtract: dead code, complexity, duplication, and styling for the changed files are reported and kept OUT of the judgment loop, so attention is not spent on what a deterministic check already owns.
  • focus: changed-file units are ranked by a composite attention score (fan-in/out, risk zone, change shape) with a
    review-here
    /
    not-prioritized
    label and a full
    deprioritized
    escape-hatch list, so nothing is hidden.
  • structure: the decision surface lifts the handful of consequential STRUCTURAL decisions out of the diff and frames each as a judgment question, capped to a working-memory-sized set, each anchored to a
    signal_id
    fallow emitted.
  • direct: the walkthrough guide hands an agent a graph-derived digest, the review direction, a graph-snapshot pin, and the exact judgment schema to return.
fallow review
将代码变更集转化为确定性的、基于图谱生成的评审摘要,以及一套Agent合约闭环流程。它解决的是“我该关注哪里,哪些内容真正需要人工判断?”的问题,而非“CI是否会阻止此次合并?”(后者是
fallow audit
的职责,用于门禁管控)。
review
命令始终返回0,因此无论评审结果如何,运行该命令都是安全的。
它按顺序完成四项工作:
  • 剥离:报告变更文件中的死代码、复杂度、重复代码和代码风格问题,并将这些内容排除在判断流程之外,避免将注意力浪费在确定性检查已覆盖的内容上。
  • 聚焦:根据综合关注度得分(扇入/扇出、风险区域、变更形态)对变更文件单元进行排序,标记
    review-here
    (需重点审查)/
    not-prioritized
    (非优先)标签,并提供完整的
    deprioritized
    (低优先级)排除列表,确保无内容被隐藏。
  • 结构化:从差异中提炼出少数关键的结构决策,将每个决策转化为一个判断问题,数量控制在工作记忆可承载的范围内,每个问题都锚定fallow生成的
    signal_id
  • 引导:引导指南向Agent提供基于图谱的摘要、评审方向、图谱快照标识以及需返回的精确判断 schema。

When to use

适用场景

  • Reviewing a PR, branch, or diff (AI-generated or human-written) before merge.
  • After an agent has done work and removed the fallow findings it could; this surfaces what is left for human/agent taste.
  • Producing inline-reviewable judgments that can flow back to the agent that wrote the code.
  • 合并前审查PR、分支或差异(AI生成或人工编写的代码)。
  • Agent完成工作并修复了fallow检测到的问题后,用于筛选出仍需人工/Agent判断的内容。
  • 生成可嵌入评审的判断结果,反馈给编写代码的Agent。

When NOT to use

不适用场景

  • Gating CI on a pass/fail verdict: use
    fallow audit
    (it exits non-zero on a fail verdict).
  • Whole-project health, cleanup, or dead-code reports: use the
    fallow
    skill.
  • 基于通过/失败结果管控CI门禁:请使用
    fallow audit
    (失败时返回非0值)。
  • 全项目健康检查、清理或死代码报告:请使用
    fallow
    技能。

Quick human brief

快速人工评审指南

bash
undefined
bash
undefined

Auto-detect the base (merge-base against the upstream / remote default):

自动检测基准分支(与上游/远程默认分支的合并基准):

fallow review
fallow review

Pin the base, or scope to a precise diff:

指定基准分支,或限定精确的差异范围:

fallow review --base origin/main git diff --find-renames origin/main...HEAD | fallow review --base origin/main --diff-stdin

The human brief prints the orientation facts, the focus map, and the decision surface ("Decisions to make"). `--format json` emits the full structured envelope (`decisions`, `focus`, `deltas`, `impact_closure`, `partition`, `graph_facts`). `--max-decisions N` tunes the cap (clamped to a small band). `--show-deprioritized` expands what the focus map collapsed.
fallow review --base origin/main git diff --find-renames origin/main...HEAD | fallow review --base origin/main --diff-stdin

人工评审指南会显示定位信息、聚焦映射表以及决策面(“需做出的决策”)。使用`--format json`可输出完整的结构化包(包含`decisions`、`focus`、`deltas`、`impact_closure`、`partition`、`graph_facts`)。`--max-decisions N`可调整决策数量上限(限制在较小范围内)。`--show-deprioritized`可展开聚焦映射表中折叠的低优先级内容。

The decision surface

决策面

Each decision is a framed question anchored to a
signal_id
fallow deterministically derived from the graph (a delta key or a coordination-gap key). There are exactly three shippable categories:
  • coupling-boundary: a new cross-zone dependency edge.
  • public-api-contract: a new exported public-API surface, or a changed contract consumed by modules OUTSIDE this diff (a coordinate-or-confirm signal).
  • dependency: a new third-party dependency (new maintenance + supply-chain surface).
A decision may carry
previous_signal_id
when its anchor file was renamed in the change: that is the
signal_id
the same decision would have had at the old path, so a review surface can re-attach a prior reviewer comment across a
git mv
.
每个决策都是一个结构化问题,锚定fallow从图谱中确定性生成的
signal_id
(差异键或协调间隙键)。共有三类可交付的决策:
  • coupling-boundary:新增跨区域依赖边。
  • public-api-contract:新增导出的public-API接口,或变更了被此差异外的模块所依赖的合约(需协调或确认的信号)。
  • dependency:新增第三方依赖项(新增维护及供应链层面的关注点)。
当锚定文件在变更中被重命名时,决策可能会携带
previous_signal_id
:这是该决策在旧路径下对应的
signal_id
,便于评审界面在
git mv
操作后重新关联之前的评审评论。

Eliciting the broader trade-offs (taste ownership)

挖掘更广泛的权衡(判断归属)

The decision surface above is the DETERMINISTIC slice: only the trade-offs fallow can prove from the graph (the three categories). Real architectural trade-offs are broader, abstraction level, error-handling strategy, data-model shape, eager-vs-lazy, state ownership, extensibility-vs-YAGNI, testability, trust boundaries, and none of those are graph-detectable. Surfacing them needs a model reading the diff, not a static pass.
Run the trade-off elicitation prompt in
references/tradeoff-elicitation.md
over the diff plus the guide. It applies TASTE OWNERSHIP: the model makes each choice legible and frames a genuinely open question; the human decides. It never prescribes the answer (not even via a leading "..., or should you X?"), never blocks. The honesty rails: anchor every trade-off to a line present in the diff (with one sanctioned cross-cutting slot), keep
observed
(neutral fact) /
tradeoff
(inference) /
question
(open decision) separate, fence every item as
deterministic: false
, mark provenance honestly (
captured
is a hint, not a trust score), rank by
consequence
and keep the top five or honestly abstain, and never repeat what fallow's deterministic surface already framed.
This is the model-inferred companion to the deterministic surface: fallow owns what it can prove, the prompt covers the rest, and the fencing keeps the two from being confused. The framing prose (the
observed
/
tradeoff
/
question
discipline) is still agent-enforced. The ANCHOR is now fallow-validated: the guide emits a per-changed-region
change_anchors
set, and a judgment may cite a
change_anchor
instead of a
signal_id
. fallow post-validates it on reentry and rejects an anchor it never emitted (
unknown-change-anchor
), recording
anchor_kind: "change"
to mark it as the WEAKER, region-level anchor (it proves the region changed, not that a finding exists there, which is
anchor_kind: "signal"
).
上述决策面是确定性部分:仅包含fallow可通过图谱证明的权衡(三类)。实际架构权衡涉及更广泛的内容,如抽象层级、错误处理策略、数据模型形态、即时加载vs延迟加载、状态归属、扩展性vsYAGNI、可测试性、信任边界等,这些都无法通过图谱检测。挖掘这些内容需要模型读取差异,而非静态扫描。
在差异内容及指南之上运行
references/tradeoff-elicitation.md
中的权衡挖掘提示词。它遵循判断归属原则:模型明确每个选择的依据,并提出真正开放性的问题;由人类做出决策。它从不给出预设答案(甚至不会通过引导性的“……或者你应该选择X?”来暗示),也不会阻止流程。需遵循诚实准则:每个权衡都锚定差异中存在的代码行(允许一个跨领域例外),区分
observed
(中性事实)/
tradeoff
(推论)/
question
(开放性决策),标记每个条目为
deterministic: false
,如实标记来源(
captured
是提示而非信任分数),按
consequence
排序并保留前五项或如实弃权,且绝不重复fallow确定性决策面已涵盖的内容。
这是确定性决策面的模型推论补充:fallow负责它能证明的部分,提示词覆盖其余部分,边界划分避免两者混淆。结构化表述(
observed
/
tradeoff
/
question
规则)仍由Agent执行。锚点现在由fallow验证:指南会为每个变更区域生成
change_anchors
集合,判断结果可引用
change_anchor
而非
signal_id
。fallow在返回时会进行事后验证,拒绝未生成的锚点(
unknown-change-anchor
),并标记
anchor_kind: "change"
以表明这是较弱的区域级锚点(仅证明该区域发生了变更,而非该区域存在问题,后者对应
anchor_kind: "signal"
)。

Running it as a review step

作为评审步骤运行

When a review surface (the fallow review app, or you in the terminal) wants the trade-off surface alongside the deterministic decisions:
  1. Fetch the guide and read the diff:
    bash
    fallow review --base <ref> --walkthrough-guide --format json > guide.json
    git diff <ref>...HEAD            # or: git diff --cached  for staged work
  2. Run the
    references/tradeoff-elicitation.md
    prompt over the diff plus
    guide.json
    .
  3. Emit the envelope (the
    { graph_snapshot_hash, abstained, tradeoffs[] }
    shape) to
    .fallow-review/tradeoffs.json
    in the repo root, the sibling of
    .fallow-review/feed.jsonl
    , so a review surface can render it.
This step is deliberately NOT part of the post-validate agent-contract loop below. The trade-off envelope is never round-tripped through
fallow review --walkthrough-file
(which only validates emitted
signal_id
s), so it carries NO fallow-grade guarantee: every item stays
deterministic: false
, agent-self-checked against the diff, not graph-validated. Do not present it as fallow-validated.
当评审界面(fallow评审应用或终端中的你)希望同时获取权衡面和确定性决策时:
  1. 获取指南并读取差异:
    bash
    fallow review --base <ref> --walkthrough-guide --format json > guide.json
    git diff <ref>...HEAD            # 或:针对暂存的工作,使用 git diff --cached
  2. 在差异内容及
    guide.json
    之上运行
    references/tradeoff-elicitation.md
    中的提示词。
  3. 将结果包(
    { graph_snapshot_hash, abstained, tradeoffs[] }
    格式)输出到仓库根目录的
    .fallow-review/tradeoffs.json
    中,与
    .fallow-review/feed.jsonl
    同级,以便评审界面渲染。
此步骤特意未纳入下方的事后验证Agent合约闭环。权衡结果包绝不会通过
fallow review --walkthrough-file
进行往返验证(该命令仅验证生成的
signal_id
),因此不具备fallow级别的保证:所有条目始终标记为
deterministic: false
,由Agent自行对照差异检查,而非通过图谱验证。请勿将其呈现为fallow验证过的内容。

The agent-contract loop

Agent合约闭环

The loop lets an agent produce judgments that fallow post-validates against the live graph. The verifier is the graph, not a second model.
  1. Fetch the guide:
    bash
    fallow review --base origin/main --walkthrough-guide --format json > guide.json
    The guide contains:
    digest
    (the brief + decision surface),
    direction
    (where to look),
    graph_snapshot_hash
    (the staleness pin),
    agent_schema
    (the exact shape to return), and
    injection_note
    . The digest is built from the graph ONLY; PR prose is never folded in, so the guide is injection-resistant by construction.
  2. Read the decisions in
    digest
    . Each carries a
    signal_id
    , a
    category
    , the framed
    question
    , and an
    anchor_file
    /
    anchor_line
    .
  3. Return a judgment matching
    agent_schema
    :
    json
    {
      "graph_snapshot_hash": "<echo the value from the guide>",
      "judgments": [
        {
          "signal_id": "<one signal_id fallow emitted>",
          "framing": "<your reasoning for the human reviewer>",
          "concern": "<optional: the specific thing to check>"
        }
      ]
    }
    Every
    signal_id
    MUST be one fallow emitted in the guide (
    emitted_signal_ids
    ). An unanchored id is rejected. Echo the
    graph_snapshot_hash
    verbatim.
  4. Post-validate:
    bash
    fallow review --base origin/main --walkthrough-file judgment.json --format json
    The response sorts each judgment into:
    • accepted
      : the
      signal_id
      was emitted and the snapshot matches; the agent's
      framing
      is fenced as non-deterministic (
      deterministic: false
      ) and never gates.
    • rejected
      with
      reason: "unanchored-signal-id"
      : the
      signal_id
      was never emitted (a hallucination). Drop or correct it.
    • rejected
      with
      reason: "stale-snapshot"
      and
      stale: true
      : the tree moved since the guide was fetched. Re-fetch the guide and redo the judgments.
该闭环允许Agent生成判断结果,再由fallow基于实时图谱进行事后验证。验证方是图谱,而非第二个模型。
  1. 获取指南:
    bash
    fallow review --base origin/main --walkthrough-guide --format json > guide.json
    指南包含:
    digest
    (评审摘要+决策面)、
    direction
    (审查方向)、
    graph_snapshot_hash
    (快照新鲜度标识)、
    agent_schema
    (需返回的精确格式)以及
    injection_note
    。摘要仅基于图谱构建;绝不会纳入PR描述,因此指南从设计上具备抗注入性。
  2. 读取
    digest
    中的决策
    。每个决策包含
    signal_id
    category
    、结构化
    question
    以及
    anchor_file
    /
    anchor_line
  3. 返回符合
    agent_schema
    的判断结果:
    json
    {
      "graph_snapshot_hash": "<echo the value from the guide>",
      "judgments": [
        {
          "signal_id": "<one signal_id fallow emitted>",
          "framing": "<your reasoning for the human reviewer>",
          "concern": "<optional: the specific thing to check>"
        }
      ]
    }
    每个
    signal_id
    必须是指南中
    emitted_signal_ids
    列表里的一个。未锚定的ID会被拒绝。需原样回显
    graph_snapshot_hash
  4. 事后验证:
    bash
    fallow review --base origin/main --walkthrough-file judgment.json --format json
    响应会将每个判断结果分类为:
    • accepted
      signal_id
      已生成且快照匹配;Agent的
      framing
      被标记为非确定性(
      deterministic: false
      ),绝不会用于门禁管控。
    • rejected
      reason: "unanchored-signal-id"
      signal_id
      从未生成(幻觉内容)。请删除或修正。
    • rejected
      reason: "stale-snapshot"
      并标记
      stale: true
      :自获取指南后代码树已变更。请重新获取指南并重新生成判断结果。

Human-in-the-loop walkthrough (terminal, no app)

人工参与的闭环流程(终端,无需应用)

The agent-contract loop above carries the AGENT's framing. The SAME loop carries a HUMAN's verdict with the identical graph-validated, anti-hallucination guarantee, so a terminal reviewer with no review app can leave notes that fallow anchors and round-trips. This is the no-app path the review app's
.fallow-review/feed.jsonl
otherwise owns: the contract is the existing
--walkthrough-guide
/
--walkthrough-file
round-trip, not a new surface.
The human owns the taste; you only carry the note. fallow validates the ANCHOR (the signal or changed region exists), never the note's correctness; every carried note stays
deterministic: false
and never gates.
  1. Render the tour and read the anchors:
    bash
    fallow review --base origin/main --walkthrough                       # the staged human tour
    fallow review --base origin/main --walkthrough-guide --format json > guide.json
    guide.json
    carries the decision
    signal_id
    s (the framed structural questions), a per-changed-region
    change_anchors
    set (each
    { "change_anchor": "chg:<hex>", "file", "start_line", "line_count" }
    ), and the
    graph_snapshot_hash
    staleness pin. Surface the tour to the human and collect, per item they choose to flag, a short verdict/note.
  2. Carry each human note as a judgment (echo the hash verbatim; cite a
    signal_id
    fallow emitted for a flagged decision, or a
    change_anchor
    for any other changed region the human notes):
    json
    {
      "graph_snapshot_hash": "<echo from guide.json>",
      "judgments": [
        { "signal_id": "<an emitted decision signal>", "framing": "<the human's verdict/note>", "concern": "<optional>" },
        { "change_anchor": "<an emitted chg: id>", "framing": "<the human's note on this region>", "concern": "<optional>" }
      ]
    }
  3. Validate the capture:
    bash
    fallow review --base origin/main --walkthrough-file judgment.json --format json
    • accepted
      (with
      anchor_kind: "signal"
      or
      "change"
      ): the anchor was emitted and the snapshot matches; the human's
      framing
      is fenced
      deterministic: false
      .
    • rejected
      unanchored-signal-id
      /
      unknown-change-anchor
      : the human cited something fallow never emitted. Re-anchor to a real signal or region; do not invent one.
    • stale: true
      (
      stale-snapshot
      ): the tree moved since
      guide.json
      was fetched. Re-fetch the guide, re-capture, resubmit.
  4. Act: relay the accepted human verdicts into the coding session in place, or append them to
    .fallow-review/feed.jsonl
    so the live-injection hooks (below) carry them to the session that wrote the code. Either way the note arrives anchored and fenced, never as a fallow-grade fact.
The guarantee matches the review app's: the human cannot anchor a note to a signal or region fallow did not emit, and a note left against a moved tree is refused rather than silently mis-mapped. The terminal is a first-class capture surface, no app required.
上述Agent合约闭环承载Agent的判断逻辑。同样的闭环也可承载人类的评审结论,并具备相同的图谱验证、抗幻觉保证,因此无需评审应用的终端评审人员也可留下由fallow锚定并往返传递的注释。这是评审应用
.fallow-review/feed.jsonl
之外的无应用路径:合约基于现有的
--walkthrough-guide
/
--walkthrough-file
往返流程,而非新界面。
人类负责判断;你只需记录注释。fallow仅验证锚点(信号或变更区域存在),从不验证注释的正确性;所有记录的注释始终标记为
deterministic: false
,绝不会用于门禁管控。
  1. 渲染引导内容并读取锚点:
    bash
    fallow review --base origin/main --walkthrough                       # 暂存的人工引导内容
    fallow review --base origin/main --walkthrough-guide --format json > guide.json
    guide.json
    包含决策
    signal_id
    (结构化的结构问题)、每个变更区域的
    change_anchors
    集合(每个条目为
    { "change_anchor": "chg:<hex>", "file", "start_line", "line_count" }
    )以及
    graph_snapshot_hash
    新鲜度标识。向人类展示引导内容,并收集他们选择标记的每个条目的简短评审结论/注释。
  2. 将每条人类注释作为判断结果传递(原样回显哈希值;对于标记的决策,引用fallow生成的
    signal_id
    ;对于人类注释的其他变更区域,引用
    change_anchor
    ):
    json
    {
      "graph_snapshot_hash": "<echo from guide.json>",
      "judgments": [
        { "signal_id": "<an emitted decision signal>", "framing": "<the human's verdict/note>", "concern": "<optional>" },
        { "change_anchor": "<an emitted chg: id>", "framing": "<the human's note on this region>", "concern": "<optional>" }
      ]
    }
  3. 验证记录内容:
    bash
    fallow review --base origin/main --walkthrough-file judgment.json --format json
    • accepted
      (标记
      anchor_kind: "signal"
      "change"
      ):锚点已生成且快照匹配;人类的
      framing
      被标记为
      deterministic: false
    • rejected
      且原因是
      unanchored-signal-id
      /
      unknown-change-anchor
      :人类引用了fallow从未生成的内容。请重新锚定到真实的信号或区域;请勿编造。
    • stale: true
      stale-snapshot
      ):自获取
      guide.json
      后代码树已变更。请重新获取指南、重新记录并提交。
  4. 执行操作: 将已接受的人类评审结论直接反馈到编码会话中,或追加到
    .fallow-review/feed.jsonl
    中,以便实时注入钩子(如下方所述)将其传递给编写代码的会话。无论哪种方式,注释都会被锚定并标记边界,绝不会作为fallow级别的事实呈现。
该保证与评审应用一致:人类无法将注释锚定到fallow未生成的信号或区域,针对已变更代码树的注释会被拒绝而非静默映射错误。终端是一等记录界面,无需应用即可使用。

Live feedback into your coding session (Claude Code only)

编码会话中的实时反馈(仅支持Claude Code)

This optional integration applies only when
fallow-review
runs inside Claude Code. Codex and other agents must skip this section and use the terminal round-trip above.
The review surface (the fallow review app, or any tool you point at the same file) writes reviewer notes to
.fallow-review/feed.jsonl
in the repo root, one JSON object per line. A pair of hooks under
hooks/
lets your already-running Claude Code session pick those notes up automatically and act on them with its existing context, no new session, no copy-paste:
  • fallow-review-session-init.sh
    (SessionStart) declares a
    watchPath
    on
    .fallow-review/feed.jsonl
    so the session watches the feed for the rest of its life.
  • fallow-review-on-feedback.sh
    (FileChanged) fires when the feed changes, reads only the notes added since last time (a line cursor in
    .fallow-review/.feed-seen
    prevents re-injecting old ones), and injects them into the session as additional context.
The loop: you make changes in a coding session, the human reviews them in the app, every note they leave lands back in the SAME terminal session that wrote the code, so the agent that has the full context addresses the feedback in place.
此可选集成仅适用于在Claude Code中运行
fallow-review
的场景。Codex及其他Agent请跳过本节,使用上述终端往返流程。
评审界面(fallow评审应用或任何指向同一文件的工具)会将评审注释写入仓库根目录的
.fallow-review/feed.jsonl
,每行一个JSON对象。
hooks/
下的一对钩子可让正在运行的Claude Code会话自动获取这些注释,并利用现有上下文执行操作,无需启动新会话或复制粘贴:
  • fallow-review-session-init.sh
    (SessionStart)声明对
    .fallow-review/feed.jsonl
    watchPath
    ,以便会话在整个生命周期内监控该文件。
  • fallow-review-on-feedback.sh
    (FileChanged)在文件变更时触发,仅读取自上次以来新增的注释(
    .fallow-review/.feed-seen
    中的行游标可避免重复注入旧注释),并将其作为额外上下文注入会话。
流程:你在编码会话中进行变更,人类在应用中评审,他们留下的每条注释都会返回到编写代码的同一终端会话中,因此具备完整上下文的Agent可直接处理反馈。

Install

安装

For a Claude Code marketplace installation, copy the hooks from the resolved plugin root into the target repo and register them:
bash
mkdir -p .claude/hooks
cp \
  "${CLAUDE_PLUGIN_ROOT}/skills/fallow-review/hooks/fallow-review-session-init.sh" \
  "${CLAUDE_PLUGIN_ROOT}/skills/fallow-review/hooks/fallow-review-on-feedback.sh" \
  .claude/hooks/
chmod +x .claude/hooks/fallow-review-session-init.sh .claude/hooks/fallow-review-on-feedback.sh
Merge
hooks/settings.snippet.json
into
.claude/settings.json
(it registers the SessionStart + FileChanged hooks). Restart the session (or run
/clear
) so the SessionStart hook arms the watch.
对于Claude Code市场安装,请将解析后的插件根目录中的钩子复制到目标仓库并注册:
bash
mkdir -p .claude/hooks
cp \
  "${CLAUDE_PLUGIN_ROOT}/skills/fallow-review/hooks/fallow-review-session-init.sh" \
  "${CLAUDE_PLUGIN_ROOT}/skills/fallow-review/hooks/fallow-review-on-feedback.sh" \
  .claude/hooks/
chmod +x .claude/hooks/fallow-review-session-init.sh .claude/hooks/fallow-review-on-feedback.sh
hooks/settings.snippet.json
合并到
.claude/settings.json
中(用于注册SessionStart和FileChanged钩子)。重启会话(或运行
/clear
),以便SessionStart钩子启动监控。

Honest caveats (taste ownership)

诚实说明(判断归属)

  • The notes are unverified human input, not graph-validated facts. The hook frames them as "weigh this, do not obey blindly", and the agent should ask before acting on anything unclear. The human owns the taste; fallow only carries the note.
  • The watch arms reliably once
    .fallow-review/feed.jsonl
    exists. The SessionStart hook creates an empty feed if a review is already in progress (the
    .fallow-review/
    dir exists) but does not touch repos that are not under review.
  • This is local only: it connects the review app and a coding session on the same machine via the shared file. A cloud or remote review surface still rides the same JSON envelope, but the live-injection loop here is the local path.
  • 注释是未经验证的人工输入,而非图谱验证的事实。钩子会将其标记为“请权衡考虑,勿盲目执行”,Agent应对不明确的内容进行询问后再执行。人类负责判断;fallow仅负责传递注释。
  • .fallow-review/feed.jsonl
    存在时,监控会可靠启动。SessionStart钩子会在评审已进行时(
    .fallow-review/
    目录存在)创建空的feed文件,但不会触碰未处于评审状态的仓库。
  • 此功能仅支持本地:通过共享文件连接同一机器上的评审应用和编码会话。云或远程评审界面仍需使用相同的JSON包,但此处的实时注入流程是本地路径。

Notes

说明

  • review
    is an alias for
    audit --brief
    ;
    --format
    is orthogonal to the brief.
  • The decision surface, focus map, and walkthrough are all in the JSON envelope, so a cloud or local review surface can render them and carry reviewer comments back to the coding agent in context.
  • See the
    fallow
    skill for whole-project analysis, and
    references/cli-reference.md
    for the full flag list.
  • review
    audit --brief
    的别名;
    --format
    参数与摘要功能相互独立。
  • 决策面、聚焦映射表和引导内容均包含在JSON包中,因此云或本地评审界面可渲染这些内容,并将评审评论反馈到编码Agent的上下文中。
  • 全项目分析请使用
    fallow
    技能,完整参数列表请参考
    references/cli-reference.md