luma-guest-selection

Luma Guest Selection

Core contract

Approve only pending guests who clearly satisfy the host's confirmed rubric. For every non-match, missing field, contradiction, unavailable profile, or uncertain identity, leave the guest unchanged. Never decline a guest.

Prerequisites

This skill uses the official Luma commands provided by Webcmd.

• Run node --version; Node.js 20 or newer is required.
• Run webcmd --version. If Webcmd is missing, ask before installing it globally with npm install -g @agentrhq/webcmd.
• When the agent runtime supports Webcmd skills, refresh them with webcmd skills install --provider codex and load webcmd:webcmd-usage before live Webcmd work. Otherwise use live --help output.
• Run webcmd luma --help to verify that the Luma commands are installed. If they are unavailable, follow the webcmd:webcmd-usage discovery order: check a complete Luma-filtered webcmd list -f json result, then, only if it is empty, run webcmd plugin search luma -f json. If a matching plugin is available, ask before installing its returned installSource with webcmd plugin install <installSource>, then rerun webcmd luma --help. If discovery fails or returns no match, stop and report it.
• Run webcmd doctor, then webcmd luma whoami -f json. If authentication is required, run webcmd luma login, follow its human handoff, and rerun whoami before continuing.

Workflow

1. List managed events with webcmd luma events -f json and have the host select the event.
2. Fetch the complete current pending_approval guest set with webcmd luma guests <eventId> --status pending_approval --limit <N> -f json. Stop on pagination, authentication, or shape errors; never evaluate a partial list.
3. Inspect standard fields, profiles, and arbitrary answers. Tell the host which evidence fields exist, then ask for approval criteria once. If criteria were already supplied, do not ask again.
4. Convert the request into required conditions, acceptable evidence, and missing-data handling.

Rubric confirmation

Restate the concrete rubric and wait for confirmation. Refuse protected-characteristic or sensitive-trait criteria and request event-relevant alternatives. Do not evaluate before confirmation and never loosen a rubric because few guests match.

1. For submitted external profiles, use webcmd:webcmd-usage to choose available read-only Webcmd commands. Keep this skill independent of any particular research command. Use only an exact submitted URL or handle; never search by name. Never connect, follow, message, comment, like, or modify an external account. Confirm the profile matches the submitted identifier and record criterion-relevant claims with its source URL. Failed, private, rate-limited, or mismatched enrichment is uncertainty, never negative evidence.
2. Evaluate only guests still marked pending_approval:
   • approve: every required condition has explicit evidence.
   • pending: any other outcome; leave the guest unchanged.
3. Show the event name and ID, confirmed rubric, totals evaluated, proposed approval count, unchanged count, ambiguous count, and each proposed guest's name, guest ID, matched criteria, reason, and evidence provenance.

Batch execution confirmation

Wait for explicit confirmation of the displayed event, rubric, and exact guest set. Any change invalidates the confirmation. A request to reject non-matches does not expand V1; leave them unchanged.

1. Immediately re-fetch pending guests. Skip and report any guest whose status or relevant submitted data changed.
2. Approve only the remaining confirmed IDs, one at a time:

webcmd luma update-guest-status <eventId> <guestId> --status approved --confirm true -f json

Never retry an ambiguous write automatically. After execution, fetch guests again and verify every attempted approval. Report verified approvals, failures, concurrent-change skips, and all guests left unchanged.

Evidence record

Use this internal shape for every evaluated guest:

{
  "guestId": "gst-...",
  "decision": "approve|pending",
  "criteriaMatched": ["criterion"],
  "evidence": [
    {
      "claim": "criterion-relevant observation",
      "sourceType": "luma-answer|external-profile",
      "source": "field label or exact URL"
    }
  ],
  "reason": "concise explanation"
}

Stop conditions

• No management access, incomplete guest fetch, missing criteria, rejected rubric, rejected batch, unsafe criteria, or verification mismatch: stop without further writes.
• Zero matches: report zero and leave everyone unchanged; offer rubric revision without changing it automatically.
• Partial write failure: stop automatic progression and report exact attempted, verified, failed, and untouched guest IDs.

Common mistakes

• Treating missing evidence as failure: it means pending.
• Using social data that was not tied to an exact submitted URL or handle: discard it.
• Asking for criteria twice: ask once, then confirm the interpretation.
• Showing only scores: show criterion-level evidence and provenance.
• Assuming confirmation survives changed data: re-fetch and invalidate changed entries.