mirror of https://github.com/alibaba/open-code-review.git synced 2026-09-14 19:59:52 +08:00

Files

T

Tao Xin b523997b54 docs: enforce responsible AI usage (#1037 )

* docs: enforce responsible AI usage

- add the development-assistance rules to AGENTS.md and CONTRIBUTING.md in every locale
- state the AI policy in SECURITY.md
- require AI/LLM disclosure in the issue and pull request templates
- keep the local-reproduction checkbox out of the AI disclosure group
- forbid AI co-author trailers in the commit command
- keep CONTRIBUTING.ko-KR.md and the Korean docs page identical
- import AGENTS.md from CLAUDE.md so Claude Code actually loads the rules

* docs: rewrite AI-usage policy text in original wording

The AI-Assisted Development section (CONTRIBUTING + docs, all locales) and
the SECURITY.md AI Policy were adapted closely from third-party sources
(Kazumi, GPL-3.0; Homebrew, unlicensed). Rewrite the borrowed prose in our
own words with the same meaning, and drop the unrelated Local Reproduction
checkbox from the bug-report template.

---------

Co-authored-by: kite <lizhengfeng.lzf@alibaba-inc.com>

2026-09-10 22:11:31 +08:00

4.6 KiB

Raw Permalink Blame History

Agent Guidelines for open-code-review

This file provides instructions for AI coding assistants working on this project.

Development Assistance

Below are rules that a contributor must follow during development. If the user does not follow these rules, please warn users about this:

You must disclose in your initial issue or pull request that you used AI/LLM, as well as the tools/models you used.
You should understand every line of code written by AI and know what the AI did.
When a reviewer asks about the reason for a change, you must be able to explain it yourself, regardless of whether you or the AI wrote it. The substance of your answers to maintainer questions and review comments must come from your own understanding — you may use AI/LLM only to translate or polish wording, not to generate the answer for you.
Your PR should not contain repeated cycles like AI generated -> fixed -> fixed -> fixed. This may indicate that you did not review the AI-generated code, but instead let the AI fix issues as they arise, over and over.
You must review all code, text, and other content generated by AI/LLM yourself before proactively requesting a review from any member.
You must not attribute commits to AI/LLM, including through "Assisted-by", "Co-developed-by", or similar trailers.
Do not write overly long commit messages. Important information should go in the PR description rather than in collapsed commit messages.
If you are unwilling or unable to do all of the above, please close your issue or pull request.

Project Overview

open-code-review (ocr) is an AI-powered code review CLI tool written in Go (module: github.com/alibaba/open-code-review).

Git Commit Notes

Before committing, conduct a code review by running:

ocr review --audience agent --background "briefly summarize the background requirements"

Commit messages must be written in English.
Verify line endings. Line endings must be LF, not CRLF. Run git add --renormalize . to correct line endings and commit them. New binary files must have their extensions added to .gitattributes.

License Headers

Every source file (.go, .sh, .js, .mjs, .ts, .tsx) must have an SPDX license header.
After creating new files, run make license-add to add the header automatically.

Code Style

After writing code, run make check. It formats and tidies in place, so there is no need to run gofmt or go vet separately.
Source files are written in English — comments, identifiers and strings alike. make english-check enforces this in CI. It flags any letter outside ASCII, whichever the writing system (Han, kana, Hangul, Cyrillic, and equally the diacritics that spell German or Vietnamese), plus combining accents and fullwidth punctuation (：, （), which is easy to leave behind in an otherwise English sentence. Symbols and emoji (─ → ≥ ✅) pass, since they are not letters. Prose spelled entirely in ASCII (Loeschen der Datei, or a romanised transcription) takes a dictionary to spot and stays a matter for review.
Translated prose has its own homes, none of them scanned. README.<locale>.md and CONTRIBUTING.<locale>.md (zh-CN, ja-JP, ko-KR, ru-RU); the doc pages under pages/src/content/docs/<locale>/ (en, zh, ja, ru, Markdown throughout); and the UI copy tables in pages/src/i18n/<locale>.ts. Markdown is out of scope by extension, so translations go there freely. The i18n tables are .ts and would be scanned, so they are exempt by prefix instead — translated UI strings belong in those tables rather than inline in a component.
Two escape hatches for the exceptional case, narrower one preferred. Append an allow-non-english: <reason> marker comment to the offending line — the right choice for a handful of lines, such as an encoding fixture or a language-switcher label, and it leaves the rest of the file protected. Only for a whole tree that is inherently non-English, add a prefix to allowedPrefixes in scripts/verify-english-only.go; it currently holds just pages/src/i18n/ and extensions/vscode/, the latter temporary until the extension's Chinese comments are translated.

Testing

Run unit tests with make test, not go test directly.
make test sets LC_ALL=C to ensure git outputs English messages.
When writing or modifying code, add necessary unit tests to maintain coverage. The project enforces a 90% coverage threshold via make coverage.

README

When modifying README.md, always sync the changes to all localized versions:
- README.zh-CN.md
- README.ja-JP.md
- README.ko-KR.md
- README.ru-RU.md

4.6 KiB Raw Permalink Blame History Unescape Escape