The Weekly Reset

// 01 — The 15-minute checklist

The whole reset is five micro-tasks, three minutes each. The hard part isn't doing them — it's doing them every Friday without skipping. Three minutes feels short until week six, when you've quietly let two weeks lapse and the brain is now noticeably stale.

The discipline is the timer. Open a stopwatch, run task one, stop at 3:00 regardless of whether you finished, move on. Each task produces a concrete artifact. If the artifact is empty (zero new decisions to promote, zero cross-pollination items), that's fine — "nothing this week" is a valid output. What's not valid is "I didn't run it."

Same time as a standup. One person, 15 minutes, alone with the AI — or distributed: each rotation owner picks one task per day across the week and the whole reset finishes by Friday close. Whatever the team prefers, the constraint is the same: five artifacts on the board by end-of-week, every week.

// 02 — The promotion prompt

Decisions don't decide themselves. decisions.md in your shared base has two halves: the opens at the top (questions the team is wrestling with) and the resolved ADRs below (what we actually settled on, why, and when). T02 introduced the file. T05 introduces the cadence.

Most teams' opens section grows for a month and then collapses under its own weight — nobody can remember what was already decided, so the same question reopens for the third time in two months. The Friday promotion is the antidote: every week, every open question gets either promoted to a decision or explicitly tagged as still-pending with a reason.

The prompt (verbatim)

You are helping me run the Friday Promotion task on our team's
decisions.md file. Read the entire file.

For each entry in the "Opens" section:

1. Is there enough information in the past week's state-shared.md,
   project-shared.md, or ticket activity to resolve it? If yes,
   draft an ADR-style entry for the Decisions section with:
   - Date (today, YYYY-MM-DD)
   - One-sentence decision
   - Two-to-four-bullet "why" with concrete references
   - Owner (the person who made the call)
   - Status: ACCEPTED

2. If not enough info, leave it in Opens but ADD a "blocked-on"
   tag naming what specifically is needed (a number, a stakeholder
   answer, a test result).

3. If the open question has been sitting unresolved for 4+ weeks
   without a blocked-on reason, flag it: "STALE -- review or drop."

Output: the proposed diff to decisions.md. I'll review before
committing.

Who runs which version

• Individual contributor — runs the prompt against their personal decisions.md in their Personal Knowledge Database. Promotes their own opens. Takes 1–2 minutes; usually zero or one promotion per week.
• Rotation owner — runs the prompt against the team's shared decisions.md. Promotes team-wide opens. Usually 0–3 promotions per week. The diff gets posted to the team channel for 30-second review before commit; nobody objects because the AI cites the source for each "why" bullet.

What a promoted ADR looks like

The promotion prompt produces entries shaped like this. The shape matters — future you (or a new hire six months from now) will read this entry without any of the context that made the decision feel obvious at the time.

### 2026-05-08 — Adopt SOPS for secrets across all repos

**Decision:** SOPS with age keys, encrypted at rest in the repo,
keys distributed via 1Password vault per environment.

**Why:**
- Vault was rejected (operational overhead too high for a team
  of 6; see state-shared.md 2026-04-30).
- AWS Parameter Store costs $0/mo for our volume but couples
  every dev workflow to AWS console access (BA + tech writer
  don't have IAM and we don't want to expand the IAM blast radius).
- Plain .env files in 1Password worked for two years but fell
  apart at 4 environments × 6 repos.

**Owner:** Marcus (Architect)
**Status:** ACCEPTED · revisit 2026-11-08 (6-month check)

Three sentences, three references, an owner, a revisit date. Nothing more. The AI generates the entire block from the week's source files; the rotation owner reviews for accuracy and commits. Most ADRs are written in 90 seconds.

When promotion produces zero

Some weeks the AI scans opens and produces nothing — either because the section was already empty, or because nothing in this week's state files unblocks any open. That's fine. A zero-promotion week is a real signal: either the team isn't currently making decisions worth recording (quiet operational week), or the opens are blocked on something external (waiting on a stakeholder, a vendor, a test result). The promotion prompt's "blocked-on" tag is what turns the second case into a tracked dependency instead of silent rot.

// 03 — The cross-pollination prompt

This is the prompt that justifies the entire ritual. Teams have lateral signal nobody surfaces: the DBA spotted a customer-traffic pattern that the BA's segmentation model assumes doesn't exist; the support lead has a recurring ticket type the architect would solve in a Tuesday afternoon if they knew; the tech writer noticed the API doc and the SDK disagree on a field name. None of this is hidden. It's just unaddressed, because in normal week-to-week work people stay in their own lane.

The cross-pollination prompt is the AI scanning every role's slice and surfacing what an adjacent role should know. It runs against the shared base, so it sees everything.

The prompt (verbatim)

You are the team's cross-pollination scout for this week's reset.

