dreamina-video-evaluator

Dreamina Video Evaluator

Evaluate only, and only after measurement. This Skill produces shot_evaluation.schema.json content and nothing else.

Example request

Use dreamina-video-evaluator for shot S03 attempt 1 after reading its measured
gates and approved design. If retry is necessary, select only the next request
fingerprint already present in the activated batch allowance.

Capability Boundary Description

✅ Can do

• Read the measured clip gates for one shot attempt.
• Judge whether the clip satisfies the design intent.
• Return accepted, a prequoted retry, rejected, or manual_review.

⚠ Requires material

• A measured artifact with its SHA-256 and deterministic gate results.
• The design version the attempt was generated from.

❌ Out of scope

• Do not produce shot_annotation.schema.json. Shot semantics belong to dreamina-shot-annotator.
• Do not re-measure media or override the measured gates.
• Do not request more attempts than the batch quote already covers.
• Do not resubmit. retry must reference an attempt the quote already enumerated.

Workflow

1. Receive the measured gates for exactly one shot attempt.
2. Compare against the design intent for that shot.
3. Return the evaluation with one of the four decisions, and for retry the prequoted attempt.

Never do

• Never accept a clip whose measured gates failed.
• Never invent an attempt beyond the quote.
• Never blur the line between design intent and acceptance verdict.

When to use

Load this skill when the user needs to perform generation or write operations after clarifying inputs, budget, and delivery constraints . First extract the goal, inputs, constraints, delivery format, and acceptance criteria from the request; the description summary is: Use when judging generated Dreamina shot clips against measured gates, producing shot_evaluation.schema.json content only.

Rules

• Read before write: first confirm the current state and actual capabilities, then perform actions that change external state.
• Least privilege: use only the files, tools, accounts, and network scope required to complete the current step.
• Evidence first: when run results, resource IDs, versions, hashes, or test outputs are missing, explicitly mark them as NOT_VERIFIED。
• Idempotency first: retain request identifiers and stage status; when results are unclear, query first rather than blindly retrying.
• Privacy and security: logs, examples, receipts, and error messages must not contain tokens, cookies, keys, or personally sensitive data.

Workflow

Step 1: Clarify intent

Confirm whether this skill matches the goal; if it is only an adjacent need, hand it off to a more precise skill.

Step 2: Perform prechecks

Validate inputs, model/tool capabilities, output paths, budget caps, and approval status; if any key condition is unknown, stop at the read-only stage.

Step 3: Form a plan

List the tools to be called, the objects that will change, the success criteria, and the safe exit method after failure.

Step 4: Execute actions

Execute once as approved and record the request identifier; for ambiguous results, query first instead of resubmitting; retain an associable status or receipt for every external call.

Step 5: Verify delivery

Verify artifact existence, format, hash/identifier, cost status, and quality gates, and state facts, inferences, and unverified items separately.

Validation checklist

• The skill trigger conditions match the user's intent, and adjacent tasks were not misrouted to this skill.
• Inputs, target objects, versions, and output locations are all clear, and no guessed values were used in place of required values.
• All write, paid, publish, or irreversible actions are within the scope of user authorization.
• Results have been verified with independent checks; "command succeeded" or "file exists" alone does not count as complete acceptance.
• Output includes actual evidence, failed/skipped items, remaining risks, and executable next steps.

Gotchas

1. Treating a plan as a result: a document or prompt is not the same as actual execution; the actual execution level must be stated.
2. Incorrect retry: a timeout or lost response may already have produced remote state; query first before deciding whether to retry.
3. Implicit scope expansion: batch, full-scale, publish, overwrite, and paid operations are not natural extensions of ordinary reads and writes.
4. Version drift: when referencing external resources, record the version, tag, or commit; do not treat a mutable branch as release evidence.
5. Stale evidence: caches, old screenshots, and historical tests cannot prove the current environment; refresh key evidence before delivery.

Non-applicability and boundaries

Paid, publishing, coverage, uploading, or external writes must use the explicit authorization of the current task; do not automatically expand the number of times and the budget. If the request requires a different skill, do not copy its content; hand off by skill name and preserve the current task context.

Progressive disclosure

• When input/output, state, and authorization points need to be determined, read references/workflow-contract.md。
• When pre-delivery self-check is needed, read references/validation-checklist.md。
• When encountering timeouts, partial success, or recovery scenarios, read references/error-recovery.md。
• For first run, denial of privilege escalation, and failure recovery, refer respectively to examples/happy-path.md、examples/boundary-refusal.md、examples/failure-recovery.md。