Notion DB Hygiene (Live)
Trackers rot: entries stuck "In progress" for months, blank owners, the same project logged twice, statuses that no longer match reality. In Claude Cowork this skill reads the real database, finds the rot, and — after showing you the plan — fixes it in place, so the tracker becomes trustworthy again.
What This Skill Produces
- The hygiene report — stale entries, missing required fields, duplicates, and status drift, each with the row and the issue
- The fix plan — exactly what would change (archive, fill, merge, re-status), shown before anything is written
- The applied fixes — executed via the connector after confirmation, with an undo-friendly change log
Required Inputs
Ask for these if not provided:
- The database — a Notion DB link or name
- The rules — what "stale" means (e.g. no update in 30 days), which fields are required, what the valid statuses are
- Autonomy — preview-only, or apply after confirmation (default: preview then apply on approval)
Framework: The Four Rots
- Stale — no update past the threshold while still "active" → nudge, re-status, or archive.
- Incomplete — required fields blank (owner, due date, status) → fill or flag.
- Duplicate — same entity logged more than once → merge, keep the richer record.
- Status drift — status contradicts reality (done items still open, shipped items "in progress") → correct.
Execution (Cowork)
- Read the DB — via the Notion connector, pull all rows and the schema (properties, required fields, status options).
- Audit — apply the four rots using the user's rules; group findings by type; detect duplicates by title/key similarity, not exact match only.
- Preview the plan — present every proposed change (row → field → old → new, or archive/merge) and wait for confirmation. Never write first.
- Apply — on approval, execute via the connector: update fields, set statuses, archive stale rows, merge duplicates (keeping the richer record and its links). Log each change.
- Emit the artifact — the hygiene report + the applied change log, plus anything left for the human.
Guardrails: never write before the preview is approved; never hard-delete — archive; when merging, preserve the richer record and its relations; respect the user's rules over defaults; if the connector is unauthorised, produce the report and plan without applying, and say so.
Output Format
A Notion Hygiene Report:
Summary
R rows · S stale · I incomplete · D duplicates · X status-drift
Findings & plan
Applied (after approval)
Left for you
- rows needing a human call (e.g. which duplicate is canonical)
Quality Checks
Anti-Patterns
- Editing before showing the plan. Preview, confirm, then apply.
- Deleting rows instead of archiving.
- Exact-match-only dedupe that misses "Acme" vs "Acme Corp".
- Guessing owners/dates to fill blanks — flag them for the human.
Example Trigger Phrases
- "Clean up my Notion projects database in Cowork."
- "Find the stale and duplicate entries in my tracker and fix them."
- "My Notion CRM is a mess — audit it and show me the plan."
- "Tidy my tasks DB: fill blanks, archive dead rows, fix statuses."
1---2name: notion-db-hygiene3description: Clean the user's REAL Notion database — read it, find stale/incomplete/duplicate entries, and fix them via the connector — not advice on keeping Notion tidy. Use when asked to clean up my Notion database, my tracker is a mess, find the stale and duplicate entries, or tidy my projects DB in Cowork. Reads the database via the Notion connector, audits for staleness / missing required fields / duplicates / status drift, and produces a hygiene-report artifact plus the applied fixes (with a preview-and-confirm step before any change).4---5
6# Notion DB Hygiene (Live)
7
8Trackers rot: entries stuck "In progress" for months, blank owners, the same project logged twice, statuses that no longer match reality. In Claude Cowork this skill reads the *real* database, finds the rot, and — after showing you the plan — fixes it in place, so the tracker becomes trustworthy again.
9
10## What This Skill Produces
11
12- **The hygiene report** — stale entries, missing required fields, duplicates, and status drift, each with the row and the issue
13- **The fix plan** — exactly what would change (archive, fill, merge, re-status), shown before anything is written
14- **The applied fixes** — executed via the connector after confirmation, with an undo-friendly change log
15
16## Required Inputs
17
18Ask for these if not provided:
19- **The database** — a Notion DB link or name
20- **The rules** — what "stale" means (e.g. no update in 30 days), which fields are required, what the valid statuses are
21- **Autonomy** — preview-only, or apply after confirmation (default: preview then apply on approval)
22
23## Framework: The Four Rots
24
251. **Stale** — no update past the threshold while still "active" → nudge, re-status, or archive.
262. **Incomplete** — required fields blank (owner, due date, status) → fill or flag.
273. **Duplicate** — same entity logged more than once → merge, keep the richer record.
284. **Status drift** — status contradicts reality (done items still open, shipped items "in progress") → correct.
29
30## Execution (Cowork)
31
321. **Read the DB** — via the Notion connector, pull all rows and the schema (properties, required fields, status options).
332. **Audit** — apply the four rots using the user's rules; group findings by type; detect duplicates by title/key similarity, not exact match only.
343. **Preview the plan** — present every proposed change (row → field → old → new, or archive/merge) and **wait for confirmation**. Never write first.
354. **Apply** — on approval, execute via the connector: update fields, set statuses, archive stale rows, merge duplicates (keeping the richer record and its links). Log each change.
365. **Emit the artifact** — the hygiene report + the applied change log, plus anything left for the human.
37
38Guardrails: never write before the preview is approved; never hard-delete — archive; when merging, preserve the richer record and its relations; respect the user's rules over defaults; if the connector is unauthorised, produce the report and plan without applying, and say so.
39
40## Output Format
41
42A **Notion Hygiene Report**:
43
44### Summary
45`R rows · S stale · I incomplete · D duplicates · X status-drift`
46
47### Findings & plan
48| Row | Issue | Proposed fix |
49|---|---|---|
50
51### Applied (after approval)
52| Row | Change made |
53|---|---|
54
55### Left for you
56- rows needing a human call (e.g. which duplicate is canonical)
57
58## Quality Checks
59- [ ] Nothing was written before the preview was approved
60- [ ] No hard deletes — stale rows archived, not destroyed
61- [ ] Merges kept the richer record and its relations
62- [ ] "Stale/required/valid status" followed the user's rules, not defaults
63- [ ] The change log lets the user see (and reverse) every edit
64
65## Anti-Patterns
66- **Editing before showing the plan.** Preview, confirm, then apply.
67- **Deleting rows** instead of archiving.
68- **Exact-match-only dedupe** that misses "Acme" vs "Acme Corp".
69- **Guessing owners/dates** to fill blanks — flag them for the human.
70
71## Example Trigger Phrases
72- "Clean up my Notion projects database in Cowork."
73- "Find the stale and duplicate entries in my tracker and fix them."
74- "My Notion CRM is a mess — audit it and show me the plan."
75- "Tidy my tasks DB: fill blanks, archive dead rows, fix statuses."