/civitai-plan-review

name: civitai-plan-review
description: Plan-first review for Civitai work (civitai/civitai, apps/*, the orchestrator, Creator Studio, HQ-facing features), run BEFORE building, not after. Every Civitai plan gets two sections written by the author, "Existing systems" (what in the codebase, past PRs, tasks and services already does part of this, with file:line and the searches run) and "How it ships" (one finished change in one PR unless a named release constraint forces phases). Larger or riskier plans then get fresh Opus critics, reuse first, until every lane gives a thumbs up, then one ask to your user. Use when you write a plan, design doc or build brief for a Civitai feature, migration, backfill, generator/orchestrator change, payment or moderation flow, or a new app or service.

Civitai plan review: find what exists, then build

Most reuse and scope checking happens after the code exists, in `civitai-review` and the hosted `pr-review`, where a "no" means a rewrite. This skill asks those questions of the plan, where a "no" costs a paragraph. The after-the-fact reviews still run; this adds a step in front of them.

Hub seats and everyone else

Some steps name tools that exist only on the agent hub (`who_worked_on`, `store_find`, `hq_task`, cards). Each has a fallback, so the skill works from any Claude Code session:

| Step | On a hub seat | Otherwise | |---|---|---| | Ask your user (a decision, the tier-2 sign-off) | One card to your user (`ask_templates` first) | Ask your user however your setup does | | Past seats' work on this concept | `who_worked_on query:"<concept>"` | Ask your user who has worked on it | | Standing rules | `store_find collection:ruling` (project civitai) | Ask your user for any standing rules | | Tasks, including closed and wontfix | `hq_task list` or the `hq` CLI | The `hq` CLI if you have it; else your team's tracker | | File a follow-up or a removal task | `hq_task` / `task` | Your team's tracker, with a closing condition (`docs/dev/filing-follow-ups.md`) |

"Ask your user" below always means this row.

Tiers

| Tier | When | What runs | Rough cost | |---|---|---|---| | **0: Existing systems + How it ships** | Every Civitai plan or build brief, no exceptions | Author writes both sections below. No critics. | ~10 min of the author | | **1: Reuse check** | The plan adds a new service, table, tRPC router, component family, app, cron/job, cache, endpoint or skill | Tier 0 + lane R (reuse) | ~$3 | | **2: Full** | Any trigger in the list below | Tier 0 + lanes R, 1, 2, 3, 4, and 5 when anything turns on | ~$20-35 |

Tier 2 triggers:

• migration, schema change, or backfill over prod rows
• money, Buzz, payouts, payments, membership
• auth, sessions, permissions, API keys, tokens
• moderation, content safety, NSFW or minors gating, scanning
• the generation or orchestrator pipeline (generators, workflows, providers, coverage)
• a feature flag or anything on by default for users
• a new app under `apps/`, or a new service that other teams will call
• a user-facing flow on the feed path or the home page
• your user or a lead asked for a review

Not sure between tiers? Run the higher one. A one-file bug fix with a known cause needs only tier 0, and its two sections can be three lines.

Tier 0, part 1: "Existing systems" (author, always)

Put this section in the plan, ABOVE the design. Write it before you design anything.

For each moving part of the plan (each new function, table, page, job, endpoint, flag, script):

| Part | What already does some of it (file:line, task, PR, service) | Search that found it | Extend or new, and why | |---|---|---|---| | e.g. "list a user's images" | `getMyImages` in `src/server/services/image.service.ts` | grep of the export list | Extend: add a filter |

Where to look, in this order (record each search you ran, including the ones that found nothing): 1. **Feature docs**: `docs/features/README.md` and the feature doc for this area. 2. **Architecture map**: `.claude/rules/server.md`, `.claude/rules/components.md`, `.claude/rules/database.md`. 3. **The reuse map**: the "Where the existing thing usually lives" section of `.claude/agents/civitai-reuse-review.md` (big services, selectors, schema, caches, tRPC ladder, server utils, components, hooks, constants). Read the whole export list of any service you would add to: `grep -nE "^export (async function|function|const) " src/server/services/<x>.service.ts`. 4. **Search by shape, not by name**: the table, the column, the URL shape, the Mantine component. The duplicate is never named like the new code. 5. **Packages and sibling apps**: `packages/civitai-*`, `apps/*` (Svelte apps have their own conventions, `docs/svelte-app-standard.md`). 6. **History**: was it built, tried or rejected before?

• `gh pr list -R civitai/civitai --state all --search "<concept>" --limit 20`
• `git log --oneline -S "<symbol>" -- <path>` for removed code
• tasks for the concept, including closed and wontfix ones (table above)
• earlier seats' work and standing rules (table above)

7. **Other services**: the orchestrator's issues if you can read them, existing skills in `.claude/skills/` and `~/.claude/skills/`, the moderator app. 8. **Data that already exists**: is the number or field you plan to compute already stored, cached or in ClickHouse? Read replica / ClickHouse only, with a `# why:` line.

A part with "new" in the last column needs a reason that names the existing thing and why it does not fit (wrong shape, wrong owner, deprecated, too slow, measured). "Didn't find anything" is only acceptable with the searches listed next to it.

Tier 0, part 2: "How it ships" (author, always)

Every plan says how the change ships. **The default is one finished change in one PR.** Phases, feature-flag stages and back-compat shims are allowed only for a named release constraint:

• old clients in the wild that still call the old shape;
• migration ordering: a migration or