Scan:
- state-shared.md (this week's deltas)
- decisions.md (new entries since last Friday)
- the most recent 5 ticket-resolution notes in tickets/recent/
- project-shared.md (any status changes)

Surface 0-3 items that an adjacent role would benefit from knowing,
even if it's outside their normal lane. Adjacent roles to consider:
BA, DBA, PM, Support Lead, Architect, Tech Writer, QA Lead.

For each item:
- One sentence: what happened.
- One sentence: why the adjacent role cares.
- WHO on the team most directly needs it (name + role).

If there is genuinely nothing worth surfacing, say so explicitly:
"NO CROSS-POLLINATION ITEMS THIS WEEK." Do not invent items to
fill the slot.

Output: a markdown block I can paste at the top of digest.md.

Why it works

Most lateral signal surfaces in the bad week: the BA discovers the stack constraint when their proposal gets shot down in review; the DBA finds the segmentation gap when a migration breaks production. By that point it's a fire. The Friday cross-pollination surfaces the same signal one to four weeks before the fire — cheaply, routinely, while it's still cheap to address.

It also normalizes "I read about your stuff." Teammates get used to seeing their work referenced in other roles' digests; collaboration improves not because someone organized a workshop, but because the brain made it ambient.

Example output (real shape, plausible content)

Three items, posted Friday afternoon, costs three minutes to produce. Each one is a fire that didn't happen.

Where the digest lives

Two viable patterns, pick one and stick with it:

• Append to team-brain/digest.md with a dated header per week. The file grows linearly; quarterly, the reset owner moves anything older than 90 days into archive/{year}/digest-{quarter}.md. Good if you want the team channel kept clean.
• Post to the team channel as a Friday-afternoon message, then file a copy in digest.md. Higher visibility (the @-mentions actually ping the named role), at the cost of channel noise. Good if cross-pollination is currently being ignored.

Teams that struggle to act on cross-pollination items should pick the second pattern for a quarter. Once acting-on-the-signal becomes habit, you can quietly drop back to the appended-file pattern.

// 04 — The dead-context pruner

Here's the failure mode nobody anticipates: the team brain grows monotonically. Every project that ships leaves its project-*.md behind. Every customer that churns leaves their context overlay. Every architectural exploration that didn't go anywhere leaves a half-finished spec. After six months the brain is 4× the size it needs to be, the AI is paying token cost on every session for files that are no longer relevant, and the real signal is buried in stale weight.

The instinct is to prune by feeling — "this looks old, delete it." That's wrong twice: you'll delete files you needed, and you'll keep files you didn't. The truth is in the AI's session history. Files that haven't been read by any session in 30+ days are dead context, regardless of how important they feel.

The prompt (verbatim)

You are the dead-context pruner for the team-brain/ folder.

List every markdown file under team-brain/ that has NOT been read
by any AI session in the past 30 days (use the session log at
team-brain/_meta/access-log.jsonl as ground truth).

Group the unread files into three buckets:

DEFINITELY-ARCHIVE
  - File covers a project, customer, or initiative that is
    explicitly marked closed/shipped/cancelled in project-shared.md
    or its own frontmatter status field.
  - Move target: archive/{year}/{quarter}/

MAYBE-ARCHIVE
  - File covers something whose status is ambiguous, OR
  - File is referenced (by name) in an active file but hasn't
    itself been loaded in 30+ days.
  - For each: write ONE question I need to answer to decide.

KEEP
  - File is small, foundational (team-identity, glossary, role
    overlays), or clearly evergreen reference material.

Output: candidates-for-archive.md with the three sections.
Do not move anything. I'll review and execute moves manually.

Why brains rot

Files that are still relevant but never loaded are dead weight that hides real signal. The Friday reset surfaces the unread tail so you can either (a) move it to archive and stop paying for it, or (b) realize the team has been ignoring something important and explicitly re-prioritize.

Either resolution beats the silent rot.

The rule

Prune by usage signal, not by feeling. The AI's session history is the truth. If you didn't load it in 30 days, you don't need it loaded by default. (You can always pull it back from archive on demand — that's the point of the archive structure, not deletion.)

The archive structure

team-brain/
├── active/                          ← what every session loads
│   ├── project-acme-migration.md
│   ├── project-q3-rearchitecture.md
│   └── ...
├── archive/                         ← searchable, not loaded
│   ├── 2025/
│   │   ├── Q1/
│   │   ├── Q2/
│   │   ├── Q3/
│   │   └── Q4/
│   └── 2026/
│       └── Q1/
│           ├── project-sunset-customer-portal.md
│           └── project-legacy-billing-migration.md
└── _meta/
    └── access-log.jsonl             ← session reads, ground truth

Never delete — just move. Search still hits files under archive/ when the AI is explicitly looking for historical context ("how did we handle the legacy billing migration last year?"). You stop paying token cost for stale files on every session; you keep the institutional memory.

