Campaign planning

Campaign Planning

Purpose

Large efforts fail in characteristic ways: the riskiest part is discovered last, half-done states poison the codebase, parallel workers collide on shared state, and a delegated slice comes back as something else entirely. This skill is the orchestration discipline — slice by risk, verify per slice, keep every checkpoint working, parallelize only true independence, delegate with contracts, and plan the retreat before the advance.

Metadata

• Prerequisites: the design being executed should already exist (system-design for systems, refactoring-playbook step 6 for migrations); change-control governs every individual slice's diff.
• Related Skills: system-design (produces the delivery plan this skill executes), refactoring-playbook (strangler-fig migrations are campaigns), code-review-playbook (reviewing delegated output), research-methodology (digest-form reporting for delegation), engineering-minimalism (the when-NOT gate below).
• Owns: work decomposition and slicing; delegation contracts; checkpoint discipline; parallelization rules; failure-recovery planning for multi-step work.

When to Use / When NOT to Use

Use when:

• A task will span many files, sessions, days, or workers (human or agent).
• Planning a migration, rollout, or any effort with a dangerous middle state.
• Dispatching subagents/teammates on slices of one larger goal.
• A big effort has stalled and needs restructuring to finish or retreat.

Do NOT use (load the sibling instead):

• The task fits in one sitting with one verification → just do it; a plan document for a two-hour task is process theater (engineering-minimalism).
• The DESIGN doesn't exist yet → system-design first; you cannot slice what isn't shaped.
• The campaign is a code restructuring → refactoring-playbook owns the behavior-preservation strategy; this skill orchestrates its slices.
• A single slice is failing → debugging-playbook for the failure; return here for whether the campaign continues.

Definitions & Mental Model

• Slice: a unit of campaign work with its own done-criteria and verification, sized so one worker completes it in one focused stretch, and shaped so the system still works when it lands.
• Checkpoint: the state after a slice lands — always green (builds, tests pass, system runs). Campaigns move checkpoint to checkpoint, never through mud.
• Risk-first ordering: the slice most likely to invalidate the plan ships first — it is the cheapest place to learn you're wrong.
• Delegation contract: the written agreement handed with a slice — inputs, expected output shape, verification the delegate must run, and blocked-behavior instructions.
• Retreat plan: the pre-decided answer to "how do we get back to a good state if this stalls at 60%?"

Mental model: a campaign is a sequence of releasable states, not a pile of tasks. The naive decomposition ("first all the models, then all the handlers, then all the tests") produces slices that are categories — nothing works until everything does. The professional decomposition produces slices that are increments — after each one, the system is whole, verified, and better. Two consequences follow: risk goes first (an increment that disproves the plan on day one saves the month), and the middle states are safe by construction (any checkpoint is a place you can stop, ship, or retreat from). Delegation adds the third law: a slice handed off without a contract comes back as a surprise.

Core Methodology

1. Run the when-NOT gate. Estimate honestly: one worker, one sitting, one verification? Then skip the ceremony and do it. Campaign machinery is for work that cannot be held in one head at one time.
2. Slice by risk and increment, not by layer or file (decision tree):

How to cut the work?
├─ FIRST SLICE = the assumption that could invalidate everything:
│    the unproven integration, the performance question, the
│    "does the API even allow this?" — build the thinnest end-to-end
│    path through it. If it fails, the campaign redesigns cheaply.
├─ EACH SUBSEQUENT SLICE = one increment that leaves the system
│    working: a vertical path, a migrated consumer, a replaced module
│    behind a stable seam — never "all the Xs".
├─ A slice needing >1 focused stretch → split it.
├─ A slice that can't be verified alone → merge it with what
│    verifies it, or reshape the boundary (contracts-as-seams:
│    architecture-analysis).
└─ Work nobody asked for appearing in a slice → cut it
     (engineering-minimalism).

