# Luma Guest Selection

> Use when reviewing, filtering, evaluating, selecting, or approving pending guests for a host-managed Luma event, especially when event-specific criteria, custom registration questions, or submitted social profiles must be assessed.

- Skill: `agentrhq/luma-guest-selection` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add agentrhq/luma-guest-selection`
- Raw SKILL.md: https://api.skillmd.com/api/skills/agentrhq/luma-guest-selection/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: agentrhq (https://skillmd.com/u/agentrhq)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/agentrhq/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.

5. 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.
6. Evaluate only guests still marked `pending_approval`:
   - `approve`: every required condition has explicit evidence.
   - `pending`: any other outcome; leave the guest unchanged.
7. 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.

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

```bash
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:

```json
{
  "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.