agentleFS
serejarisserejaris/ris-claude-code/skills/weekly-planning/SKILL.md

weekly-planning

Skill243 starsChanged 3 months agoMITView on GitHub

Use when the user is transitioning from a completed retro into a weekly plan, choosing weekly outcomes, scheduling a full ISO week, or asking for "план на неделю", "weekly planning", priorities, capacity, or outcomes.

3 other projects use a version of this.

Adopted by

Most recently taken up by

The file

Show its rules and text

We split this skill into the rules it gives an agent

19 rules. About 0 are common, 16 are distinctive, and 3 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈16

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 3

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    After weekly retro is complete

    line 14
  2. Distinctive:

    Read calendars, issues, project boards, CRM/backlog files, and recent notes

    line 24
  3. Distinctive:

    Not allowed during planning:

    line 27
  4. Distinctive:

    Start implementation work for a chosen outcome

    line 28
  5. Distinctive:

    Create deliverables, briefs, proposals, content, code, or production changes

    line 29
  6. Distinctive:

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

    line 32
  7. Distinctive:

    Read known sources before asking the user.

    line 65
  8. Distinctive:

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

    line 72
  9. Distinctive:

    NOT limited to 3 — as many as realistic

    line 106
  10. Distinctive:

    Use the backlog as input, then ask the user to choose or edit outcome options

    line 111
  11. Distinctive:

    Before creating any issue:

    line 132
  12. Distinctive:

    VERIFY current state (check existing issues, files, data)

    line 133
  13. Distinctive:

    CREATE only after verification

    line 135
  14. Very specific:

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

    line 141
  15. Distinctive:

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

    line 143
  16. Very specific:

    Remove every element with data-placeholder="true".

    line 164
  17. Very specific:

    Keep exactly one pair of daily:updated, daily:kanban, and hidden daily:day-slice markers.

    line 166
  18. Distinctive:

    Put the goal captured during retro/planning into each Area definition.

    line 169
  19. Distinctive:

    Keep Wealth as the recovery Area or rename it in config.

    line 170

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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

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:

SurfaceDescription
Product deliveryMain product/service repos
Sales/pipelineCRM, sales tooling
ContentBlog, videos, social media
StrategyPlanning, cross-cutting decisions
InfrastructureInternal tools, automation

4. Eisenhower split with delegation

For each task, classify:

UrgentNot Urgent
ImportantFounder does TODAYFounder schedules this week
Not ImportantAgent does asyncParking 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.

# 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.

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 a mutable view. Issues/task records and WNN-outcomes.md remain sources of truth. Daily updates preserve the full ISO week and mutate only the marked regions.

Red Flags — STOP

  • Creating all issues in one repo → WRONG, route to correct repo per config
  • Creating issue without checking current state → VERIFY FIRST
  • Claiming status without checking actual data → VERIFY
  • Planning 40h of productive work → budget 60% capacity
  • Skipping calendar mapping → leads to conflicts
  • Mixing "task" with "outcome" → outcome = result by Friday
  • Doing execution work inside planning → finish planning first, execute separately
  • Asking the user for facts that are already available in sources → read sources first
  • Writing deadlines without checking the actual date → verify current date and week range
  • Replacing the entire plan during daily update → mutate only the marker regions and preserve browser habit state
  • Copying last week's filename or localStorage key → resolve the current ISO week with the generator

Common Mistakes

MistakeFix
All issues in one repoRoute to where work happens
Issue created without verificationCheck issues + files + data first
Outcomes = task listRewrite as "by Friday, X is true"
Ignoring B2B as "bonus"Active deals with money = outcomes
Publishing paid content publiclyPaid content stays in paid repos
Assuming data without checkingVerify with gh issue list + actual files
Fixed 3 outcomes limitAs many outcomes as realistic
Executing tasks during planningCapture as outcomes/issues, execute after planning
Asking instead of readingCheck source systems first, ask only for missing facts

Integration with weekly-retro

This skill runs AFTER weekly-retro. Expected inputs:

  • Retro summary with what worked / didn't
  • Issues created during retro (label retro:W{NN-1})
  • Lessons learned and playbook updates
  • New tasks from retro interview

Setup

This skill reads config from your project's AGENTS.md / CLAUDE.md. Run corp-doctor first to generate or repair the config block, or add manually:

## Agent Operations Config

### Repos (scanned during retro/planning)
repos:
  - owner/repo-1    # what it does
  - owner/repo-2    # what it does

### GitHub Project
project_id: N
owner: your-github-handle

### Task Routing
routing:
  - pattern: "backend, bugs"
    repo: owner/backend-repo
  - pattern: "content, marketing"
    repo: owner/content-repo
  - pattern: "strategy, cross-cutting"
    repo: owner/main-repo

### Living plan
reports_dir: reports
local_timezone: system
display_timezones:
  - Europe/Berlin
  - Europe/Moscow
  - America/Argentina/Buenos_Aires
areas:
  - delivery
  - sales
  - systems
  - content
  - people
  - strategy
  - wealth
wealth_habits:
  - sport
  - reflection

Quick Reference

# All tasks for current week
gh search issues --owner $YOUR_OWNER --label "W{NN}" --state open

# By repo
gh search issues --owner $YOUR_OWNER --label "W{NN}" --state open --json repository,number,title

# Close week (Friday)
gh search issues --owner $YOUR_OWNER --label "W{NN}" --state open --json title,repository
# Review: done / spillover / drop

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.