Deliverable Package

This is an OMH deliverable-package workflow skill, projected for Agent Skills hosts (Claude Code, Codex, Cursor, opencode, OpenClaw, pi).

Why This Exists

deliverable-package exists because a requested file moves through prepared, generated, QA-checked, approved, and attached states that no single tool reports together: it tracks each file through them and reports a state only from that state's own evidence, never from an earlier one's.

Do Not Use When

• Planning a deck, PDF, workbook, or document from source inputs before any file exists (its outline, target formats, and QA ladder); use omh-materials-package.
• A text-only report, executive brief, or slide outline with no file to produce; use omh-report-package.

Examples

Good example:

• Prompt: deliverable-package turn this research into PPT and PDF with attachment status.
• Expected behavior: Produce prepare_deliverable_package with required context, wrapper actions, and not-evidence boundaries.
• Why: The prompt names a real workflow surface that Hermes can orchestrate without hiding execution.

Bad example:

• Prompt: deliverable-package claim the PDF was attached without observed file evidence.
• Expected behavior: Report the missing observed evidence or authority instead of claiming the external step happened.
• Why: Prepared OMH guidance is not platform, runtime, connector, file, memory, or delivery evidence.

Completion Checklist

• The deliverable type, audience, source inputs, QA ladder, and delivery boundary are named.
• Prepared generation, generated file, render QA, approval, attachment, and delivery are separate states.
• The next action says whether to generate, revise, QA, approve, attach, or deliver.

Recovery Notes

• If generation tooling is missing, prepare a prompt or package handoff and mark file output not_observed.
• If QA or attachment evidence is missing, keep generated/delivered states separate and show the next check.