Force Multiplier

Bulk change is hard because dozens of edits must be provably correct, consistent, and reversible — this skill compiles any intent into a structured, safe fan-out rather than a catalogue of canned changes. Discovery patterns live in references/finding-targets.md; worked campaigns live in examples/ — read the closest for shape, then generalize.

Core concept: the campaign

A single fan-out is a campaign. The skill never freestyles across the fleet. It compiles the user's generic prompt into a structured campaign spec, echoes it back for confirmation, then executes it deterministically.

A campaign = intent + target selector + recipe + validation + PR spec + safety policy. See references/campaign-spec.md for the field-by-field schema.

The pipeline — always execute in this order

1. SELECT — enumerate candidate targets across the Bitwarden ecosystem, then apply an applicability filter so only targets where the change is actually relevant survive (the signal the change keys on is present). Patterns for both are in references/finding-targets.md. Present the exact resolved list.
2. CHECK YOURSELF (reality-check #1 — before anything is touched) — see the section below. This gate stands between SELECT and PILOT and is the most important step in the skill.
3. PILOT (reality-check #2 — prove on ONE) — run the recipe on one representative target and surface the full diff. Read every line. Validate it (build/lint/test as the target defines). "Here is exactly what I will do, ×N." If the pilot diverges from intent or fails validation, STOP — do not fan out. Mandatory for agentic recipes — --no-pilot is refused for them (with an explanation), never silently honored, because a non-deterministic change fanned out without review is exactly the failure the pilot exists to catch. For deterministic recipes whose diff is fully reviewable the pilot is default-on and --no-pilot may downgrade it, noted in the report.
4. FAN-OUT — apply to each confirmed target in isolation: fresh branch (deterministic name) cut from the target's default branch, apply recipe, run the per-target second pass, compare the target's diff shape against the pilot and flag divergence, secrets-scan the staged diff, then commit and open a draft PR following the conventions confirmed at pilot. One target failing never aborts the rest.
5. REPORT (reality-check #3 — reconcile, don't declare victory) — aggregate target → status (applied / already-compliant / skipped-not-applicable / held-back / failed) → PR URL → notes. Reconcile the arithmetic: selected = applied + already-compliant + skipped-not-applicable + held-back + failed, with nothing silently dropped. Only applied targets have a PR; an already-compliant no-op has none; a held-back target is a reference-check decision pending (see the destructive-recipe reference-check), not a failure.
6. REMEDIATE — re-run on the failed/skipped subset. Campaigns are idempotent, so re-running a succeeded target is a no-op.