Check design-ticket completeness before intake

Why use this

1. A design team may receive a ticket that appears actionable but lacks the reference, objective or decision owner needed to begin. Discovering those omissions only after intake creates avoidable clarification work and ambiguous expectations.

2. This job could identify missing information before a person commits the ticket to the queue. A precise gap report helps the requester supply what is needed without treating a checklist result as approval of the design work itself.

Why an agent / simpler alternative

Useful judgment

Interpret whether supplied references answer the brief and distinguish genuinely missing context from an optional field.

Simpler alternative

Use required form fields when completeness can be checked mechanically.

Unsuitable when

The task would reject work automatically or assess design quality from missing-field signals alone.

Proposed inputs

1. Name

   Intake checklist

   Owner

   Design operations owner

   Minimum scope

   Required context and conditional exceptions

   Quality check

   Define which fields are mandatory for each request type

2. Name

   Ticket snapshot

   Owner

   Requester or queue owner

   Minimum scope

   Brief, references and stated owner

   Quality check

   Distinguish absent links from inaccessible ones

Access and setup — proposed or unknown

Proposed minimum

1. Read copied tickets and approved reference metadata; create private findings without ticket mutations.

Compatibility unknowns

1. Current ticket/design connectors, link visibility and exact runtime compatibility are unknown.

External actions requiring approval

1. Posting questions, changing ticket status, assigning owners or expanding reference access requires approval.

Expected deliverable and review checks

Proposed artifact

Per-ticket completeness findings with missing item, reason, evidence and a proposed clarification question.

Critical checks

1. Apply the relevant request-type checklist; avoid duplicate questions; label access failures separately from missing information.

Missing output evidence

This overlay adds no new output inspection, execution or validation; consult the referenced canonical source outcome limits.

Failure signals and proposed responses

1. Signal

   A Figma link exists but points to the wrong work

   Why it matters

   Presence alone creates a false pass

   Proposed response

   Flag relevance as unverified and ask for the intended reference.

2. Signal

   A private link is labelled absent

   Why it matters

   The requester is asked to fix the wrong problem

   Proposed response

   Report inaccessible reference and preserve the existing URL.

Effort and cost — unknown

Setup work

1. Agree mandatory fields and permitted exceptions.

Ongoing review

1. Review disputed findings and update intake rules.

Unknowns

1. Checklist coverage, connector permissions, review volume and service costs are unknown.

First check — proposed, unexecuted

Status

proposed_unexecuted

Synthetic fixture

Invent three tickets: complete, missing a required reference and containing an inaccessible reference; use fictional URLs.

Acceptance checks

1. Differentiate missing from inaccessible; cite the applicable rule; create no rejection, assignment or message.

Stop conditions

1. Stop if the checklist is unclear or verification would require new permissions.

Limits

1. Completeness findings do not establish project priority, feasibility, design quality or readiness for an automatic queue transition.