Skip to main content

create-a-personal-records-system

Design a maintainable workflow for capturing, naming, reviewing, retaining, and retrieving personal records. Use when documents repeatedly become lost, duplicated, or outdated.

Source facts

Repository
protosphinx/sphinxstack
Last source activity
July 29, 2026 at 13:55
Detected SKILL.md language
English
Stars
3
Forks
0

Install options

The review-first prompt is selected by default. You can switch to a direct command or download a local copy.

Review the source files

Read SKILL.md and any companion files shown by SkillsMP before deciding whether to install.

File Explorer
2 files

Showing SKILL.md

SKILL.md
Source instructions · Read-only preview
name
create-a-personal-records-system
category
start
description
Design a maintainable workflow for capturing, naming, reviewing, retaining, and retrieving personal records. Use when documents repeatedly become lost, duplicated, or outdated.
# create-a-personal-records-system Build the lifecycle, not just folders. Every incoming record needs a route from capture to decision, storage, update, and eventual disposal. ## When to use - Use when multiple people, devices, paper files, inboxes, or life domains create recurring recordkeeping friction. - Use `organize-important-documents` for a one-time cleanup; use this for the ongoing system. ## Procedure 1. List record-producing channels, users, devices, physical locations, recurring tasks, and failure points. 2. Define a small set of record classes and the decisions each class supports. 3. Create one capture inbox per practical channel and one regular processing cadence. 4. Specify naming, dates, ownership, version status, source, and stable identifiers. 5. Define the system of record for each class and rules for links versus copies. 6. Add retention, review, renewal, and destruction rules with an “unknown—review” state. 7. Design access by role and need; separate daily convenience from high-sensitivity storage. 8. Add encrypted backup, restore testing, offline or offsite resilience, and emergency handoff. 9. Migrate a representative sample before bulk filing and measure retrieval success. 10. Document a one-page operating guide and review the system after real use. ## Failure plan - Do not duplicate sensitive records across tools merely for convenience. - If two systems both appear authoritative, choose one or document a synchronization owner. - Do not automate destruction without review for holds, disputes, or legal requirements. - Reduce categories when filing decisions remain inconsistent. ## Done - Capture, processing, storage, review, backup, retrieval, and disposal have owners and rules - Each record class has one clear system of record - A second authorized person can use the guide and pass a retrieval-and-restore test
View on GitHub