Asset Manifest

Asset Manifest

Use this skill to make produced files auditable before QA or delivery. It records what exists, where it came from, what should be excluded, and what the next role can trust.

Language Policy

Public instructions and installation guidance stay in English. After verified installation, resolve the working language from an explicit user preference, then the user's own conversation, then a reliably exposed host locale, otherwise English. Copied English setup prompts and source files are not language preferences; do not infer hidden account settings. Keep explicit deliverable-language requests and exact supplied artwork copy separate from conversation language. Do not translate or rewrite public source files to localize a session.

When To Use

Use this skill when:

• Produced files, drafts, prompts, exports, or source materials need a traceable file list.
• QA needs a clear allowlist, exclusion list, version note, or source summary.
• Delivery would be risky without knowing which files are final, rejected, duplicated, or temporary.

Do not use this skill to review creative quality, rewrite assets, upload files, or decide final acceptance.

For explicitly requested separate static-design components, use component/version handoffs and their manifest template. Track selected versions, full project copy, dependencies and assembly limitations without turning an ordinary poster into a layered workflow.

Inputs

Required:

• file_list: files or folders to inventory.
• source_notes: origin of important files, including user-provided inputs, generated outputs, or edited derivatives.
• acceptance_criteria: what makes an asset eligible for QA or delivery.

Optional:

• version_notes: naming, revision, or export notes.
• checksums: use when reproducibility or audit strength matters.
• exclusions: files that must never be delivered or packaged.

Outputs

Produce an Asset Manifest with:

• managed file list, version labels, and source traceability
• excluded files with reasons
• missing or ambiguous files
• checksum or reproducibility notes when useful
• continuity carriers and accepted output references when assets are part of a generated sequence
• handoff notes for qa-iteration or delivery-documentation

Process

1. Inspect the requested files and classify them as source, working, final candidate, rejected, cache, or metadata.
2. Record only reviewable assets and explicit exclusions.
3. For generated sequences, record the actual continuity carrier used by each dependent request and identify which outputs have been accepted for rewrite-forward.
4. Preserve relative paths when possible so the manifest remains portable.
5. Flag missing source context, uncertain versions, or files that need human confirmation.
6. Hand off only files that can be explained and traced.

Decision Rules

• Prefer a smaller reviewed allowlist over a broad folder dump.
• Treat generated outputs as final candidates only after they pass the requested QA gate.
• Include checksums when files will be transferred, archived, or compared across machines.
• Keep manifest language factual; do not add creative approval language.

Guardrails

• Do not include secrets, credentials, private cloud links, local-only sensitive paths, or user-private notes.
• Do not include metadata sidecars, caches, logs, backups, temporary files, or hidden operating-system files as workflow assets.
• Do not upload, publish, compress, or delete files.
• Do not approve assets for delivery without qa-iteration when generated assets exist.

Handoff

Review gate: asset_manifest_fit.

Hand off to qa-iteration with:

• file_list
• source_traceability
• continuity_carriers
• accepted_output_refs
• excluded_files
• acceptance_criteria
• open_questions

Hand off to delivery-documentation only after QA identifies accepted assets.

QA Checklist

• Every included file has a role and source note.
• Final candidates are separated from working files and exclusions.
• Exclusions explain why the file is not deliverable.
• Paths are portable and public-safe.
• Continuity carriers and accepted output references are factual, request-bound, and not inferred from planned states.
• The manifest does not contain hidden metadata, caches, secrets, or private links.
• Open questions are explicit instead of hidden in prose.