MCP HubMCP Hub
SKILL·1F496D

crit-cli

tomasz-tomczyk
更新日 27 days ago
3 閲覧
979
74
979
GitHubで表示
メタautomation

について

crit-cliスキルは、マルチエージェントワークフロー向けのコードレビューコメントのプログラムによる作成と管理を可能にし、GitHub PRとの同期やレビューファイルの処理を含みます。自動化されたレビュープロセスのために、crit comment、share、pull、pushなどのCLI操作を提供します。インタラクティブなレビューセッションには別途`crit`スキルが必要なため、スクリプト化されたレビューアクションにご利用ください。

クイックインストール

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-cli

このコマンドをClaude Codeにコピー&ペーストしてスキルをインストールします

ドキュメント

Crit CLI Reference

If a plan was just written and the user said "crit" or "review", use the $crit skill instead — it covers the full review loop. This skill covers CLI operations like crit comment, crit pull/push, and crit share.

Comments have three scopes:

  • Line comments (scope: "line") — tied to specific lines, stored in files.<path>.comments
  • File comments (scope: "file") — about a file overall, stored in files.<path>.comments with start_line: 0
  • Review comments (scope: "review") — general feedback, stored in the top-level review_comments array

The review file path is shown by crit status.

Reading comments

When crit completes a review round, read stdout and follow its instructions. Unresolved comments are often embedded in that prompt as JSON. Check stderr for approved: true or approved: false.

When you need to read comments separately:

crit comments            # human-readable, unresolved only (default)
crit comments --json     # flat JSON for agents
crit comments --all      # include resolved comments
crit comments --plan <slug>   # plan reviews
crit comments [path]     # explicit review.json or .crit directory

Review-level comments are listed first — easy to miss in raw review.json. Uses the same review resolution as crit comment (--output, --plan, daemon session).

Multiple active sessions

When more than one review session matches the current directory and branch, crit comment refuses to guess. Run crit status (or crit status --json) to list every active session, then target the intended review explicitly:

crit comment --session <id> --author <name> <path>:<line> <body>
crit comment --session <id> --json --file comments.json --author <name>

The JSON status output exposes the candidates in sessions.

Review file format

{
  "review_comments": [
    {
      "id": "r_f1e2d3",
      "body": "Overall the architecture looks good",
      "scope": "review",
      "author": "User Name",
      "resolved": false,
      "replies": [
        { "id": "rp_b4a5c6", "body": "Thanks, addressed the minor issues", "author": "Codex" }
      ]
    }
  ],
  "files": {
    "path/to/file.go": {
      "comments": [
        {
          "id": "c_a1b2c3",
          "start_line": 5,
          "end_line": 10,
          "body": "Comment text",
          "quote": "the specific words selected",
          "anchor": "The sessions table needs a complete rewrite...",
          "author": "User Name",
          "resolved": false,
          "replies": [
            { "id": "rp_c7d8e9", "body": "Fixed by extracting to helper", "author": "Codex" }
          ]
        }
      ]
    }
  }
}

Field rules:

  • resolved: false or missing — both mean unresolved. Only true means resolved.
  • quote (optional): the specific text the reviewer selected — narrows scope within the line range. Focus changes on the quoted text rather than the entire range.
  • anchor (line comments): full text of the commented lines when placed. When edits shift line numbers, locate content by anchor rather than trusting start_line/end_line.
  • drifted: true: original content was removed or heavily rewritten — line numbers are approximate at best.
  • Unresolved comments may have replies — read them before acting.

Authoring comments

# Review-level (general feedback)
crit comment --author 'Codex' '<body>'

# File-level (whole file, no line numbers)
crit comment --author 'Codex' <path> '<body>'

# Line (single line or range)
crit comment --author 'Codex' <path>:<line> '<body>'
crit comment --author 'Codex' <path>:<start>-<end> '<body>'

# Reply to an existing comment
crit comment --reply-to <id> --author 'Codex' '<body>'

Hard rules:

  • Always pass --author 'Codex' so comments are attributed correctly.
  • Always single-quote the body — double quotes break on backticks and shell metachars.
  • Line numbers reference the file on disk (1-indexed), not diff line numbers.
  • Reply bodies support markdown — use code fences and inline code where helpful.
  • Only pass --resolve when the user explicitly asks. Never resolve proactively. Same rule applies to the resolve field in --json mode.

Bulk commenting (3+ comments)

Use --json for atomicity (single write, no partial state) and speed (one process). The JSON can come from stdin or --file <path>:

# stdin — fine for short, single-line bodies:
echo '[
  {"body": "overall feedback", "scope": "review"},
  {"path": "session.go", "body": "restructure", "scope": "file"},
  {"file": "src/auth.go", "line": 42, "body": "Missing null check"},
  {"file": "src/auth.go", "line": "50-55", "body": "Extract to helper"},
  {"reply_to": "c_a1b2c3", "body": "Fixed — added null check"},
  {"reply_to": "r_f1e2d3", "body": "Done"}
]' | crit comment --json --author 'Codex'

For multi-paragraph bodies, prefer --file. A literal newline inside a "body" string breaks JSON parsing, and shell-quoted heredocs make this easy to introduce by accident. Write the JSON to a temp file (use your file-edit tool), then:

crit comment --json --file /tmp/crit-bulk.json --author 'Codex'

--file - is an explicit "read stdin" if you ever need it.

Per-entry schema:

