ai-dating（艾约会）

Ai Dating

This skill supports dating and matchmaking workflows through curl against the dating HTTP API. It helps users create a profile, define partner preferences, check matching results, reveal contact details, and submit post-chat reviews.

Trigger Conditions

Trigger this skill when any of the following intents appear:

1. The user explicitly asks to make friends, find a partner, date, or run a match.
2. The user provides personal information and asks the system to find a matching person.
3. The user describes partner preferences (for example gender, height, city, personality, hobbies) and asks for matching.

Language Alignment Rule

When constructing curl request bodies, prefer the same language as the user for updateProfile, createTask, and updateTask, especially for all free-text fields and labels (for example taskName, characterText, hobbyText, abilityText, intention, preferred*Text, and comment).

• Do not translate user-provided content unless the user explicitly requests translation.
• Keep language style consistent across one request payload. If the user speaks Chinese, prefer Chinese text values in JSON fields.
• Keep gender and preferredContactChannel as the backend's fixed English values. Do not translate them into Chinese or other languages.

Update Commands

When users ask to update this skill, run:

npx skills add 1asdwz/ai-dating

Note: This skill uses direct curl requests. Do not invoke dating-cli.

External Service And Requirements

• This skill sends user data to an external dating backend over the network.
• The default backend in this repository is https://api.aidating.top unless AIDATING_BASE_URL is set to another value.
• Review the endpoint owner, privacy policy, retention policy, and organizational approval before installing or using this skill.
• Require outbound network access, curl, and preferably jq for response parsing.
• Do not use this skill in environments that forbid sending personal data, photos, profile traits, or contact information to third-party services.

Privacy And Consent Rules

• Tell the user which external base URL will receive their data before the first write request if that is not already obvious from context.
• Obtain explicit user consent before sending profile details, photos, location, contact handles, or other sensitive personal data to the external backend.
• Prefer data minimization. Only send fields the user has provided and that are necessary for the current action.
• Do not require contact fields on first use. Treat phone numbers, email addresses, social handles, exact location, and uploaded photos as especially sensitive.
• Do not upload photos or reveal contact details automatically. Perform those actions only after the user explicitly asks or clearly consents.
• Do not send highly sensitive documents or identifiers such as government IDs, banking details, passwords, private chat logs, or unrelated secrets.
• If the user only asks for advice, brainstorming, or preference drafting, help locally first and avoid network calls until the user asks to execute the workflow.

Standard Execution Flow (AI Agent)

1. Check skill and curl availability.

Then verify:

curl --version

If the user or environment provides a base URL, use it. Otherwise, in this repository default to:

BASE_URL="${AIDATING_BASE_URL%/}"
if [ -z "$BASE_URL" ]; then
  BASE_URL="https://api.aidating.top"
fi

1. Prepare local request context (full examples).

BODY_PATH="$(pwd)/.tmp_dating_body.json"
AUTH=""
TASK_ID=""
MATCH_ID=""

1. Register or login (full parameter examples).

Before register or login, confirm the user wants to use the external dating backend and understands that account data will be stored there.

cat > "$BODY_PATH" <<'JSON'
{"username":"amy_2026"}
JSON

REGISTER_RESP=$(curl -sS -X POST "$BASE_URL/register" \
  -H "Content-Type: application/json" \
  --data-binary @"$BODY_PATH")

cat > "$BODY_PATH" <<'JSON'
{"username":"amy_2026","password":"123456"}
JSON

LOGIN_RESP=$(curl -sS -X POST "$BASE_URL/login" \
  -H "Content-Type: application/json" \
  --data-binary @"$BODY_PATH")

AUTH=$(printf '%s' "$LOGIN_RESP" | jq -r '.data.tokenHead + .data.token')

Note: Build the Authorization header as <tokenHead><token> exactly as returned. In this codebase tokenHead already includes the trailing space (Bearer ).

1. Parse user self-description and update profile (full parameter example).

For updateProfile, prefer the user's language for descriptive text fields. Keep gender in the backend's fixed English vocabulary. Before updateProfile, send only the fields required for the current task and confirm before including photos, exact location, or contact handles.

UPLOAD1_RESP=$(curl -sS -X POST "$BASE_URL/minio/upload" \
  -H "Authorization: $AUTH" \
  -F "file=@./photos/amy-1.jpg")

UPLOAD2_RESP=$(curl -sS -X POST "$BASE_URL/minio/upload" \
  -H "Authorization: $AUTH" \
  -F "file=@./photos/amy-2.jpg")

UPLOAD1_URL=$(printf '%s' "$UPLOAD1_RESP" | jq -r '.data.url')
UPLOAD2_URL=$(printf '%s' "$UPLOAD2_RESP" | jq -r '.data.url')

cat > "$BODY_PATH" <<JSON
{
  "gender": "male",
  "birthday": "1998-08-08",
  "heightCm": 180,
  "weightKg": 72,
  "characterText": "sincere, steady, humorous",
  "hobbyText": "badminton, travel, photography",
  "abilityText": "cooking, communication, English",
  "major": "Computer Science",
  "nationality": "China",
  "country": "China",
  "province": "Zhejiang",
  "city": "Hangzhou",
  "addressDetail": "Xihu District",
  "email": "amy@example.com",
  "phone": "13800000000",
  "telegram": "amy_tg",
  "wechat": "amy_wechat",
  "whatsapp": "amy_wa",
  "signalChat": "amy_signal",
  "line": "amy_line",
  "snapchat": "amy_snap",
  "instagram": "amy_ins",
  "facebook": "amy_fb",
  "otherContacts": {
    "xiaohongshu": "amy_xhs",
    "discord": "amy#1234"
  },
  "photoUrls": ["$UPLOAD1_URL", "$UPLOAD2_URL"]
}
JSON

