SKILL·36BB4A

crit

tomasz-tomczyk
更新于 8 days ago
883
64
883
在 GitHub 上查看
开发general

关于

The `crit` skill provides inline code review for changes, plans, live web pages, or local HTML files, delivering structured feedback. It automatically detects review mode from arguments like files, directories, URLs, or GitHub PRs without requiring manual mode selection. Use it when you need human-like code review on diffs, running applications, or development work.

快速安装

Claude Code

推荐
主要方式
npx skills add tomasz-tomczyk/crit -a claude-code
插件命令备选方式
/plugin add https://github.com/tomasz-tomczyk/crit
Git 克隆备选方式
git clone https://github.com/tomasz-tomczyk/crit.git ~/.claude/skills/crit

在 Claude Code 中复制并粘贴此命令以安装该技能

技能文档

Review with Crit

Review and revise code changes, plans, live pages (running dev servers, staging URLs), or local HTML files using crit for inline comment review.

Step 1: Pass arguments to crit

The CLI auto-detects the review mode from its arguments. Do not ask the user which mode to use. Pass arguments through:

crit <arguments>               # file, dir, URL, .html — CLI auto-detects mode
crit --pr <num|url>            # GitHub PR (range mode)
crit --range <base>..<head>    # commit range (range mode)
crit                           # no args → branch diff

If no arguments, check conversation context:

  1. A plan file was written earlier in this conversation → crit <plan-file>
  2. Otherwise → bare crit (branch diff)
<important if="the user wants to open the review from another device — e.g. a phone over Tailscale"> Keep crit on loopback and reverse-proxy in. Same Step 1 args still apply (file, bare `crit`, etc.):
crit --public-url "https://<machine>.ts.net" --allow-unauthenticated-network --no-open [args…]
# then: tailscale serve --bg --https=443 http://127.0.0.1:<port>
  • --public-url only changes the URL crit prints — it does not expose the server.
  • --allow-unauthenticated-network is required with --public-url (even on loopback) and with any non-loopback --host. Crit has no auth: anyone who can reach the URL can read the repo and post comments that may trigger agents. Confirm the user wants that blast radius.
  • Do not bind --host to a Tailscale/LAN IP — proxy with tailscale serve (or an SSH tunnel). Get <port> from crit's startup output, or fix it with -p. Relay the URL crit prints (the public one), not localhost. </important>

Step 2: Launch crit and wait for review completion

CRITICAL — you MUST run this step. Do NOT skip it. Do NOT proceed without it.

Run crit and wait until it exits:

crit <plan-file>   # specific file
crit               # git mode

If a crit server is already running from earlier in this conversation, crit automatically connects to it. Starting from scratch, it spawns the daemon, opens the browser, and blocks until the user clicks "Finish Review".

crit prints the review URL on startup (e.g. Started crit daemon at http://localhost:<port>). Relay it verbatim:

"Crit is open at http://localhost:<port>. Leave inline comments, then click Finish Review."

Do NOT proceed until crit completes. Do NOT ask the user to type anything. Do NOT read the review file early. Wait for the command to finish — that is how you know the human is done reviewing.

While crit is still running, do not send user-facing progress updates. Treat the wait loop as internal state.

Step 3: Read the review output

When crit completes, read stdout and follow its instructions. Check stderr for approved: true or approved: false.

When a comment has quote, anchor, or drifted:

  • quote: the specific text the reviewer selected — focus your changes on the quoted text rather than the entire line range
  • anchor: use it to locate the current position of the content; line numbers may be stale after edits
  • drifted: true: original content was removed or heavily rewritten — line numbers are approximate at best

Fallback (mid-round re-entry, plan hooks, or headless workflows): crit comments / crit comments --json. Use crit comments --plan <slug> for plan-mode reviews.

Step 4: Address each review comment

For each unresolved comment:

  1. Understand what the comment asks for
  2. If it contains a suggestion block, apply that specific change
  3. Revise the referenced file (plan or code file from the diff)
  4. Reply with what you did: crit comment --reply-to <id> --author 'Codex' '<what you did>' (reply bodies support markdown)
  5. Do not pass --resolve. Resolving is the reviewer's call. Only add --resolve if the user explicitly asks.

Editing the plan file triggers Crit's live reload — the user sees changes in the browser immediately.

<important if="you are revising in plan mode"> Re-emit the revised plan inside `<proposed_plan>...</proposed_plan>` so Crit can review the new version. </important>

When replying to multiple comments

Use --json for a single bulk call instead of one invocation per comment:

echo '[
  {"reply_to": "c_a1b2c3", "body": "Fixed"},
  {"reply_to": "c_d4e5f6", "body": "Refactored as suggested"}
]' | crit comment --json --author 'Codex'