FieldTypeRequiredNotes
file / pathstringline/file commentsRelative path. path alone (no line) → file-level.
lineint/stringline comments42 or "45-47"
end_lineintoptionalDefaults to line
bodystringalways
authorstringoptionalPer-entry override; falls back to --author
scopestringoptional"review" / "file" — usually inferred
reply_tostringrepliesComment ID (c_… or r_…)
resolvebooloptionalOnly when user explicitly asks

Scope inference (when scope omitted): has reply_to → reply; no file/path and no line → review-level; path but no line → file-level; file/path + line → line.

Multi-file disambiguation

Comment IDs are unique per session, but the same ID can collide across files. If crit comment errors with "comment found in multiple files", disambiguate with --path:

crit comment --reply-to c_a1b2c3 --path src/auth.go --author 'Codex' 'Fixed the null check'

In --json mode, set the file field on the entry. Review-level IDs (r_…) are globally unique and never need this.

Plan-mode comments

Plan reviews (via crit plan or the ExitPlanMode hook) store the review file in ~/.crit/plans/<slug>/. Always pass --plan <slug> — without it, crit comment looks in the project root and won't find the comments. The slug is shown in the review feedback prompt.

crit comment --plan my-plan-2026-03-23 --reply-to c_a1b2c3 --author 'Codex' 'Updated the plan'

GitHub PR Integration

crit pull [pr-number]                                    # Fetch PR review comments into the review file
crit push [--dry-run] [--event <type>] [-m <msg>] [pr]   # Post review comments as a GitHub PR review

Requires gh CLI installed and authenticated. PR number is auto-detected from the current branch.

--event values: comment (default), approve, request-changes. -m adds a review-level body message.

Sharing

crit share <file> [file...]                          # Upload and print URL
crit share --qr <file>                               # Also print QR code (terminal only)
crit share --org <slug> <file>                       # Share under an organization
crit share --org <slug> --visibility unlisted <file> # Org share with explicit visibility
crit unpublish [file...]                              # Remove shared review
  • Always relay the output — copy the URL (and QR if used) into your response. Don't make the user dig through tool output.
  • --qr is terminal-only — skip in mobile apps, web chat UIs, or anywhere Unicode block characters won't render correctly.
  • --org <slug> shares under an organization. Visibility defaults to organization (members only). Override with --visibility (organization, unlisted, public).
  • If a review file exists, comments for the shared files are included automatically.
  • Unpublish uses the persisted delete token in the review file — no extra args needed.

GitHub リポジトリ

tomasz-tomczyk/crit
パス: integrations/codex/plugin/crit/skills/crit-cli
0
agentic-codingai-agentsai-toolsclicode-reviewdeveloper-tools
FAQ

よくある質問

crit-cli Skillとは何ですか?

crit-cli はtomasz-tomczyk が作成した Claude Skillです。Skillは、Claudeが必要に応じて読み込む指示とリソースをまとめ、追加の指示なしで crit-cli に関連するタスクを実行できるようにします。

crit-cli をインストールするには?

このページのインストールコマンドを使用してください。crit-cli をプラグインとして Claude Code に追加するか、リポジトリを skills ディレクトリにクローンし、Claudeを再起動してSkillを読み込みます。

crit-cli はどのカテゴリに属しますか?

crit-cli は メタ カテゴリに属します。

crit-cli は無料で利用できますか?

はい。crit-cli は AIMCP に掲載されており、無料でインストールできます。

関連スキル

content-collections
メタ

このスキルは、Content Collections(Markdown/MDXファイルを型安全なデータコレクションに変換するTypeScriptファーストのツール)の本番環境でテストされた設定を提供します。Zodバリデーションによる型安全性を実現し、ブログ、ドキュメントサイト、コンテンツ重視のVite + Reactアプリケーション構築時にご利用ください。Viteプラグインの設定、MDXコンパイルから、デプロイ最適化、スキーマバリデーションまで、すべてを網羅しています。

スキルを見る
polymarket
メタ

このスキルは、開発者がPolymarket予測市場プラットフォームを活用したアプリケーション構築を可能にします。API統合による取引や市場データの取得に加え、WebSocketを介したリアルタイムデータストリーミングにより、ライブ取引や市場活動を監視できます。取引戦略の実装や、ライブ市場更新を処理するツールの作成にご利用ください。

スキルを見る
creating-opencode-plugins
メタ

このスキルは、開発者がコマンド、ファイル、LSP操作など25種類以上のイベントタイプにフックするOpenCodeプラグインを作成することを支援します。JavaScript/TypeScriptモジュール向けに、プラグイン構造、イベントAPI仕様、および実装パターンを提供します。カスタムイベント駆動ロジックでOpenCode AIアシスタントのライフサイクルをインターセプト、監視、または拡張する必要がある場合にご利用ください。

スキルを見る
sglang
メタ

SGLangは、高性能なLLMサービングフレームワークであり、RadixAttentionプレフィックスキャッシュを活用したJSON、正規表現、エージェントワークフロー向けの高速で構造化された生成を特長とします。特にプレフィックスが繰り返されるタスクにおいて、大幅に高速な推論を実現し、複雑な構造化出力やマルチターン対話に最適です。制約付きデコードが必要な場合や、広範なプレフィックス共有を伴うアプリケーションを構築する場合は、vLLMなどの代替案ではなくSGLangを選択してください。

スキルを見る