---
name: branch-tree-view
description: >-
  Tree of every file changed on the branch, with +/− line counts. Same shape GitHub shows on a PR.
---

# Branch Tree View

Show all files changed in the current branch as a folder tree with `+added` / `-removed` line counts.

## Steps

1. Fetch the latest `origin/main` and diff against it (this matches what GitHub shows):

```bash
git fetch origin main --quiet
git diff --numstat origin/main...HEAD | sort -k3
```

2. Parse each line (`added  removed  filepath`) and build a folder tree.

3. Render as a fenced code block using box-drawing characters:

```
.
├── src/
│   ├── components/
│   │   └── Button.tsx          +25 -10
│   └── utils/
│       └── helpers.ts           +8  -3
└── package.json                 +1  -0
```

## Formatting Rules

- Right-align the `+N` / `-N` columns for readability.
- Collapse intermediate directories that contain no direct file changes into a single line (e.g. `src/utils/` instead of nesting `src/` then `utils/`).
- If a directory has many snapshot or auto-generated files with similar diffs, summarize them on one line: `__snapshots__/cloud-agent/  (24 files)  ~+170 ~-210`.
- Use `+0` or `-0` rather than omitting a zero side.
- Compare against `origin/main` (not local `main`) to match what GitHub would show in a PR.

---
name: scoped-agent
description: >-
  Before any agent touches the repo: a brief, a blast radius, and a definition of done. Ambiguity here is what costs the afternoon later.
---

# Scoped Agent

When the user hands you a non-trivial coding task, do not start editing until the scope is written down.

## Before you touch files

1. Restate the goal in one sentence: outcome, not implementation.
2. List the files or directories you may touch.
3. Name what is off limits (auth, billing, migrations, public API names, unless explicitly requested).
4. State how you will know you are done (build, test that fails when reverted, readable diff).

Wait for confirmation if any of those are unclear. A question costs thirty seconds; a confident wrong assumption costs an afternoon.

## While working

- Match patterns already in the files you edit. No new dependencies without asking.
- One concern per change. Do not "clean up while you're in there."
- Prefer a small blast radius over a clever wide refactor.

## When handing back

- Summarize what changed and what you deliberately did not touch.
- Call out anything you are unsure about. Do not bury it.

---
name: adversarial-review
description: >-
  Review a diff like it will break in production. Compliments are useless; concrete failure scenarios are not.
---

# Adversarial Review

When asked to review a diff (the user's or an agent's), do not say it looks good.

Argue that it breaks in production. Specifically:

1. What input makes this throw, hang, or silently return the wrong value?
2. What happens under concurrency: two of these running at once?
3. What was forgotten: cleanup, connections, timers, listeners, locks, migrations?
4. Which error path is unhandled or swallowed?

For each finding: the concrete scenario, not the category. Rank by blast radius.
If something is genuinely fine, say nothing about it.

Plausible code always builds. Your job is the quiet wrongness that would ship.