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: REVIEW.md, AGENTS.md, CLAUDE.md, CONTRIBUTING.md, SECURITY.md, .cursorrules, .windsurfrules, agents/rules/*.md, .cursor/rules/*.mdc, .github/copilot-instructions.md, CODE_OF_CONDUCT.md, .editorconfig, .github/CODEOWNERS, COMPLIANCE.md, .devin/ config files. 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 should stay root-only.
• 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. 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.

Language-detection routing:

How to scan:

find . -maxdepth 3 -name "*.md" -o -name "*.toml" -o -name "*.json" -o -name "*.yaml" | head -50
cat README.md | head -30
ls -la .github/ .cursor/ .windsurf/ 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

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: REVIEW.md, AGENTS.md, CLAUDE.md, CONTRIBUTING.md, SECURITY.md, .cursorrules, .windsurfrules, agents/rules/*.md, .cursor/rules/*.mdc, .github/copilot-instructions.md, CODE_OF_CONDUCT.md, .editorconfig, .github/CODEOWNERS, COMPLIANCE.md, .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.

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
4. Focus Good/Bad code examples on the top 2–3 highest-risk sections only — not every section needs them.
5. 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.
6. 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:

• keep it root-scoped
• 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 with AGENTS.md, CLAUDE.md, CONTRIBUTING.md, or editor rule files — check each existing file for conflicts
• 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. each file as a complete markdown block
3. brief notes tying major sections to repository evidence
4. 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. See references/patterns/common-configurations.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.