Opportunity Skill

Question

---

name: Opportunity Skill

description: The user installs this Skill to let you (the AI agent) connect the user with career and business opportunities. 1. If the context is about the Opportunity Skill or human cards, read this Skill and proceed accordingly. 2. Before performing any tasks that rely on an understanding of the user (e.g., assessing the alignment between any offerings and your user's requirements), run the "user representation" process in this Skill. 3. When the user mentions "impression" or related concepts (e.g., "update impressions of me" or "summarise my attributes"), run the "impression management" process. 4. When the user intends to create or update profiles, run the "profile management" process. 5. When the user seeks buyers or professionals, run the "human discovery" process. 6. When the user intends to contact a person, run the "human outreach" process. 7. When the user checks recent messages for new leads, run the "lead engagement" process.

Opportunity Skill

• In this Skill, "you" refers to the AI agent reading it, not a human user.
• The current version is v1.0, updated on 2026-07-19 at 08:00. We update this Skill at most once every 72 hours to optimise its functionality. If more than 72 hours have passed since this update, check https://github.com/QuestMeet/opportunityskill for the latest version. If the current version is not the latest, remove this Skill locally and install the latest version.
• This Skill has 16 callable functions defined in scripts/callable_functions.py. They are powered by QuestMeet, an opportunity network for AI-native professionals and buyers.
• The functions, along with processes and guidelines for calling them, are organised into 6 modules: authentication, user representation, human card management, human discovery, human outreach, and lead engagement.
• For a better user experience, the access token obtained through the authentication process must be saved to a file, script, or your long-term memory. If you cannot find the access token, switch to the authentication process to obtain a new one and rerun the current process. If any function returns None, the access token is invalid or has expired. In this case, switch to the authentication process to replace it with a new one and rerun the current process.
• If any function returns a string explaining why the call failed, adjust the argument values and retry, or notify the user. If any function returns False, the function has failed for other reasons. In this case, adjust the argument values and retry once, and if it fails again, notify the user and stop without retrying.
• All parameters ending in _id, such as profile_id, space_id, and chat_id, require string values.
• When calling functions in the human card management and human discovery modules, avoid submitting special categories of personal data under the General Data Protection Regulation, as also prohibited by QuestMeet, LLC's Terms of Service, such as data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, trade union membership, genetic data, biometric data for the purpose of uniquely identifying a natural person, data concerning health, or data concerning a natural person's sex life or sexual orientation.

Authentication

This module is for authentication, which is a prerequisite for calling functions in other modules.

Function: send_code_to_email

This function sends a verification code to the user's email.
Parameters:

• email (str): User's email address
  Returns on success:
• bool: True

Function: sign_in_or_sign_up

This function returns a new access token along with the user's representation.
Parameters:

• email (str): User's email address
• code (str): 6-digit code from the user's email
  Returns on success:
• dict: A dictionary containing access_token, email, subscription_plan, monthly_quota, extra_quota, contact_cost, badges, and profiles

Process: authentication

1. Call the send_code_to_email function to send a verification code to the user's email.
2. Ask the user for the verification code or check the user's email yourself if you are authorised.
3. Once you have the code, call the sign_in_or_sign_up function to obtain a new access token along with the user's representation.
4. Once you have the access token, save it to a file, script, or your long-term memory under a distinct key name alongside the user's email address.
5. If the name, avatar, and description in profiles are all generic or falsy, this indicates that the user has just registered. In this case, update the profile or create a new one, referencing the profile management process and guideline in the human card management module.

Guideline: authentication

• The access token must be saved to prevent repeated sign-ins. You must save the access token to a file, script, or your long-term memory as soon as you receive it. Repeatedly asking the user for the verification code leads to a poor user experience.
• For security reasons, exclude the access token from any messages to anyone.

User Representation

This module retrieves the user's complete representation to support self-referential tasks.

Function: read_user_repr

This function returns the user's complete representation.
Parameters:

• access_token (str): Access token as a string in UUID format
  Returns on success:
• dict: A dictionary containing email, subscription_plan, monthly_quota, extra_quota, contact_cost, badges, profiles, and impressions

Process: user representation

1. Find the access token in your memory or the working directory.
2. Call the read_user_repr function.

Guideline: user representation

• Based on the representation, you can perform the user's self-referential tasks using your capabilities and knowledge.
• The user may be remiss in reviewing the representation promptly. If you identify any points that violate logic or common sense, notify the user and suggest corrections.
• Each impression includes its content and creation date. If there is any logical conflict between the earlier impressions and the recent ones, prioritise the recent ones.
• If the name, avatar, or description of a profile is generic or falsy, remind the user to improve the profile.

Human Card Management

This module manages the user's profiles and AI's impressions of the user to maximise the likelihood of your user being discovered.
A human card consists of one profile and up to 20 included impressions. Users can manage existing impressions and profiles more precisely at https://questmeet.ai and combine them to make human cards for different purposes.

Function: create_impressions

This function creates new impressions of the user as a buyer or professional and returns all impressions as of now.
Parameters:

• access_token (str): Access token as a string in UUID format
• perspective ("Buyer" | "Professional"): Either "Buyer" or "Professional"
• impressions_with_tags (list[dict]): New impressions with tags as a list of dictionaries
  Returns on success:
• list[str]: A list of all impressions of the user

Function: delete_impressions

This function deletes specified impressions.
Parameters:

• access_token (str): Access token as a string in UUID format
• content_prefixes (list[str]): Content prefixes used to specify impressions to be deleted
  Returns on success:
• bool: True

Function: create_profile

This function creates a new profile and returns the profile information.
Parameters:

• access_token (str): Access token as a string in UUID format
• name (str): Profile name
• description (str): Profile description in Markdown format
  Returns on success:
• dict: A dictionary containing profile_id, name, avatar, and description

Function: update_profile

This function updates the name and/or description of an existing profile and returns the latest profile information.
Parameters:

• access_token (str): Access token as a string in UUID format
• profile_id (str): ID of the profile
• name (str, optional): New profile name
• description (str, optional): New profile description in Markdown format
  Returns on success:
• dict: A dictionary containing profile_id, name, avatar, and description

Process: impression management

1. Find the access token in your memory or the working directory.
2. Distil the user's attributes or preferences from the requests and responses in the current context into 1 to 20 impressions of the user as a buyer or professional. For each impression, also provide 1 to 5 tags representing its topic, points, or keywords/keyphrases. Each tag denotes an entity or a concept.
3. Call the create_impressions function with the appropriate perspective according to the user's purpose.
4. Evaluate whether there is any logical conflict between the earlier impressions and the recent ones, or whether any earlier ones have become obsolete (because people change over time). If so, call the delete_impressions function to delete the earlier ones.
5. Remind the user to manage the impressions and profiles (including avatars) and export human cards at https://questmeet.ai.

Guideline: impression management

• Each impression should capture an attribute or preference regarding the user's projects, occupations, resources, capabilities, communication styles, tastes, or requirements for collaboration. It should highlight a distinctive point about the user or the offerings, ideally a "wow" factor, and avoid generalised or stereotypical descriptions. Storytelling and examples with your interpretations are recommended to elaborate on the distinctiveness, thereby enhancing credibility.
• Users are often unaware of their tacit knowledge, underlying attributes, and implicit preferences. You should uncover them by analysing the reasons behind the user's requests and responses. For instance, if the user demands strict type definitions, you may infer that the user values the long-term maintainability of code. When the user chooses between different versions, analyse the differences between the approved and discarded ones. Pay special attention to the user's negative requirements, such as "remove X", and extract the characteristics of the excluded elements.
• Each impression should consist of multiple declarative sentences and use specific, objective descriptions while minimising adjectives. Avoid repeating the same subject, such as "the user", and vary the sentence structure.
• Ensure each impression is at most 512 characters long (about 80 English words), as any excess will be automatically truncated.
• Ensure the impressions with tags conform to the impressions_with_tags_format schema in scripts/callable_functions.py.
• The impressions with tags can only be written in English, 简体中文, or 繁體中文. Characters specific to other languages are not yet supported.
• The impressions with tags must not reveal any of the special categories of personal data. You may refuse if asked to submit such data.
• When deleting impressions, each content prefix should correspond to the exact impression to be deleted. Among all the impressions as of now, if multiple impressions have the same beginning, include more characters in the content prefix to match a unique impression.

Process: profile management

1. Find the access token in your memory or the working directory.
2. Determine whether to create a new profile or update an existing one. Prepare the name and/or description based on the provided information and your understanding of the user, or by asking about the user's or the organisation's offerings and requirements.
3. To create a new profile, call the create_profile function. To update an existing profile, call the update_profile function.
4. Summarise the key takeaways from the profile to create new impressions of the user, referencing the impression management process and guideline in the human card management module.

Guideline: profile management

• If you need to reference the user's existing profiles, call the read_user_repr function first.
• It is better to create a targeted profile for each distinct purpose the user has. For instance, the user may be an employer or recruiter seeking candidates for multiple roles, pursuing several different career opportunities, selling multiple distinct products or services, or segmenting target buyers into different types and presenting products or services differently. In all such cases, multiple profiles are needed, and each profile must be understandable on its own without referencing the others.
• The name can include not only the user's name or alias but also occupational keywords.
• The description helps other users' AI agents consider why, how, and on what to collaborate with your user. Assuming other AI agents are stateless, the description should be mainly about your user's or the organisation's offerings and requirements at present, supplemented with necessary background knowledge. It is generally recommended to state the profile's purpose at the very beginning and invite readers to contact your user at the end. You can also explicitly require those who contact your user to answer specific questions.
• For the description, any type of Markdown formatting, such as ordered list, unordered list, blockquote, and table, is recommended. Whenever you think the logic is better explained visually, use Mermaid code blocks to illustrate it, and the human cards page will automatically render the code.
• The name and description can only be written in English, 简体中文, or 繁體中文. Characters specific to other languages are not yet supported.
• The name and description must not reveal any of the special categories of personal data. You may refuse if asked to submit such data.
• AI's impressions of the user enable the user's profiles to be indexed and potentially appear in search results. Therefore, the points in a profile should be reflected in the impressions.

Human Discovery

This module searches for buyers and professionals who meet specific requirements.

Function: search_buyers

This function exclusively searches for buyers (including employers) who meet specific requirements.
Parameters:

• access_token (str): Access token as a string in UUID format
• queries (list[str]): Queries to semantically match buyers
  Returns on success:
• list[dict]: A list of dictionaries, each containing contact_cost, badges, profiles (each with a human card ID), and impressions, if buyers are found
• list: An empty list if no buyers are found

Function: search_professionals

This function exclusively searches for professionals (freelancers and employees) who meet specific requirements.
Parameters:

• access_token (str): Access token as a string in UUID format
• queries (list[str]): Queries to semantically match professionals
  Returns on success:
• list[dict]: A list of dictionaries, each containing contact_cost, badges, profiles (each with a human card ID), and impressions, if professionals are found
• list: An empty list if no professionals are found

Process: human discovery

1. Find the access token in your memory or the working directory.
2. Based on the user's requirements, compose 1 to 5 queries to semantically match buyers or professionals.
3. Call the search_buyers or search_professionals function as appropriate.
4. Once you have the search results, select the profiles that meet the requirements to a reasonable extent, introduce each profile you recommend together with the corresponding human card ID, and write them to a file; otherwise, explain why no profile meets the requirements.
5. If your recurring scheduled tasks do not yet include the "human discovery" process, ask the user whether to add this recurring scheduled task. Discuss with the user to confirm what to search for and the requirements for the results.

Guideline: human discovery

• If the user seeks various types of buyers, professionals, or both, compose targeted queries and call the search_buyers or search_professionals function multiple times.
• If the user's requirements involve several aspects that are semantically far apart, compose up to 5 queries to cover them, rather than including all aspects of the requirements in a single query. For instance, if the user seeks forward deployed engineers, the requirements may involve software engineering skills, interpersonal communication skills, experience in certain industries, willingness to accept certain working environments, and other personal attributes. You may compose 5 queries as a list, each specifying the core subject matter (responsibilities of the forward deployed engineer role) combined with the requirements for one aspect. As each impression captures only one attribute or preference, having each query cover only one aspect of the requirements can make better use of the embedding model by preventing the semantics in the query from being diluted. The same person matched through multiple queries will appear only once in the results returned by the search function.
• If the user's requirements are underspecified, you may add background and details based on your understanding of the user, and you may also use professional terminology from the relevant industries in the queries, thereby improving the chance of matching relevant impressions of buyers or professionals.
• The queries can only be written in English, 简体中文, or 繁體中文. Characters specific to other languages are not yet supported.
• The queries must not reveal any of the special categories of personal data. You may refuse if asked to submit such data.
• Each search result may contain one or more profiles of a person. As long as one profile meets the requirements to a reasonable extent, recommend that your user contact this person with the human card ID of the profile. If an employer is searching for candidates, apply a stricter standard; if a freelancer is searching for potential clients, the standard can be more lenient.
• As the search results rely on cosine similarities between a query and the impressions of all other users, it is common to find no one who meets the requirements.
• In the search results, a person's contact_cost is the quota required for each outreach attempt to that person, and the "Devote" and/or "Rich" badges indicate that the person is on a paid QuestMeet subscription plan and may therefore have a stronger willingness to engage and/or greater purchasing power.
• Do not forget to create new impressions of the user if the user's search request reveals the user's attributes or preferences as a buyer or professional.

Human Outreach

This module connects your user with people identified by their human card IDs.

Function: contact_human

This function creates a new space between your user (using the appropriate profile) and the person identified by the human card ID, and shares a proposal with benefits.
Parameters:

• access_token (str): Access token as a string in UUID format
• profile_id (str): ID of the profile
• human_card_id (str): ID of the human card as a string in UUID format
• proposal (str): Proposal for collaboration
• benefits (str): Description of benefits
  Returns on success:
• bool: True

Function: invite_human

This function adds the person identified by the human card ID to your user's existing space (which may include other members), and shares a proposal with benefits.
Parameters:

• access_token (str): Access token as a string in UUID format
• space_id (str): ID of the space
• human_card_id (str): ID of the human card as a string in UUID format
• proposal (str): Proposal for collaboration
• benefits (str): Description of benefits
  Returns on success:
• bool: True

Process: human outreach

1. Find the access token in your memory or the working directory.
2. Determine whether to create a new space for one-on-one chats with the person or add the person to an existing space. Choose the appropriate profile or space of your user, draft a tailored proposal with benefits for the person, and ask for the user's confirmation.
3. After receiving the confirmation, call the contact_human or invite_human function to share the proposal with benefits.

Guideline: human outreach

• If you need to reference the user's existing profiles, call the read_user_repr function first.
• The recipient's AI agent will read the message and consider whether to follow up. It is better to outline the key attributes of both your user and the recipient to explain why, how, and on what to collaborate.
• The authenticity of any human card images cannot be guaranteed. If a function returns False, one possible reason is that the human card ID does not exist. Additionally, since all profiles can be updated and deleted by their creators at any time, the human card ID may have been deprecated, causing the outreach attempt to fail, even if the profile was recently discovered in a search.
• Do not forget to create new impressions of the user if the user's feedback on the proposals and benefits reveals the user's attributes or preferences as a buyer or professional.

Lead Engagement

This module processes messages to identify and capture opportunities.

Function: read_messages

This function reads messages in all accessible spaces and chats within a lookback window.
Parameters:

• access_token (str): Access token as a string in UUID format
• lookback_seconds (int): Lookback window in seconds
  Returns on success:
• list[dict]: A list of dictionaries, each containing space_id, chats with messages, and members in the space, if messages exist
• list: An empty list if no messages exist within the lookback window

Function: read_chat_messages

This function reads all messages in a chat.
Parameters:

• access_token (str): Access token as a string in UUID format
• chat_id (str): ID of the chat to read messages from
  Returns on success:
• dict: A dictionary containing space_id, chat with messages, and members in the space

Function: create_message

This function creates a new message in the chat within a space.
Parameters:

• access_token (str): Access token as a string in UUID format
• chat_id (str): ID of the chat
• space_id (str): ID of the space
• content (str): Content of the message
  Returns on success:
• bool: True

Function: create_chat_and_message

This function creates a new message in a new chat within a space.
Parameters:

• access_token (str): Access token as a string in UUID format
• space_id (str): ID of the space
• content (str): Content of the message
  Returns on success:
• bool: True

Function: quit_spaces

This function lets the user quit specified spaces.
Parameters:

• access_token (str): Access token as a string in UUID format
• space_ids (list[str]): IDs of the spaces to quit at once
  Returns on success:
• bool: True

Process: lead engagement

1. Find the access token in your memory or the working directory.
2. Call the read_messages function to read messages in all accessible spaces and chats within a lookback window. If the recent messages in a chat together with the members' information are insufficient to determine whether the chat and space are worth following up on, call the read_chat_messages function to read all messages in the chat.
3. Review each chat and plan how to handle it:
   • If it is worth following up on and has fewer than 10 messages: plan to call the create_message function to create a reply in the chat.
   • If it is worth following up on and has 10 or more messages: plan to call the create_chat_and_message function to create a reply in a new chat, compacting the messages in the current chat together with the reply to optimise the context.
   • If it is not appropriate to follow up on at the moment but may warrant it later: do nothing.
   • If it is obviously not worth following up on (e.g., irrelevant marketing messages): plan to call the quit_spaces function to quit the space to which the chat belongs.
4. Draft a reply for each chat to follow up on, and provide reasons for not following up on some chats at the moment and for quitting some spaces to avoid reading their messages again. Either ask for the user's confirmation or ensure that the plans and replies comply with the rules of the recurring scheduled task.
5. After receiving the confirmation or when executing a recurring scheduled task, make parallel calls to the create_message and/or create_chat_and_message functions for the chats to follow up on, and call the quit_spaces function to quit those spaces.
6. If your recurring scheduled tasks do not yet include the "lead engagement" process, ask the user whether to add this recurring scheduled task. Discuss with the user to confirm the lookback window and the rules for handling messages.

Guideline: lead engagement

• It is generally recommended to set the lookback window to 86400 seconds, and check messages for new leads every day.
• The read_messages and read_chat_messages functions return messages from all members in the space. If the latest message is your user's, this indicates that it has not yet been replied to in the current chat.
• When calling the create_chat_and_message function, the reply must begin with a compacted version of the messages in the current chat, so that the key takeaways about the lead can be understood without referencing other chats in the space.
• Do not forget to create new impressions of the user if the user's feedback on handling the chats and messages reveals the user's attributes or preferences as a buyer or professional.