# Bootstrap friendlyReviewer Configuration Files

You will generate 3 friendlyReviewer configuration files:
`.friendlyreviewer/ignore-reviewer.md`, `.friendlyreviewer/ignore.md`, `.friendlyreviewer/helper.md`.

**Your role:** orchestrate — spawn 3 sub-agents via the Agent tool (in parallel), each responsible for researching its own domain and generating one file. You collect the outputs, review them, and write them.

No central inventory phase. Each sub-agent researches what it needs.

---

## Spawn 3 Sub-Agents

Spawn **3 sub-agents in parallel**, each with its own prompt containing:
- The goal of the file it must generate
- Its own research instructions
- Its own generation rules
- The instruction to **return only the complete file content**, nothing else

### Sub-agent A — `.friendlyreviewer/ignore-reviewer.md`

**Goal:** Produce a list of bot usernames that friendlyReviewer should skip. Each non-comment line = one exact username.

**Research:**
- Run `git log --format="%an <%ae>" -500 | sort -u` to list commit authors
- Find CI config files: `.github/dependabot.yml`, `renovate.json`, `.github/renovate.json`, `.gitlab/renovate.json`, `.github/workflows/*.yml`
- Find CODEOWNERS: `.github/CODEOWNERS`, `CODEOWNERS`, `docs/CODEOWNERS`
- Identify accounts that look like bots (name containing `[bot]`, `bot`, commit patterns like `chore(deps)`, `Merge branch`, `Update dependency`)
- Identify regular human accounts (frequency, variety of commit messages)

**Format:**
```markdown
# Users skipped by friendlyReviewer
# Format: one username per line, case-insensitive
# Lines starting with # are comments

# Dependency bots
dependabot[bot]
renovate[bot]
renovate

# CI/automation bots
pre-commit-ci[bot]
gitlab-bot
```

**Rules:**
- Put the most certain bots first, uncertain ones at the bottom prefixed with `# ` (commented out as TODOs)
- If a name contains `[bot]`, keep it as-is (that's exactly how GitHub presents it)
- For uncertain users, prefix the line with `# ` so the user can decide
- **Return the complete file content** as your output, nothing else.

### Sub-agent B — `.friendlyreviewer/ignore.md`

**Goal:** Produce a list of file patterns that friendlyReviewer should skip during review. Gitignore-style format (`pathspec` patterns, one per line).

**Research:**
- List file extensions: `find . -not -path './.git/*' -type f | sed -n 's/.*\.\([^.]*\)$/.\1/p' | sort | uniq -c | sort -rn`
- List top-level directories: `ls -d */`
- Read `.gitignore` (if it exists)
- Read `.dockerignore` (if it exists)
- Identify build output directories (e.g. `dist/`, `build/`, `.next/`, `target/`, `_build/`)
- Identify lock files, cache dirs, generated files, IDE/OS artifacts present in the repo

**Priority order:**
1. **Lock files** — if present, always ignore them (often huge, never relevant in review)
   ```
   package-lock.json
   yarn.lock
   pnpm-lock.yaml
   poetry.lock
   Gemfile.lock
   Cargo.lock
   go.sum
   ```
2. **Build/generated directories** — identify build output directories
3. **Minified/generated files** — `*.min.js`, `*.generated.*`, `*.pb.go`, `*_pb2.py`, `*_pb2.pyi`
4. **IDE/editor directories** — if tracked (check they aren't already in `.gitignore`)
5. **OS files** — `.DS_Store`, `Thumbs.db`
6. **Cache files** — `.eslintcache`, `.ruff_cache/`, `.mypy_cache/`, `__pycache__/`

**Format:**
```markdown
# Files ignored by friendlyReviewer
# gitignore format: one pattern per line, # lines are comments
# Inline comments (# after the pattern) are supported

# Lock files
package-lock.json
yarn.lock
Gemfile.lock

# Build output
dist/
build/
.next/

# Cache and temp files
__pycache__/
*.pyc
.eslintcache
```

**Rules:**
- For each pattern, verify it actually matches files in the repo (don't generate orphan patterns)
- Add a comment explaining why
- **Return the complete file content** as your output, nothing else.

### Sub-agent C — `.friendlyreviewer/helper.md`

**Goal:** Produce a markdown file with **rules for the AI to follow during review**. This file will be injected into every AI review prompt.

**Research:**
- **Start by understanding the application at a high level:** Read `README.md`, entry-point files (`main.py`, `index.js`, `cmd/`, `app/`), and any architecture docs to distill what the app does — purpose, main features, target users
- Read `CLAUDE.md`, `AGENTS.md`, `CONTRIBUTING.md` / `CONTRIBUTING.adoc` if they exist
- Look for ADRs: `docs/adr/`, `docs/architecture/`, `decisions/`, `docs/decisions/`
- Look for PR/MR templates: `.github/PULL_REQUEST_TEMPLATE/`, `.gitlab/merge_request_templates/`
- Look for commit rules: `commitlint.config.js`, `.commitlintrc*`, `.gitmessage`
- Examine directory structure to infer the project's architecture
- Look for makefiles, taskfiles, or build scripts: `Makefile`, `Taskfile.yml`, `Justfile`, `package.json` (scripts)

**Types of relevant rules** (no formatting/style rules — that's what linters/formatters are for):

1. **Architectural rules** inferred from structure or docs:
   - "This project follows hexagonal architecture: adapters must not import use cases directly"
   - "Layer dependencies flow: domain → application → infrastructure"

2. **Testing rules** found in docs/README:
   - "Unit tests are mandatory for every new function"
   - "Bug fixes must include a regression test"
   - "Integration tests go in `tests/integration/`"

3. **Project-specific patterns**:
   - "Business exceptions must extend `DomainError`"
   - "Every API endpoint must validate its inputs"

4. **Best practices dictated by config or architecture**:
   - "Secrets must never be committed"
   - "SQL queries must use the query builder, not raw SQL"

5. **Rules extracted from AGENTS.md, CLAUDE.md, or CONTRIBUTING.md**:
   - If these files exist, summarize them into actionable review rules

**Format:**
```markdown
# Team Rules for Review

## Overview
[10-line functional description of the application — purpose, main features, target users.
Extracted from README, entry-point files, and architecture docs.
This gives the reviewer the context needed to assess the impact of any change.]

## Architecture
- [rules]

## Testing
- [rules]

## Best Practices
- [rules]
```

**Rules:**
- Keep rules actionable by an AI during review (avoid overly vague rules)
- Only include what you can actually infer from the project's docs and structure
- **Return the complete file content** as your output, nothing else.

---

## Assembly

You now have the output of all 3 sub-agents. Before writing the files, do a quick quality check:

- [ ] Are the patterns in `.friendlyreviewer/ignore.md` appropriate? (Don't accidentally ignore important source files)
- [ ] Are the users in `.friendlyreviewer/ignore-reviewer.md` actually bots?
- [ ] Are the rules in `.friendlyreviewer/helper.md` actionable by an AI during review? (Avoid overly vague rules)
- [ ] Are there any clearly irrelevant files (large generated files, lock files) not already covered in `.friendlyreviewer/ignore.md`?

If any file fails a check, fix it directly. Then write the 3 files to the repository root.