---
name: manage-personal-productivity-wiki
description: Onboard users, build, adopt, ingest, reconcile, query, audit, repair, migrate, and maintain a human-readable personal productivity wiki in Obsidian-compatible Open Knowledge Format (OKF) v0.2. Use for personal or business knowledge systems that turn meetings, contacts, notes, presentations, content work, and curated learning sources into durable decisions, projects, reusable knowledge, and artifacts, including source comparisons and consequential knowledge gaps. Do not use as a task manager, calendar, CRM, document store, or indiscriminate note archive.
---

# Manage Personal Productivity Wiki

Maintain a personal operating model, not a digital attic. Optimize for the human's next decision and the LLM's next reliable retrieval.

## Hold the line

1. **Privacy boundaries precede taxonomy.** Separate personal, business, and deliberately shareable knowledge by audience and access risk before choosing folders or tags. A folder is not a security boundary.
2. **The wiki is not every system.** Tasks belong in a task manager, time commitments in a calendar, relationship pipelines in a CRM, binaries in document storage, and raw evidence in immutable source roots. Link those systems; do not clone them.
3. **Evidence is upstream.** Never edit raw notes, messages, transcripts, files, or snapshots. A derived page never becomes evidence through repetition.
4. **Ingest means reconcile.** Compare new evidence with the current model; confirm, extend, contest, supersede, or discard.
5. **One claim, one canonical home.** Link to it from projects, people, and artifacts. Do not copy “context” until it forks truth.
6. **Meetings are inputs.** Preserve a meeting as a `Source`; route its decisions, commitments, relationship context, and reusable ideas to their canonical homes.
7. **Pages must pay rent.** Create a page only when it improves a recurring decision, a bounded outcome, a relationship, reusable knowledge, a repeatable procedure, or a consequential artifact.
8. **Human readability is a constraint.** Use plain Markdown, descriptive titles, concise current-state-first writing, and scannable indexes. Keep Obsidian graphs, plugins, and caches non-canonical.
9. **Keep uncertainty lossless.** Distinguish source-backed fact, explicit user statement, decision, inference, contested claim, and unknown.
10. **Never profile by stealth.** Do not infer sensitive traits, personality, health, intent, or relationship state from weak signals. Contacts are contextual relationship aids, not dossiers.
11. **Review is semantic.** Weekly review changes beliefs, decisions, project framing, and reuse opportunities; it does not produce status prose for its own sake.
12. **Make mechanics deterministic.** Generate indexes, validate structure, inspect freshness, and log mutations with the bundled script. Keep search indexes and embeddings disposable.

## Orient

1. Locate the OKF bundle root: prefer `index.md` with `okf_version`, then `meta/policy.md`.
2. If no wiki or no valid `meta/policy.md` exists, read [onboarding.md](references/onboarding.md) and [architecture.md](references/architecture.md), then start the guided onboarding interview. Do not initialize, import, or write semantic pages before the user approves the proposed baseline.
3. If a governed wiki exists, read `meta/policy.md`, the root index, the human-facing `home.md` if present, and only the relevant child indexes.
4. Identify the access domain and active mode:
   - `read-only`: answer or audit without writes;
   - `reviewed`: write within policy, but leave sensitive claims, sharing, cross-domain movement, conflict resolution, and binding commitments for explicit review; use by default;
   - `autonomous`: permit bounded maintenance while retaining all privacy, provenance, and review gates.
5. Honor repository instructions, access controls, and the user's actual systems of record before wiki policy.

## Route narrowly

| Intent | Load | Act |
| --- | --- | --- |
| No wiki exists or a new user needs onboarding | [onboarding.md](references/onboarding.md), [architecture.md](references/architecture.md) | Interview the user in small stages, propose the operating baseline, obtain explicit approval, then initialize and pilot one real workflow. |
| Design or initialize an approved system | [architecture.md](references/architecture.md), [page-model.md](references/page-model.md), [format.md](references/format.md) | Apply the approved access boundaries, initialize one or more bundles, then tailor their policies and human home pages. |
| Ingest a meeting, note, message, contact update, or file | [workflows.md](references/workflows.md), [page-model.md](references/page-model.md) | Preserve evidence, produce a change map, update the minimal canonical set, and route tasks or appointments to their actual systems. |
| Learn a topic from saved sources, compare wiki evidence, or identify knowledge gaps | [learning-loop.md](references/learning-loop.md), [workflows.md](references/workflows.md) | Curate around real questions, reconcile across sources, answer with evidence, and identify the next useful evidence need. |
| Organize presentations or social content | [use-cases.md](references/use-cases.md), [page-model.md](references/page-model.md) | Separate reusable knowledge from the `Artifact`; keep the binary or published item in its source system. |
| Review projects or personal operations | [workflows.md](references/workflows.md), [architecture.md](references/architecture.md) | Reconcile outcomes, decisions, open questions, due reviews, and system links without recreating a task list. |
| Query the wiki | [workflows.md](references/workflows.md) | Navigate index-first, reopen direct evidence for consequential claims, and answer without writing unless requested. |
| Adopt, migrate, audit, or repair an Obsidian vault | [format.md](references/format.md), [workflows.md](references/workflows.md) | Inventory before rewriting; preserve useful paths; separate evidence, knowledge, navigation, and caches; validate incrementally. |

