agentleFS
wundercorpwundercorp/loki/skills/productivity/weekly-review-planning/SKILL.md

weekly-review-planning

Skill28 starsChanged 2 months agoMITView on GitHub

Weekly reset: commitments, stalled work, next-week plan.

11 other projects use a version of this, 10 of them edited.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

3 rules. 1 is common, 0 are distinctive, and 2 are very specific to this project.

  • 1

    Common

    Most of the 11 edited versions we read keep these.

  • 0

    Distinctive

    This author's own choices. Worth a look.

  • 2

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Run a bounded weekly reset across the user's chosen systems.

    line 16
  2. Very specific:

    Don't use for: daily briefs (see the google-workspace daily-brief reference) or single-inbox triage (email-inbox-triage).

    line 26
  3. Common:

    Update tasks/projects, create calendar holds, archive processed items, and draft follow-ups only as approved.

    line 56

“Common” is measured: kept by at least 6 in 10 of the 11 edited versions of this file we could read. “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 Review and Planning

Run a bounded weekly reset across the user's chosen systems. This is a concrete recurring task, not a generic productivity methodology — the weekly-review Automation Blueprint schedules it as a cron job.

When to Use

  • "Run my weekly review."
  • "What did I commit to and what is slipping?"
  • "Plan next week from my calendar, tasks, and notes."
  • "Find stale projects and waiting items."
  • A cron tick fires for a scheduled weekly review.

Don't use for: daily briefs (see the google-workspace daily-brief reference) or single-inbox triage (email-inbox-triage).

Procedure

1. Set systems and window

Confirm timezone, review period, planning horizon, authoritative task/project store, calendars, inboxes, and allowed writes. Default to recommendations/drafts, not mutations. Done when source-of-truth conflicts have a declared winner.

2. Review calendar evidence

Load google-workspace or the relevant calendar connector. Inspect the completed week for meetings and commitments, then the next 1-2 weeks for deadlines, travel, preparation, and capacity. Capture follow-ups implied by past events and conflicts ahead. Done when both retrospective and horizon are covered.

3. Clear capture inboxes

Review the task inbox, notes (obsidian, notion), flagged email (email-inbox-triage owns thread-level triage), and other declared capture points. Convert each item to next action, project, waiting, scheduled, someday, reference, archive, or delete proposal. Do not mutate until scope is approved. Done when remaining unprocessed items are counted and stated.

4. Reconcile active projects

For each project identify desired outcome, next action, owner, deadline, blocker, last meaningful activity, and source link. Flag projects with no next action, missed dates, duplicate records, or contradictory status. Done when every active project is actionable or explicitly paused.

5. Review waiting and commitments

Find promises made by the user and items owed by others. Propose follow-ups with dates and channels. Do not infer that silence means completion. Done when each waiting item has an owner and next review/follow-up date.

6. Build a capacity-aware plan

Estimate fixed calendar load and select a small set of weekly outcomes plus near-term next actions. Rank by consequence, deadline, dependency, and effort; do not fill every free hour. Done when the plan fits actual capacity and names deferred work.

7. Apply approved updates

Update tasks/projects, create calendar holds, archive processed items, and draft follow-ups only as approved. Read every changed record back from the provider. Done when verified writes match the review summary.

Output Shape

  1. Wins and completed commitments
  2. Overdue or at risk
  3. Waiting/follow-ups
  4. Stalled or ambiguous projects
  5. Next week's outcomes and calendar constraints
  6. Proposed updates awaiting approval
  7. Coverage gaps

Pitfalls

  • Planning from tasks without calendar capacity.
  • Carrying every unfinished item forward as high priority.
  • Marking projects active with no next action.
  • Silently deleting or rescheduling personal commitments.
  • Treating silence from others as completion.

Verification

  • Both the completed week and the planning horizon were covered, or gaps are stated.
  • Every stalled/waiting flag traces to a specific record, event, or thread.
  • No task, event, or note was mutated without approval; approved writes were read back.
  • The plan names what was deferred, not just what was chosen.

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.