curl -sS -X PUT "$BASE_URL/member-profile" \
  -H "Authorization: $AUTH" \
  -H "Content-Type: application/json" \
  --data-binary @"$BODY_PATH"

Note: The parameters for profile update, task create, and task update are optional. For the sake of user experience, do not force users to enter personal information on first use.

1. To receive matching success notifications promptly, strongly recommend registering an email address through the profile update payload.

1. Parse partner preferences and create a match task (full parameter example). Users do not need to fill in all fields. Only provide the information they have available.

For createTask, prefer the user's language for taskName and all descriptive criteria text fields. Keep preferredContactChannel in the backend's fixed English vocabulary. Before createTask, confirm that the user wants to submit these matching criteria to the external backend.

cat > "$BODY_PATH" <<'JSON'
{
  "taskName": "Find partner in Hangzhou",
  "criteria": {
    "preferredGenderFilter": { "eq": "female" },
    "preferredHeightFilter": { "gte": 165, "lte": 178 },
    "preferredCityFilter": { "eq": "Hangzhou" },
    "preferredNationalityFilter": { "eq": "China" },
    "preferredEducationFilter": { "contains": "Bachelor" },
    "preferredOccupationFilter": { "contains": "Product" },
    "preferredEducationStage": "Bachelor or above",
    "preferredOccupationKeyword": "Product Manager",
    "preferredHobbyText": "reading, travel",
    "preferredCharacterText": "kind, positive",
    "preferredAbilityText": "strong communication",
    "intention": "long-term relationship",
    "preferredContactChannel": "telegram"
  }
}
JSON

TASK_RESP=$(curl -sS -X POST "$BASE_URL/match-tasks" \
  -H "Authorization: $AUTH" \
  -H "Content-Type: application/json" \
  --data-binary @"$BODY_PATH")

TASK_ID=$(printf '%s' "$TASK_RESP" | jq -r '.data.taskId')

*EmbeddingMinScore means the minimum semantic similarity threshold for embedding matching. Default recommendation is to leave it unset. When omitted in task creation, the backend defaults semantic text thresholds to 0.0 where applicable.

Write API response note: task create returns the created task payload, including taskId and taskName.

1. If an unfinished taskId already exists and the user did not explicitly request a new task, update the existing task (full parameter example).

For updateTask, prefer the user's language for taskName and all descriptive criteria text fields. Keep preferredContactChannel in the backend's fixed English vocabulary. Before updateTask, confirm that the user wants to overwrite the remote task criteria with the new values.

cat > "$BODY_PATH" <<'JSON'
{
  "taskName": "Update criteria - Hangzhou/Shanghai",
  "criteria": {
    "preferredGenderFilter": { "eq": "female" },
    "preferredHeightFilter": { "gte": 163, "lte": 180 },
    "preferredCityFilter": { "in": ["Hangzhou", "Shanghai"] },
    "preferredHobbyText": "reading, travel, sports",
    "preferredCharacterText": "independent, optimistic",
    "preferredAbilityText": "communication and collaboration",
    "intention": "serious relationship with marriage plan",
    "preferredContactChannel": "wechat"
  }
}
JSON

curl -sS -X POST "$BASE_URL/match-tasks/$TASK_ID/update" \
  -H "Authorization: $AUTH" \
  -H "Content-Type: application/json" \
  --data-binary @"$BODY_PATH"

Note: Keep taskId from the create response. The public API does not expose a list endpoint for recovering an unknown active task.

1. Query task status (full parameter example).

curl -sS "$BASE_URL/match-tasks/$TASK_ID" \
  -H "Authorization: $AUTH"

1. Execute check to inspect match results (full parameter example, paginated).

CHECK_RESP=$(curl -sS "$BASE_URL/match-tasks/$TASK_ID/check?page=1" \
  -H "Authorization: $AUTH")

Each page returns 10 candidates. Use the page query parameter to fetch subsequent pages when needed. check candidate items include photoUrls (user uploaded image URL array), which should be used when explaining and selecting candidates. If the result is NO_RESULT_RETRY_NOW, call check again as needed. If the result is MATCH_FOUND, continue to contact reveal.

Note: Candidates' photos should be shown to users first. You should automatically select candidates that better meet the user's requirements, reducing the user's information burden.

1. Select the best candidate from match results and reveal contact details (full parameter example).

Only call reveal-contact after the user explicitly chooses that candidate and agrees to retrieve contact information from the external backend.

MATCH_ID="<selected matchId from check response>"

REVEAL_RESP=$(curl -sS -X POST "$BASE_URL/match-results/$MATCH_ID/reveal-contact" \
  -H "Authorization: $AUTH")

1. Submit review when needed (full parameter example).

cat > "$BODY_PATH" <<'JSON'
{
  "rating": 5,
  "comment": "Good communication and aligned values"
}
JSON

curl -sS -X POST "$BASE_URL/match-results/$MATCH_ID/reviews" \
  -H "Authorization: $AUTH" \
  -H "Content-Type: application/json" \
  --data-binary @"$BODY_PATH"

1. Optional commands (full parameter examples).

curl -sS -X POST "$BASE_URL/match-tasks/$TASK_ID/stop" \
  -H "Authorization: $AUTH"

curl -sS -X POST "$BASE_URL/logout" \
  -H "Authorization: $AUTH"

Reference

For detailed field-level behavior, validation rules, and response structures:

• references/curl-api-operations.md