init-devin-review（初始化德文评论）

Init Devin Review

Generate Devin review configuration from repository evidence. REVIEW.md controls what Bug Catcher flags in diffs. AGENTS.md controls how Devin should behave while working in the repo. Default to the smallest configuration that meaningfully improves review quality.

Use this skill when

• setting up Devin Bug Catcher for a repository
• fixing noisy or weak REVIEW.md guidance
• deciding whether the repo needs only REVIEW.md or both REVIEW.md and AGENTS.md
• scoping review rules across packages or services in a monorepo

Core working rules

• Start with the repository, not the scenario library.
• Inspect existing instruction and context files before writing anything: matching **/REVIEW.md, **/AGENTS.md, **/CLAUDE.md, **/CONTRIBUTING.md, SECURITY.md, .cursorrules, .windsurfrules, agents/rules/**/*.md, .cursor/rules/**/*.mdc, .github/copilot-instructions.md, .coderabbit.yaml, .coderabbit.yml, greptile.json, CODE_OF_CONDUCT.md, .editorconfig, .github/CODEOWNERS, COMPLIANCE.md, and .devin/ config files.
• Account for scoped instruction files inside agent-style subdirectories such as .agents/, .devin/, .cursor/, or .github/ when checking for overlap. Also read LICENSE for licensing context (do not duplicate its content).
• Reuse the repo's real paths, libraries, commands, docs, and pain points. Never copy reference text verbatim.
• REVIEW.md can live at the root or in scoped subdirectories. AGENTS.md can also be scoped, but default to one root file and add scoped AGENTS.md only when package-specific execution rules truly diverge.
• Keep REVIEW.md focused on reviewable diff issues. Put coding workflow, architecture, and task-execution behavior in AGENTS.md only when needed.
• Prefer one strong root REVIEW.md over many weak files. Keep root rules cross-cutting and add scoped REVIEW.md files only where review concerns truly diverge.
• Do not encode formatter, linter, or CI rules unless Devin adds value beyond existing automation.

Required workflow

1. Scan the repo

Collect only the evidence needed to write grounded rules. Start by identifying the primary language and stack — this determines which artifacts, tools, and risk areas to look for.

Start by changing into the target repo root. If you are working from a shared fixture or sample repository, copy it to a scratch repo/worktree before writing REVIEW.md or AGENTS.md so the source fixture stays unchanged.

Language-detection routing:

How to scan:

find . -maxdepth 3 \( -name "REVIEW.md" -o -name "AGENTS.md" -o -name "CLAUDE.md" -o -name "CONTRIBUTING.md" -o -name ".cursorrules" -o -name ".windsurfrules" -o -name "*.rules" -o -name "*.mdc" -o -name ".coderabbit.yaml" -o -name ".coderabbit.yml" -o -name "greptile.json" \) | sort
find . -maxdepth 3 \( -name "*.md" -o -name "*.toml" -o -name "*.json" -o -name "*.yaml" \) | head -50
[ -f README.md ] && head -30 README.md
ls -la .github/ .cursor/ .windsurf/ .agents/ agents/ .devin/ 2>/dev/null
grep -r "lint\|format\|check" package.json Makefile pyproject.toml 2>/dev/null | head -20

• Read the dependency manifest first: package.json, go.mod, requirements.txt/pyproject.toml, Cargo.toml, pom.xml
• For monorepos (>5,000 files), limit deep scanning to top two directory levels plus any apps/, packages/, services/, cmd/, or internal/ subdirectories
• Check for CI configuration: .github/workflows/, .gitlab-ci.yml, Jenkinsfile, Makefile
• When root and scoped instruction files overlap, do not guess at undocumented precedence. Keep root files cross-cutting, make scoped files local, and remove contradictions instead of relying on overrides.

What to collect:

• structure: single-service repo or monorepo; top-level directories (apps/, packages/, services/, cmd/, internal/, src/)
• stack: primary language(s), frameworks, data/storage layer (ORM, direct DB, object storage, key-value stores), transport/runtime (HTTP framework, gRPC, message queues, CLI), test tooling (unit runner, integration, E2E, benchmarks)
• existing instructions: matching **/REVIEW.md, **/AGENTS.md, **/CLAUDE.md, **/CONTRIBUTING.md, SECURITY.md, .cursorrules, .windsurfrules, agents/rules/**/*.md, .cursor/rules/**/*.mdc, .github/copilot-instructions.md, .coderabbit.yaml, .coderabbit.yml, greptile.json, CODE_OF_CONDUCT.md, .editorconfig, .github/CODEOWNERS, COMPLIANCE.md, and .devin/ config files. Read LICENSE for licensing context — don't duplicate its content.
• contracts and docs: OpenAPI/Swagger specs, Prisma/Django/SQLAlchemy schema, go.mod, ADRs, architecture docs, security docs, design docs in docs/
• enforcement already present: the repo's existing linters, formatters, CI, or SAST tools (e.g. Semgrep, Bandit, gosec, CodeQL) — check actual config files rather than assuming which tools are used
• recurring risk areas: detect which apply by scanning for related code and config:

