Xu-125/portfolio-collection-skill

Portfolio Collection / Build and Maintain Searchable Collections

Turn dispersed work into one browsable collection; keep its real data source maintainable.

1. Confirm Scope

Classify the request as design discussion, build, incremental update, repair, or schedule. Do not implement during a discussion-only request.

Inspect provided links/files and existing artifacts before asking. Confirm only material unknowns, preferably in one batch of up to three questions:

• Collection name, audience and authorized sources; distinguish public links, private source documents and user uploads.
• Existing application/data source versus new build; shared maintenance, required editable fields and access model.
• Categories, visual reference and required title/cover behavior. For recurring work, obtain frequency, exact local time, time zone and update destination separately.

Use the existing project's style and chosen stack. For a new collection without a reference, propose a restrained, content-first layout before costly implementation. Never impose a particular brand, platform, six-category taxonomy or daily schedule.

2. Route by Available Capabilities

Discover and read the host's relevant skills before using their tooling.

• Use Browser Use by default for website/feed collection: observe → navigate → inspect post → record evidence. Read exact tool schemas; never guess connector names or flags.
• Use a host-approved authenticated connector for private documents/messages. Search private history only when explicitly requested or necessary within the user's authorized scope.
• Use the host's web/app builder for interactive applications. A shared collection needs shared persistence and server-side authorization; local storage is not a substitute.
• A one-off static showcase can use the host's HTML skill. Explain its lack of shared editing or automatic collection.
• Use the host's spreadsheet/database skill when the chosen source is a sheet, Base or database.
• Use the host scheduler only after schedule approval and successful configuration. A written prompt is not a scheduled task.

If capabilities are unavailable, finish independent work and identify the exact missing capability. Do not silently replace a shared app with a local demo. This package is an agent workflow, not a standalone application or crawler.

3. Collect and Reconcile

For build/update/repair, read references/data-and-maintenance.md.

1. Re-read the real current data source and snapshot existing records before any change. Locate the actual read/write path, not an unused table or source copy.
2. Use an exact user-provided source link or verified official account identity. Do not substitute another account, repost or generic search result for the requested source.
3. Record the original URL verbatim, true title, verified cover, media type, real date if available, categories and evidence. Keep uncertain fields marked unknown.
4. Obtain article covers from article cover/share metadata, not an avatar, decorative body image or screenshot. Use actual platform video covers; use a video frame only if authorized as a fallback. Save durable assets and preserve provenance.
5. Match an entry's display title to the agreed policy. Default article titles to verbatim originals. Short video labels may summarize verified source text only when permitted; keep the original and the short label separately. Never call a description an audio transcript.
6. Deduplicate by verified source identity, then manually reconcile corroborated same-work cross-platform versions. Store multiple sources/categories on one entry, not duplicate cards.
7. Find private originals only when requested; read candidate content to distinguish final drafts from briefs, schedules or interview outlines. Preserve original document permissions.
8. Apply only authorized field-level changes, protect manual edits, and verify the stored result. If a write times out, inspect actual state before retrying.

4. Present the Collection

For UI work, read references/presentation-and-access.md.

• Use authentic covers, a clear search field and the user-approved categories. Separate media-format filters from topic categories.
• Let each card take its natural height. For mixed horizontal/vertical media, use genuine shortest-column masonry or an equivalent verified layout. Do not stretch a short article card to a tall video card.
• Derive ratios from the brief or original assets. Optional recommendation: 2.35:1 for wide articles and 3:4 for portrait videos; not an invariant for all projects.
• Keep a concise title and necessary actions. Do not add summaries, dates, metrics or badges the user did not request.
• Make card-body clicks open the public work URL. A separate private-original button opens the source document; neither that button nor like controls should trigger the card-body link.
• Apply confirmed ordering; if a category is prioritized, sort that group and the rest by real dates independently. Do not fabricate dates or reset old dates to look recent.
• Offer a simple owner-maintenance entry backed by the same data source. Show recognizable titles and only the chosen editable fields.

5. Isolate Public Use and Private Administration

Require a server-verified owner identity for all administrative reads/writes. A hidden button or any logged-in account is not authorization. Keep owner identity/configuration off public clients. Anonymous readers receive published public fields only; keep contact data and private document contents out of public responses. Refer to the access tests in the presentation reference.

Publishing, internet visibility and application code are separate layers. Ask for precise scope before enabling public sharing. Never open a private original's permissions simply because the collection is public. Use the host's authorized deployment path; if publication must be done by the user, bring them to the verified development/publish entry and stop before that action.

6. Schedule Incremental Maintenance

For scheduling, read references/recurring-update.md. Confirm the schedule and target, resolve existing jobs to avoid duplicates, and use the actual scheduler. Keep the collection identity, account sources, overlap window, protected fields and failure/report behavior in the job instructions. Record successful checkpoints only after verified writes. Report unsupported or auth-blocked sources rather than silently skipping them.

7. Verify and Deliver

Read references/verification.md before declaring completion. The optional local checker is:

python3 scripts/validate_manifest.py path/to/manifest.json
python3 scripts/validate_manifest.py path/to/after.json --baseline path/to/before.json --allow-update cover,original_urls --require-cover-proof

These commands perform local integrity checks only; they do not fetch pages, prove a live image loads, authenticate users, write a database or schedule work. Read the reference for the manifest shape and evidence rules.

Report the real number added, duplicate candidates skipped, originals linked, actual cover-load coverage, blockers and whether preview/production differ. Verify every claimed item; label sample-only checks. Deliver the current artifact using the host's delivery mechanism. Do not re-deliver temporary evidence, private logs or secrets.

Optional Prompts

Use references/prompts.md for bilingual build/update prompts. Fill only user-approved values; unresolved material parameters require clarification, not invented defaults. Keep private configuration and credentials outside this reusable package.