Brief: master planning process for the team

Status: brief for a new session, 2026-10-05. Nothing here is decided.

Question

How do we create a master plan of work for the team, week to week and month to month, by pulling issues and tracking from across our repos? Some projects live in this planning repo (as Markdown records plus Beads), and some work lives elsewhere (other repos, GitHub Issues such as life-itself/comms#229, Asana, Google Docs).

The plan also has to answer a personal question for each team member: what is my next week? That means every task needs an owner and a timeline, which Beads currently lacks in practice.

Proposed project

A new project, "Team master planning process", to design and run the weekly and monthly planning rhythm. Check projects/ and the portfolio index for an existing home before creating it. Candidates: 2605-project-management-infrastructure (likely, as it already covers tracker policy) or 2604-operations. Do not create a near-duplicate.

Needs

Master view across repos. One place to see all committed work, drawn from this repo's Beads and from external trackers, without a second hand-maintained task queue (see CLAUDE.md: no parallel NEXT.md).
Month to month. Themes and objectives per month, tied to the roadmap (projects/2600-life-itself-roadmap-september-december.md).
Week to week. What is planned for this week and next, by person and by project.
Per-person next week. Each team member can see their own list for next week and can trust it. Includes who triages and assigns, and when.
Owners and timeline on Beads. Most beads are unassigned and have no date.

Starting hypotheses (to test, not decisions)

Owners: use the existing assignee field with person slugs from people/ (see docs/bd-task-conventions.md). The gap is triage discipline, e.g. bd list --no-assignee, not a new field.
Timeline: check what bd supports natively (due dates, defer --until) via bd create --help and bd update --help. Otherwise use labels such as week:2026-W41 and month:2026-10.
Cross-repo view: a generated view, not a hand-written plan. Extend scripts/list_beads_by_initiative.py to group by owner and week or month. Pull GitHub Issues with gh issue list --json, or mirror them as a bead that links to the issue.
Durable plan content (monthly themes, decisions) stays in project Markdown. Task state stays in Beads.
Beads-first direction: Rufus wants to use Beads rather than GitHub Issues where possible. This depends on collaborators and Claude cloud instances being able to read and write Beads (lip-tqk.1, decision lip-wz8).

Open questions

Does the team plan weekly, monthly, or both? What day does the weekly plan get set?
Which repos and trackers beyond this one hold live work? Which are in scope first?
Who reads the plan: Rufus, the team, or both? Where do they open it (Markdown, a generated page, a Google Doc)?
Who assigns owners and dates: Rufus alone, project owners, or each person for their own work?
How are estimates or capacity handled, if at all?

Beads: lip-tqk.1 (cloud Beads access), lip-wz8 (Beads-first decision), lip-tqk.2 (closed tracker policy).
Docs: docs/workflow.md, docs/bd-task-conventions.md, docs/data-model.md.
Script: scripts/list_beads_by_initiative.py.
Skill: plan-for-delegation.