Weekly review
Runs a timeboxed weekly review - empty every inbox to a decision, audit every open commitment, and pick the 3-5 outcomes that define next week. Use when someone asks "walk me through a weekly review", "help me plan my week", "my task system feels stale and I don't trust it", or "I keep dropping commitments". Do NOT use for setting up the underlying capture-and-organize system itself - use gtd-system instead - or for tracking long-horizon personal goals with an accountability loop - use goals-accountability instead.From its SKILL.md
npx -y skills add SkillMedev/skills --skill weekly-reviewAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 4 stars4 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
6.4 KB, ~1.4k tokens by cl100k_base, as published. Nobody here has run it
Weekly Review
The weekly review is the maintenance ritual that keeps a productivity system trustworthy. Skip it two weeks in a row and the lists go stale, the brain stops trusting them, and everything moves back into working memory - which is the exact failure the system existed to prevent. Run it as a repeatable checklist at a fixed time, not as a guilt session, and it takes 60-90 minutes to buy a week of clear-headed execution.
Operating procedure
The three phases run in this order because each depends on the last: you cannot audit projects honestly (get current) while unprocessed inputs hide commitments (get clear), and you cannot pick next week's outcomes (get ahead) from a project list you have not audited.
Step 1: gather inputs (5 minutes)
Collect before starting; if the user cannot produce one, note it as a gap in their system and continue.
- The list of inboxes. Default set: email, chat, notes app, task-manager inbox, physical desk/papers. If they name fewer than three, ask where meeting commitments land - there is almost always a hidden inbox.
- The project list, waiting-for list, and someday/maybe list.
- The calendar, last week through two weeks ahead.
- Last week's plan, if one exists. If none exists, say so plainly and build the first one this session.
If the user estimates anything ("I think I have about 10 open projects"), label it a guess and verify during Phase B.
Phase A - Get clear (25-30 minutes)
- Empty every inbox to zero. Process each item to one of four decisions: do (under 2 minutes - do it now), defer (put on the calendar or task list with a next action), delegate (hand off and add to waiting-for), or drop. Inbox zero means every item has a decision, not that every item is done.
- Run a 5-minute mind sweep: capture anything the head is still holding - promises made in hallways, nagging worries, ideas. Write, don't evaluate.
Phase B - Get current (20-30 minutes)
- Scan the calendar backward over last week for loose ends: meetings that produced commitments never captured, follow-ups owed.
- Scan the calendar forward two weeks for anything that needs prep. Two weeks, not one - one week gives no runway for prep that itself takes days.
- Walk the project list. Every open project must have a concrete next action; a project without one is stalled by definition, whatever its status field says.
- Walk the waiting-for list. Nudge anything with no response for more than a week. Delete items that no longer matter.
Phase C - Get ahead (10-15 minutes)
- Pick the 3-5 outcomes that would make next week a win. Hard cap at 5 - a list of eight priorities is a list of zero priorities.
- Block calendar time for the most important outcome, not the most urgent, and place its first block before Wednesday. Deep-focus blocks that land on Friday get eaten. For heavier time-block design, pair with deep-work-planner.
- Scan someday/maybe and activate at most one item. Activating more than one per week silently inflates the project list.
- End with a short written Monday plan: the 3-5 outcomes, the first calendar block for each, and the single most important thing to start Monday morning.
Concrete thresholds
- Full review: 60-90 minutes. Consistently over 2 hours means the system is too complex or the review too infrequent - fix the system (gtd-system), don't lengthen the ritual.
- Missing two consecutive weeks is the trust-collapse threshold. When time is short, shrink instead of skipping: the 20-minute minimum is inboxes to zero, calendar scan, pick 3 outcomes.
- Waiting-for nudge line: 7 days without a response.
- Calendar lookahead: 2 weeks. Outcome cap: 5. Someday/maybe activation cap: 1 per week.
Template: weekly review record
Copy, fill, and keep in the same document week over week - the running history is what makes patterns visible.
WEEKLY REVIEW - week of [FILL: date]
GET CLEAR
Inboxes emptied: [FILL: list] - all to zero? yes / no
Mind sweep captures: [FILL: count] items
GET CURRENT
Loose ends from last week: [FILL]
Prep needed (next 2 weeks): [FILL]
Projects without a next action (now fixed): [FILL: count]
Waiting-for items nudged: [FILL]
GET AHEAD - next week's 3-5 outcomes
1. [FILL: outcome] - first block: [FILL: day/time]
2. [FILL] - first block: [FILL]
3. [FILL] - first block: [FILL]
Someday/maybe activated (max 1): [FILL or none]
HONESTY LINE
What didn't happen last week and why (one sentence, no self-flagellation):
[FILL]
MONDAY: start with [FILL: one thing]
Deliverable
Produce a completed weekly review record containing: confirmation every inbox reached zero, the fixed project and waiting-for lists, the 3-5 named outcomes each with a calendar block before Wednesday where possible, the one-sentence honesty line about last week, and the Monday starting action.
Do NOT
- Do not turn the review into doing the work. Two-minute items get done; everything else gets a decision and a slot. A review that runs 4 hours because you answered email is not a review.
- Do not let the honesty line become a guilt session. One sentence on what slipped and why, then adjust the plan - piling on erodes the habit that keeps the system alive.
- Do not pick outcomes by urgency. Urgent items already defend themselves; the review exists to protect the important ones.
- Do not skip Phase A to "save time". Auditing projects on top of unprocessed inboxes produces a plan missing the commitments hiding in email.
- Do not rebuild the system mid-review. Note friction, finish the review, then fix the system separately with gtd-system.
Quality bar
A finished review passes only when all hold:
- Every inbox is at zero (decisions made, not necessarily done).
- Every open project has a written next action.
- Next week has 3-5 outcomes, no more, each with a first calendar block.
- The honesty line exists and names a cause, not just a miss.
- The whole thing fit inside 90 minutes - or the gap is logged as a system problem.
What ships with it
Read from the repository
Just SKILL.md. No reference files, no scripts.
Gives 0 of the 12 instructions most review quality skills give in ~1.4k tokens
Counted across 1,048 of the 1,783 authors here whose files we hold, read 2026-08-07
- Ask questions one at a timein 81 of 1048, across 64 files
- Provide a recommended answer for each questionin 73 of 1048, across 50 files
- Explore the codebase instead of asking answerable questionsin 66 of 1048, across 42 files
- Resolve dependencies between decisions one-by-onein 42 of 1048, across 17 files
- Interview the user relentlessly about the planin 38 of 1048, across 13 files
- Order findings by severityin 31 of 1048
- Resolve each branch of the decision treein 27 of 1048, across 5 files
- Run a grilling sessionin 26 of 1048, across 5 files
- Update CONTEXT.md immediately when a term is resolvedin 26 of 1048, across 11 files
- Propose precise canonical terms for vague languagein 25 of 1048, across 7 files
- Create documentation files lazilyin 24 of 1048, across 5 files
- Assign severity to every findingin 24 of 1048
Said here and by no other author read
- gather all inputs before starting
- empty every inbox to zero decisions
- process each inbox item to one decision
- do under two-minute tasks immediately
- capture open loops in a mind sweep
- ensure every open project has a next action
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.