Household Document Binder

Inspiration: Most households have one person who keeps the paperwork. If that person is ill, travelling or gone, nobody else knows where the insurance policy, the vehicle registration or the warranty cards are. Trustworthy's 2025 Family Resilience Index found that only 52% of parents said they could quickly retrieve vital documents in an emergency. AARP reports that 56% of US adults over 50 have no important documents saved digitally.

A pre-release Macwelt test of the iDX6011 Pro noted that the built-in assistant could not yet list one thing across many text documents. A binder is that kind of job.

What it does: Household Document Binder is a Skill for the UGOS assistant. The owner names one or more folders and a destination. The Skill asks consent, then reads the papers and writes one Markdown binder: what was found, what is coming up, what was not found in these folders, and what needs a look.

It does three things ordinary document chat does not. It reports absence, by comparing what it found with a household checklist. It writes a kept file for someone other than the owner. And it can be re-run: a refresh lists what changed since the last binder. Account, policy and identity numbers are cut to their last four characters. It moves, renames and deletes nothing.

How it was built: The Skill is Markdown only: SKILL.md and five reference files. It delegates to four experts: file-agent lists files, document-agent reads them, photo-agent reads photographed papers as a fallback, and knowledge-agent saves the binder after platform approval. The UGOS Skill Creation Tool's capability catalog and static checker were used to verify each capability and the package.

Claude (through Claude Code) was used for research, for shortlisting ideas for me to choose from, and for drafting and checking. I chose the idea from that shortlist and reviewed the materials before submitting.

Challenges: Round 1 has no NAS access. Nothing has run on a NAS yet. The catalog is checked against a source release, not a deployed system, so approval behaviour and file-type support are unknown until testing. I designed for that: the five delegation states are handled by name, and an empty result is reported as empty, never widened.

What was learned: Limits help: 200 files per run, batches of 40 and 20 images for text recognition keep each step checkable. The binder points to sensitive papers, so masking and consent are part of the design, not add-ons.

What is next: If selected, I will build a synthetic fixture of about 25 papers for "the Sample household" and run three tests on the NAS: a build, a refresh, and an edge case with unreadable files, an ambiguous date and a missing will. I will then fix what the NAS shows.