What it does
Incident Evidence Binder is a Skill for UGOS that builds one organized evidence binder for a single incident, such as a water leak, car damage, a break-in attempt or a deposit dispute. It works from camera events, photos and documents that are already on the NAS. It also reads the user's own insurance policy or lease, lists the proof that document asks for, and shows which of those items the NAS holds and which are still missing.
Why this idea
Evidence for a claim is usually spread across camera history, phone photos and PDFs, and people often learn what the insurer wanted only after they file. A NAS already keeps all three kinds of material in one place, so the gathering can happen where the data lives and nothing has to be uploaded anywhere.
How it works
Build mode:
- The Skill repeats the incident window and sources back to the user and waits for a yes.
- It resolves the user's directory and picks a free folder name.
- It lists cameras and queries camera events for the window.
- It searches photos in the incident window and in an optional earlier baseline window, and gets a neutral description and capture time for each.
- It finds documents, reads the policy or lease requirements with page quotes, and extracts receipt and estimate amounts.
- It shows a timeline, a requirement checklist and a gap list, then waits for approval.
- After approval it creates a new folder, copies (never moves) the approved files, compares the SHA-256 value of every original and copy, and saves a timeline file and a hash manifest. A neutral statement draft and tags are offered as options.
Verify mode recomputes the hashes of an existing binder later and reports unchanged, changed, missing and added files. It writes nothing.
The Skill never deletes or edits originals, never identifies people or vehicles, and never sends anything outside the NAS.
How it was built
The package is Markdown only and follows the Uliya Skill Development Standard: a SKILL.md entry point and four linked reference pages (capability map, binder layout, test plan, disclosure). The parent Skill only sends delegate commands to file-agent, security-monitor-agent, photo-agent, document-agent and knowledge-agent, and passes each real result to the next step. The capability catalog (version 2.0.0) and the static checker from the UGREEN Skill Developer Package were used to design and check it. The submitted package reports zero errors and zero warnings in that checker.
AI tools used
An AI agent (Aside, running Anthropic Claude models) read the rules and the Starter Kit, proposed the concept, drafted the Skill files, this page and the proposal, ran the checker, and rendered the PDF. The concept and the wording were AI assisted from start to finish. The same disclosure is in the package.
Status
Built: the Skill package and the proposal. Not done: nothing has been run on a UGREEN NAS, because Round 1 has no NAS access. If this becomes a finalist entry, the testing day covers three runs on synthetic data: a full build, a verify run on a deliberately altered binder, and an empty-scope run that must report zero matches and create nothing. Open questions for the NAS are whether camera snapshots can be saved as files instead of temporary references, and how approval prompts appear for writes.
Third-party components
UGREEN Skill Developer Package, uliya-skill-kit 0.7.3-en (terms published by UGREEN with the kit): used locally for the capability catalog and static checker, not included in the package. Node.js 26.7.0 (MIT) ran the checker. Playwright 1.64.1 (Apache-2.0) with Chromium (BSD-3-Clause) rendered the proposal PDF. Repository: MIT license.
Log in or sign up for Devpost to join the conversation.