# Ai Diff Reviewer Setup

> Interactive installer for the AI Diff Reviewer GitHub Action — walks the developer through 6 key decisions (provider, strictness, trigger mode, external-contributor policy, PR description mode, complexity labels), detects the repo's stack for sensible defaults, and writes a working `.github/workflows/pr-review.yml` tailored to those choices. Also acts as the reference manual for every `action.yml…

- **Type:** Skill
- **Install:** `agentstack add skill-dailybothq-agent-skill-setup`
- **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior
- **Seller:** [DailybotHQ](https://agentstack.voostack.com/s/dailybothq)
- **Installs:** 0
- **Category:** [Developer Tools](https://agentstack.voostack.com/c/developer-tools)
- **Latest version:** 0.1.0
- **License:** MIT
- **Upstream author:** [DailybotHQ](https://github.com/DailybotHQ)
- **Source:** https://github.com/DailybotHQ/agent-skill/tree/main/.agents/skills/ai-diff-reviewer/setup

## Install

```sh
agentstack add skill-dailybothq-agent-skill-setup
```

Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent.

## About

# AI Diff Reviewer — Setup Wizard (sub-skill)

Companion to the [`ai-diff-reviewer`](../SKILL.md) skill. Where the parent
**runs** the review and [`generate-extension`](../generate-extension/SKILL.md)
**tailors the prompt**, this sub-skill **bootstraps the GitHub Action
itself** — walks the developer through the ~6 key decisions and writes
a working `.github/workflows/pr-review.yml` tailored to those choices.

Also doubles as the **reference manual** for every `action.yml` input:
if a developer asks any coding agent *"what does `strictness` do?"* or
*"how do I run only when a label is added?"*, the agent can read
[`reference.md`](reference.md) in this directory and answer without
opening the source.

---

## When it fires

Explicit triggers (recommended):

- "Set up AI Diff Reviewer for this repo"
- "Configure the reviewer action"
- "Install the AI Diff Reviewer GitHub Action"
- "Help me create the pr-review workflow"
- "How do I add AI Diff Reviewer to this project?"

The parent [`ai-diff-reviewer`](../SKILL.md) skill may also route here
automatically when a review-flow request activates on a repo that
clearly has no `.github/workflows/pr-review.yml` (opt-in — future
enhancement; not the default today).

---

## Step 0 — Trust boundary

This skill **writes** exactly two categories of files, both with
explicit developer consent:

- **`.github/workflows/pr-review.yml`** — the tailored workflow after
  all six questions are answered. If a file already exists at that
  path, the skill ASKS before overwriting (offers to write to
  `pr-review-new.yml` alongside for review).
- **`.review/extension.md`** — only if the developer says **yes** to
  the optional Step 5 handoff, which invokes the
  [`generate-extension`](../generate-extension/SKILL.md) sub-skill.

It **does not**:

- Commit anything, push anything, or open a PR — the developer stages
  and commits themselves.
- Touch GitHub Secrets — they're set once by the developer in the
  repo's Settings UI (link surfaced in Step 4).
- Modify existing unrelated workflows in `.github/workflows/`.
- Call the LLM provider directly or send data off the machine.

---

## Step 1 — Discovery (light — target ≤ 6 tool calls)

Gather just enough to pick sensible defaults; don't do a full
`generate-extension`-style Discovery.

### 1a. Repo identity

```bash
# Slug (owner/repo)
git remote get-url origin | sed -E 's|.*[:/](.+/.+)\.git$|\1|'

# Public or private? (gh required; skip cleanly if absent)
gh repo view --json isPrivate,visibility 2>/dev/null
```

### 1b. Existing workflows

```bash
ls .github/workflows/*.yml 2>/dev/null
test -f .github/workflows/pr-review.yml && echo "EXISTS"
```

If `pr-review.yml` (or a similarly-named workflow) already exists,
tell the developer and offer three paths:

1. **Overwrite** — replace the existing file (require them to confirm
   `yes overwrite`, not just `yes`).
2. **Side-by-side** — write to `.github/workflows/pr-review-new.yml`
   so they can diff and merge manually.
3. **Cancel** — abort the setup entirely.

### 1c. Stack detection (defaults hint)

```bash
# Presence of any of these tells you the primary language / ecosystem.
ls package.json pnpm-lock.yaml yarn.lock 2>/dev/null   # Node
ls pyproject.toml requirements*.txt Pipfile 2>/dev/null # Python
ls go.mod 2>/dev/null                                   # Go
ls Cargo.toml 2>/dev/null                               # Rust
ls Gemfile 2>/dev/null                                  # Ruby
ls pom.xml build.gradle 2>/dev/null                     # Java/Kotlin
```

The stack shapes only one suggestion downstream: whether the CLI
providers make sense (`claude-code` / `cursor` / `codex` all need
Node 20 to install, which is fine on `ubuntu-latest` regardless of
your project's language, but the workflow's `timeout-minutes` may
want to be higher for larger diffs).

### 1d. Default branch

```bash
gh repo view --json defaultBranchRef -q .defaultBranchRef.name 2>/dev/null || echo "main"
```

Used to fill `on.pull_request.branches: []` in the composed
workflow.

---

## Step 2 — The six questions

Ask them **one at a time**, showing the default marked as
**(recommended)** in the response so the developer can just say "go
with defaults" and get the safest workflow in ~30 seconds. Use the
Discovery data to pre-fill anything you can (e.g. `default_branch`,
`visibility`).

### Q1 — Provider

> **Which LLM provider should run the review?**
>
> - **`anthropic`** (recommended for first setup) — Zero install
>   overhead, uses `ANTHROPIC_API_KEY`. The action calls the
>   chat-completions API directly. Best default unless you already
>   have a specific reason to want a CLI provider.
> - **`claude-code`** — Runs the Claude Code CLI headlessly. Same
>   Anthropic models, but accepts a subscription OAuth token
>   (`sk-ant-oat…`) via `api-key`, so you can bill against a Claude
>   Pro / Max plan instead of API usage.
> - **`cursor`** — Runs the Cursor Agent CLI headlessly. Default
>   model `auto` is unlimited on Cursor Pro plans. Best if the team
>   already lives inside Cursor.
> - **`codex`** — Runs the OpenAI Codex CLI headlessly (GPT models).
>   Best if the team already has OpenAI billing.

Record: `PROVIDER`. Also record the corresponding secret name for
Step 4: `ANTHROPIC_API_KEY` / `CLAUDE_CODE_TOKEN` (or
`ANTHROPIC_API_KEY`) / `CURSOR_API_KEY` / `OPENAI_API_KEY`.

### Q2 — Strictness

> **When should the GitHub check fail?**
>
> - **`lenient`** (recommended for weeks 1–2) — The check never
>   fails; every review posts, no PR is ever blocked. Use this to
>   calibrate the prompt and the extension against your codebase
>   without breaking anyone's merge flow.
> - **`block-on-critical`** (recommended for steady-state) —
>   Fails only if the reviewer marks any comment as `critical`
>   (security, data loss, breaking API). Warnings and info-level
>   comments still post but don't gate merges.
> - **`block-on-warning`** — Fails on `warning` OR `critical`.
>   Aggressive; only recommended when the extension has been tuned
>   to keep false positives near zero.
> - **`block-on-any`** — Fails on ANY inline comment, including
>   `info`. Zero-tolerance mode for security-critical or regulated
>   stacks.

Record: `STRICTNESS`.

### Q3 — Trigger mode

> **When should the reviewer run?**
>
> - **on every push to the PR** (recommended for most teams) — Uses
>   `types: [opened, synchronize]`. Reviews the diff on the first
>   open and again every time new commits are pushed. Predictable
>   feedback loop for the author.
> - **only when a `ready` label is applied** — Uses
>   `trigger-mode: label-once` + `label-gate: ready`. Keeps WIP PRs
>   quiet; costs run only when the author explicitly signals
>   readiness. Toggle the label off/on to re-run. Best for cost
>   discipline in large repos.
> - **only on `labeled` events** — Uses `trigger-mode:
>   label-added-only` and subscribes to `types: [labeled]`. Even
>   more conservative; the workflow doesn't run on `synchronize`
>   at all, so new commits after the label was applied don't
>   trigger new reviews (only re-labeling does).

Record: `TRIGGER`, plus `LABEL_GATE` (empty or `ready`) and the
workflow event types.

### Q4 — External contributors

> **Who should be allowed to trigger the review?**
> (Applies mostly to public open-source repos — private repos can
> skip the gate.)
>
> - **`OWNER,MEMBER,COLLABORATOR`** (recommended for public repos) —
>   Only writes-tier authors trigger the review. Blocks external
>   contributors from opening PRs to burn your API budget.
> - **`OWNER,MEMBER,COLLABORATOR,CONTRIBUTOR`** — Also allows
>   returning contributors (people whose PRs you've merged before).
>   Good middle ground once you have a stable contributor pool.
> - **empty string `''`** — Review every PR from anyone.
>   Recommended for private repos; risky on public ones.

Skip this question if `visibility == "PRIVATE"` (default to empty).

Record: `AUTHOR_ASSOC`.

### Q5 — PR description mode

> **Should the reviewer also check that PR descriptions are meaningful?**
>
> - **`off`** (recommended if you don't have PR-body standards yet) —
>   Ignore the description entirely.
> - **`warn`** — Flag "missing/vague description" in the review
>   summary (doesn't affect the strictness gate).
> - **`block`** — Force the check to fail if the description is
>   missing/vague, regardless of `strictness`. Cheap way to enforce
>   PR hygiene.
> - **`autocomplete`** — The reviewer AI writes a first-draft body
>   for you. Guarded by a marker so it never overwrites your edits.
>   Best UX for solo maintainers.

Record: `PR_DESC_MODE`. If the developer picks anything other than
`off`, ask a follow-up: "Minimum character count?" (default `50`).

### Q6 — Complexity labels

> **Should the reviewer apply complexity labels (`complexity:low` /
> `complexity:medium` / `complexity:high`) to PRs?**
>
> - **no** (recommended for first setup) — Skip this feature until
>   you have a use case for it.
> - **yes** — The reviewer assesses cognitive load / files touched /
>   security surface / coverage delta and applies a label. Useful for
>   triage boards, code-owner routing, or PR-size KPIs. Adds a small
>   amount of latency + one more label the team has to reason about.

Record: `COMPLEXITY_LABELS`.

---

## Step 3 — Compose and write the workflow

Assemble the YAML from the recorded answers. Template below (variables
in `` come from Step 2's answers; the header comment is
generated so the developer knows which options this file reflects).

```yaml
# AI Diff Reviewer — generated by the setup skill.
# Source: https://github.com/DailybotHQ/ai-diff-reviewer
#
# What's configured here:
#   - Provider: 
#   - Strictness: 
#   - Trigger:   ()
#   - External contributors: 
#   - PR description mode: 
#   - Complexity labels: 
#
# Regenerate: run the ai-diff-reviewer-setup skill again.

name: PR review
on:
  pull_request:
    branches: []
    types: []     # e.g. [opened, synchronize]

concurrency:
  group: pr-review-${{ github.event.pull_request.number }}
  cancel-in-progress: true

jobs:
  review:
    runs-on: ubuntu-latest
    timeout-minutes: 15
    permissions:
      contents: read
      pull-requests: write
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0        # required — the action runs `git diff origin/...HEAD`

      - uses: DailybotHQ/ai-diff-reviewer@v2
        with:
          provider: 
          api-key: ${{ secrets. }}
          github-token: ${{ secrets.GITHUB_TOKEN }}
          strictness: 

          # Only include the lines below when they differ from action defaults.
          >
          >
          '>
          >
          >
          
```

**Rules for the composition:**

1. **Omit every input that matches its action default.** The result
   should read like a hand-written minimal workflow, not a giant
   config dump. Explicit inputs only for the choices that differ.
2. **Never emit a placeholder secret value.** Use
   `${{ secrets. }}` — the developer wires it in Step 4.
3. **Header comment reflects reality.** If the trigger is
   label-added-only, the comment must say so and the event types
   must match — don't ship a mismatch.
4. **`applied-label` and `collapse-previous`** are not asked (they
   default to sensible values); the composed workflow inherits both
   defaults silently.
5. **`prompt-extension-file`** is not asked in the wizard — it's set
   later, either by the developer or by Step 5's handoff to
   `generate-extension`.

Write the file:

```bash
mkdir -p .github/workflows
# Write the composed YAML to .github/workflows/pr-review.yml (or
# pr-review-new.yml if the developer picked "side-by-side" in Step 1b)
# via the harness's file-write tool.
```

---

## Step 4 — Post-setup instructions

After the file is written, tell the developer the exact next steps.
**Include the repo-specific URL** — makes the friction go away.

```markdown
Workflow written to `.github/workflows/pr-review.yml`. Next steps:

1. **Add the API secret.**
   Go to: https://github.com///settings/secrets/actions/new
   Name: ``
   Value: your API key from 

2. **Commit + test.**
   ```bash
   git checkout -b chore/setup-ai-diff-reviewer
   git add .github/workflows/pr-review.yml
   git commit -m "chore: add AI Diff Reviewer GitHub Action"
   git push -u origin chore/setup-ai-diff-reviewer
   ```
   Open a draft PR. The reviewer will run on the first push, post its
   findings, and (given your `` choice) either gate the
   check or just comment.

3. **Only if you picked `label-gate: ready`** (Q3, second option):
   also create the label on the repo before merging the workflow.
   ```bash
   gh label create ready --color 0e8a16 --description "Signals PR is ready for AI review"
   ```

4. **Defaults you already have (no extra config needed).**
   Iteration-Aware Review runs on every CI review with
   `convergence-policy: first-pass-exhaustive` — exhaustive first
   pass, then dedup on later rounds so the same warnings don't
   trickle forever. To force a full un-deduped pass once, label
   the PR `full-review-please` (the shipped
   `iteration-escape-label`). Optional emergency bypass for
   hotfixes: add `skip-review-label: skip-ai-review` to the
   workflow and protect that label with a ruleset — see
   `examples/skip-review-label.yml` and
   `docs/ITERATION_AWARENESS.md` / `docs/TRIGGER_MODES.md` in the
   action repo.
```

Provider-console URLs to substitute in the instructions:

| Provider | Console URL for API key |
|---|---|
| `anthropic` | https://console.anthropic.com/settings/keys |
| `claude-code` | https://console.anthropic.com/settings/keys OR `claude setup-token` for subscription-mode |
| `cursor` | https://cursor.com/dashboard → Settings → API Keys |
| `codex` | https://platform.openai.com/api-keys |

---

## Step 5 — Optional handoff: bootstrap the extension file

After the workflow is written, ask ONE more question:

> **Want to also tailor the review to this repo?**
>
> The workflow uses the shipped default prompt right now — great for
> general-purpose review, but it doesn't know YOUR conventions
> (money-handling in ``, banned patterns, etc.).
>
> I can bootstrap a `.review/extension.md` for this repo now
> (~30 seconds of Discovery + a ~100-line file). The workflow will
> auto-detect it if you also add
> `prompt-extension-file: .review/extension.md` to the `with:` block,
> and the local review skill picks it up too.
>
> - **yes** — invoke `generate-extension` now.
> - **no** — skip; the shipped default is fine. Run
>   `generate-extension` any time later.

Handle:

- **yes** → invoke [`generate-extension`](../generate-extension/SKILL.md)
  in extension mode. After it writes `.review/extension.md`, update the
  freshly-composed workflow file to add
  `prompt-extension-file: .review/extension.md` (a two-line
  in-place edit). Announce both files at the end.
- **no** → stop after Step 4. Tell the developer they can bootstrap
  the extension later ("say 'generate a `.review/extension.md`' any
  time — one command, zero re-config").

---

## Reference — all action inputs

The full input table with description, default, and per-scenario
recommendations lives in [`reference.md`](reference.md) in this
directory. Read it directly when the developer asks a specific
question about any input the wizard didn't cover
(`mcp-config-file`, `max-turns`, `agent-extra-args`, etc.).

Any coding agent with this skill installed can answer
*"what does `` do?"* by consulting `reference.md` alone — no
need to open `action.yml`.

---

## Notes

- **The wizard is the happy path; `reference.md` is the escape hatch.**
  If the developer wants to hand-craft a workflow with knobs the
  wizard doesn't ask about (`mcp-config-file`, `max-turns`, model
  pinning, etc.), point them at `reference.md` and let them compose
  themselves.
- **Re-running the wizard is safe.** If a `.github/workflows/pr-review.yml`
  already exists, the skill offers overwrite

…

## Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

- **Author:** [DailybotHQ](https://github.com/DailybotHQ)
- **Source:** [DailybotHQ/agent-skill](https://github.com/DailybotHQ/agent-skill)
- **License:** MIT

Install and usage instructions live in the source repository linked above.

## Pricing

- **Free** — Free

## Security capabilities

Automated source analysis of v0.1.0 — what this tool can access:

- **Network access:** no
- **Filesystem access:** no
- **Shell / process execution:** no
- **Environment & secrets:** no
- **Dynamic code execution:** no

*"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.*


## Versions

- **0.1.0** — security scan: passed — Imported from the upstream source.

## Links

- Listing page: https://agentstack.voostack.com/l/skill-dailybothq-agent-skill-setup
- Seller: https://agentstack.voostack.com/s/dailybothq
- Browse the marketplace: https://agentstack.voostack.com/browse

---
Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.