Load only the references needed for the active intent.

## Onboard before first write

When the target has no governed wiki, onboarding is mandatory:

1. Conduct the phased interview from [onboarding.md](references/onboarding.md) in the user's preferred language, asking no more than three related questions per turn.
2. Keep interview notes ephemeral until ownership, privacy, and capture boundaries are understood.
3. Separate confirmed user statements, agent proposals, unknowns, and excluded topics.
4. Present a concise baseline covering purpose, non-goals, bundle boundaries, systems of record, seed pages, the first pilot, review gates, and exact requested writes.
5. Obtain explicit approval for bundle creation, evidence capture, seed sources, and any external access or cross-domain movement.
6. Only then run initialization and one end-to-end pilot. Validate and ask the user to review the resulting baseline before scaling.

Do not turn onboarding into a life inventory, personality assessment, taxonomy workshop, connector authorization, or bulk migration.

## Apply the boundary decision

- If personal and business material have different employers, legal duties, sync providers, collaborators, retention rules, or sharing audiences, use separate OKF bundles and usually separate Obsidian vaults.
- If the same owner, device, sync policy, and audience apply, one bundle may use explicit `domain` and `sensitivity` fields. Do not claim that those fields enforce access.
- Put only deliberately sanitized, reusable knowledge in a `Commons` bundle. Personal and business bundles may consume Commons; Commons must not depend on sensitive pages.
- Never move or publish content across a boundary merely because it is useful. Require review and create a sanitized destination representation with its own provenance.

## Apply the creation gate

Before creating a non-`Source` page, require at least one:

- a recurring reader question with no canonical home;
- a bounded outcome with decisions or constraints that must survive its task list;
- a decision, policy, procedure, preference, or commitment that will change future behavior;
- a synthesis that reconciles multiple evidence items;
- a consequential unresolved question;
- a person or organization referenced by multiple durable pages or interactions;
- a presentation, post, document, or other artifact whose intent, evidence, or reuse will matter after delivery.

Otherwise update an existing page, leave the item in its source system, or discard it. Merge one-hop stubs. Split only when sections serve independent reader jobs.

## Process evidence into action

Use this flow without conflating its stages:

```text
capture/system of record -> immutable evidence -> reconciled wiki
                                             -> task/calendar/CRM commitment
                                             -> presentation/post/other artifact
```

- Record a durable commitment or decision in the wiki when future interpretation matters; put the executable next action in the task system.
- Link the task, event, CRM record, file, or published post when it is a stable reference. Do not mirror its volatile fields.
- Make artifacts consume canonical knowledge. Feed new evidence from an artifact or its reception back through normal ingestion; never treat the artifact page as independent proof.

## Write transactionally

1. Establish the reader job, access domain, authority order, and systems of record.
2. Read the canonical pages and their direct evidence before editing.
3. Name the minimal affected page set and the external records that only need links.
4. Preserve unknown frontmatter, stable paths, valid content, and unresolved conflict.
5. Attribute load-bearing factual claims with footnotes keyed to `sources[].id`. Label inference explicitly.
6. Refresh `generated`; remove invalidated verification after material edits. Never fabricate human verification or source metadata.
7. Update useful reciprocal navigation, regenerate affected indexes, prepend one semantic log entry, and validate.
8. Report changed beliefs or behavior, routed commitments, privacy decisions, remaining conflicts, and validation results.

## Query with epistemic discipline

- Treat the wiki as a retrieval map, not automatic truth.
- Trace unstable, disputed, sensitive, high-impact, or surprising claims to direct evidence.
- State what is established, inferred, contested, unknown, and possibly stale.
- If the wiki misses, abstain or research only within authorization. Persist research only when writing was requested.
- Promote a useful answer only through the normal creation and boundary gates. Chat output is never a `Source` unless the conversation itself is the evidence and has a stable reference.

## Use the deterministic tool

Run with Python 3.9 or newer:

```text
python scripts/wiki.py init <bundle> --profile personal-productivity --title "Personal" --purpose "Improve recurring decisions, outcomes, and reuse without duplicating operational systems." --language de --source-root ../raw
python scripts/wiki.py index <bundle>
python scripts/wiki.py index <bundle> --check
python scripts/wiki.py validate <bundle> --strict
python scripts/wiki.py stats <bundle>
python scripts/wiki.py log <bundle> --kind Review --message "Reconciled active projects and routed meeting commitments."
```

Do not auto-install dependencies. The script uses the standard library and validates the managed subset; report parser limits explicitly.