# Danger — Automate PR Review Rules in CI

> Danger runs scripted PR checks and posts review comments, turning team style rules into repeatable CI feedback instead of manual nitpicks.

## Install

Save the content below to `.claude/skills/` or append to your `CLAUDE.md`:

## Quick Use

1. Add Danger to an existing Ruby/Bundler repo (Gemfile):
   ```ruby
   gem 'danger'
   ```
   ```bash
   bundle install
   ```
2. Scaffold a `Dangerfile` (guided):
   ```bash
   bundle exec danger init
   ```
3. Run Danger in CI (requires a token, e.g. `DANGER_GITHUB_API_TOKEN`):
   ```bash
   bundle exec danger --verbose
   ```

## Intro

Danger runs scripted PR checks and posts review comments, turning team style rules into repeatable CI feedback instead of manual nitpicks.

- **Best for:** teams who want consistent PR hygiene (changelog, labels, links) enforced automatically
- **Works with:** GitHub/GitLab PR pipelines, Ruby + Bundler, a CI token (e.g. GitHub API token)
- **Setup time:** 20–40 minutes

## Practical Notes

- Quant: start with 1–3 rules and expand after a week of signal/noise review.
- Quant: use `--verbose` for the first 3 CI runs to diagnose token/PR context issues.

## Pattern: make PR policy explicit (and reviewable)

Treat your `Dangerfile` like any other engineering policy:
- keep the first sentence of each message actionable (what to change),
- link to the team standard (CONTRIBUTING / style guide),
- and version it with code review.

## Pattern: split “hard fail” vs “soft warn”

Start with warnings (comments) to build trust, then promote the most stable checks into strict merge gates.

## Troubleshooting checklist

- Confirm the CI job runs only on PRs/MRs.
- Confirm the correct token env var exists in that job.
- Run `bundle exec danger --verbose` locally (in a PR checkout) to reproduce.

### FAQ

**Q: Is Danger free?**
A: Yes. It’s open-source under the MIT license; you host and run it in your own CI.

**Q: Do I need Ruby in my repo?**
A: Typically yes. Most teams run Danger via Bundler so versions are pinned per repo.

**Q: How do I keep it from being noisy?**
A: Start with a few high-signal checks, and distinguish warnings from failures.

## Source & Thanks

> Source: https://github.com/danger/danger
> License: MIT
> GitHub stars: 5,666 · forks: 488

---

<!-- ZH -->

## 快速使用

1. 在现有 Ruby/Bundler 项目里加入 Danger（Gemfile）：
   ```ruby
   gem 'danger'
   ```
   ```bash
   bundle install
   ```
2. 生成 `Dangerfile`（带向导）：
   ```bash
   bundle exec danger init
   ```
3. 在 CI 里执行（需要 Token，例如 `DANGER_GITHUB_API_TOKEN`）：
   ```bash
   bundle exec danger --verbose
   ```

## 简介

Danger 会在 CI 中运行自定义规则，读取 PR/MR 元数据并自动发评论或 Checks，把团队规范固化为可重复的机器审查；还能把问题直接反馈到评审流程里，在不拖慢节奏的前提下减少人工挑刺与漏检。

- **适合谁：** 希望把 PR 卫生规则（变更记录、标签、链接等）自动化落地的团队
- **可搭配：** GitHub/GitLab 的 PR 流水线、Ruby + Bundler、CI Token（例如 GitHub API token）
- **准备时间：** 20–40 分钟

## 实战建议

- 量化建议：先从 1–3 条规则开始，一周后再扩展，控制噪音。
- 量化建议：前 3 次 CI 运行加 `--verbose`，快速定位 Token/PR 上下文问题。

## 常用打法：把 PR 规则写成可评审的“政策文件”

把 `Dangerfile` 当成工程规范的一部分：
- 每条提示第一句就说清“改什么”，
- 需要时附上团队标准（CONTRIBUTING / style guide），
- 通过正常 code review 迭代。

## 常用打法：区分“硬失败”与“软提醒”

先用 warning（评论）建立信任，再把最稳定的规则升级成严格的合并门禁。

## 排障清单

- 确认 job 只在 PR/MR 上下文运行。
- 确认 Token 环境变量在该 job 可见。
- 在 PR checkout 环境本地跑 `bundle exec danger --verbose` 复现。

### FAQ

**Danger 是免费的吗？**
答：是的。它是 MIT 开源项目，你在自己的 CI 环境里运行。

**必须用 Ruby 吗？**
答：大多数场景需要。团队通常用 Bundler 把版本固定在仓库里。

**怎么避免刷屏？**
答：先做少量高信号规则，并区分 warning 与 failure。

## 来源与感谢

> Source: https://github.com/danger/danger
> License: MIT
> GitHub stars: 5,666 · forks: 488


---
Source: https://tokrepo.com/en/workflows/danger-automate-pr-review-rules-in-ci
Author: Script Depot