3. Write per-slice done-criteria and verification BEFORE starting. Each slice gets one line each: done means (observable state) and verified by (the command/check that proves it). A slice without a verification line is not plannable — it is hope with a name. (Verification craft: validation-and-testing.)
4. Order by dependency, explicitly. For each slice: what must already be true when it starts? Draw the arrows (a list is fine; a graph if it branches). Two rules: no slice starts on an unverified predecessor, and shared-state slices are ordered, never parallel (step 6).
5. Enforce checkpoint discipline. A slice lands only when its verification passes AND the whole system is green. If a slice cannot land green, its boundary is wrong — reshape it (feature flags and seams exist for exactly this: configuration-management, architecture-analysis). The campaign's invariant: at every checkpoint, stopping forever is acceptable. That is what makes stalls survivable and priorities changeable.
6. Parallelize only true independence. Two slices may run in parallel only if: no shared files/state, no dependency arrow between them, and separate verifications. Everything else is sequential — the coordination cost of "careful" parallel work on shared state exceeds the time saved, every time. For agent swarms this is absolute: agents cannot negotiate over an edit conflict; the orchestrator must never create one.
7. Delegate with a contract. Every handed-off slice carries, in writing:
   • Context: the minimum background the delegate needs (not the whole campaign — context is a budget).
   • Inputs: files, facts, constraints — including what is read-only.
   • Expected output: the shape of what comes back (a diff, a file, a report in digest form — research-methodology step 7).
   • Verification to run: the exact check the delegate executes before reporting done.
   • Blocked behavior: "if you cannot proceed, STOP and report the blocker with what you tried — do not improvise around it." Improvisation around a blocker is how one bad slice becomes three. On return: review the output against the contract (code-review-playbook for code), and run the verification yourself before integrating — trust the work, verify the claim.
8. Plan the retreat before the advance. Before slice 1: what is the rollback unit (revert a commit? a branch? a flag flip?), and what happens to completed slices if the campaign is abandoned at each checkpoint? Because of step 5's invariant, the answer should always be "keep them — they stand alone." If a slice's failure would poison siblings (shared migration state, half-renamed concepts), redesign the slicing until it wouldn't.
9. Track status in one visible place. One list: slice → state (pending / in-progress / verified / blocked) → owner. Updated at every checkpoint. The campaign's single source of truth prevents the classic multi-worker failure: two owners, or zero, for the same slice.
10. On slice failure, contain then decide. A failed slice stops itself, not the campaign: siblings at their checkpoints are safe by construction. Diagnose (debugging-playbook); then choose explicitly — retry with what was learned, reshape the slice, or retreat per step 8. What is never acceptable: pushing forward on top of an unverified failure.

Campaign checklist

• When-NOT gate passed: this genuinely exceeds one sitting/head
• Slice 1 attacks the plan-invalidating risk, end to end
• Every slice: one-line done-criteria + one-line verification, written before start
• Dependency order explicit; no slice starts on an unverified predecessor
• Every checkpoint leaves the whole system green and stop-forever-acceptable
• Parallel slices share nothing — no files, no state, no dependency arrow
• Every delegation carries: context, inputs, output shape, verification, blocked-behavior
• Delegated output verified by the orchestrator before integration
• Retreat plan written before slice 1; per-checkpoint abandonment answered
• One visible status list, updated at checkpoints

Discovery & Audit Commands

This domain is judgment-driven; the applicable commands audit campaign hygiene in a repository:

# Is a stalled campaign already in flight? (half-done states, abandoned branches)
git branch -a | head -20
git log --oneline -20                        # look for "WIP", "part 1/", stalled sequences
git stash list                               # forgotten half-states

# Checkpoint health: is the system green right now?
git status --short                           # clean tree = a real checkpoint
pytest tests/ -x 2>/dev/null || npm test     # the repo's verification, whatever it is

# Blast-radius map before slicing (what does the change touch?)
grep -rln "the_concept_being_changed" --include="*.py" --include="*.ts" . | grep -v node_modules | wc -l

# Shared-state collision check before parallelizing two slices
# (run per slice; overlapping file lists = sequential, not parallel)
git log --oneline -5 --name-only -- path/to/slice-A-area | sort -u

Failure Modes & Anti-patterns

Symptom	Mistake	Correction
Month of work, fatal flaw found in week four	Riskiest slice scheduled last	Risk-first: the plan-invalidating assumption is slice 1 (step 2)
Nothing runs until everything is done	Sliced by layer/category, not increment	Vertical increments; every checkpoint whole and green (steps 2, 5)
Campaign stalls; codebase stuck half-migrated	No checkpoint invariant, no retreat plan	Stop-forever-acceptable checkpoints; retreat written before slice 1 (steps 5, 8)
Two agents edit the same file; both slices lost	Parallelized shared state	True-independence test; shared anything = sequential (step 6)
Delegated slice returns the wrong thing entirely	No contract — a vibe was delegated	Context + inputs + output shape + verification + blocked-behavior (step 7)
Delegate "worked around" a blocker into new breakage	Blocked-behavior unspecified	"Stop and report" is part of every contract (step 7)
Orchestrator integrates unverified delegate claims	Trusted "done" without running the check	Run the slice's verification yourself before integration (step 7)
Failed slice, campaign pushes on regardless	No contain-then-decide discipline	Stop the slice, diagnose, explicitly retry/reshape/retreat (step 10)
Nobody knows what's left or who owns what	Status scattered across chats and heads	One visible slice list, updated at checkpoints (step 9)
Planning document longer than the work	Campaign machinery on a one-sitting task	The when-NOT gate; just do small things (step 1)

