Personal Knowledge System Design Prompt

Public field comparison

Personal Knowledge System Prompt

Personal Knowledge System Design Prompt

Design a lightweight knowledge system for notes, ideas, references, reviews, and retrieval habits.

Design a lightweight, evidence-based personal knowledge system for capturing, organizing, retrieving, reviewing, and safely migrating notes and references.

—

Create a practical personal knowledge system tailored to your tools, information sources, retrieval needs, privacy constraints, and available maintenance time.

Requirements Clarification
Output Quality Review
Review Checklist Building
Implementation Planning

Designing a personal knowledge system from an existing note inventory
Reducing capture friction, tag sprawl, duplicate notes, and review debt
Planning a reversible migration between note-taking tools
Defining note types, metadata, retrieval paths, and review routines
Testing whether a knowledge system meets retrieval and privacy requirements

Goal or task
Current context
Constraints
Files, data, or examples
Definition of done

Knowledge goals
Current tools and note inventory
Capture sources and content types
Constraints and privacy requirements
Retrieval scenarios
Review capacity
Success criteria

Replace every bracketed placeholder before running. Give the model enough context to inspect assumptions, ask only blocking questions, and produce a concrete deliverable. For code prompts, include relevant files, errors, logs, and test commands.

In Claude, replace every bracketed variable with your own information. Provide relevant source materials and task evidence, such as sanitized note samples, folder and tag inventories, templates, exports, search examples, retrieval timings, tool documentation, privacy rules, and review-time estimates. Then run the prompt. If sensitive records are involved, redact them or provide metadata-only samples and review Claude’s proposed approval gates before taking action.

Use this when you need a production-ready knowledge management result in Productivity, not a generic brainstorm. The expected output should include findings, implementation steps, risks, and verification checks.

A researcher has notes split across Apple Notes, Obsidian, browser bookmarks, and project documents. They provide a sanitized inventory, common retrieval scenarios, privacy limits, and two hours per month for maintenance. Claude produces a tools-aware architecture, content schema, capture and review procedures, a reversible pilot migration, and an evidence-based acceptance matrix without claiming that any migration or test has occurred.

Advanced

Advanced

Claude

Claude

knowledge management

knowledge management

claude
productivity
pkm
notes

claude
productivity
personal knowledge management
note-taking
information-retrieval
knowledge systems

Personal Knowledge System Prompt | AMO.ng

Personal Knowledge System Design Prompt | AMO.ng

Design a lightweight knowledge system for notes, ideas, references, reviews, and retrieval habits.

Design a practical personal knowledge system with capture, retrieval, review, privacy, migration, and verification controls.

Prompt-body line comparison

Removed Added Unchanged context

−Act as a senior Productivity specialist using Claude. Your task is: [Goal or task].
+Design a personal knowledge system from the information below.
 
−Context:
−- Current situation: [Current context]
−- Constraints: [Constraints]
−- Available materials: [Files, data, examples, URLs, logs, notes]
−- Success criteria: [Definition of done]
+Inputs
+- Knowledge goals: [Knowledge goals]
+- Current tools and note inventory: [Current tools and note inventory]
+- Capture sources and content types: [Capture sources and content types]
+- Constraints and privacy requirements: [Constraints and privacy requirements]
+- Retrieval scenarios: [Retrieval scenarios]
+- Review capacity: [Review capacity]
+- Success criteria: [Success criteria]
 
−Workflow:
−1. Restate the objective in operational terms and identify any missing information that would block a reliable answer.
−2. Make reasonable assumptions only when they are low risk, and label them clearly.
−3. Produce the main deliverable for "Personal Knowledge System Prompt" with enough detail that a skilled operator can execute it immediately.
−4. Include edge cases, failure modes, dependencies, and tradeoffs that a junior prompt would usually miss.
−5. Add a verification checklist with concrete tests, review questions, metrics, or acceptance criteria.
−6. End with the smallest safe next action.
+Operating boundaries
+- Analyze only the materials supplied in this conversation. You may compare uploaded note samples, folder or tag listings, exports, templates, and usage observations, but do not imply access to note applications, cloud drives, accounts, browsing history, or integrations unless their contents or verified outputs are provided.
+- Produce a design and implementation plan, not an executed migration. Do not create, move, delete, publish, synchronize, or reclassify records outside this response.
+- Require explicit human approval before any bulk import, deletion, destructive deduplication, permission change, public sharing, automated synchronization, or retention-policy change.
+- Treat private journals, credentials, health information, financial records, client material, and third-party personal data as sensitive. Recommend data minimization, appropriate access controls, backups, and redaction. Do not reproduce sensitive note content when metadata or a short sanitized example is sufficient.
+- Never describe a system as implemented, migrated, tested, verified, backed up, or approved unless supplied evidence proves that action occurred. Keep proposed, observed, executed, blocked, and unverified states distinct.
 
−Output format:
−- Executive summary
−- Detailed plan or implementation
−- Risks and mitigations
−- Verification checklist
−- Next action
+Input triage and evidence rules
+1. First determine whether the inputs identify at least one knowledge goal, the current storage situation, a realistic retrieval scenario, material constraints, and available review capacity. These are blocking prerequisites for a tailored final design.
+2. If a blocking prerequisite is absent or conflicting, ask no more than five focused questions and stop before prescribing a final architecture. Explain why each answer affects the design.
+3. If only optional details are absent, continue with a bounded draft. Mark each assumption, explain its likely impact, and provide alternatives where the choice could materially change capture effort, retrieval quality, privacy, portability, or maintenance burden.
+4. Classify material statements as supplied fact, observation from supplied artifacts, assumption, recommendation, conflict, or unknown. Do not infer actual habits merely from folder names, templates, or stated intentions.
+5. When note samples or inventory data are supplied, cite them by filename, item label, or user-provided identifier. If no inspectable artifacts are supplied, say that the design is based on self-reported context rather than an audited collection.
 
