Planning

Two modes:

• sweep — prep. Read live work across repos, spot what is stale, unowned or missing, and propose corrections.
• week — plan next week for the team or for one person (--person <slug> from people/).

Month planning is not built yet; monthly themes live in the roadmap. Specification of a selected item uses the global plan-for-delegation skill's spec mode. Rufus's personal day/now planning stays in his own repo.

Principles: suggest from context first, never start from a blank page; one question at a time; keep it light; commitment over completeness.

What's next (GTD, not due dates)

Next work is whatever is in progress plus the top of bd ready by priority. Do not give every bead a due date. Use --due only when a date is genuinely fixed (an event, a launch, an external deadline); --defer for "not before". Ownership is the assignee field with a person slug (see Beads conventions); epics and larger pieces need an owner before their children do.

Context: read live, no cache

Run from this repository's root:

.venv/bin/python scripts/team_sweep.py                      # team
.venv/bin/python scripts/team_sweep.py --person asdra       # one person
.venv/bin/python scripts/team_sweep.py --refresh            # git fetch; fast-forward clean checkouts
.venv/bin/python scripts/team_sweep.py --extra-repo design  # repo not yet linked from any record

The script reads every active (next/in-progress) initiative and project, takes the repos named in github:/tracker:, finds sibling checkouts (../<repo>), and reads their Beads (bd -C <repo> --readonly) and linked GitHub Issues (gh issue list). This repo's Beads covers records with tracker: beads. It writes nothing; --refresh only fetches and fast-forwards clean checkouts that are behind. Each repo shows its checkout state; treat dirty, behind or diverged as possibly stale.

Per person it shows items assigned to them (matching slug, legacy email, GitHub handle or the full name that bd update --claim writes) and unassigned ready work in repos whose records they own.

Not read automatically: Asana, GitHub Projects boards, Google Docs, repos not checked out. Surface the link and ask for the next action; don't invent task detail.

Also read: the roadmap, the active project/initiative files the sweep surfaces, and (for one person) their Google Calendar for next week when available. Never block on the calendar.

Mode: sweep

An audit, not a re-derivation. Read what trackers already claim; spot-check what matters; propose corrections.

1. Run the sweep (team, or the person in scope). Use --refresh unless the user says otherwise.
2. Exceptions first, compactly: repos not checked out, Beads read errors, active records with no owner, active records with no linked repo/tracker, repos with work but no linking record, legacy assignees (email or full name instead of slug).
3. Spot-check in-progress items and top-ranked ready items not updated in ~7 days: open the source and propose bd update, defer, close or reassign with evidence.
4. Gaps: an active record with no open work is a gap, not an absence of work. Propose a next action (kind:, who:, project:<slug> label, one-line source pointer); don't create it without confirmation.
5. Lanes (from plan-for-delegation): delegatable to AI (who:ai, unblocked), AI-collaborative (who:collab), gated on a person (who:<slug> or assignee), needs a next action. Rank by friction, real deadlines/decay, leverage; say which criterion does the work for the top few.

Never write to Beads, GitHub or records without confirmation. A request to apply the proposed changes confirms that batch.

Mode: week

Goal: a small next-week plan at project/initiative level with named owners. Not a portfolio review.

1. Frame. Run the sweep for the scope. For one person, show next week's calendar load if available. State any hard dates in the window (due items, events).
2. Focus. Propose 3–5 focus areas from in-progress work, hard dates and roadmap priorities. Ask which to keep. For the team, each area gets one owner.
3. Next moves. For each area, suggest 1–3 concrete next items, using existing bead/issue IDs. Where detail lives in Asana, a GitHub board or a doc, surface the link and ask.
4. Commit in the tracker. Offer to set assignee (slug), claim, --due only for genuinely fixed dates, or create missing beads. Apply on confirmation.
5. Output. Present the plan in chat as below, then save it in weeks/ (see below) once agreed.

Week notes

• weeks/YYYY-MM-DD.md for the team plan (no suffix); weeks/YYYY-MM-DD-<slug>.md only when a person wants theirs written down. Date = the Monday of the planned week.
• Contents: focus areas, owners, hard dates, bead/issue IDs, "not this week", tracker fixes. Never copy a task list: task state stays in Beads/GitHub (no NEXT.md).
• A week note is a dated snapshot. Don't keep editing old weeks; next week gets a new file that starts from last week's note.
• Rufus's personal week plans stay in his own planning repo; don't duplicate them here.

## Next week (week of YYYY-MM-DD) — <team|person>

### Focus
- **Area** (owner): outcome — `id`, `id`

### Hard dates
- YYYY-MM-DD — what — `id` (owner)

### Not this week
- named items deliberately left

### Fix in trackers
- unowned / stale / unlinked items found by the sweep

Common mistakes

• Turning a week plan into a portfolio review or backlog grooming.
• Asking everyone to put due dates on everything.
• Treating a stale or dirty checkout as current.
• Fetching or inventing detail from trackers the sweep doesn't read.
• Writing assignments or dates without confirmation.