The access log

The pruner depends on _meta/access-log.jsonl — one JSON line per AI session read, capturing file path, session ID, and timestamp. Most filesystem-aware AI tools (Claude Code, Cursor, Windsurf) can be configured to emit this; for shared-Project setups (Claude Team, ChatGPT Team) the log is approximate (you derive it from project-history exports weekly).

If your tooling can't emit an access log at all, the pruner falls back to git log: files whose most recent commit OR most recent reference in any commit-message is > 30 days old. Less precise (a file might have been read often without being edited), but better than feeling. The prompt detects which signal is available and uses whichever is present.

First run is loud, subsequent runs are quiet

The first time you run the dead-context pruner on a six-month-old brain, expect 20–40 candidates — most of them definitely-archive. That's a one-time cleanup. After the brain has been running with the weekly reset for two or three months, the pruner typically surfaces 0–3 candidates per week. That's the steady state: the brain is self-tending.

// 05 — Who runs it

15 minutes a week, 50 weeks a year — that's 12.5 hours per year of reset work. If one person owns it, they will silently resent the team by month three and quit by month six. Rotate it.

The rotation

Per quarter, designate the reset owner. Default rotation across a typical IT Pro team:

Each role does it 1–2 weeks per quarter. The Tech Lead does it more often because the role has more context on the team's state already — but only marginally more.

Why the rotation matters

• Bus-factor protection. If only one person knows how the team brain works — how the prompts run, where the files live, what the archive convention is — the brain dies the day they go on vacation. Rotating the reset forces every role to learn the operating system.
• Different eyes find different gaps. The BA running the cross-pollination prompt notices BA-shaped gaps the architect would miss, and vice versa. The brain ends up better-tended than if a single role owned it.
• Distributes the political work. Some weeks the promotion prompt surfaces decisions someone won't like. If the same person runs it every week, they become the person who "always brings up the awkward stuff." Rotation spreads the social cost.

The handoff

The previous owner spends 5 minutes training the next owner on Friday before they wrap. The training is literally: "here's the checklist, here are the five prompts, here's where the access log lives, here's the channel I post the digest to." After two rotations (six months for a typical six-role team), everyone has done the reset twice and nobody needs handoff anymore.

The first month is the hardest

For the first four weeks after standing up the reset, expect friction. Three predictable failure modes show up in roughly this order:

• Week 1. The rotation owner forgets — runs the reset on Monday instead of Friday, or skips entirely. Solution: put a recurring 15-minute calendar block titled "Team brain reset" on every owner's calendar for the quarter, with the owner-of-the-week's name in the title. Slack reminder bot 10 minutes before. Two weeks of forgetting and the habit dies.
• Week 2–3. The prompts produce output the rotation owner doesn't know what to do with — a cross-pollination item that names a teammate who doesn't read the digest, a dead-context candidate that the owner is afraid to move "in case someone needs it." Solution: act on the output anyway. Mis-routed digest items get noticed and routed correctly next week. Moved archive files come back from archive/ in seconds if needed. Hesitation is what kills the brain; action is recoverable.
• Week 4. Someone asks "do we still need to do this?" Solution: yes. Show them the decisions.md ADR count from the past month (likely 4–8 new entries) and the cross-pollination digest items that turned into adjacent-role tickets (likely 2–5). If they still think it's not worth 15 minutes a week, they're wrong, but the brain has produced enough receipts to make the case without you arguing it.

By week six, the reset is muscle memory and nobody asks whether it's worth doing.

"I'm not the role for this" pushback

You will get this. The DBA will say "the cross-pollination prompt is more of an architect's job." The BA will say "the dead-context pruner is an engineering task." The PM will say "I don't really do markdown."

Doesn't matter. The reset is a hygiene task, not a skill task. Every prompt is verbatim — nobody is doing original thinking. Anyone who can read English and copy a prompt into an AI can run it. The pushback is almost always status-anxiety dressed up as competence-claim; the answer is "the rotation includes you, and the prompts work for any role — that's the whole point."

The one exception: if the rotation owner is genuinely overloaded that week (production outage, parental leave, etc.), swap with the next person on the schedule. Don't skip.

// 06 — The brain-rot warning signs

The reset is preventive maintenance. Some weeks it's not enough — the brain is decaying faster than 15 Friday minutes can fix. Watch for these four symptoms. Each has a specific intervention; none of them is "just run more resets."

"Is the reset enough?" — the decision tree

How to tell whether the weekly reset is sufficient or you need the heavier brain-refresh sprint:

Three or four "yes" answers means the weekly reset is doing its job. Two or fewer means you have specific symptoms (matched above) to address — not "do more resets." More reset doesn't fix any of these failure modes; the right intervention does.

When to escalate beyond the reset

