weekly-planning

# Weekly Planning

## Overview

Turn retro findings + existing backlog into a prioritized week with clear outcomes, issues in correct repos, and delegation matrix (founder vs agent).

## When to Use

- After weekly retro is complete
- Monday/Tuesday when planning the week
- When user says "план на неделю", "приоритизация", "что делаем"

## Iron Rule: Planning Is Not Execution

Weekly planning creates a plan. It does not execute the plan.

Allowed during planning:
- Gather context needed to choose outcomes
- Read calendars, issues, project boards, CRM/backlog files, and recent notes
- Draft outcomes, issue proposals, and board updates

Not allowed during planning:
- Start implementation work for a chosen outcome
- Create deliverables, briefs, proposals, content, code, or production changes
- Spawn executor agents for work that belongs to the coming week

If the user asks to "do this now" while planning, finish or pause planning first, then handle that as a separate execution task.

## Process

```dot
digraph planning {
  rankdir=TB;
  node [shape=box];

  collect [label="1. Collect all tasks"];
  calendar [label="2. Map calendar"];
  group [label="3. Group by surface"];
  eisenhower [label="4. Eisenhower split"];
  outcomes [label="5. Choose outcomes"];
  issues [label="6. Create issues\nin correct repos"];
  board [label="7. Add to board\nwith W{NN} label"];
  page [label="8. Create living\nweekly plan"];

  collect -> calendar -> group -> eisenhower -> outcomes -> issues -> board -> page;
}
```

### 1. Collect all tasks

Sources to scan:
- Retro backlog (label `retro:W{NN-1}`)
- Open issues across ALL repos: `gh search issues --owner $YOUR_OWNER --state open`
- GitHub Projects for active initiatives
- Calendar events (meetings, lectures, mentoring)
- User input (new tasks from interview)

### 2. Map calendar

Read known sources before asking the user. Use calendar, existing issues, project boards, and planning files to establish:
- Today's date
- Planned week start/end
- Fixed events
- Known deadlines
- Available capacity

Ask only for facts that are not recoverable from sources, one question at a time.

IMPORTANT: Verify dates before writing outcomes. Do not create deadlines in the past. If the deadline is today, include a time boundary such as "by EOD".

### 3. Group by surface

Group tasks by where work happens. Use the repos and task routing defined in `AGENTS.md` / `CLAUDE.md` config (set up by `corp-init`).

Example surfaces:

| Surface | Description |
|---------|-------------|
| Product delivery | Main product/service repos |
| Sales/pipeline | CRM, sales tooling |
| Content | Blog, videos, social media |
| Strategy | Planning, cross-cutting decisions |
| Infrastructure | Internal tools, automation |

### 4. Eisenhower split with delegation

For each task, classify:

| | Urgent | Not Urgent |
|---|--------|-----------|
| **Important** | Founder does TODAY | Founder schedules this week |
| **Not Important** | Agent does async | Parking lot / drop |

Key question per task: "Does this require founder judgment, or can an agent execute it from the issue description?"

### 5. Choose outcomes

Outcomes = results, not tasks. Format: "By Friday, X is true."

Rules:
- NOT limited to 3 — as many as realistic
- Each outcome has a measurable check
- Include both founder-only and agent-delegated work
- Include B2B/sales if there are active deals — these are outcomes, not bonuses
- Outcomes are commitments chosen with the user, not a silent reconstruction from the backlog
- Use the backlog as input, then ask the user to choose or edit outcome options

Example:
```
Outcome: New feature launched
Check: deployed to production, 0 critical bugs by Friday
Founder: final UX decisions, announcement copy
Agent: implementation, tests, deploy script
```

### 6. Create issues in CORRECT repos

CRITICAL: Issue lives where the work happens. Use the task routing from your `CLAUDE.md` config.

```
Issue about backend bug → backend repo
Issue about marketing → marketing repo
Issue about content → content repo
Issue about strategy → main planning repo
```

Before creating any issue:
1. VERIFY current state (check existing issues, files, data)
2. PROPOSE to user
3. CREATE only after verification

Label every issue: `W{NN}` + optionally `retro:W{NN-1}` if from retro.

### 7. Add to unified board

All W{NN} issues → your GitHub Project (from `CLAUDE.md` config: `project_id` and `owner`).

Create or use view "W{NN}" filtered by label.

```bash
# Add to project (use project_id and owner from your config)
gh project item-add $PROJECT_ID --owner $YOUR_OWNER --url $ISSUE_URL

# Verify
gh search issues --owner $YOUR_OWNER --label "W{NN}" --state open
```

### 8. Create the living weekly plan

Resolve the ISO week from the current local date. Never hardcode `W34` or copy the previous filename.

```bash
python3 skills/weekly-planning/scripts/living_week.py context --workspace . --json
python3 skills/weekly-planning/scripts/living_week.py create --workspace .
```

The generator creates `reports/WNN-plan.html`. Before presenting it:

1. Remove every element with `data-placeholder="true"`.
2. Populate all seven day columns with accepted work; every task card has one `data-area`.
3. Keep exactly one pair of `daily:updated`, `daily:kanban`, and hidden `daily:day-slice` markers. The local `daily` skill may replace only these marked regions.
4. Mark past days as closed with the tasks and facts that actually happened. Highlight the current day. Keep future days as plan.
5. Configure the three display time zones and the seven work Areas in the page script. Card color comes from Area metadata.
6. Put the goal captured during retro/planning into each Area definition. The Area Explorer derives cards from the weekly board; it never stores a second task list.
7. Keep Wealth as the recovery Area or rename it in config. Its daily habit checkboxes use a week-scoped localStorage key and must not be overwritten by agents.

The HTML page is