Add, revise, or remove source-code comments while preserving executable behavior. Use for comment-only cleanup, documentation comments, TODO quality, and reducing narration. Do not use when the requested change modifies logic.
日本語の概要は準備中です。原文の説明を表示しています。
実行スコア 未検証
インストール方法を見るインストールする前に、エージェントに与えられる指示の中身を確認できます。
Make comments carry information that the code cannot express clearly. In comment-only tasks, do not alter executable code, formatting beyond the comment, imports, configuration, or generated files.
Do not remove license headers, attribution, generated-file warnings, linter directives, migration notes, or operational instructions without proving they are obsolete.
Prefer one comment for the reason behind a coherent block over one comment per statement. Repeating the precise domain term is clearer than cycling through synonyms.
Preserve the repository's language, comment syntax, documentation format, and normal tone. Keep comments close to the behavior they constrain. When a comment is wrong but the code is in scope only for reading, correct the comment to describe current behavior; do not silently change the behavior to match it.
Review the diff and confirm that only comments changed. Run a narrow formatter or parser only when comment syntax can affect compilation, generated documentation, directives, or tooling. Report any ambiguous comment you preserved because its operational role could not be disproved.
まだレビューはありません。使ってみた感想をお寄せください。
ログインなしで書き込めます。使ってみた感想、質問、動かなかった環境などを気軽にどうぞ。
まだコメントはありません。最初のコメントを書いてみませんか。
Review or implement interface accessibility for semantics, keyboard operation, focus, contrast, status communication, zoom, and assistive technology. Use when accessibility is explicitly requested, required by the product contract, or a changed interaction creates substantial accessibility risk. Do not activate for every visual edit or use it as a generic design audit.
日本語の概要は準備中です。原文の説明を表示しています。
Implement, harden, or review defensive security controls for REST APIs, including authentication and authorization boundaries, validation, rate limiting, abuse prevention, resource limits, SSRF defenses, safe errors, logging, and security tests. Use when API security, endpoint hardening, threat review, rate limiting, token handling, or sensitive business-flow protection is an explicit concern. Do not use for ordinary endpoint logic without meaningful security scope or for offensive exploitation.
日本語の概要は準備中です。原文の説明を表示しています。
Design, implement, or assess project structure, module ownership, dependency boundaries, and safe file or folder organization. Use when project architecture, feature placement, separation of responsibilities, or architectural refactoring is a primary concern, including new framework projects. For a read-only assessment, do not modify files unless the user also requests changes; do not activate merely because ordinary feature work adds a file.
日本語の概要は準備中です。原文の説明を表示しています。
Review a code change, diff, commit, branch, or pull request for actionable defects, regressions, security risks, compatibility breaks, and missing verification. Use when code review is the primary requested outcome. Keep the review read-only unless the user explicitly asks to implement fixes; do not use as a substitute for implementation or a specialized visual audit.
日本語の概要は準備中です。原文の説明を表示しています。
Write or revise user-facing product and marketing copy with a specific voice, verifiable claims, natural rhythm, and useful actions. Use for interface labels, onboarding, landing pages, help text, and product messaging. Do not use for code comments or neutral technical documentation unless tone editing is requested.
日本語の概要は準備中です。原文の説明を表示しています。
Design, implement, review, or repair database schemas, queries, indexes, transactions, migrations, and backfills with explicit integrity and rollout constraints. Use when the datastore behavior or data lifecycle is a primary part of the task. Do not use for routine persistence calls whose schema and consistency contracts are unchanged.
日本語の概要は準備中です。原文の説明を表示しています。