GSD parity sprint kickoff (Version 2)

The prompt I gave Claude Code to plan, staff, and run a three-platform parity sprint with a team of agents. It's the kickoff behind 64 PRs Before Lunch.

Run Claude Code from /Users/vinnycarpenter/Projects/GSD, then: Read sprint/kickoff.md and execute it. Start with Phase 0 and stop at the checkpoint.

Context (fill in before running)#

Every blank you leave empty becomes a guess.

All paths are relative to the sprint root, /Users/vinnycarpenter/Projects/GSD. Each app directory is its own git repo.

Directory	Role in this sprint
`CLAUDE.md`	Read first. Workspace-level instructions.
`gsd-taskmanager/`	Web app. In scope.
`gsd-iosapp/`	iPhone, iPad, and Mac app. In scope.
`gsd-android/`	Android app. In scope.
`sprint/`	Sprint docs: this kickoff, the board, and the parity matrix. Not a repo.
`wt/`	Git worktrees for every engineer. Nothing else goes here.
`gsdtaskmanager.com/`	Marketing site. Read only, for feature descriptions and the design guide.
`findings.json`	`[what this holds, and whether the lead should read it]`
`gsd-taskmanager-usage/`	`[out of scope]`

Source of truth for behavior: [web app | iOS app | spec file]. Where platforms disagree, this one wins unless I decide otherwise.
Sprint goal: [e.g., close every parity gap for recurring tasks, top-three priorities view, and weekly sweep]
Shared contracts: [sync payload schema, data model, MCP server, shared enums]
Release constraints: [e.g., Android release branch is frozen; do not touch release/*]
Timebox and budget: [N hours], max [N] concurrent engineer panes
Out of scope: [list]

Your role#

You're the tech lead for this sprint. You plan the work, write the briefs, staff the team, answer escalations, review PRs, and keep the board current. You write code only for contract tickets or to unblock someone, and you log it when you do.

Follow the Engineering Playbook for code standards and vinny-voice for PR descriptions, commit messages, and docs. Include the same pointers in every engineer brief.

Rules of engagement#

Each engineer works in its own git worktree under wt/, on its own branch named sprint/<ticket-id>-<slug>. Name the worktree wt/<platform>-<ticket-id> (for example, wt/android-T07) and create it from the app repo, such as git -C gsd-android worktree add ../wt/android-T07 -b sprint/T07-recurring-tasks. Never put two engineers in one checkout, and never let an engineer edit the main checkouts in gsd-taskmanager/, gsd-iosapp/, or gsd-android/. Remove a worktree after its PR merges.
Engineers may commit, push their sprint branch, and open PRs. Nobody merges. I merge.
No pushes to main or release branches, no App Store or Play Store submissions, no production deploys, no changes to production sync infrastructure, and no secrets in code, logs, or PR text.
Ask, don't guess. If the reference implementation looks like a bug, don't port the bug; escalate it.

Phase 0: discovery and plan (stop for approval)#

Read CLAUDE.md, then each app repo's own CLAUDE.md and README, then the code. Build a feature inventory and write sprint/parity-matrix.md with one row per feature and a column per platform. Mark each cell present, partial, missing, or divergent, and cite the file path as evidence.
Identify the shared contracts the work depends on: data model, sync payload, enums, date and time-zone handling, and recurrence rules.
Propose the backlog as tickets using the template below. Size each ticket to one PR. Group them into waves:
- Wave 0: contracts and shared test fixtures (golden JSON inputs and expected outputs that all three platforms test against).
- Wave 1: parallel platform tickets that code against the Wave 0 contracts.
- Wave 2: integration and cross-platform verification.
Propose staffing for each ticket (level plus a one-line reason) and the file-ownership map, so no two concurrent tickets edit the same file.
Find the real verification commands for each repo (test, lint, typecheck, and build) from its scripts, Gradle tasks, and Xcode schemes. Run each one once on the main branch and record the commands and the baseline result in sprint/SPRINT.md, so a test that's already failing isn't blamed on a sprint PR.
List open questions and every decision you need from me, ranked by how much work each one blocks.

Stop here. Don't spawn any engineers until I approve the plan.

Staffing#

Use herdr to run the team. Load the herdr skill first if it's installed. Create one workspace for the sprint rooted at /Users/vinnycarpenter/Projects/GSD and one pane per engineer, with the pane's working directory set to that engineer's worktree. Label each pane <level>-<ticket-id>, and start Claude Code in it with the model for that level.

Staff engineers (Opus 5.5): contracts, sync, data migrations, cross-platform architecture, hard bugs, and reviews of senior PRs.
Senior engineers (Sonnet 5.5): feature work on one platform against an approved contract, with tests.
Junior engineers (Haiku 5.5): mechanical work with a deterministic check, such as string tables, fixture generation, renames, test scaffolding from a spec, and summarizing diffs. Never schema, sync, auth, or anything without a passing test to prove it.

Stay at or under the concurrent pane limit. Close a pane once its PR is open and reviewed.

Engineer brief template#

Each engineer starts with an empty context. The brief is everything it knows, so every brief includes all of these:

Ticket ID, title, and one-sentence goal stated as user-visible behavior
Platform, repo, worktree path under wt/, and branch name
Source of truth: the reference implementation's file paths and the contract doc
Files it owns, and files it must not touch because another ticket owns them
Acceptance criteria, each one testable
Verification commands that must pass (see below)
Dependencies by ticket ID, and the rule for unmerged ones: code against the contract and shared fixtures, not against another engineer's branch
The escalation protocol below, copied in full
The report format: what changed, commands run with results, what wasn't verified, and follow-ups noticed but not done

Verification#

Use the commands recorded in Phase 0 and approved with the plan. Every brief copies the commands for its platform.

Web (gsd-taskmanager): test, lint, typecheck, and build
Apple platforms (gsd-iosapp): xcodebuild test and build for each scheme the ticket touches
Android (gsd-android): Gradle test, lint, and debug build
Cross-platform: the shared fixture tests pass on every platform the ticket touches.

Every PR description lists the commands run and their results, plus anything left unverified, such as on-device UI or real sync between two devices.

Escalation and coordination#

Engineers escalate to you, not to me, and they don't coordinate with each other directly. You're the single point of coordination.

An engineer escalates when acceptance criteria are ambiguous, the work needs a file another ticket owns, the contract looks wrong, a failure sits outside its ticket, or two attempts at the same problem have failed. To escalate, it stops, writes a line starting with ESCALATION: that states the question and the options it sees, and waits. Watch pane states in herdr, answer blocked panes in the pane itself, and log the decision.

You escalate to me only for product behavior decisions, scope changes, contract changes after approval, anything touching release branches or production, and budget or timebox overruns. Decide everything else yourself and log it.

Review#

Every PR gets a review before it's marked ready. A different staff engineer reviews staff PRs, a staff engineer reviews senior PRs, and a senior engineer reviews junior PRs. Give each reviewer a briefing with the ticket, the diff range, the contract, and constraints already agreed. If /adversarial-review is installed, use it for contract and sync PRs. You confirm the acceptance criteria last.

The board#

sprint/SPRINT.md is the board, and only you write to it. It holds each ticket's owner pane, status, PR link, and blockers, plus the file-ownership map and a decision log.

Checkpoints#

After Phase 0: I approve the plan, staffing, and contracts.
After Wave 0: I merge the contract and fixture PRs before Wave 1 starts.
End of sprint: the closing report.

Non-goals#

New features beyond parity, unless the sprint goal lists them
Refactors outside a ticket's scope (log them as follow-ups)
Dependency upgrades a ticket doesn't require
Releases, store submissions, or production changes

Done#

Every approved ticket has a PR that passes its verification commands and its review.
sprint/parity-matrix.md shows PR links for closed gaps and lists the gaps that remain.
The closing report in sprint/SPRINT.md covers what shipped, what was verified and how, what wasn't verified, open escalations, and a recommended next sprint.