−Do not give generic advice. Optimize for a production-quality knowledge management outcome.
+Design workflow
+1. Translate the knowledge goals into concrete jobs such as remembering commitments, developing ideas, supporting projects, preserving sources, preparing writing, or retrieving decisions. For each job, define the triggering situation, desired information, retrieval path, and acceptable time-to-find.
+2. Diagnose the current system for capture friction, inbox accumulation, duplicate notes, inconsistent naming, tag sprawl, orphaned notes, broken links, source ambiguity, stale project material, mixed private and shareable content, over-classification, and review debt. Distinguish evidenced problems from plausible risks.
+3. Select the smallest architecture that supports the retrieval scenarios. Compare folders, tags, links, search, saved queries, indexes or maps of content, and project or area views. Use methods such as PARA, Zettelkasten, or evergreen notes only where their mechanics solve a stated need; do not adopt a method by brand alone.
+4. Define a content model. Specify necessary note types, such as inbox items, source notes, durable concept notes, project notes, decisions, meeting notes, and indexes. For each retained type, state its purpose, minimum metadata, naming convention, lifecycle, link behavior, archive rule, and example. Avoid metadata that has no retrieval or governance function.
+5. Define the operating flow from capture through clarification, linking or filing, use, review, archive, and deletion. Include fast capture rules, a processing threshold, duplicate handling, source attribution, task-versus-note separation, and a fallback for items that cannot yet be classified.
+6. Design retrieval before optimizing organization. Map each important retrieval scenario to a primary route and a fallback route. Include search vocabulary, filters, links, indexes, dates, project context, or source metadata as appropriate.
+7. Set review routines that fit the stated capacity. Separate inbox processing, active-project review, periodic knowledge gardening, link or source maintenance, and archive review. Assign a trigger, time box, input, action, and completion condition to each routine.
+8. Evaluate trade-offs explicitly: capture speed versus metadata quality, flexible search versus controlled vocabulary, linking versus folder maintenance, local ownership versus cross-device convenience, automation versus transparency, and comprehensive migration versus gradual adoption.
+9. Propose a reversible pilot before broad migration. Use a representative but non-sensitive subset, preserve originals, define backup and export checks, maintain an exception log, and specify rollback steps. Prefer copy-first migration and quarantine over irreversible deletion or merging.
+10. Define verification tests and acceptance evidence. If tests have not been run, provide expected observations and mark actual observations as unavailable rather than fabricating results.
+
+Required deliverable
+Produce the following sections in order:
+
+1. Input and evidence register
+A table with: item, status, classification, source or artifact reference, confidence, conflict or limitation, and design consequence.
+
+2. Knowledge jobs and retrieval requirements
+A table with: knowledge job, trigger, target information, primary retrieval path, fallback path, target time-to-find, privacy level, and acceptance condition.
+
+3. Current-state diagnosis
+List evidenced pain points separately from unverified risks. For each, provide affected material, likely cause, consequence, and whether it should be fixed now, monitored, or accepted.
+
+4. Recommended system architecture
+Describe the proposed tools-neutral structure and, where the supplied tools permit, map it to their actual features. Include containers, note types, metadata schema, naming rules, linking and tagging policy, search or index strategy, archive boundaries, and task-management boundary. Explain rejected alternatives and trade-offs. Do not claim a feature exists unless the supplied materials establish it; label feature assumptions for confirmation.
+
+5. Content model specification
+Provide a table with: note type, purpose, creation trigger, required fields, optional fields, naming example, linking rule, review rule, archive or deletion rule, and sensitivity considerations.
+
+6. Capture-to-retrieval operating procedure
+Give executable procedures for capture, inbox processing, source attribution, synthesis, linking or filing, retrieval, review, archiving, duplicate resolution, and handling unknown items. Include decision rules rather than vague advice.
+
+7. Review calendar and maintenance budget
+Provide daily or event-driven, weekly, monthly, and quarterly routines only where justified. For each, state trigger, maximum duration, inputs, actions, completion signal, and what to defer when capacity is exceeded.
+
+8. Pilot and migration plan
+Define scope, sample-selection rationale, prerequisites, backup and export evidence, copy-first steps, mapping rules, duplicate policy, exception log, rollback procedure, human approval gates, and stop conditions. Stop conditions must include missing backups, unexpected data loss, permission exposure, unreadable exports, material record-count discrepancies, or unresolved handling of sensitive content.
+
+9. Verification and acceptance matrix
+Include: test, method, expected observation, actual observation, evidence required, status, and remediation. Cover at minimum capture speed, inbox processing, retrieval for each priority scenario, source traceability, duplicate handling, orphan detection, sensitive-content access, export readability, backup recovery sampling, review workload, and rollback. Use not run or unavailable for actual observations without execution evidence.
+
+10. Decision and uncertainty log
+Record major decisions, supplied facts, assumptions, unresolved conflicts, unknowns, approval owner, and the consequence of leaving each unresolved.
+
+11. Handoff
+State the smallest safe next action, the person who must authorize it, the materials needed, and the evidence that would permit advancement from proposed to pilot-ready or from pilot-ready to accepted.