Step 5: Signal completion and start next round

CRITICAL — you MUST run this step. Do NOT skip it. Do NOT proceed without it.

The finish prompt on stdout includes the command to run again — use it to start a new round.

On subsequent calls, crit automatically signals round-complete first, then blocks until the next "Finish Review" click.

Tell the user: "Changes applied. Review the diff in your browser and click Finish Review when ready."

Do NOT proceed until the background crit task completes. When it does, return to Step 3. If the user finishes with zero comments, the review is approved — stop the loop and proceed.

Sharing

If the user asks for a URL, a shareable link, or to share the review:

crit share <file>

Always relay the full output to the user — copy the URL directly into your response. Don't make them dig through tool output.

To remove a shared review:

crit unpublish [file...]

QR codes

Only use --qr in real terminal environments with monospace rendering. Skip it in mobile apps or web chat UIs — Unicode block characters won't render.

crit share --qr <file>

GitHub 仓库

tomasz-tomczyk/crit
路径: integrations/codex/skills/crit
0
agentic-codingai-agentsai-toolsclicode-reviewdeveloper-tools
FAQ

常见问题

什么是 crit Skill?

crit 是一个 Claude Skill,作者为 tomasz-tomczyk。Skill 将 Claude 按需加载的说明和资源打包,让 Claude 无需额外提示即可执行与 crit 相关的任务。

如何安装 crit?

使用本页的安装命令:将 crit 作为插件添加到 Claude Code,或将其仓库克隆到 skills 目录,然后重启 Claude 以加载该 Skill。

crit 属于哪个分类?

crit 属于开发分类。

crit 可以免费使用吗?

可以。crit 已收录在 AIMCP,可免费安装。

相关推荐技能

qmd
开发

这是一个本地搜索和索引的CLI工具,支持BM25、向量搜索和重排序功能。开发者可以用它快速索引本地文件(如Markdown文档)并进行混合搜索,特别适合代码库或文档的本地检索。它还提供MCP模式,能轻松集成到Claude开发环境中使用。

查看技能
subagent-driven-development
开发

该Skill用于在当前会话中执行包含独立任务的实施计划,它会为每个任务分派一个全新的子代理并在任务间进行代码审查。这种"全新子代理+任务间审查"的模式既能保障代码质量,又能实现快速迭代。适合需要在当前会话中连续执行独立任务,并希望在每个任务后都有质量把关的开发场景。

查看技能
mcporter
开发

mcporter Skill 让开发者能在Claude中直接管理和调用MCP服务器。它支持列出可用服务器、调用工具、处理OAuth认证以及管理服务器守护进程。开发者可以通过命令行式交互快速执行`mcporter list`查看服务器,或使用`mcporter call`直接调用工具,简化了MCP工作流程。

查看技能
adk-deployment-specialist
开发

这是一个用于部署和编排Google Vertex AI ADK智能体的Claude Skill,专为构建生产级多智能体系统而设计。它支持通过A2A协议进行智能体通信,提供代码执行沙箱和记忆库功能,并能处理智能体发现与任务提交。当开发者需要部署ADK智能体或编排多智能体协作时,可使用此Skill来简化Vertex AI Agent Engine的部署流程。

查看技能