Worked Example

Task: migrate a service's persistence from JSON files to SQLite — ~30 call sites, must stay shippable throughout.

1. Gate: many files, multiple sessions, a dangerous middle — a campaign.
2. Risk-first slice 1: the plan-invalidating question is concurrent-write behavior under SQLite with the service's access pattern. Slice 1 builds the thinnest path: one storage seam interface, an SQLite implementation of it, and a two-writer stress check. Done: both backends pass the same seam tests. Verified by: the seam's test file. (Had SQLite failed here, the campaign would have pivoted in a day, not a month.)
3. Slices 2–5: migrate consumers seam-ward one vertical group at a time (readers; writers; the exporter; the CLI) — each slice: switch that group to the seam, tests green, JSON still the backing store. Every checkpoint ships.
4. Slice 6: flip the backing store behind a config flag (configuration-management), dual-write for one release, verify parity with a comparison script.
5. Slice 7: remove JSON writes; slice 8 (the strangling): delete the JSON path entirely — scheduled, not "someday" (refactoring-playbook step 6).
6. Parallelization: slices 2 and 3 touch disjoint modules with no shared arrows → run in parallel by two workers. Slice 4 touches files slice 3 owns → sequential.
7. Delegation: slice 3's contract to a subagent: the seam interface (read-only), the writer files list, expected output "a diff switching writers to the seam, plus passing pytest tests/storage/", and "if any writer needs seam changes, STOP and report — do not modify the seam." The subagent hits exactly that blocker on one exotic writer, stops, reports; the orchestrator amends the seam in a micro-slice, and slice 3 resumes.
8. Retreat: every checkpoint keeps JSON as truth until slice 6; abandoning anywhere before it costs nothing but the seam — which is an improvement on its own.

Repository Examples

Repo facts below are point-in-time illustrations — examples, never assumptions about your system.

• This library's own construction (2026-07-04/06) — a live campaign case study: skills were authored by parallel writer agents from one shared spec and fact pack (delegation contracts: format spec + fact pack + output shape); when the writers' file-writes were permission-denied, the recovery was contract renegotiation — agents returned contents as text for the orchestrator to persist — without poisoning sibling slices; when a second writer wave was killed by session limits before producing anything, the retreat plan executed: the orchestrator authored the slices directly, checkpoint by checkpoint, each skill landing whole and registered before the next began. Three independent reviewers ran as parallel slices (no shared state); one died mid-run and its lens was covered by orchestrator spot-checks — contain, then decide.
• prism (~/prism, as of 2026-07-04) — checkpoint discipline in a 4-commit history: e264a72 (working skeleton) → b7bbabb (docs synced) → 51b92c9 (hardening) → b011239 (tests locking the hardening) — each commit a green, stop-forever-acceptable state; the hardening and its verification landed as adjacent slices.
• orphy (~/orphy, as of 2026-07-04) — slicing by contract: phases connected by JSON contracts with deterministic validators gating each, designed so phases are independently implementable — slice boundaries chosen where verification is possible, which is step 2's rule made architectural.

Validation Criteria

You applied this skill correctly when:

1. Slice 1 demonstrably attacked the campaign's plan-invalidating risk, and you can say what would have happened had it failed.
2. Every landed slice's checkpoint was green — provable from the history (each merge/commit passes the suite).
3. No two parallel slices' file sets intersected (auditable from their diffs).
4. Every delegation's contract exists in writing, and the orchestrator ran each verification before integrating.
5. At any point mid-campaign, you could answer "what happens if we stop today?" with "we keep everything landed."
6. If anything failed, the record shows contain → diagnose → explicit retry/reshape/retreat — never advance-on-red.

Provenance & Maintenance

• Sources: this library's own build campaign (2026-07-04/06, first-hand), ~/prism, ~/orphy — investigated 2026-07-04. Skill authored 2026-07-06; methodology is repo-independent.
• Assumptions: the prism commit sequence is read as deliberate checkpointing (Candidate — consistent with the history; the author's intent is not documented).
• Re-verification commands:

  git -C ~/prism log --oneline
  ls ~/.claude/skills/ | wc -l    # the library campaign's own artifact count
  

• Likely to drift: the library-build case study's details as the library evolves; agent-orchestration platform capabilities (delegation mechanics improve).
• Maintenance checklist:
  • Re-run re-verification; re-stamp Repository Examples.
  • After each future library campaign, update the first-hand case study with new lessons.
  • Confirm cross-referenced skills still exist under their directory names.