Airtable Participants Skill

Purpose

Query retreat participant data from the Ceremonia Airtable base. This is the
authoritative source of truth for who receives emails and SMS messages.
Access is read-only by default — record modifications require Austin's
explicit instruction per change.

Required Setup

Ensure AIRTABLEAPIKEY is set in .env.

You will also need:

• - Base ID: [VERIFY — find in Airtable API docs at airtable.com/developers or ask Austin]
• Table name: [VERIFY — confirm the participant table name with Austin]

Store confirmed values in TOOLS.md and MEMORY.md once verified.

Expected Data Structure

Participant records are expected to have at minimum these fields:

[VERIFY actual field names with Austin on first use — update this section when confirmed]

Common Query Patterns

Get all active participants (for newsletter sends)

Get participants with phone numbers (for SMS campaigns)

Get participant count by status

Get participants by tag

Note: Airtable paginates at 100 records. Use the offset parameter from the response to fetch subsequent pages:

curl -s "https://api.airtable.com/v0/{BASE_ID}/{TABLE_NAME}?offset={OFFSET_TOKEN}" \
  -H "Authorization: Bearer $AIRTABLE_API_KEY" | jq .

Behavior Rules

• - Read-only by default — never PATCH, POST, or DELETE Airtable records without Austin's explicit instruction per operation
• When building a recipient list for email or SMS: always filter out records where retreat_status is 'unsubscribed'
• Never include email addresses or phone numbers in Slack messages — summarize counts and segments only
• If a query returns 0 results unexpectedly: report the issue to Austin rather than sending to an empty list
• Paginate all list queries fully — do not report partial counts or build partial recipient lists
• If Airtable API returns an error: surface it to Austin immediately with the error code and message

Record Modification (Requires Austin Approval)

When Austin instructs a record change (e.g., marking someone unsubscribed, updating last_contact):

1. 1. Confirm the specific change with Austin before executing
2. Execute the PATCH request
3. Log the change in memory/logs/crm-writes/YYYY-MM-DD.md with: record name/email, field changed, old value, new value, Austin's instruction timestamp

Example Invocations

• - "How many active participants do we have?"
• "Get the email list for the February retreat attendees"
• "Who attended the last three retreats?"
• "How many people have phone numbers in the system?"
• "Mark [name] as unsubscribed" (requires Austin approval)
• "Pull the full active participant list for the newsletter"
• "How many people joined since January?"