Two situations call for stopping the reset cadence entirely and running something different:

• Re-org or major team change. When more than 30% of the team has changed roles or composition in a quarter, pause the weekly reset and run a 4-hour brain refresh sprint. Everyone audits their slice, the foundational files get rebuilt against the new reality, and then the weekly reset resumes against an accurate base. Running the reset against an outdated foundation just compounds drift.
• New product line or customer segment. When the team starts working on something genuinely new — a different product, a new customer tier, a parallel codebase — spin up a fresh active/project-*.md with full context rather than letting the new work bleed into existing files. The weekly reset on the existing brain continues unchanged; the new project gets its own bootstrap from T01/T02. Cleaner separation, less cross-contamination.

// 07 — Common questions

"What if Friday is genuinely impossible most weeks?"

Pick a different day and commit to it. The Friday convention exists because it pairs with end-of-week reflection naturally, but Monday-morning works (especially for teams in distributed timezones where Friday is half the team's weekend) and Wednesday-afternoon works too. The day matters less than the consistency. What doesn't work is "whenever someone has time" — that becomes "never."

"Can the AI just run all five tasks autonomously?"

Mostly yes — but the human-in-the-loop step is load-bearing. The promotion prompt produces a proposed diff to decisions.md; the rotation owner reviewing that diff is what catches the case where the AI promoted an open question that shouldn't be a decision yet (still genuinely open, the AI just found surface evidence and pattern-matched). Same for dead-context: the AI produces the candidates list; the rotation owner is what catches the file that's been unread for 30 days but is about to become urgent (project starting next sprint). Review is 30 seconds per task. Skip it and the brain starts making subtly wrong decisions for you.

"Our team is 3 people, do we still need rotation?"

Yes, but a lighter version. Three-person teams rotate every month instead of every two weeks — each person owns the reset for ~4 consecutive weeks. The bus-factor logic still applies (any one of three can be sick, on vacation, or leave) and the "different eyes find different gaps" benefit is even stronger on a small team where any single perspective dominates. The handoff is the same 5-minute walkthrough.

"Our team is 30+ people, does this scale?"

The reset doesn't scale linearly past about 10 people on one shared brain. Above that, the right pattern is sub-team brains — each functional pod (5–8 people) maintains its own team-brain/, and a thin org-brain/ at the parent level holds cross-pod identity, decisions, and cross-pollination digests. Each sub-team runs its own weekly reset; the org-brain gets a monthly reset run by an engineering-leadership rotation. Same prompts, different scope.

"What tools work best for the rotation owner?"

Any AI tool that can read a folder of markdown files works. Practical recommendations:

• Filesystem-aware tools (Claude Code, Cursor, Windsurf) — best for the dead-context pruner because they have native access to file metadata and the session access log. Strongly recommended for tech-lead and architect rotations.
• Shared-Project tools (Claude Team Projects, ChatGPT Team Projects, NotebookLM) — work fine for promotion, state refresh, and cross-pollination. Dead-context pruning is approximate (you derive access patterns from project-history rather than a live log). Good for BA / PM / Support rotations.
• Any chat with the brain attached — M365 Copilot pointed at a SharePoint folder, Gemini pointed at a Drive folder, Claude with a one-shot folder upload. Works for the simpler tasks (promotion, state refresh). Use the heavier-tool fallback for cross-pollination and pruning.

"Should the digest be public to the whole company?"

The cross-pollination digest is internal to the team by default. Two exceptions worth considering: (1) adjacent teams (your sister pod, the platform team you depend on) often benefit from seeing your digest; share it weekly in a cross-team channel. (2) Leadership sees real value in the digest as a low-friction status read — what's the team learning, what's surfacing — without you preparing anything bespoke. Forward the Friday digest to your manager as a 30-second status note. Most managers will quietly stop asking for separate status updates within a month.

// What "alive" looks like at month 6

A team brain that's been getting the weekly reset for six months looks measurably different from one that hasn't. Concrete signals you can audit at the half-year mark:

• decisions.md has 25–50 ADRs — one to two promotions per Friday, accumulated. The Opens section is small (under 10 entries) and every one has a blocked-on tag.
• active/ contains only currently-relevant projects. Roughly the same file count as month-1, despite the team having shipped 8–15 projects in between — because completed work moved to archive/ instead of accumulating.
• New hires onboard in <15 minutes (per T03's drill) without anyone walking them through context. The brain answers their questions on its own.
• The cross-pollination digest has a track record — you can point at 10–25 items that led to concrete adjacent-role actions over the six months. The team doesn't have to remember those wins individually; they're written down.
• The rotation has cycled at least twice. Every role has run the reset multiple times. No one person is irreplaceable on brain-maintenance grounds.

These aren't aspirational. They're what you get for 15 minutes a week. The compounding is the point.

// Key takeaways