- grep -r "password\|secret\|token\|key\|credential" --include="*.env*" → secrets handling - find. -name "migrations" -o -name "migrate" → schema migration safety - grep -r "mutex\|lock\|sync\.\|goroutine\|thread" → concurrency patterns - grep -r "authorize\|permission\|role\|rbac\|pbac" → auth/permissions - Also check for: payment/billing modules, IPC/API boundaries, generated code, async task queues (Celery, BullMQ), distributed coordination (locks, consensus), data serialization boundaries - Systems-programming risks: goroutine/thread safety, race conditions, memory management (unsafe blocks, manual allocation), distributed coordination, file/network I/O error handling

2. Choose the file plan

Default to REVIEW.md only unless the request or repo evidence clearly calls for AGENTS.md.

When multiple rows match, choose the row that produces the least output. Start minimal — add scoped files later.

First deployment? Start with REVIEW.md only. Run 5 PRs. Audit findings. Then add AGENTS.md if needed.

3. Split concerns correctly

Rule of thumb: if the statement is about reviewing a diff, it belongs in REVIEW.md. If it is about how Devin or contributors should work, it belongs in AGENTS.md.

4. Draft from evidence

Before writing, find the closest scenario in references/scenarios.md and use it as your starting template. Adapt — don't copy.

If no scenario is a close fit, choose the nearest one by primary language/runtime and reuse only its section order and severity style. Drop stack-specific rules that do not match the repo instead of inventing new framework guidance from the template.

When writing REVIEW.md:

1. Put high-signal sections near the top. Preferred order: Critical Areas → Security → Conventions → Performance → Patterns → Ignore → Testing.
2. Reference real repo details in every important section: paths, middleware, libraries, commands, docs, or contracts.
3. Use severity intentionally:

- severe bug language: must never, always required, prohibited - important but not always severe: use X instead of Y, do not - lower-priority guidance: prefer, consider, watch for

1. Focus Good/Bad code examples on the top 2–3 highest-risk sections only — not every section needs them.
2. Add an Ignore section using glob patterns (e.g., *.generated.*, **/migrations/, *_test.go, **/__pycache__/, dist/, *.lock) so generated files, lockfiles, build output, snapshots, and similar noise do not consume review bandwidth.
3. Use the closest scenario from references/scenarios.md as structural inspiration for your stack, then rewrite every rule against actual repo evidence.

When writing AGENTS.md:

• prefer one root file; add scoped AGENTS.md only when package-level workflow, architecture, or dependency rules truly diverge
• keep root guidance cross-cutting and scoped guidance local to that subtree
• focus on architecture, workflow, dependencies, file organization, testing, and communication expectations
• do not restate bug-finding rules that already belong in REVIEW.md

Do this, not that

Validation checklist

Before returning any configuration, verify:

• the front-loaded sections match the repo's highest-risk areas
• rules are specific enough to test against a diff
• no obvious overlap with the repo's existing linters, formatters, CI, or SAST tools
• ignore patterns match actual generated and build files in the repo
• monorepo scoped files add new package-specific guidance instead of duplicating root rules
• AGENTS.md is only included when agent-behavior guidance is truly needed
• no contradictions across overlapping REVIEW.md, AGENTS.md, CLAUDE.md, CONTRIBUTING.md, or editor/review rule files
• REVIEW.md stays lean enough for Bug Catcher to focus

Output requirements

When asked to generate files, return:

1. a short file plan or tree
2. If filesystem access exists, write the files into the target repo first unless the user explicitly asked for draft-only output
3. each file as a complete markdown block
4. brief notes tying major sections to repository evidence
5. a simple verification path: submit a test PR to see Bug Catcher's response, or use devinreview.com to preview rule behavior, or run npx devin-review locally — see references/setup/getting-started.md for setup details and references/customization/rules-and-exclusions.md for tuning exclusions after the first run

Recovery loops

• Too much noise: shorten the file, add or expand Ignore, delete vague rules, and remove rules already enforced elsewhere. See references/customization/rules-and-exclusions.md and references/troubleshooting/common-issues.md.
• Missing real bugs: move critical rules higher, add path-specific critical areas, tighten phrasing, and add repo-accurate examples. See references/review-md/format-and-directives.md and references/troubleshooting/common-issues.md.
• Monorepo confusion: keep root rules cross-cutting; put only package-specific risks in scoped files; do not rely on precedence to resolve contradictions. See references/patterns/common-configurations.md and references/review-spec.md.
• REVIEW.md vs AGENTS.md overlap: move diff-catching rules back to REVIEW.md; keep coding workflow in AGENTS.md. See references/agents-md/configuration.md.
• Need a starting pattern for a known stack: use the closest scenario as inspiration, then rewrite it against the repo. references/scenarios.md covers TypeScript backends, Next.js sites and dashboards, Django APIs, Tauri apps, MCP servers, Python mcp-use, and monorepos.

Reference routing

Final reminder

The best Devin review config is not the longest one. It is the smallest repo-grounded set of instructions that makes Bug Catcher focus on the bugs your team actually cares about.