notion-personal-space-audit

When to use

Use when the user asks to audit a Notion personal workspace or page, inspect secondary pages or inline databases, explain why the space is hard to use, decide where ambiguous materials such as sensitive analysis reports belong, or design a safer and more searchable information architecture.

Steps

Steps 2–4 are [Deterministic] (Notion API calls); steps 1 and 5–11 are [LLM] analysis and synthesis.

1. [LLM] Confirm the target page URL and scope. Treat the task as read-only unless the user explicitly authorizes a structural change.
2. [Deterministic] Resolve the page ID from the URL and retrieve the page metadata.
3. [Deterministic] Recursively retrieve block children. Follow child_page blocks and query child_database rows; preserve the parent path, page title, block count, and last-edited time.
4. [Deterministic] Retrieve database schemas and record property names/types. Separate database rows from true navigation pages when interpreting the root layout.
5. [LLM] Build an inventory by content identity using references/audit-checklist.md: log/event, analysis report, raw transcript/source, long-form archive, plan, reading item, person record, life utility, or inbox item.
6. [LLM] Detect structural issues per the checklist: missing dashboard, mixed responsibilities, inconsistent naming, empty placeholder records, long reports inside short-log databases, stale plans without lifecycle status, and sensitive materials mixed with ordinary notes.
7. [LLM] Recommend a small functional top-level architecture. Include an inbox, current actions, sensitive-analysis area, cognition/inputs, memory/archive, life tools, and archive only when evidence supports each area.
8. [LLM] Map every major existing database or page to a proposed destination. For ambiguous content, state the rule explicitly: sensitive analysis reports belong in a separate high-sensitivity archive; short event logs retain event records; raw conversations remain source material and link to derived decisions.
9. [LLM] Recommend minimal shared fields: content type, domain, status, occurrence date, organization date, sensitivity, and relations. Do not force one schema onto all content types.
10. [LLM] Produce a concise Markdown report with evidence, signal-light findings, proposed tree, migration table, phased migration order, and a clear statement that no Notion content was changed.
11. [LLM] If the user explicitly authorizes structure creation, create only empty navigation pages and usage instructions after the audit. Never move, delete, rename, or rewrite existing content unless separately authorized.

Hard Rules

1. Read-only by default: no Notion write endpoint is called unless the user explicitly authorizes structure creation, and then only empty navigation pages.
2. Never move, delete, rename, or rewrite existing content as part of an audit or structure setup.
3. Never expose access tokens in reports, logs, or user-facing output.
4. Do not invent content the API did not return; mark inaccessible or uncertain areas explicitly.
5. Sensitive analysis reports are never classified as ordinary log events, and never merged into general archives.

Pitfalls

• Do not assume a page visible in the root snapshot is a standalone navigation page; inline database rows can appear as pages.
• Do not classify a sensitive analysis report as a log event merely because it concerns the same topic (emotions, relationships, health).
• Do not merge raw conversations, derived reports, and action plans into one record. Keep source, analysis, and action linked but distinct.
• Do not delete empty book/person placeholders during an audit. Put them in an archive or pending-review view first.
• Do not expose access tokens in reports, logs, or user-facing output.
• Do not modify Notion without explicit confirmation. The audit should produce a migration plan first.
• When structure creation is authorized, use idempotent title checks and create pages under the audited parent; do not move, delete, rename, or rewrite existing content as part of structure setup.
• Avoid inventing content that the API did not return. Mark inaccessible or uncertain areas explicitly.

Failure Handling

Scenario	Action
API returns 401/403 on a sub-page	Mark the branch as inaccessible; continue the audit on accessible areas; report the gap
Recursive crawl times out on a very large space	Crawl top two levels fully; sample deeper levels and state the sampling method
Database schema unreadable	Record the error and the visible properties; do not guess types
Ambiguous content cannot be classified	List it in a pending-review section with the ambiguity stated, rather than forcing a category
User requests in-audit deletion	Refuse; deletion is out of audit scope — produce the migration plan first

Output Format

# Notion Space Audit Report

## 1. Scope and crawl summary (pages / databases / rows, access gaps)
## 2. Current-state tree (with content-type labels)
## 3. Findings (signal-light: red blocks / yellow friction / green healthy patterns)
## 4. Proposed information architecture (top-level areas with one-sentence purpose)
## 5. Migration table (existing location → proposed destination, with rule for ambiguous items)
## 6. Phased migration order (low-risk first)
## 7. Declaration (no Notion content was changed during this audit)

Verification

• Confirm the recursive crawl completed and report the page/database/row counts.
• Confirm each root database has a schema inventory and row count.
• Confirm the report includes a direct answer for ambiguous materials, especially sensitive reports.
• Confirm no Notion write endpoint was called.
• Confirm the output file exists and names the inspected page, scope, findings, and migration plan.